<andrewrk>
it's not incredibly contributor friendly yet, but starting to get there. I think once I work through the compile errors it will start to make sense how people could jump in
<andrewrk>
zir.zig is done. Sema.zig is mostly done. Module.zig is mostly done. astgen.zig is nearly untouched.
<andrewrk>
next problem to solve is resolving LazySrcLoc during ZIR=>TZIR phase because (for now) TZIR wants byte offsets only.
waleee-cl has quit [Quit: Connection closed for inactivity]
cole-h has quit [Ping timeout: 264 seconds]
sundbp has quit [Ping timeout: 245 seconds]
riba has joined #zig
yyp has joined #zig
<mikdusan>
til about rclone. wow.
forgot-password has joined #zig
gpanders has joined #zig
<ifreund>
andrewrk: nice, I look forward to digging in :)
<mikdusan>
if I disable BYPRODUCTS then cmake proceeds to build
<mikdusan>
err then ninja can build
<mikdusan>
can't put my finger on it exactly but this might be introducing a race condition in make. I had weird out-of-dep-order building happening but didn't narrow it down and resorted to -j1 (make)
jumpnbrownweasel has quit [Ping timeout: 240 seconds]
halbeno_ has quit [Remote host closed the connection]
halbeno has joined #zig
<dutchie>
huh, there's no btreemap in zig std. i'm implementing one for a little fun side project, would it be worth me tidying it up and submitting it?
<cepheus>
working inasmuch that it passes the pre-existing tests and i've validated it against serialized data written with data structures serialized from zig 0.7, anyway
forgot-password has quit [Ping timeout: 264 seconds]
forgot-password has joined #zig
forgot-password has quit [Quit: leaving]
<Cadey>
does zig work if you compile it to wasi?
fireglow has quit [Quit: Gnothi seauton; Veritas vos liberabit]
<ifreund>
and yeah you want it to panic, that's how you trigger test failure
<aconbere>
I mean I get I want a test failure :)
<aconbere>
this is just surprisingly unhelpful test output
<aconbere>
that's what surprised me
<ifreund>
expectEqualSlices() will give you better test output
<aconbere>
I would typically expect a fairly verbose statement of what had failed, what was different, the stack trace to be local to the test that failed etc.
<g-w1>
i get a nice backtrace
<ifreund>
this is what you get if you use the proper test function
<aconbere>
g-w1: my stack is full of stuff in the std library
<aconbere>
like it takes me to where the failure was, but it's not telling me a lot about how my program isn't working :)
<g-w1>
ah, makes sense :)
<ifreund>
that's exactly what testing.expect() does. It's an opaque bool to the std code
<ifreund>
the std can't know that you are passing the result of mem.eql() on two slices
<aconbere>
so I mean, my example there was just a small reproduction
<ifreund>
instead using testing.expectEqualSlice() which IS then aware you are comparing slices and can print a nice message
<aconbere>
in reality what's happening is that the function I was calling was returnning an error
<yyp>
I wouldn't say that expectEqualSlice is that nice
<aconbere>
ooo maybe not
<aconbere>
maybe it's just a different enum value
<aconbere>
but I couldn't tell haha
<aconbere>
I think I probably want expectEqual
<aconbere>
I've just been plodding along from what I read in the std library and ziglearn
<ifreund>
yyp: I said can not does to be fair :P
<ifreund>
as you can see there is a TODO in the function
<ifreund>
expectEqualStrings is actually nice
<yyp>
Let me check that
<ifreund>
aconbere: totally fair, the std is certainly not well documented yet, nor is that the top priority
<aconbere>
yeah expectEqual is way better
<yyp>
Yep, that's really nice
<aconbere>
it's cool! That's why I asked
sundbp has quit [Ping timeout: 264 seconds]
<aconbere>
Maybe just to ... reply my mental model because I think it might shed some light on how expect could be better
<aconbere>
I expected panics to be... unusual rather exceptional even
<aconbere>
my initial concern was that my function was panicing in some way
<aconbere>
I'm messing with this peekStream and readers in ways that I'm unfamiliar with
<aconbere>
I looked into wether my reader was being passed in incorrectly and getting the wrong anytype
<aconbere>
and poking into the wrong memory
<aconbere>
I was worried that my [0..1] slice was creating some sort of weird memory
<aconbere>
or an invalid call in some way
<aconbere>
so the hard part for me was differentiating the panic behavior of `testing.expect` from the potential panic'ing of my own software
<aconbere>
:)
<ifreund>
the panic message of "test failure" should make that clear...
<aconbere>
haha
<ifreund>
but I guess that's probably only obvious to someone already familiar with how this stuff is set up
<aconbere>
I couldn't tell if the test suite was catching the panic
<vent>
I'm trying to pass a slice from std.os.argv into std.mem.joinZ, but I'm getting a type error. The compiler claims "slice type child '[*:0]u8' cannot cast into slice type child '[]const u8'". It is possible to cast a var into a const, right?
<aconbere>
and being like "yo, your code panic'd thus failure"
<ifreund>
vent: indeed, but a [*:0]u8 is a null terminated pointer not a slice.
<ikskuh>
vent: [*:0]u8 is not a slice type but a pointer to many
<ifreund>
you can iterate and find the length with std.mem.span()
<ikskuh>
you can use std.mem.spanZ() to obtain a nul-terminated slice
<aconbere>
ifreund: I don't think this is horrible, but I think it's useful to hear from neophytes just so we walk about the experience :)
<aconbere>
s/walk/talk
<ifreund>
ikskuh: don't use spanZ() here, you don't need it
<ikskuh>
it removes less information from the type though
<ifreund>
that's only necessary if you have e.g. an array with 0s somewhere in the middle
<ifreund>
ikskuh: std.mem.span() should return a [:0]u8
ur5us has joined #zig
<ifreund>
does it not?
<ikskuh>
not sure
<ifreund>
the doc comment says it does...
<ikskuh>
yeah true
<ifreund>
the code looks like it should work too, but I'm to lazy to test it
fireglow has quit [Quit: Gnothi seauton; Veritas vos liberabit]
<ifreund>
ikskuh: span and spanZ have the exact same return type...
<ikskuh>
ah well :D
* ikskuh
stupid
<ifreund>
Oh I was definitely guilty of using spanZ() without need for a while until I looked more closely :D
<ikskuh>
well
<ikskuh>
spanZ will guarantee you the shortest span :D
<ikskuh>
i think it's actually better to use spanZ by default
<ikskuh>
as you get the "expected" result when working with sentinelled data types
<ifreund>
I disagree, passing a [:0] to spanZ() wastes cycles
<ifreund>
you only need to do spanZ() when you have a [N:0]u8 that has early sentinels
<ifreund>
I guess [:0]u8 could have early sentinels as well, but it generally doesn't
<vent>
So, I'm still a bit lost, I need to iterate through each of the args that I want to pass to joinZ, right? Should I be passing each through span and storing that slice in a seperate array, then pass that array to joinZ?
<ifreund>
if you have a fixed number of args you could do mem.joinZ(ally, ",", &[_][]const u8{mem.span(os.argv[1]), mem.span(os.argv[2])})
<vent>
That seems good, but I don't have a fixed number of args.
<vent>
A maximum limit on the args is okay though
<ifreund>
then yeah just collect the slices returned by mem.span() in a [42][]const u8 before colling joinZ()
<vent>
Okay, I think I'm getting closer. joinZ is now complaining that it expected a []const []const u8 but found a [256][]const u8
<ifreund>
you're just one & away, pass joinZ a pointer to the array instead
<ifreund>
(which will coerce to the expected slice of slices)
<vent>
Ah, yeah that's done it. But it looks like I'm getting an integer overflow in joinZ: http://ix.io/2T6g
<ifreund>
vent: the problem is that joinZ is trying to join the whole array, while not all of the 42 items are defined
<ifreund>
you want to pass args[0..argv.len - 1] to joinZ
<vent>
Nice! Yep, that worked!
<ifreund>
:)
<vent>
Thanks for helping me out, appreciate it
<ifreund>
no problem! one other thing you probably want to do for robustness is add a check if there are more args than fit in your buffer of length 42
<ifreund>
you could also just allocate a buffer of the correct size using your fixed buffer allocator
sundbp has joined #zig
<andrewrk>
mikdusan, thanks will do
<vent>
Yeah, I've changed the buffer to 256 bytes. AFAIK 255 bytes is the limit for file paths on most filesystems. Although it looks like exFAT's limit is 255 UTF-16 characters, so I think I'll make it 512 bytes.
<andrewrk>
vent, we have std.fs.MAX_PATH_BYTES
<vent>
andrewrk: Ah awesome, using that now. Thanks.
<ifreund>
vent: that's not the same as the max number of args
<andrewrk>
ah my bad I did not read any context
<ifreund>
I don't think there is a maximum there, just a cap on the total amount of memory argv can take
<ifreund>
see the execve(2) man page for some info
<mikdusan>
andrewrk: I'm working on a new ci job for macos-arm64. what do you think, should we switch to ninja?
powerofzero has joined #zig
<yyp>
`var arr: [10]u8 = undefined;` makes an empty array of 10 u8s, right? Or will it crash once I try to use something?
<ifreund>
yyp: using a undefined value is illegal behavior
<yyp>
-.-
<ifreund>
s/using/branching on/ to be more precise
<yyp>
how do I create an empty array then?
<ifreund>
define empty?
<g-w1>
wdym empty?
<ifreund>
if you want a array full of 0s: var arr = [1]u8{0} ** 10;
<yyp>
Yeah, that was it, thanks!
<andrewrk>
mikdusan, ninja might save a few minutes of time - go for it!
<andrewrk>
yyp, if you are passing to a parameter (or other context where you have a type to coerce to) you can use this form: &.{}
<yyp>
I was just wondering how FixedBufferAllocator works when you give buffer of undefined
<andrewrk>
undefined bytes, or undefined pointer?
<dutchie>
is &.{} now considered more idiomatic than &[_]T{}?
<dutchie>
i gues it's a few chars shorter
<yyp>
andrewrk: undefined pointer
<andrewrk>
dutchie, it can be convenient to omit the type
<g-w1>
yyp: then you get ub :)
<yyp>
but it did work
<dutchie>
andrewrk: true
<g-w1>
wdym undefined ptr? that should segfault
<yyp>
nevermind, I didn't actually use FBA
<yyp>
Hm, passing &buf (buf = undefined) to Reader.readUntilDelimiterOrEof worked fine
<yyp>
I honestly have no idea why
<g-w1>
what is type of buf?
<yyp>
[512]u8
<g-w1>
it seems like the *value* is undefined which is fine
<dutchie>
that's expected, the reader will do the equivalent of `buf[0] = thing i just read` so you never get back undefined
<g-w1>
yeah the pointer is not undefined; the value is
<yyp>
Okay, got it
<yyp>
I still don't get why it could index into undefined
<g-w1>
its not indexing into undefined
<dutchie>
indexing is basically just pointer arithmetic, like in c
<g-w1>
the pointer is totally defined; it is the addr of buf
<andrewrk>
yyp, how do you know it worked fine?
<yyp>
Looks like I don't understand Zig's undefined yet
<yyp>
andrewrk: it read the text
<aconbere>
hmmm
<yyp>
nevermind, I passed undefined VALUE not a pointer
<andrewrk>
I think we need to see some code to understand what's happening :)
<g-w1>
undefined in zig is the same as `var buf: [512]u8;` in c
<aconbere>
my peekstream does not appear to be peeking
<yyp>
Problem solved: that was just me not understanding Zig yet
<g-w1>
andrewrk: what is happening is they are writing into a buf that is undefined which is perfectly fine. the type of the buf is [512]u8. the ptr is not undefined, the buf is.
<cepheus>
if a pointer is undefined, then dereferencing it is undefined
<cepheus>
if a pointer is to an undefined value, dereferencing it is fine
<ifreund>
nope, only branching on the undefined value is illegal
<ifreund>
s/nope,// I didn't read well enough
<mikdusan>
hmm I added a build-artifact to azure pipeline. Is there a download button somewhere?:
<ed_t>
gen is function which I have in a struct (so @field can be used to find it)
cole-h_ has joined #zig
<oats>
so you want to make a number processing language of some kind?
<andrewrk>
step 1: tokenize, step 2: Abstract Syntax Tree
<ed_t>
its sig looks like: fn gen(self:*Stage, limit:usize) callconv(.Async) !void
<ed_t>
I've figured out how to create tuples with the function and args. now I need to go from the string 100 to the value. Also instead of 100 there could be a variable.
<ed_t>
I am not sure how to get these values into the tupples
<ed_t>
btw this uses async on each of the stages (gen, exactdiv, fanin etc)
<ed_t>
it provides a easy para-dyne for using async
cole-h has quit [*.net *.split]
g-w1 has quit [*.net *.split]
dimenus has quit [*.net *.split]
knebulae has quit [*.net *.split]
<ed_t>
and it gets even more fun. In that there maybe many pipes in a program, also a stage like (gen) may also contain a pipe which can be connected in various ways to the parent pipe.
jicksaw has quit [Ping timeout: 246 seconds]
<ed_t>
zig's async fits pipes very well and the low level stuff (eg running the pipe etc is 'easy'). Its how to handle the the pipes and there args which is giving me headakes (std.meta.Tuple and ...ArgsTuple are handy_
jicksaw has joined #zig
<ed_t>
I find it quite confusing to understand exact what zig is doing at comptime vs runtime (simple in concept, hard in understanding)
powerofzero has quit [Ping timeout: 244 seconds]
Akuli has quit [Quit: Leaving]
<ed_t>
oats I want to adapt "CMS Pipelines" to zig. It cannot be an exact mapping but should be close enough to be quite useful.
<oats>
well, I might be missing some details here, but have you ever written an interpreter? I wonder if following the traditional parser -> AST -> tree-walking interpreter paradigm might be simpler
<oats>
why do you want to use async things?
<oats>
do you need to be able to programmatically put together "pipelines" at runtime?
<ed_t>
its how to get from astage(arg1,arg2...) and end up doing something like tuple[index of astage][1][1]=arg1, [astage}[1][2]=arg2 (currently [astage][0] is the stage function, and [astage][1][0]=is a pointer to a stage structure.
<ed_t>
oats google cms pipelines
<ed_t>
to implement that you need to use async (or threads, but async fits better)
<oats>
sorry, I'm having trouble following what you're trying to do then :(
<oats>
maybe someone else will have something useful
<ed_t>
in the example above gen output numbers from 0 to 100, each number is passed to exactdiv, if it divides exactly its passes to fanin and then to console, if it does not exactly divide it gets passed to the second exactdiv which ignores anything that does not divide by 9 and passes the numbers that divided exact to the fanin stage.
<ed_t>
(think directed graph)
<ed_t>
the idea is to make the item passed anytype, so you could do things like, read a file, sort the lines, apply filters, and write the results back to a file or arraylist etc
<ed_t>
oats been around quite a while (my first computer had all of 2K of ram to put it in perspective). My knowledge is more practical than anything else, I've used more languages that most (from machine code, assemblers, things like forth, to many different high level compilers and interpreters).
<ed_t>
my goal here is to get pipelines so they can be used as a zig utility with a library of builtin stages and the ability to easily add your own stages.