ChanServ changed the topic of #zig to: zig programming language | https://ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<andrewrk> what, how did allowzero get into std.hash.murmur?
<andrewrk> somebody (me) didn't review this code carefully
<mikdusan> ah right. that's not a c-interop layer. that's zig userland
<mikdusan> *std
<andrewrk> this main loop of murmur hash looks like it should be rewritten with simd
<andrewrk> also IMO the API should accept aligned slices
ave_ has quit [Quit: Connection closed for inactivity]
<andrewrk> wow mikdusan it was a 1 liner that fixed all the rest
<mikdusan> nice.
<mikdusan> oh yeah I can see how that 1 liner has a huge effect
benjif has joined #zig
ur5us has joined #zig
_Vi has quit [Ping timeout: 272 seconds]
jmiven has quit [Quit: bye]
jmiven has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
<andrewrk> ir-clean-up-vars branch takes std lib tests from 3.378 GiB (4.59 GiB peak with time -v) down to 3.19 GiB (4.52 GiB peak with time -v)
jicksaw has quit [Ping timeout: 265 seconds]
<andrewrk> we can narrow the gap between the measured-with-profiler and actual peak usage by freeing IrInstGen instructions after rendering them to LLVM, before calling emit module
<daurnimator> What is your non-peak number there?
<mikdusan> daurnimator: zig src/ C++ manual heap alloc/free counting/statistics. ie: doesn't include LLVM heap usage
<andrewrk> peak is the real thing. the other thing is to help figure out what would be useful to work on
<andrewrk> GenConst: 10342808 items, 64 bytes each, total 631.275 MiB
<andrewrk> pretty sure none of these are referenced after each ir analysis
<andrewrk> would be worthwhile to track down what these are:
<andrewrk> Unknown_64: 2968513 items, 64 bytes each, total 181.184 MiB
<andrewrk> Unknown_40: 3180098 items, 40 bytes each, total 121.311 MiB
<daurnimator> 40 byte allocations... wat
<andrewrk> (they're "unknown" when the allocate<Foo>(...) calls don't have the string annotation)
<daurnimator> shachaf: any more thoughts around implementing b+trees in zig?
<mikdusan> also there's some alignment padding we don't account for. not terribly important just sayin'
<shachaf> daurnimator: Is it clear what the API for this sort of thing should be?
<shachaf> I could port my C code but right now it's just for u64 keys/values. It has a cursor API for iteration but it's a little ad-hoc, I'll probably work on that.
<daurnimator> shachaf: any data structure like that should be parametized by Type
<daurnimator> shachaf: similar to ArrayList or HashMap
<shachaf> Sure, but it requires a little more thought how to do this for for more complex types.
<mikdusan> Unknown_8: 37022601 items, 8 bytes each, total 282.460 MiB actually occupies twice that. if we found those and fwd'd them to a slab or arena allocator (that isn't even deinit'd) we'd get back 282 MiB
<andrewrk> that's all pointers though, probably not a single type
<andrewrk> every un-annotated T* is Unknown_8
jicksaw has joined #zig
<mikdusan> but they're still malloc'd which on x86_64 does 16-byte allocations?
<daurnimator> mikdusan: I'd be more concerned about overhead of allocation metadata
<andrewrk> I do think there are several uses for an slab/arena allocator in stage1
<andrewrk> oh I see what you're saying though
<andrewrk> simply avoid overhead of unfreed things
<daurnimator> shachaf: does it?
<andrewrk> something that's kind of fun... once self-hosted is what we ship, and stage1 can be simplified to only be required to build self-hosted, we can make memory allocation decisions that are optimized for that use case
<mikdusan> profile it and ship it :)
<andrewrk> e.g. if we know that all of self-hosted source .zig files adds up to 9 MiB, then the memory allocation strategy is to allocate 9 MiB slab, and that's where source code goes
<mikdusan> makes perfect sense. stage1 literally has 1 use case to tune for
<daurnimator> five 2MB huge pages. done. :P
<daurnimator> or I guess you can just have a huge buffer on the stack and allocate out of that
<mikdusan> on macos re some malloc options: MallocScribble: "0x55 is written upon free and 0xaa is written on allocation"
<mikdusan> there might be value for zig to write a different value than 0xaa to free'd areas?
<andrewrk> there's value in having 0xaa be the bit pattern of `undefined` - we can use it for runtime safety to detect whether things are undefined
<andrewrk> it would be a bit weird to introduce 2 different kinds of undefined states
<daurnimator> mikdusan: sounds like it's already a perfect match
<mikdusan> yeah I can see benefits of single undef value
<daurnimator> mikdusan: mem-belongs-to-OS (segfault) -> malloc (0xaa) -> zig sets to undefined (0xaa) -> zig uses -> zig sets to undefined (0xaa) -> free (0x55) -> back to OS (segfault)
<mikdusan> true. the option is still there isn't it
<andrewrk> sometimes might have stronger detection of undefined, where 0x55 would also register as undefined
<andrewrk> *some types
<andrewrk> e.g. there can be a "not undefined" canary value
<andrewrk> and 0xaa would clobber that
<andrewrk> so would 0x55
<andrewrk> it felt like a long dark tunnel this morning, but I think I may actually be able to merge #4152 today
<andrewrk> that's a good sign that this actually has paid off some tech debt
<shachaf> daurnimator: For example the tree stores multiple copies of keys at different levels, which I guess is probably fine.
<shachaf> Depending on implementation it might store keys that have been deleted (though I don't do that right now).
<shachaf> And you might want to minimize comparisons if comparison is expensive, etc.
<daurnimator> shachaf: those first points don't matter; and the last one sounds like an optimization we could provide tuning options for in the future: not worry about it for a first implementation
dddddd has quit [Remote host closed the connection]
<shachaf> I mean, if you have a tree of strings, and you delete a string from a tree, and free the string's memory, you probably don't want it to stick around as a key?
<shachaf> Maybe that's not an expected use case, I don't know.
<daurnimator> how would it stick around as a key?
<shachaf> Keys that aren't used in the leaves might still be valid separators in internal nodes.
<shachaf> I mean, maybe that doesn't matter.
<daurnimator> to me it sounds like it doesn't matter...
mooch2 has joined #zig
adamkowalski has joined #zig
<andrewrk> alright I'm giving up on #4152 for today but hopefully will be able to merge tomorrow
<andrewrk> it's quite close
<shachaf> I should probably finish making my C library nicer before thinking about porting it, really.
<fengb> Nah, ditch C already >_>
<shachaf> Can you easily do something like C's struct Header { ... }; struct A { Header hdr; ... }; struct B { Header hdr; ... }; union AorB { Header hdr; A a; B b; };?
<shachaf> (Where you're not always allocating A and B through a union, I guess I should add.)
<fengb> Yeah you can use a packed union or extern union to share the data bits
<shachaf> I don't particularly want these to be packed, just to share the header. I guess I can pad them manually.
<fengb> They both mean well-defined memory layout. Sounds like extern union would be good since it emulates the C ABI
<wilsonk> anybody know of a good terminal app/debugger that highlights the line of C and shows the dissassembly beside it? I thought someone here recommended one a few weeks back
<wilsonk> I think I even installed it but now I can't remember what the name of it was...duh...
<wilsonk> maybe it was mentioned as an alternative to remedyBG?
<mikdusan> wilsonk: this one? https://github.com/cyrus-and/gdb-dashboard
<wilsonk> yep, that was it! Thanks :)
<wilsonk> I mean I could use Ghidra or something but this is so much more lightweight
<companion_cube> (the `var i = 0; while …` pattern is a bit of a wart though)
<fengb> `zig/lib/std/sort.zig:942:26: error: evaluation exceeded 1000 backwards branches`
<fengb> I think sorting at comptime is breaking the compiler :P
salotz has joined #zig
<fengb> Actually I’m a little surprised since there’s only 30 elements. I hope this can scale to at least 200
<companion_cube> you can change the limit though, can't you? :)
<fengb> Yeah but I didn’t expect it to hit the limit at 30. Curious what’s going on
<shachaf> Is std/sort.zig actually a good algorithm in practice?
<shachaf> It has a bunch of nice theoretical properties but it seems really complicated.
<fengb> I’m less than the minimum threshold so it’s just an insertion sort
<fengb> Or it should be...
<companion_cube> it's probably super fast at runtime
<companion_cube> but too complicated for comptime? :)
<fengb> I’ll replace it with bubble sort
<companion_cube> boggosort
<shachaf> Is it actually fast at runtime?
<fengb> I remember benchmarking std.sort and it’s about as fast as regular mergesort so it’s not bad
lunamn has quit [Ping timeout: 265 seconds]
<shachaf> https://github.com/ziglang/zig/issues/657 says it used to be quicksort but it was replaced because of linear stack space?
<fengb> Yeah, prevents blowing out the stack
<shachaf> But making quicksort use logarithmic stack space is a 2-line change.
<fengb> Wiki sort is constant stack
<fengb> So it’s impossible to overflow
<shachaf> (Just use the stack for the smaller half and then loop for the bigger half.)
lunamn has joined #zig
<shachaf> Anyway I should learn how this block sort works probably.
<companion_cube> anyway it's not like it's urgent
<fengb> It’s a fancy in place sort
<companion_cube> someone will rewrite it into timsort by 1.0, I'm sure
<fengb> In place merge sort
<andrewrk> shachaf, if you want less code and less theoretical properties use std.sort.insertionSort
<andrewrk> it's real simple
<shachaf> Fair enough! Or just write your own insertion sort.
<andrewrk> 9 lines
<shachaf> Yep.
marmotini_ has joined #zig
<fengb> "The memory.grow instruction grows memory by a given delta and returns the previous size, or −1 if enough memory cannot be allocated." ... why is the spec so vague
<andrewrk> maybe the wasm spec is less vague
<fengb> That's wasm spec from W3c. I have no idea how to return pages above u31 because the return value is i32
<fengb> I guess I'll just ignore it!
mooch2 has quit [Ping timeout: 248 seconds]
<shachaf> wasm only supports 32-bit pointers as far as I know.
marmotini_ has quit [Remote host closed the connection]
<fengb> Oh right
<fengb> I'm doing bad math
<fengb> Ignore me!
<companion_cube> on the one hand, that's sad; on the other hand, do I really want one browser tab to get 4GB of ram…
<fengb> wasm64 is a spec of sorts
benjif has quit [Quit: Leaving]
<daurnimator> companion_cube: yeah I've had tabs use more than that already
marmotini_ has joined #zig
marmotini_ has quit [Ping timeout: 272 seconds]
nyberg has quit [Quit: Ping timeout (120 seconds)]
ltriant has quit [Quit: leaving]
adamkowalski has quit [Remote host closed the connection]
qazo has joined #zig
wilsonk has quit [Ping timeout: 268 seconds]
wilsonk has joined #zig
return0e has joined #zig
_Vi has joined #zig
_Vi has quit [Ping timeout: 272 seconds]
nyberg has joined #zig
novaskell has joined #zig
Snetry has quit [Ping timeout: 265 seconds]
Snetry has joined #zig
lqd has quit []
lqd has joined #zig
return0e has quit [Remote host closed the connection]
dddddd has joined #zig
<betawaffle> is there a way to dump out the zig code generated by a @cImport?
return0e has joined #zig
return0e has quit [Ping timeout: 268 seconds]
BaroqueLarouche has joined #zig
<daurnimator> betawaffle: 1. use `zig translate-c` 2. look in zig-cache
_Vi has joined #zig
<gonz_> betawaffle: If you build/compile with `--verbose-cimport` you'll get a printout of the path to the generated zig file.
<betawaffle> ok, thanks
euantor has quit []
euantor has joined #zig
<betawaffle> is it safe to use an `extern enum(T)` as the type for an argument to an extern function that normally accepts `T` as an argument?
<daurnimator> betawaffle: yes.... as long as you know that T will only be the values in the enum; or the enum is non-exhaustive
<betawaffle> the enum is non-exhaustive, in this case
<betawaffle> ok, same question, but with a packed struct of the same size and alignment as T?
cbarrett has quit []
cbarrett has joined #zig
alexpana has joined #zig
<daurnimator> yes
Snetry has quit [Ping timeout: 268 seconds]
odc has quit []
odc has joined #zig
frmdstryr has quit [Ping timeout: 272 seconds]
zfoo_ has joined #zig
zfoo_ has quit [Read error: Connection reset by peer]
neceve has joined #zig
nofmal has joined #zig
<nofmal> hello, is it possible to list all error values that a function returns?
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen1 has joined #zig
<mq32> nofmal: yes, you can inspect the return value via comptime/reflection/std.meta
<nofmal> mq32: which function in std.meta?
dingenskirchen1 is now known as dingenskirchen
<mq32> good question, do you know the online docs?
<nofmal> of course
<mq32> i would search there, maybe you find something useful
<mq32> i don't know the exact naem
<mq32> (or if such function actually already exists)
<nofmal> i see, thought you were trying to walk me through the docs lol
<fengb> I don’t think it exists. Was hunting last night
<fengb> Not a convenient function I mean
<daurnimator> Can anyone think of a nicer way to write: http://sprunge.us/j7V0di
<daurnimator> I wanted to write `catch continue;`
<daurnimator> (and get rid of the `found` variable)
<mq32> daurnimator: catch null?
<daurnimator> mq32: nope, the function returns a `!T` (where T can be ?something)
<fengb> How about if (parseInternal) |t| { return stuff} else |err| {}
<daurnimator> uh; is that valid?
<daurnimator> yes
<daurnimator> I was missing a {
maerwald has quit [Quit: gone]
<daurnimator> thanks fengb, http://sprunge.us/1YcVgf is much tidier
<fengb> nofmal: the raw data is available at `@typeInfo(return_type).ErrorUnion`: https://github.com/fengb/korwerdna/blob/master/src/op.zig#L19
<nofmal> fengb: thanks, let me try that
alexpana has quit [Ping timeout: 252 seconds]
<daurnimator> fuck yeah; autojson now supports tagged unions
<daurnimator> I'm amazed this actually works
<mq32> \o/
<mq32> nice!
<mq32> in both serialising and deserialising?
<daurnimator> yup
<fengb> Oh the later incantation has a more obvious usecase: https://github.com/fengb/korwerdna/blob/master/src/op.zig#L146
alexpana has joined #zig
bheads has quit [Quit: bheads]
bheads has joined #zig
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
waleee-cl has joined #zig
<daurnimator> I swear we had a CountingAllocator
<mq32> daurnimator, LoggingAllocator?
<daurnimator> na I want to call myfree() and test that it called the saved allocator X times
<daurnimator> I can do it with failingAllocator....
<andrewrk> fengb, I always read words backwards to see if they spell anything
<fengb> Well damn, I was hoping to upload the beard later
<andrewrk> hahaha
<Snektron> nice
<andrewrk> I made the beard photo for this conversation with my dad: https://imgur.com/NJu772p.png
<Snektron> if zig doesn't work out you can always go into the photoshop business
BaroqueLarouche has joined #zig
<daurnimator> andrewrk: petition to reopen https://github.com/ziglang/zig/issues/4166#issuecomment-578579541 ?
<andrewrk> thanks now I understand
<daurnimator> andrewrk: looks like PRs can't be reopened? https://github.com/ziglang/zig/pull/3155
<daurnimator> that same branch is now a candidate for merge again
<daurnimator> I guess I have to open a new PR?
nofmal has quit [Remote host closed the connection]
<andrewrk> I don't have a re-open button either
<daurnimator> Replacement pr sent. (#4304).
<betawaffle> is the byte-boundary thing still an issue for packed struct bit fields?
<daurnimator> time to head to bed
<fengb> Is the correct way to declare a named tuple to use `@"0", @"1"` ?
<daurnimator> fengb: not sure I've considered that before.... `const foo = @TypeOf(.{@as(T, undefined), @as(T2, undefined)});`
<daurnimator> I get the feeling that sort of code may end in compiler segfaults :P
<Snektron> this gives me std::declval vibes
<Snektron> The correct zig-type for a zero-terminated char* in C is `?[*:0]` right?
<novaskell> as with error unions `||` is there an equivalent for structs such that `.{ x: u8 } <> .{ y: u8 } = .{ x: u8, y: u8 }`?
<daurnimator> novaskell: no.
<daurnimator> novaskell: there's a couple of open proposals that could result in that though
<novaskell> nice, will try looking for them again
<andrewrk> fengb, naming the fields as integers won't make zig consider the type to be a tuple. there's arguably a hole in the syntax for declaring tuples
<andrewrk> it would make sense to be something like: tuple {i32, bool}
decentpenguin has joined #zig
<daurnimator> almost at 1000 open issues!
dingenskirchen1 has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen1 is now known as dingenskirchen
<waleee-cl> the last commit to master (926a7adb3), wasn't the sentence identical before and after (doc/langref.html.in) ?
dingenskirchen1 has joined #zig
dingenskirchen has quit [Client Quit]
dingenskirchen1 is now known as dingenskirchen
<waleee-cl> oh, my bad. The font I use apparently have crap difference between a and o in tig
<novaskell> thanks daurnimator
<novaskell> seems to be enough to emulate row polymorphism to some extent
metaleap has joined #zig
<metaleap> novaskell: what more "row polymorphism" than the already existing `var` could you possibly want? curious :D
<metaleap> (the "type" placeholder, not the var-decl keyword of course)
dingenskirchen has quit [Remote host closed the connection]
<daurnimator> okay really bed now :P
naltun has joined #zig
<Snektron> no c_char?
dingenskirchen has joined #zig
<novaskell> Just ease of use since sometimes the combination of two structs would satisfy the type and repacking isn't usually that much fun (as in Idris (type machinery can but it's heavy), Haskell, etc) along with generating types based on DSLs. Though I probably need to explore zig more in depth than I currently have for it
<companion_cube> row polymorphism and monomorphization together might not be that simple
<fengb> Zig is much lower level than either of those languages. Struct fields need to map to memory directly
<metaleap> i was only thinking of the duck-typing scenario `var` allows, but a join of 2 structs is sth else
<novaskell> Sure, it's closer to ATS
<andrewrk> the way I think of it is: zig is as high level as possible, without ignoring the reality of memory as a limited resource
<andrewrk> and without giving up the ability to match ABIs
<metaleap> can anyone explain me the whole "traits" design (seems too much in flux to make it into langref?) wrt this scenario: my struct-type is to have both an instream and an outstream field. whether socket or file or buffer etc (assume OSes where not "everything is a file" if that helps =) so far I temporarily declared them explicitly `*std.io.InStream(std.os.ReadError)` and `*std.io.OutStream(std.os.WriteError)` to be able to take stdin/stdout's
<metaleap> `&.<in/out>Stream().stream`. but is that the whole idea or is there a more interface-like notation without specific error sets? there could be instream impls having different errors. does the struct itself need to be generified/type-parameterized? hoping not, would become a cumbersome api
<fengb> Yeah... diverging errorsets are a giant pain right now :P. One of the main drivers for https://github.com/ziglang/zig/issues/130
bheads_ has joined #zig
bheads has quit [Ping timeout: 265 seconds]
bheads_ is now known as bheads
<fengb> https://gist.github.com/fengb/bab9a7bbfff5a11393ebcdc11c6f4e66 @field() doesn't work with tuples?
<fengb> Oh duh, I can't access fields through the type
<fengb> user error!
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
<metaleap> whats with using "@memberName(tupletype, idx)" =)
<andrewrk> beautiful. the solution to fixing a test case in the ir-clean-up-vars branch was to delete result location code special handling of 0 bit types
<mq32> andrewrk: those are the best fixes
<mq32> deleting code means removing possible bugs :)
<Snektron> oh man
<Snektron> i just stumbled across this symbol
<Snektron> VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_FORCEABLE_BIT_KHR
<mq32> oof
<fengb> Reminds me of InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState
<fengb> Wow that got purged from Stackoverflow. What happened to that website? :(
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
<Snektron> This is why i wanted to remove the C namespace from the enum variants
<Snektron> its almost a 100 chars
dingenskirchen has quit [Ping timeout: 245 seconds]
<andrewrk> this seems like the kind of thing where you can decide that it's not problem, and then it stops being one
<Snektron> yeah i doubt anyone will ever use that specific flag, but there are plenty of other names longer than 60 characters
dingenskirchen has joined #zig
dimenus has joined #zig
<dimenus> Snektron: are you around at the moment?
Snetry has joined #zig
<naltun> Has anyone worked with libcurl and zig?
<metaleap> ok, zig: "expected type 'jsonrpc2.struct:45:32', found 'jsonrpc2.struct:45:32'"
<metaleap> and now?
<andrewrk> metaleap, now implement more of report_recursive_error so that it tells you which field is problematic, or otherwise
<naltun> Actually, this may be a general cImport/cInclude question then. I've a GH gist: https://gist.github.com/naltun/a1a305584d5f890d2f3914eece275e25
<naltun> I'm getting `lld: error: unable to find library'
<metaleap> just found the err-msg amusing to read. first will make a minimal repro
<naltun> Not sure if it has to do with how I'm building w/ Zig
Snetry has quit [Quit: left Freenode]
Snetry has joined #zig
<andrewrk> naltun, you're probably hitting https://github.com/ziglang/zig/issues/2041. the workaround right now is to pass -I and -L flags
<andrewrk> then you can change it from /usr/include/curl/curl.h to curl/curl.h as well
<andrewrk> I'm guessing for you it will be -I/usr/include -L/usr/lib
<naltun> So add the -l and -L onto what I already have?
<andrewrk> that's a capital i
<naltun> Ah
<andrewrk> this tells zig where to find headers and library files, respectively
<andrewrk> after #2041 is solved, then adding any -l option when building natively will trigger zig to detect your native system paths
<Snektron> dimensus, now i am
<naltun> andrewrk, I'm getting `Invalid argument: -I/usr/include' as a result
<Snektron> dimenus i mean
<andrewrk> naltun, what zig version?
Snetry has quit [Quit: left Freenode]
<naltun> 0.5.0
<andrewrk> -isystem /usr/include
<naltun> trying
<andrewrk> btw there was an overhaul of translate-c between 0.5.0 and master branch, which relates to using @cImport with curl
<andrewrk> next release is in april
<naltun> Awesome, thanks for that info.
<naltun> Also, I just compiled successfully and was able to access the curl symbols. Thanks!
Snetry has joined #zig
<naltun> Thanks andrewrk.
<andrewrk> I'm expecting that issue to be solved by 0.6.0, so you wouldn't need this workaround then
<naltun> Awesome.
dingenskirchen has quit [Remote host closed the connection]
<metaleap> do any of you know whether anonymous struct literals can today (or are planned to eventually) support the following (minimal repro gist) use-case?
<metaleap> dont think there's a field mismatch, they're easy to see as compatible with signature. as per "structural typing" I'd feel the struct compat between the literal and its corresponding arg decl should be there?
<metaleap> (err msg in gist title, same as described earlier)
Snetry has quit [Quit: left Freenode]
dingenskirchen has joined #zig
<dimenus> Snektron: trying to setup a post processing shader in a second render pass
<dimenus> and i'm running into issues with SubpassDependencies
Snetry has joined #zig
<andrewrk> metaleap, this code looks like it should work to me
<metaleap> andrewrk: indeed, if one extracts the struct into a named-def, it compiles. so for "structural typing" i suppose I'll open an issue then
<andrewrk> thanks
<Snektron> dimenus, what kind of issues? Not that i've done much with render passes
<Snektron> in my project i cheekily used the feature that you can render directly to a framebuffer from a compute shader
<Snektron> so i could skip all that
<dimenus> the image layout transitions from the first pass, i'm going to re-read the spec on subpass dependencies
<Snektron> you can manually transition the image to another layout iirc
<Snektron> i had to do that quite a lot
TheLemonMan has joined #zig
<TheLemonMan> andrewrk, what's the correct way to check if a given feature is available for the current target?
<andrewrk> TheLemonMan, here's an example: std.Target.current.cpu_features.features.isEnabled(@enumToInt(std.Target.arm.Feature.neon))
<andrewrk> it might be nice to have some helper functions for that
mahmudov has joined #zig
<andrewrk> for example: std.Target.hasArmCpuFeature(.neon)
<andrewrk> which would return false for non-arm arch
<andrewrk> err it would be std.Target.current.hasArmCpuFeature(.neon)
alexpana has quit [Ping timeout: 265 seconds]
<andrewrk> TheLemonMan, I think you're going to be happy with the changes made by #4152. it's a significant improvement in debugging experience
<andrewrk> all these fixes haven't been hacks, they've been sensible improvements
<TheLemonMan> yeah I was scrolling trough the commits, lots of nice stuff
<TheLemonMan> "bitcast sandwich" hah
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
<betawaffle> is it possible to get the value of a const declaration from TypeInfo?
_Vi has quit [Ping timeout: 272 seconds]
forbjok has joined #zig
<andrewrk> betawaffle, are you aware of @field ?
<forbjok> Is there any way to generate a set of function calls at compile time that take a non-compile time variable from the containing function?
<betawaffle> does that work for declarations too?
<andrewrk> it's equivalent to `a.b` syntax where `b` is a compile-time known string
<betawaffle> ok, so if `a` is a `type`, it should let me get the declaration then?
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk> yes
<betawaffle> awesome
knebulae has quit [Remote host closed the connection]
metaleap has quit [Quit: Leaving]
metaleap has joined #zig
Akuli has joined #zig
metaleap has quit [Quit: Leaving]
<mikdusan> well I tracked down those stage1 8-byte allocations -- they're pointers; and mostly via ZigList<IrInstSrc*> -- so there's no easy malloc overhead to be clawed back :(
<TheLemonMan> andrewrk, so, should we compile compiler-rt in release mode everywhere (but in tests) (and beside ReleaseSmall) ?
<andrewrk> I support that
<andrewrk> the code for that is in link.cpp calling create_child_codegen
<andrewrk> mikdusan, ah yes, I briefly banged my head against c++ trying to address this
<andrewrk> I keep admitting to people yeah zig's comptime parameters are basically the same as c++'s template parameters. but then I try to use c++ template parameters and it's a complete shit show
<companion_cube> "basically the same, except usable"
<TheLemonMan> BaroqueLarouche, I see you have some memset32/memcpy32 versions in your code. If you specify the right align() parameter llvm will automagically generate a call to a function that takes advantage of the alignment
<mikdusan> and this (typename -> const char*) business is truly sad. I mean the symbols are there, the linker knows about it, and yet we *MUST* turn on -frtti to get typeid() in C++. oh my. and that's a no-go because then LLVM has to be -frtti'd too. what a loss. and boost's type_index module which apparently can get typenames without rtti is just-say-no. it brings in about 10 other modules of spaghetti.
<BaroqueLarouche> TheLemonMan: where do I put this align parameter ?
<TheLemonMan> BaroqueLarouche, on your pointers
<Snektron> mikdusan, you can recreate that functionality pretty simple
<Snektron> but
<Snektron> its not for the faint of heart
<BaroqueLarouche> TheLemonMan: I'll try it soon
<TheLemonMan> right now our compiler-rt uses a generic 1-byte-a-time memcpy/memset but it's very easy to fix that :P
<mikdusan> Snektron: well I thought about hacking __PRETTY_FUNCTION__ lol
<Snektron> yeah that is the hack
<Snektron> its disgusting but it works, and if its only for diagnostics it might be viable
<Snektron> on compilers not {clang, gcc, msvc} it could just output "unknown"
<TheLemonMan> maybe you can use some constexprs to ease the pain
<Snektron> yeah you need to use constexpr to extract the type name after
<Snektron> But you cant get it in a raw way
<Snektron> anyway
<mikdusan> Snektron: we basically only need it for platforms where a developer is identifying what needs to be worked on so that's not the issue. but it is an issue needing another fricken llvm build just for rtti . grrr.
<Snektron> Does anyone know how align() works on packed structs
<Snektron> i mean, what does align(a:b:c) mean?
<mikdusan> yes!
<mikdusan> i actually know. or I think I know :)
<mikdusan> a = align in bytes. b = bitsize of type. no padding. c = "host integer" byte size. the size of what LLVM load instructions will be.
<mikdusan> oh sorry b = offset in bits from host integer
<Snektron> aha
<Snektron> thank you
<mikdusan> it's andrewr's clever way of making all sub-byte pointers work without needed any more bits in the pointer -- all the info is in static type system
<Snektron> I ran into it before but i couldn't find any information about it
_Vi has joined #zig
<fengb> I'm glad godbolt is a thing. Did not expect this stark difference: https://godbolt.org/z/8svT76
<TheLemonMan> if your string is always smaller than 32 bytes you're just wasting a lot of space heh
naltun has quit [Ping timeout: 260 seconds]
<andrewrk> fengb, swhash2 looks like it might perform better for larger input values
<andrewrk> the first one essentially assumes 8 bytes, right?
<fengb> ? doesn't u64 store 8 bytes?
<fengb> They both assume 8 bytes. I have it extending to 16/u128... and I need a comptime check to make sure I don't get to big
<andrewrk> where does swhash2 in the godbolt link assume 8 bytes?
<fengb> It's just to allow for limited switches for strings
<andrewrk> oh you're saying the result value is 8 bytes
<andrewrk> what I mean is that llvm is noticing that you are only reading the first 8 bytes in swhash
<andrewrk> but in swhash2, your result depends on the entire input
<fengb> Yeah I removed the check
<fengb> Ahhhhhh
<fengb> Good point
<andrewrk> llvm is actually allowed to omit the memcpy in swhash, but I guess it didn't figure out that much
<fengb> I need to zero extend it
<fengb> https://godbolt.org/z/JYxiTC second case is still confused. Oh well, I was trying to be fancy and it's getting worse heh
<andrewrk> in theory swhash could be compiled to simply "mov rax, [rsi]"
<TheLemonMan> just change the slice to [0..8]
<andrewrk> in the first godbolt version
<fengb> xor eax, eax
<fengb> I wonder if I can convince LLVM to do that
<TheLemonMan> llvm emits `mov rax, qword ptr [rdi]` if you do so
<andrewrk> good find
<andrewrk> I guess without that, llvm is actually avoiding engaging in optimizing UB
<andrewrk> (most likely unintentionally)
<TheLemonMan> string[0..len] cannot be constant folded and std.mem.copy iterates over that
<fengb> Well I can't guarantee the length either
<TheLemonMan> the assertion in `copy` should've stopped you `assert(dest.len >= source.len);`
<fengb> Oh the memcpy happens because I don't know the length
<fengb> dest is always 8 bytes. I have a pre-check for the source
<andrewrk> https://godbolt.org/z/J9XuBn I'm not impressed, why can't llvm turn this into a mov?
<andrewrk> I guess that pattern is rather complicated to look for
<TheLemonMan> so you just want to read a string of 8 u8 as a single u64 ?
<andrewrk> I'm just playing with godbolt. but yeah that was the thing I was playing with
<fengb> I'm compressing up to 8 bytes into a u64 so I can use it as a switch prong
<fengb> Anything over 8 is pegged at maxInt(u64) and falls through to the else
<fengb> Just the simplest "hash" that can work for my needs
<andrewrk> fengb, btw you might find this article inspiring: https://nullprogram.com/blog/2018/07/31/
ofelas has joined #zig
<TheLemonMan> fengb, if you want a `mov` just take your first version and change the slice to [0..8]
<TheLemonMan> it generates compact code also for ARM and friends
zfoo has quit [Remote host closed the connection]
<fengb> I can't guarantee that it's that length so I'd need to manually account for smaller lengths
treeshateorcs is now known as Guest10453
Guest10453 has quit [Killed (kiwi.freenode.net (Nickname regained by services))]
metaleap has joined #zig
return0e has joined #zig
return0e has quit [Read error: Connection reset by peer]
naltun has joined #zig
<mikdusan> andrewrk: if you're still adding to ir-clean-up-vars (otherwise I'll just do a tiny PR later):
<Snektron> mikdusan, if you want a quick solution for memory debugging, https://godbolt.org/z/rPJyXH
<forbjok> Is it possible to dynamically generate struct fields or enum variants at compile time based on a comptime variable?
<Snektron> you can abuse usingnamespace
<andrewrk> abusingnamespace
<Snektron> mikdusan, the msvc function is similar but you need to extract everything between the outer <>
<mikdusan> Snektron: ooh that doesn't look too bad
<Snektron> it could be better, c++11 is quite restrictive on constexpr functions
<Snektron> in c++14 you can use multiple declarations
<andrewrk> alright, I expect the tests to pass now for #4152
<mikdusan> __expect__ he says :)
<fengb> forbjok: for fields and not declarations, there's a few TODOs: https://ziglang.org/documentation/master/#Type
<fengb> Enum is in scope. structs are not (yet)
<Snektron> oh, and msvc uses FUNCSIG, mikdusan
<mikdusan> yup
<andrewrk> forbjok, this use case may be better solved with generating zig code at build time. or, better yet, maybe you don't need meta programming at all. maybe you can solve the problem with programming
<forbjok> fengb: Yeah, I saw that before. I'm already using @Type to generate an arbitrary-sized integer at compile-time, but would this allow creating struct fields at compiletime if it was implemented?
<forbjok> Yeah, there are probably ways to avoid it. I'm just trying to figure out what can be done and what can't, as I haven't used Zig until today.
<fengb> Possibly? But it's not defined or scoped out. I remember tgschultz having something in userland
<tgschultz> It involves some advanced comptime usage.
<forbjok> I was trying to create a simple Entiy Component System that takes a set of component and systems in a comptime variable and generates an ECS struct
<tgschultz> The implementation is linked within, but has not been updated since 5.0
<forbjok> Ideally, I'd want it to do as much of the setup as possible at compiletime
<mq32> forbjok, for a simple ECS you don't need much meta programming
<tgschultz> The basic technique is: take a struct type as input and a new field type, then return a struct with the previous struct as a field and the new type as another field. Use a bunch of helper methods to set and get fields.
<mq32> Each component "class" must provide an array of all components, each component must know it's entity and you need to know all possible component types
<mq32> that should be easily doable in Zig with a little bit of comptime :)
<mq32> like
<forbjok> mg32: I know it isn't strictly needed. I've implemented a similar one in C# before, where every component array field was just hardcoded in. I could probably also use a multi-dimensional array for the components to store them all in a single field
<forbjok> since code generation doesn't seem possible anyway
BaroqueLarouche has quit []
<mq32> just don't go the C# way of "inheritance"
BaroqueLarouche has joined #zig
<mq32> use array-of-data instead of data-with-array
<forbjok> I didn't use inheritance in my C# ECS. That would kinda undermine the point of an ECS.
<mq32> const MyComponent = createEcsComponent(struct { health: u32 });
<mq32> var ptr = try MyComponent.attach(entity);
<mq32> let me hack you a quick example :)
<forbjok> If you mean use an array for each component type, then that's already what I was intending
<dimenus> how do i ensure that a bool is 4 bytes?
<forbjok> as opposed to having an Entity struct
<forbjok> entities will just be an index into the component arrays
<mq32> yeah, kinadish that's the idea
<forbjok> so the entity ID is effectively just the index
<TheLemonMan> dimenus, turn it into a u32?
<dimenus> was just curious if there was a more idiomatic way
<dimenus> i spose that's it lol
<mq32> forbjok: use a double-indirection of ID→Index
<mq32> because otherwise you have to reuse indices which is bad
<mq32> make entity IDs unique
<forbjok> I kinda wanted to avoid the indirection for performance reasons
<forbjok> but it might end up being necessary
<forbjok> I can see how it might result in some weird bugs if indexes are reused and there is a reference to an entity ID in some other entity's component
<mq32> yep
<mq32> with unique ids you can check liveness
<forbjok> Yeah. Another option might be to keep a generation number separate from the component bitmasks
<Snektron> you can also use a generational id
<forbjok> That way I could keep both index and generation wherever entities are referenced and check them when retrieving a specific entity
decentpenguin has quit [Quit: decentpenguin]
<forbjok> The main iteration loops in systems wouldn't really need the check, so it'd be a lot of overhead if it was done universally
<TheLemonMan> andrewrk, re TTY.Config in debug.zig, why do you want a file payload for windows_api? isn't out_stream enough?
<naltun> Question on navigating between types. When working with CURLoption, I get `error: expected type '.cimport:13:17.CURLoption', found 'comptime_int''. https://gist.github.com/naltun/cc7924a6f8f421a94cd7713b06bff543. Question is, how do I keep Zig from setting this as a comptime_int?
<naltun> when working with libcurl's CURLoption*
<andrewrk> TheLemonMan, GetConsoleScreenBufferInfo and SetConsoleTextAttribute are using the stderr_file global, which is not available via the stream arg
<andrewrk> if you called dumpStackTrace with an out stream that is not stderr, that code is incorrect
<andrewrk> btw fengb I realized that fixing missing async spill bugs is easy
<TheLemonMan> oh well, it'd be incorrect anyway since supportsAnsiEscapeCodes is always called on stderr_file
<andrewrk> turns out I made this really convenient SpillScope thing. the hardest part is just looking at the llvm error, looking up the !1234 thing into source locations, figuring out where in the source that is referring to
<andrewrk> TheLemonMan, at all detectTTYConfig() callsites, the code is using stderr as the stream
<andrewrk> I agree the code would be more clear to accept a file parameter
<andrewrk> detectTTYConfig and TTY can probably be usefully moved out of std.debug to become generally useful
<TheLemonMan> naltun, I guess you need a @intToEnum(libcurl.CURLoption, libcurl.CURLOPT_URL)
<TheLemonMan> or just .CURLOPT_URL if it's really an enum
<TheLemonMan> andrewrk, yeah all the callsites use stderr, that's why I asked
<andrewrk> but for example writeCurrentStackTrace is public
<naltun> TheLemonMan thanks, I'll review that function now.
<TheLemonMan> yeah, making sure the titty config and the out_stream refer to the same stream is up to the caller then
<TheLemonMan> we could just shove both in a context struct but that's not a big deal atm
<fengb> Ah cool, I was planning on trying to tackle the optional spill
<andrewrk> TheLemonMan, detectTTYConfig could be a nice member function of std.fs.File
forgot-password has joined #zig
<andrewrk> fengb, here's an example of fixing a missing spill for pointer elem capture of for loops: https://github.com/ziglang/zig/pull/4152/commits/ae20574d5efaa7c63d78299b761eee38515b5865
<TheLemonMan> *shrug*, it just calls supportsAnsiEscapeCodes/isTty, it'd feel redundant
<andrewrk> I do think it would be nice to figure out some convenient way to make the easiest way to write data to a terminal, to properly terminal escape text, but also support intentional terminal escapes
<forgot-password> andrewrk: Did you read my message about the `zig translate-c` thing on sunday?
<andrewrk> e.g. if you did std.debug.warn("{}\n", blah), and `blah` contains terminal escape codes, and the output is a terminal, they should be escaped
<andrewrk> I'm using the word "escape" ambiguously here but I think you get the idea
<andrewrk> forgot-password, no, can you remind me?
<forgot-password> It was about translating the CoreAudio headers on macOS
<forgot-password> You replied to me about that, but I only saw that in the evening and you were offline
<andrewrk> can you repeat the question
<forgot-password> Sure – I got errors about some seemingly swift-wrapper-related code when using `translate-c`, but compiling with clang works fine
<forgot-password> I thought that clang maybe detected it as objective-c, where it worked fine, but even using `clang -x c $file` didn't throw the error
<forgot-password> I posted a link to a pastebin with the error messages: https://pastebin.com/zw8wAdZm
<andrewrk> you could try removing that and see if anything changes. worth finding out what happens
<andrewrk> TheLemonMan, shouldn't debug mode things still get release builds of compiler-rt?
<TheLemonMan> andrewrk, yeah, sometimes I can't think straight
naltun has quit [Ping timeout: 260 seconds]
<andrewrk> TheLemonMan, while you're at it, might be nice to make a switch, just in case that enum ever gets bigger
<TheLemonMan> sure thing, I love switches
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
<forgot-password> andrewrk: Well, it runs fine when I invoke it without `-x c`
<forgot-password> `zig translate-c` throws said errors and clang works
<andrewrk> forgot-password, feel free to make a PR for that. I think that's reasonable to consider removing the -x c
<forgot-password> But that doesn't change anything about the result
<andrewrk> did you try editing zig sources to remove -x c?
<forgot-password> No, can you point me to the right file?
<forgot-password> Wait, I'll probably have to build the compiler then, correct?
<andrewrk> ☝️ ☝️ ☝️
<andrewrk> yes
<forgot-password> Okay, I'll need to get the build process up and running then, thanks a lot! :)
Akuli has quit [Quit: Leaving]
companion_cube has quit [Quit: WeeChat 2.3]
companion_cube has joined #zig
<andrewrk> #4152 merged! I expect there to be a few regressions - with reasonable fixes - and also quite possible a bunch of seemingly unrelated bugs fixed
<TheLemonMan> andrewrk, how did you solve the problem with the sr.ht machine?
<andrewrk> TheLemonMan, the problematic behavior had this algorithm: if cpu matches exactly, assume the cpu features based on the static set of cpu features in the list we have hard coded for that CPU
ltriant has joined #zig
<andrewrk> now, master branch behavior has this: if the cpu matches a known cpu, initialize feature set with the list we have hard coded for that CPU. next, iterate over the provided cpu features, respecting the + and - affecting the set. finally, chase the dependencies
<andrewrk> so, on sr.ht if you inspect the target CPU at comptime it will be wrong. but the detected cpu features correctly override the feature set, so that everything works
<andrewrk> basically, detected cpu features override detected cpu model
<andrewrk> which is the same reason why gcc and clang work on that machine
<TheLemonMan> have you tried running clang with --march=native ?
<andrewrk> no
<andrewrk> well, kind of. zig is passing that when building libcs from source in the test suite
<TheLemonMan> I still think this is a (unneeded) workaround
<andrewrk> I don't consider it to be a workaround; I consider it to be the correct way to detect the cpu feature set
<TheLemonMan> you're throwing away a piece of information (the cpu name) because of this
<andrewrk> that's not true - the cpu name is kept, and available at comptime, and it is used to initialize the set of cpu features
<andrewrk> `std.Target.current.cpu_features.cpu.name` is always available - it's a struct field, not union, and it's non-optional
<TheLemonMan> who cares, LLVM doesn't get it so it's just a useless string
<andrewrk> llvm does get it
<TheLemonMan> it should crash and burn with the "athlon-xp" + 64bit features combo
<andrewrk> llvm also has the logic, that makes the cpu features override the model
<andrewrk> one other thing that was pointed out to me in #llvm is that the cpu model name is not unique - there are pieces of hardware that match model name yet have different sets of features enabled
<andrewrk> maybe in the bios, for example
<TheLemonMan> the cpu name specifies more than a set of features
<andrewrk> I double checked, we're passing the cpu name to llvm unconditionally, and also to clang for translate-c/cimport
<TheLemonMan> then why it's not blowing up like it did before?
<TheLemonMan> the cpu is indeed wrong, but that's a problem with qemu
<andrewrk> because before, llvm was not getting +64bit, but now it is
<andrewrk> detecting invalid combinations of cpu model and features is an interesting and probably useful concept, but it's more complicated than simply not taking into account detected cpu features. it would be more involved to add this detection
<andrewrk> it is correct to take into account detected cpu features
<andrewrk> the knowledge that detecting "64bit" on an "athlon-xp" cpu is a strange situation, is extra-cirricular
<pixelherodev> andrewrk, what's the short summary of the effects of that tech debt merge?
<pixelherodev> That is, from a user's perspective :P
<pixelherodev> Changes in speed / RAM usage? or is it fully behind-the-scenes?
<TheLemonMan> if llvm is fine with such cpu/+64bit combo then I rest my case
<andrewrk> it is; and so is gcc. that's why gcc and clang both work on that box
<andrewrk> pixelherodev, (1) fixing bugs in the most complicated parts of the compiler is now significantly easier (2) there may be some new regressions, but also I expect that to have fixed a handful of other nasty bugs (3) small reduction in RAM usage (4) meaningful progress towards #2765 and #2761
<pixelherodev> Gotcha, neat! "Small" meaning "a couple KB" or "1%" or?
<andrewrk> std lib tests from 3.378 GiB (4.59 GiB peak with time -v) down to 3.19 GiB (4.52 GiB peak with time -v)
<pixelherodev> Not bad at all!
<andrewrk> between 1-6%
<TheLemonMan> still too much to run on the freebsd CI machines?
<andrewrk> let's give it a shot
<andrewrk> who wants to do do the pull request where you mess with ci/srht/freebsd_script and try to uncomment as much test cases as possible?
<fengb> https://gist.github.com/fengb/e6af2dc55fbc7cc783bef562162ac106 is this a compiler bug or am I doing something horribly wrong?
jessermeyer has joined #zig
<mikdusan> try master :)
<mikdusan> like _really_ master: 0.5.0+13259acbc
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
BaroqueLarouche has joined #zig
<fengb> I just pulled
<TheLemonMan> that's what he said
sirnaysayer has joined #zig
jasom has joined #zig
<sirnaysayer> Hey all, I'm getting this error https://gist.github.com/sirnaysayer/2c28ce388ea0eba7e08de1618509d20c when trying to compile this code https://gist.github.com/sirnaysayer/1d022e60bf48afa3383588d09b3568d1 I am not sure exactly what library could be throwing those linker errors, since they seem to be MSVC specific
<andrewrk> fengb, your tuple has comptime-known fields
<fengb> But I'm getting the typeOf so it shouldn't matter right?
<andrewrk> your struct looks like this: struct { comptime @"0": i32 = undefined, comptime @"1": i32 = undefined };
<andrewrk> Pair(i32,i32) is a 0-bit type
<fengb> Oh
<fengb> Welp that's probably not good heh
<andrewrk> I don't think it's possible to make Pair as you want to with current zig
<andrewrk> because the function runs at comptime, so every value passed to anon tuple literal will be comptime, so all fields will be comptime
<andrewrk> you just want actual tuple syntax, right?
<TheLemonMan> sirnaysayer, how are you compiling that?
<sirnaysayer> zig build-lib -lc -dynamic .\main.zig
<fengb> Yeah, I'm trying to annotate my function so I can do some metadata analysis
<fengb> But structurally it should be a tuple since order matters. I could make a fake tuple struct
<andrewrk> I think it would make sense to have tuple syntax probably. the language has the type and it's not exposed. that's weird. it would be less weird to just expose the type with syntax like every other type
frmdstryr has joined #zig
jessermeyer has quit [Remote host closed the connection]
jessermeyer has joined #zig
<fengb> Struct field order is well defined right? It's only memory layout that's undefined
<jessermeyer> Would leveraging the build system be the most natural place to systematically implement profiling blocks?
<andrewrk> fengb, correct
<sirnaysayer> TheLemonMan: compiling as release-small seemed to work just fine, ill play with those settings. I am still curious why those errors happen on the default mode.
<TheLemonMan> sirnaysayer, yeah you're disabling some security features
<TheLemonMan> try with -target x86_64-windows-msvc
<Snektron> how often does godbolt update the trunk compiler?
<andrewrk> TheLemonMan, stack traces in stage1 panics stopped working for me btw
<TheLemonMan> linux?
<andrewrk> x86_64-linux-gnu. I can repro it with https://github.com/ziglang/zig/issues/4282
<TheLemonMan> uh, weird, it's working fine here
<andrewrk> I'll look into it
<andrewrk> this is with gcc 8.3.0
metaleap has quit [Quit: Leaving]
<TheLemonMan> same here, I'll have a look after I finish this PR
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
<jessermeyer> Does translate-c translate strictly more than the input provided?
<jessermeyer> I tried translating a very simple macro and the output was ... well.. a lot more than the macro.
<TheLemonMan> it tries its best at interpreting what the macro is trying to do
<andrewrk> yes translation of macros are heuristic at best
<jessermeyer> #define macro(param)\ (param)
<jessermeyer> gives me...
<andrewrk> consider that you're asking zig to look at arbitrary text substitution (which may not even be valid C), with no context, and convert that to zig
BaroqueLarouche has quit []
<andrewrk> but it seems like that pattern can safely be translated as inline fn macro(arg: var) @TypeOf(arg) { return arg; }
<TheLemonMan> those are default macros
<jessermeyer> C has default macros?
<TheLemonMan> C compilers define some default macros
<jessermeyer> Ah.
<andrewrk> notice that one of them is the clang version
<jessermeyer> Yup.
<jessermeyer> It was just unexpected output.
<andrewrk> the test cases in test/translate_c.zig are looking for substring matches
jessermeyer has quit [Remote host closed the connection]
<TheLemonMan> andrewrk, the stack traces are fine here
<TheLemonMan> I tried with a fresh copy of master, on the same snippet of code
<andrewrk> good to know. I'll investigate over here
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
BaroqueLarouche has joined #zig
neceve has quit [Ping timeout: 265 seconds]
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
dimenus has quit [Remote host closed the connection]
mahmudov has quit [Remote host closed the connection]
<Snektron> Is the compiler emitting "concurrent modification a known issue"? I searched github but couldn't find anything