ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
wink_ has joined #zig
m3t4synt4ct1c has joined #zig
hoppetosse has quit [Ping timeout: 255 seconds]
dewf has joined #zig
m3t4synt4ct1c has quit [Ping timeout: 268 seconds]
<daurnimator> donpdonp: re: `@ptrCast(*c_void,0)` you probably wanted `@intToPtr(*c_void, 0)`
<daurnimator> though in your circumstance, `null` was more correct.
<daurnimator> note that in C, the 0 pointer/null is really... weird. NULL isn't always the 0 pointer; but 0 as a pointer is NULL.
<daurnimator> On platforms where 0 is a valid address to read/write from, things get weird
<daurnimator> zig has `allowzero` for such places.
<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
<tyler569> is how I'm introspecting it
<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> []u8 <- FixedBuffer <- Failing <- Arena I think ?
<tyler569> the Arena being inside the test
<hryx> Yep, that's the right order
<tyler569> added some annotations to the bein/enf of all of these allocation functions, I wonder if backtraces use Arenas a little bit XD :
<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
<hryx> wilsonk|2: ah, I was mistaking your question for this one:
<wilsonk|2> yeah, similar enough. I got it figured out. Thanks hryx
neceve has joined #zig
WilhelmVonWeiner has joined #zig
WilhelmVonWeiner has left #zig [#zig]
Barabas has joined #zig
slugm has quit [Ping timeout: 245 seconds]
slugm has joined #zig
wilsonk has joined #zig
wilsonk|2 has quit [Ping timeout: 258 seconds]
_whitelogger has joined #zig
halosghost has joined #zig
Barabas has quit [Ping timeout: 256 seconds]
forgot-password has joined #zig
<forgot-password> What's the best way to profile cache characteristics of Zig programs right now?
<daurnimator> forgot-password: as with any language..... perf
<companion_cube> for cache characteristics, maybe cachegrind?
<forgot-password> companion_cube: That's what I'm using, but I was wondering whether there are any better alternatives.
<daurnimator> forgot-password: perf uses your cpu's hardware counters. valgrind is essentially a passthrough-cpu emulator
<forgot-password> Not that I know anything about it, so I have no reason to not like it. As I said, I was just wondering ^^
<forgot-password> daurnimator: Thanks, I'll check it out :)
<forgot-password> I assume that's also the reason why cachegrind slows down the program by as much as it does, isn't it?
<daurnimator> yep
<daurnimator> forgot-password: run this: perf stat -M Load_Miss_Real_Latency echo this can be any program
<companion_cube> how can I have perf display cache misses, though?
<daurnimator> companion_cube: see `perf list` for all the different stats you can get.
<companion_cube> ohhhh nice
<companion_cube> I've only ever used `perf record` and `perf report` (with a bit of flamegraph ♥)
<daurnimator> companion_cube: you can use those too..
<daurnimator> (as in, when you `perf record`, pass -e and the hardware counters you want to sample too)
<companion_cube> neat.
<forgot-password> Do you know about antyhing that works well on MacOS? Since perf is not available there.
<bgiannan> was about to ask that
<forgot-password> bgiannan: I played around with Instruments, but I couldn't get anything useful out of it.
<forgot-password> Instruments being the default profiling tool
<daurnimator> on osx everything is hidden behind dtrace somewhere :P
<daurnimator> Instruments is probably just a wrapper around dtrace? :P
<forgot-password> Well it's rather a collection of different profiling tools that one in itself
<forgot-password> Or can you use dtrace to measure network I/O, etc?
<daurnimator> According to, try: dtrace -q -n 'cpc:::PAPI_l1_icm-user-5000/pid == $target/{@m = count();} END{printa("misses = %@d\n", @m);}' -c "echo hello world"
hoppetosse has joined #zig
<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 package manager works beautifully with zig, I'm happy to report
wilsonk has quit [Ping timeout: 255 seconds]
<donpdonp> bketelsen: oh thx for mentioning wapm. ive been looking for that
jevinskie has joined #zig
<companion_cube> interesting
jevinskie has quit [Client Quit]
<bketelsen> "universal"(ish) binaries? Game on.
neceve has quit [Remote host closed the connection]
<companion_cube> (otoh their website looks like shit on firefox)
ysgard has joined #zig
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ysgard> I'm trying to get Andrew's little SDL example to work, but it's failing on a puzzling build error
<ysgard> error: expected optional type, found '[*c].cimport:1:11.struct_SDL_RWops'
<ysgard> const rw = c.SDL_RWFromConstMem(
<ysgard> Not sure where the optional type is coming from
<ysgard> Checking up the SDL definition of the C function, it appears to take a const void* and int as args:
<ysgard> so the zig code seems sound
hoppetosse has quit [Ping timeout: 244 seconds]
gamester has joined #zig
<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:
<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?
<daurnimator> ysgard: zig translate-c
<ysgard> daurnimator: Thanks you :)
<ysgard> TheLemonMan: Maybe `std.mem.set(u8, &struct_var, 0);`
<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
<mikdusan> TheLemonMan:
<TheLemonMan> meh, stupid heisenbugs
very-mediocre has quit [Ping timeout: 256 seconds]
Ichorio has quit [Read error: Connection reset by peer]
Ichorio has joined #zig
gamester has quit [Quit: Leaving]
ysgard has quit [Ping timeout: 264 seconds]
slugm has quit [Remote host closed the connection]
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
Ichorio has quit [Ping timeout: 258 seconds]
wilsonk|2 has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
halosghost has quit [Quit: WeeChat 2.4]
jevinskie has joined #zig
jevinskie has quit [Client Quit]
Sahnvour has quit [Read error: Connection reset by peer]
jevinskie has joined #zig
jevinskie has quit [Client Quit]
ltriant has joined #zig