<hryx>
tyler569: I fixed the new bug on stage2-recursive-parser. It was dumb.
<hryx>
you'll still need to add a trivial test above the `allowzero` one to reproduce the memory leak. Actually maybe I should just commit that while this branch is in progress
<tyler569>
cool cool, thanks for letting me know!
<hryx>
fo sho! Also I just pushed the test thing, no need for a manual change now :>
<tyler569>
sweet
fengb_ has joined #zig
wilsonk|2 has joined #zig
noonien has quit [Quit: Connection closed for inactivity]
jevinskie has joined #zig
<hryx>
`zig version` on homebrew install prints "0.4.0+" -- I assume the dangling plus sign is unintentional?
<fengb_>
I think that's a bug. It's appended with a git sha for a nightly, but I think it should be missing on the release
<fengb_>
It's just "0.4.0" on the Linux release
<hryx>
would it be an issue with the zig repo or with the homebrew formula?
<tyler569>
anyone know why zig just uses (verion)-(hash) ? git describe gives you (version)-(commits since tag)-(hash), which I've always found more useful because you can immidiately see an ordering between builds
<tyler569>
for my project for example: `v0.3.15-2-ge74207c` is 2 commits after tag v0.3.15, and hash e742...
<tyler569>
(I could make a proposal, just seeing if anyone knows if there's motivation behind the way it's done)
<hryx>
hm, not sure
<fengb_>
So the official release build shows "0.4.0" under Mac
<fengb_>
So my guess is Homebrew... but we should probably verify by building the source bundle
_whitelogger has joined #zig
<hryx>
When would one want to use a bare union instead of a tagged union?
<dewf>
if you have the same data and want to be able to access it different ways depending on the need at the time
<dewf>
like maybe you'
<dewf>
er
<dewf>
like maybe you've got a 32-bit value but occasionally want to access individual bytes
<dewf>
without doing bit shifting and stuff
<dewf>
I think I saw something the other day where somebody was using that instead of casting, because (according to the comment) their compiler would complain when they tried a direct cast between the types
<daurnimator>
dewf: are you looking for @bitCast?
<dewf>
? I was responding to hryx
<daurnimator>
hryx: 1. compat with existing programs/libraries/formats. 2. to keep memory usage small (e.g. if you need to fit in a register/cache line/etc.)
<hryx>
ah, because the tag takes up more bits?
<hryx>
dewf: that's a useful trick in C, but isn't that an illegal use of unions in zig?
<tyler569>
looks like it's legal for packed and extern unions
<hryx>
surprise!
<hryx>
everyone has worked together to educate me. thanks~
<daurnimator>
hryx: yes. for certain patterns you may want to store the tag elsewhere. e.g. if you wanted to store a `[64]{ foo: T1, bar: T2 }` then you might want a single 64bit value containing all the types
<tyler569>
oop, maybe not! the doc implies it's legal but doing it in debug mode is an error
<tyler569>
huh
<tyler569>
actually, that's a compile error. impressive semantic analysis
<hryx>
I see tagged unions can be used in a switch statement (cool) -- can they also be used with `if`?
<hryx>
seems ok if not, just do a switch with one normal prong and one else. Just curious for convenience though
<tyler569>
what would be the test for though?
<tyler569>
the test be for *
<hryx>
oh sorry, the tag
<hryx>
To see which field is currently active
<tyler569>
oh you mean like if (union_whatever.this_field) {}
<tyler569>
that would be cool
<hryx>
yep, ^
<tyler569>
I'm finding some odd things with this allocator stuff btw
<hryx>
I'm on the edge of my seat tyler569 :O
<daurnimator>
tyler569: hryx: I don't think the would work well if `this_field` was an optional type
<tyler569>
like, it looks like that 4k is leaked on the first run too, nothing ever deallocates it there either
<hryx>
tyler569: does every test case in master parser_test.zig allocate > 4k?
<hryx>
not sure if that's related
<tyler569>
additionally, any sense why it's allocating 4k? the Node.Root type is ~100 bytes and everything seems to just want to grab "enough for the comptime T"
<tyler569>
not as far as I can tell, let me paste what I whipped up
<hryx>
Ah I was wondering about why 4k as well. I assumed it's one of those allocators that overallocates for a pool of things, but, now that you mention it that don't seen right
<tyler569>
the pool seems to be the 100M fixed buffer in parser_test.zig
<daurnimator>
tyler569: try out PR #2338 to find it :)
<tyler569>
that's wrapped in a fixedbbufferallocator, then an arenaalocator, then the failingallocator
<hryx>
daurnimator: yeah that actually might come in handy about now -- I was manually printing stuff in the allocator earlier
<hryx>
whoa
<hryx>
0->4096 and then 0->8 ?
<tyler569>
that's just the second allocation, but notice how it never frees the 4096 in the succesful run
<tyler569>
"size of node root" is the start of each run
<hryx>
huh. is it significant that it's at a different address from all the others?
<tyler569>
the 4096 is line 44 `arena.create(Node.Root)` incidenally
<tyler569>
I think it's just a different address because it was never freed, so everything after it is farther along
<tyler569>
then the second allocation is just expanded and shrunk inplace a few times
<hryx>
oh shoot hang on a sec. gonna try something based on what you just said
<tyler569>
and here's a random thought, isn't the point of fixedbuffer/arena allocators that they don't do anything on free, they just bump a pointer until you reset them? - how would arena.deinit() be able to mark the allocations freed in that case?
<tyler569>
(am checking, but wanted to muse first)
<hryx>
Nope, idea didn't work
<hryx>
if it's the first allocation that fails maybe we can just dump a trace in `reallocFn` to see who's calling it
<tyler569>
the 4k one?
<tyler569>
I did that, it's the allocate on line 44 or parse2, the create(Node.Root)
<tyler569>
of*
<hryx>
oh I see
<hryx>
I think one of the allocations isn't going through the FailingAllocator
<hryx>
maybe
<tyler569>
hmm
<tyler569>
everything I printed above is definitely, those are in realloc and shrink of FailingAllocator
<tyler569>
(the debug prints)
<hryx>
ah, I see
<tyler569>
I'm so confused by this tower of allocators though
<tyler569>
added some annotations to the bein/enf of all of these allocation functions, I wonder if backtraces use Arenas a little bit XD : https://i.imgur.com/2oqPYkZ.png
<tyler569>
(it just spams that for every line of the backtrace)
<hryx>
whoa haha
<tyler569>
interesting development, there are things that hit the Arena without hitting the FailingAllocator and things thet hit the FailingAllocator without hitting the Arena
<tyler569>
if I'm reading this right
<hryx>
ah yes, as for the second one: the failing allocator is used for more than just the parsing itself. in parser_test.zig you can see it used to render the reformatted source for comparison
<hryx>
but Arena without FailingAllocator, not sure about that one
<tyler569>
might just be noise because I can't differentiate what's hitting the function, but it's pretty consistent. Imma poke at it
<hryx>
dope. I might be a little too close to it to see anything right now, so I'm gonna clear my head by knocking out some TODOs and the come back to it later
<tyler569>
sounds good, I'll let you know if I find anything when I come up for air
ltriant has quit [Quit: leaving]
fengb_ has quit [Ping timeout: 256 seconds]
wink_ has quit [Remote host closed the connection]
dewf has quit [Quit: Leaving]
hio has quit [Quit: Connection closed for inactivity]
hio has joined #zig
<tyler569>
Test 2/121 parser_test.temporary trivial example...OK
<tyler569>
How's you like that
<tyler569>
How'd*
slugm has joined #zig
<hryx>
tyler569: WAT
<tyler569>
yeah I think I found it
<hryx>
amazing. I can't wait to see
<tyler569>
yup, just writing up a commit to send your way now
<tyler569>
kept seeing multiple different addresses for the Arena at .alloc() and .deinit() and then it clicked
<hryx>
you absolute legend
<hryx>
that incorrect TODO to remove the field was my mistake
<tyler569>
anytime! this was a really fun debug
<hryx>
Awesome! I am really really grateful, this will make the rest of the parser changes quicker & more fun too :>
<tyler569>
glad I could help
<tyler569>
def. excited for the zig parser in zig!
<hryx>
~ damn straight ~
<wilsonk|2>
how does a struct reference a field inside itself to initilaze another field? I thought I could use @This() to do that
<daurnimator>
wilsonk|2: reference how? (got an example?)
<wilsonk|2>
like using a field to initialize the value of a second field
<wilsonk|2>
so struct { .a = 5, .b = .a, };
<hryx>
I believe there is a GitHub issue related to that wilsonk|2
<daurnimator>
I think the main thing would be: const a = t; return mystruct { .a = a, .b = a }
<daurnimator>
usually you'd have a `mystruct.init(a: mytype)` that does such things for you
<wilsonk|2>
ok, I can cobble something like that together...just wasn't sure if there was an elegant way to reference a field inside the struct while initializing it
<forgot-password>
It complains about System Integrity Protection being enabled. But to disable that I'd have to boot into recovery mode.
<forgot-password>
Gotta get some work done anyways. Thank you daurnimator I'll try it out later today
forgot-password has quit [Quit: leaving]
very-mediocre has joined #zig
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wootehfoot has joined #zig
<donpdonp>
im including a .h that has typedef enum status_t { thing = 0xFFFFFFFF } and zig says error: integer value 4294967295 cannot be implicitly casted to type 'c_int'
<donpdonp>
is there a way to say enum values should be c_uint?
Ichorio has joined #zig
slugm has quit [Ping timeout: 244 seconds]
slugm has joined #zig
ysgard has joined #zig
TheLemonMan has joined #zig
<donpdonp>
i see that C is somewhat ambiguous around the type of enum members.
<donpdonp>
here's a different problem, curl.h import creates pub const CURLoption = extern enum { CURLOPT_URL = 10002 }, but when I try to call a c.method(c.CURLoption(c.CURLOPT_URL)) I get error: expected type '.cimport:8:11.CURLoption', found 'comptime_int'
<donpdonp>
it seems the compiler is being too smart and substituting a comptime_int, which is great, except the signature doesnt match anymore :(
<donpdonp>
ah found the way out, c.CURLoption.CURLOPT_URL works. (I'm updating zig 0.3 code)
ysgard has quit [Ping timeout: 252 seconds]
<TheLemonMan>
andrewrk, why doesn't @shlWithOverflow return an optional type?
companion_cube has quit [Remote host closed the connection]
meheleventyone has joined #zig
companion_cube has joined #zig
<bketelsen>
the new wapm.io package manager works beautifully with zig, I'm happy to report
<emekankurumeh[m]>
i couldn't get the code in the repo to work so i had to remove all the optional pointers then it would compile
<gamester>
ysgard: If I were to guess, when the code was written cimport translated the C header file to make SDL_RWFromConstMem return an optional pointer, but after C pointer types were added ([*c]) cimport now makes SDL_RWFromConstMem return a c pointer. The "orelse" code expects an optional type, but that does not currently work with c pointers: https://github.com/ziglang/zig/issues/1967
<gamester>
So instead of orelse, check if SDL_RWFromConstMem returns 0
<ysgard>
Ah, I see - so between 0.3 and 0.4 there was a change in how C headers get imported
<ysgard>
gamester: Thank you!
<emekankurumeh[m]>
though that's going to change soon
<ysgard>
I'm very new to Zig - is there a way to see how Zig interprets a C header file?
<TheLemonMan>
hmm, is there a way to declare a struct and zero-fill it?
<ysgard>
Though I'm not sure how mem.set knows the size of the memory to set
<tgschultz>
mem.set expects a slice: std.mem.set(u8, std.mem.asBytes(&thing), 0);
<emekankurumeh[m]>
you can pass --verbose-cimport to zig
<gamester>
ysgard: cimport leaves a file somewhere in zig-cache called cimport.zig
<tgschultz>
there's also mem.secureZero(T, []T);
<ysgard>
Thanks again gamester and emekankurumeh!
Sahnvour has joined #zig
<TheLemonMan>
hmm, is any of you using osx?
<mikdusan>
yup
<TheLemonMan>
cool, I'd love an hand in understanding why #2318 fails only on osx with an obscure error message
<mikdusan>
running zig build test; or i could run the individual test but not sure how to exactly duplicate `macosx-x86_64-Debug-bare` for the failing test
<mikdusan>
if i just run the test native, it passes: `zig --override-std-dir . test event.zig`
<TheLemonMan>
I guess that's it and the test's not crashing, nice