ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
dimenus has joined #zig
marijnfs__ has joined #zig
marijnfs_ has quit [Ping timeout: 245 seconds]
kristoff_it has quit [Ping timeout: 246 seconds]
Ichorio has quit [Ping timeout: 264 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 272 seconds]
diltsman has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 258 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 246 seconds]
kristoff_it has joined #zig
tgschultz has quit [Ping timeout: 248 seconds]
kristoff_it has quit [Ping timeout: 245 seconds]
darithorn has quit [Quit: Leaving]
tgschultz has joined #zig
laaron has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 268 seconds]
andersfr has joined #zig
jjido has joined #zig
brakmic has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
brakmic_ has joined #zig
very-mediocre has joined #zig
brakmic__ has joined #zig
brakmic has quit [Ping timeout: 248 seconds]
brakmic_ has quit [Ping timeout: 246 seconds]
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre1 has joined #zig
brakmic__ has quit []
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
andersfr has quit [Remote host closed the connection]
belgin has joined #zig
belgin has quit [Remote host closed the connection]
andersfr has joined #zig
very-mediocre1 has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 258 seconds]
_whitelogger has joined #zig
andersfr has quit [Remote host closed the connection]
andersfr has joined #zig
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
Ichorio has joined #zig
kristoff_it has joined #zig
utzig has quit [Quit: leaving]
kristoff_it has quit [Ping timeout: 246 seconds]
andersfr has quit []
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 248 seconds]
very-mediocre has quit [Read error: Connection reset by peer]
kristoff_it has joined #zig
_whitelogger has joined #zig
very-mediocre has joined #zig
SimonNa has quit [Ping timeout: 245 seconds]
SimonNa has joined #zig
SimonN has joined #zig
SimonNa has quit [Ping timeout: 272 seconds]
kristoff_it has quit [Ping timeout: 272 seconds]
dec05eba has joined #zig
<dec05eba> Is there any way to break on return of error with gdb in zig? im stepping through code and there is a try statement and the function returns an error and gdb jumps to the place where the error is handled, making it hard to find the place where it gives error. In other words, is it possible to put a breakpoint on the longjump zig uses? (i assume that's how it works?)
<dec05eba> with languages like java you can print the stacktrace from the throw to the place where the error is handled, without knowing where the error was thrown
kristoff_it has joined #zig
<dec05eba> ah nvm, it can be done properly with errorReturnTrace and dumpStackTrace
dec05eba has quit [Quit: leaving]
kristoff_it has quit [Ping timeout: 268 seconds]
<ffddr> Is there some kind of "struct update" syntax? I am trying to achieve something like `c.sg_buffer_desc{ .size = x, .. init_zeroes(c.sg_buffer_desc) }` instead of. `var desc = init_zeroes(sg_buffer_desc); desc.size = 5;`
<ffddr> I cant make default fields unfortunately, its a C struct :(
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
<ffddr> Found the relevant issue, looks its impossible right now. Maybe it will make sense to open github issues with use case of C structs initialization?
wootehfoot has joined #zig
<daurnimator> ffddr: initialising a struct to zero is considered an antipattern in zig
<ffddr> but partially/zero initialized structs are used in C libraries a lot. Right now the only way to make such a libraries convinient to use from zig - write a wrapper for each C struct with default values. Thats a lot of work :(
<Sahnvour> ffddr: you can do a generic function that accepts any kind of struct, and zeroes it with @memcpy, would that work for you ?
sourgrasses has joined #zig
<Tetralux> Sahnvour, I believe that's unadvisable on anything other than extern or packed structs.
<Tetralux> Though honestly, it makes very little sense to consider zeroing an antipattern, considering that zeroing is the simplest possible state for a struct to be in, easy to make it, and easy to check for.
<Sahnvour> yes, but ad ffddr mentionned, it's really frequent in C apis
<Tetralux> In that, the reason zeroing is so nice is that you can just allocate, zero, and then you're done with initializing.
<Tetralux> Array<T> a; // zero-init. array_add(&a, x);
<Tetralux> No init call required.
<Tetralux> That's a beauty that's quite appealing honestly.
<Tetralux> That aspect of Zig is a little weird to me.
<daurnimator> Tetralux: as I said, in zig that's considered an antipattern: 1. zero is not always a valid state. 2. if you don't know: initialise to undefined, then we can catch accidental reads.
<Tetralux> You may have glossed over my point slightly there xD
<Tetralux> I was specifically arguing for when it _is_ a valid (uninitialized) state.
<daurnimator> Tetralux: then you can be explicit about it...
<Tetralux> Which in my example, 'array_add' would just check for and init before adding.
<daurnimator> ask yourself "is there any reason to initialize this to zero compared to.... 42?"
<Tetralux> I cannot, because in Zig, I'd have to make the struct extern in order to be able to memset to zero.
<Tetralux> And memset to zero is woefully explicit.
<Tetralux> The whole point of zero-init is that you can just make one, not do anything to it, and use it immediately knowing that's all you need to init.
<ffddr> Sahnvour: let me show some example:
<ffddr> actually, zig-nowrapper version is not that bad in this particular case, but zig-wrapped looks enough better to make a wrapper. While no-wrapper usage of C libs is such a great feature.
<ffddr> (my expirience with C libs in zig is quite limited - I used libwebsockets and now experimenting with sokol. In both I missed this a lot and wanted some wrapper with zero init)
<daurnimator> Tetralux: I don't understand why you would have array_add there... don't you just want to initialise to x?
<daurnimator> ffddr: why initialise to zero? what happens if you don't?
<Tetralux> The call to array_add was to demonstrate that you don't have to call init on the array for it to be considered initialized.
<Tetralux> You would be passing an empty, unallocated array to add
<Tetralux> And it would notice that when it checked you have enough space and do the alloc.
<daurnimator> Tetralux: I would say that *should* be an error..... what? what do you mean alloc?
<Tetralux> You're allocing an array to have enough space for the element you are adding to it...
<daurnimator> Tetralux: where is the allocation there?
<Tetralux> In array_add.
<daurnimator> ?
<ffddr> daurnimator: C lib assuming zeroes, so it would probably crash without zeroes
<daurnimator> 1. why would adding to an array need to allocate? 2. I don't seen you passing an allocator in
<daurnimator> ffddr: it *shouldn't* crash without zeros; infact I'd be very suprised if it did: and would consider that a bug in the C library
<Tetralux> Because array_add would call malloc or whatever.
<Tetralux> Or
<daurnimator> Tetralux: that would be an antipattern in zig
<Tetralux> The array itself would have an allocator field.
<Tetralux> Or you could pass an allocator in.
<daurnimator> but also... see 1.
<tgschultz> ArrayList sounds like what you want then
<daurnimator> Tetralux: wait do you mean append? not add?
<Tetralux> The Array<T> _is_ a dynamically sized array.
<Tetralux> It literally _is_ ArrayList.
<daurnimator> Tetralux: Array isn't a zig thing.
<ffddr> daurnimator: it depends on the library, sometime undefined is fine, sometime not (libwebsocket needs zeroes for sure for example).
<daurnimator> ffddr: could you show me an example where it needs zeros? there's only a couple of very specific locations I've seen where you need to init to zero.
very-mediocre has quit [Read error: Connection reset by peer]
<daurnimator> ffddr: generally we solve those in zig by adding "__pad" fields to the struct
<daurnimator> ==> because they're not really padding if the library reads them
<ffddr> daurnimator: hm, probably there is some kind of misunterstanding. My point - - structs with default values are just way easier to use.
<daurnimator> most of the occurances of it are in kernel interfaces that are considered mistakes on the kernel side, but kept for backwards compat purposes
<Tetralux> ffddr: ..This is the entire point of what I'm saying.
<daurnimator> ffddr: I'm saying the code under "zig wrapped structs" should work anyway
<ffddr> sure, but it needs a struct with default values
<daurnimator> ffddr: why?
<daurnimator> ffddr: are there more than those 3 members?
very-mediocre has joined #zig
<tgschultz> aren't we getting default values? Didn't andrewrk sign off on that?
kristoff_it has joined #zig
<daurnimator> tgschultz: we have default values.
<ffddr> daurnimator: yes, a lot of them!
<tgschultz> oh it is there already? man, I haven't written any zig in a while I guess
<daurnimator> tgschultz: ffddr's question was "how do I add a default value to a translate-c-imported struct"
<Tetralux> daurnimator: I'm not entirely sure what you mean by that. Because it is. But that's okay. I was talking about an ArrayList equivalent struct in C.
<tgschultz> ah, ok. I guess you just rewrite the struct in zig, make a wrapper function to init it, or save the translation and modify it
<Tetralux> And the fact that you can declare one, init it to zero, and append things to it without having to call init(array) etc.
<ffddr> daurnimator: default zeroes from translate-c structs will definetly solve the problem!
<daurnimator> tgschultz: yeah that's the status quo: but that's sort of annoying: it would be good if there was a way to mutate translated structs after you @cImport them
<daurnimator> ffddr: I don't think that would be accepted.
<Tetralux> In reality, you'd give all the field "= 0" so you don't have to set the array "= {}" when you declare it.
<tgschultz> well the idea of mutating a struct in-place sounds pretty anti-zen to me.
<daurnimator> tgschultz: agreed. I'd return a new one
<daurnimator> tgschultz: this sounds like a job for @reify :)
<tgschultz> sure, but then all your translations are done with the old type still, aren't they?
<daurnimator> or @Type as it seems to be called now?
<daurnimator> tgschultz: good point.
<tgschultz> seems like a complicated thing to handle just to alievate a minor annoyance, but my use cases for interacting with C don't really need it so I'm biased.
<Tetralux> This means that Zig's version of the C array is 'const a = ArrayList(T){};', whereas it'd ideally be 'const a: ArrayList(T);'
<tgschultz> Tetralux: ? Zig's array list requires an allocator to work. You have to call init regardless.
<daurnimator> Tetralux: infact Zig's version is: `ArrayList(T).init(myallocator)`
<Tetralux> With respect, you are not listening to what I'm saying.
<tgschultz> I think I'm not understanding what you're saying, yes
<Tetralux> But maybe I'm not being clear enough.
<ffddr> daurnimator: hm, I understand that its quite a serious changes to c-import, but I cant see any examples where default zeroes will actually break things
<daurnimator> ffddr: a common idea is that you *should* be initialising everything explicitly
<daurnimator> > Communicate intent precisely.
<Tetralux> (Disclaimer: Code is probably broken.)
<Tetralux> (But that's not the point of it.)
<Tetralux> The point is L28/29.
<ffddr> daurnimator: how the following code should looks in idiomatic zig? (its a static array of structs with more than 4 fields).
<daurnimator> ffddr: at the moment it ends up looking like
<tgschultz> Tetralux: I object to the very concept of a default allocator.
<tgschultz> That's a personal thing, but I think andrewrk would agree it is un-zig-like
<Tetralux> And personally, I can understand that position.
<Tetralux> It makes sense to me.
<Tetralux> But still. This is just an example.
<Tetralux> It's not just an ArrayList this feature would be useful for.
<ffddr> daurnimator: it looks like luaL_Reg have only two fields
<ffddr> i ended up with, this would looks way better with default zeroes
<Tetralux> That link is dead :3
<daurnimator> Tetralux: looking at that example.... why would .data or .len need to be initialised at all?
<daurnimator> Tetralux: or .data at least
<daurnimator> your `if (data == null)` check could be `if (self.len == self.allocated)`
<daurnimator> Tetralux: perhaps have a peek at the actual zig std.ArrayList implementation?
<via> 09:33 ( ffddr) daurnimator: how the following code should looks in idiomatic zig? (its a static array of
<via> 09:33 ( ffddr) daurnimator: how the following code should looks in idiomatic zig? (its a static array of
<via> whoops
<via> wrong double click, sorry
<ffddr> daurnimator: actually in this example there is just 2 more fields to initialize. but in libwebsockets there is a struct with 40+ fields, designed for partial initialization :(
<daurnimator> ffddr: that sounds weird.... do they provide helper macros or something?
<ffddr> they just memset it to 0 and use some of the fields
<daurnimator> ffddr: actual memset to zero? or rely on C's trailing 0 in a struct initialiser to initialise everything to zero?
<ffddr> I think the best example of C library with such a struct is sokol:
<ffddr> it would be super nice to do the same struct initialization in zig!
<daurnimator> ffddr: indeed it looks like they "expect" default values:
<ffddr> daurnimator: memset :) we could do the same in zig for sure, so its not an intresting example
<daurnimator> ffddr: though looking at the struct... they have some "interesting" fields. e.g. `_start_canary`?
<scientes> how do i just run the compiler-errors.zig tests?
<ffddr> C's designated initializers is zero initialization, so it looks legit
<daurnimator> ffddr: so really, I think your request falls into the category of "there should be a way to modify/annotate c imports" I believe there are a couple of issues around. But I don't recall them mentioning default initialisation, so perhaps add a comment
<ffddr> Maybe you recall the most relevant issue?
<daurnimator> ffddr: is related.... can't find a matching high level issue
<ffddr> oh, missed you message :)
<daurnimator> I'm trying to find an issue that mentioned passing a prefix to @cImport e.g. `sg_` and that the returned "library" would only be those symbols
<ffddr> super relevant issue about sokol specifically :)
very-mediocre has quit [Read error: Connection reset by peer]
dec05eba has joined #zig
<dec05eba> Does anyone have any good idea on how autocomplete for code in zig? the issue is that when you want to autocomplete you have an expression that isn't finished so it's a compilation error and comptime code wont run, so you cant take advantage of the zig parser for that, if you want autocomplete that works properly and even with comptime evaluated types
<dec05eba> on how to make*
darithorn has joined #zig
<dec05eba> i was thinking of something like cquery/ccls, that uses clang itself to give proper autocomplete for c++
<dec05eba> but for zig, using zig parser
dec05eba has quit [Quit: leaving]
very-mediocre1 has joined #zig
Akuli has joined #zig
tgschultz has quit [Ping timeout: 276 seconds]
tgschultz has joined #zig
tgschultz has quit [Ping timeout: 250 seconds]
tgschultz has joined #zig
very-mediocre1 has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
andersfr has joined #zig
andersfr has quit [Client Quit]
sourgrasses has quit [Ping timeout: 272 seconds]
dimenus has quit [Ping timeout: 245 seconds]
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
FireFox317 has joined #zig
<FireFox317> dec05eba: In the latest stream of andrewrk he talks about this issue.
<FireFox317> Which also includes the issue with documentation for comptime stuff
<FireFox317> generating documentation*
sourgrasses has joined #zig
sourgrasses has quit [Ping timeout: 245 seconds]
ntgg has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
very-mediocre has quit [Read error: Connection reset by peer]
Aransentin has quit [Remote host closed the connection]
darithorn has quit [Quit: Leaving]
<ntgg> are the fields TypeInfo.Enum in order?
<ntgg> if I do fields[@enumToInt(...)] would I get the EnumField for it?
<andrewrk> the fields are guaranteed to match the declaration order in the source
<andrewrk> declarations in type info are not in any order, and it's questionable that they even belong in type info at all
<andrewrk> all tests passing in llvm9 branch
dbandstra has joined #zig
tgschultz has quit [Ping timeout: 252 seconds]
tgschultz has joined #zig
very-mediocre has joined #zig
tgschultz has quit [Ping timeout: 245 seconds]
tgschultz has joined #zig
<Sahnvour> emekankurumeh[m]: did you have stack traces working in zig compiler's signal handler you added recently ?
<gonz_> Switching on strings; yes/no in the future?
<andrewrk> gonz_, not currently planned but I'd consider a proposal.
<andrewrk> the null hypothesis is an if-else chain with mem.eql
<andrewrk> which, in my opinion, is quite reasonable to read and write
<gonz_> Yeah, I think I'm mostly just spoiled. I also remember thinking "Why can't I use this on strings?" back in the day the first time I used `switch`
<gonz_> I figured I would ask because I couldn't find an issue about it.
<gonz_> I'm not going to make a proposal for it without more well-formed opinions through projects.
tgschultz has quit [Ping timeout: 264 seconds]
tgschultz has joined #zig
<gonz_> Principally I'm here because I don't really want more features than what's in atm. I don't have "that one feature" that I want to add because I've already used pretty much everything up to Idris at this point and I'm not sure there's much more net positive to gain.
tgschultz has quit [Ping timeout: 245 seconds]
<Sahnvour> I'm curious, what did you use Idris for ? looks very interesting
tgschultz has joined #zig
<gonz_> Just playing around with it, really. I used it now mostly as an example of the higher end of the spectrum. Admittedly, it's also a lateral move from most languages.
<gonz_> I wrote some statically typed state machine stuff in it. There's a v2 coming out that also adds quantified/linear types which is looking very interesting.
<ntgg> I can't seem to return a union(enum) variant that is void from a function that returns an error
<ntgg> how do I do that?
andersfr has joined #zig
andersfr has quit [Client Quit]
<mikdusan> ntgg: `0 => return Foo { .A = {} };`
darithorn has joined #zig
<emekankurumeh[m]> Sahnvour: stack traces were working the last time I checked
<Sahnvour> emekankurumeh[m]: we're talking about stack traces when the _compiler_ crashes yeah ? I recall you work on mingw, what's your linker to build zig in this env ?
<Sahnvour> asking because I'm trying to make the feature actually work with msvc and it requires substantial improvements to our coff/pdb code
very-mediocre has quit [Read error: Connection reset by peer]
Ichorio has quit [Ping timeout: 264 seconds]
<emekankurumeh[m]> you mean in stage 0?
<emekankurumeh[m]> if so then no, u use gcc to compile and lld to link so i don't have pdb files.
<Sahnvour> stage1, but yes
<Sahnvour> so this legit needs more work
<emekankurumeh[m]> are the pdbs be generated and found for stage 0?
<Sahnvour> if you instruct cmake to target RelWithDebInfo, you have zig.pdb, now I'm fixing the loading part
<Sahnvour> it works if LLVM is used to compile zig, but not cl.exe/link.exe, our support for coff and pdb is too minimal
<emekankurumeh[m]> what about debug mode?
<Sahnvour> debug mode also produces a pdb, but doesn't affect the zig code trying to read it
tgschultz has quit [Ping timeout: 268 seconds]
tgschultz has joined #zig
andersfr has joined #zig
andersfr has quit []
<scientes> I can't download Build Tools for Visual Studio 2019
<scientes> I just get an error
<scientes> I can't exactly fix the build issues on OSX and Windows if I can't build zig on those platforms
<ntgg> I'm getting different results for something that as far as I can tell shouldn't happen
<ntgg> In the commented out test fails, but only if line 65 is there
<ntgg> If line 65 isn't there it works fine
<ntgg> (and the tests testing line 65)
<scientes> are we building zig with msvc or clang?
<Sahnvour> for the releases ? msvc
<Sahnvour> on the CI too
<Sahnvour> but you can use LLVM on windows if you wish
<scientes> cause I have no way to figure out why my PR builds on linux but not OSX or Windows
<emekankurumeh[m]> which pr?
<scientes> #2914
<scientes> oh wait i just broke it on linux I will fix that
dec05eba has joined #zig
<Sahnvour> dec05eba: about your earlier question, see
<ntgg> if I move the `const val_struct_nested = ...` below the tests for val_struct the tests pass
<dec05eba> I also saw that the creator of cquery has a pull request but it's 1 year old since it was last updated
<scientes> I'm also sick of this caching bug
<scientes> and the inability to turn caching off to get around it
<mikdusan> which bug is that?
<scientes> i don't think it has been reported
<scientes> I just want to get my work done
<scientes> the cache code has a floating point exception
<mikdusan> does `--cache off` help?
<scientes> yes
<scientes> oh no it doesn't
Akuli has quit [Quit: Leaving]
<scientes> I can't reproduce it in the debugger however
<mikdusan> i saw a sporadic floating point exception trying to run tests from your branch yesterday
<mikdusan> but could not narrow it down
<mikdusan> (macOS)
tgschultz has quit [Ping timeout: 245 seconds]
<scientes> yeah probably same thing
<ntgg> Is it a compiler bug or something I am missing?
<scientes> well not being able to reproduce in the debugger is really troubling
<scientes> nothing in valgrind either
dbandstra has quit [Quit: Leaving]
<Sahnvour> do you have a 100% repro (outside of debugger) ?
<scientes> no
<scientes> common bug not 100%
<scientes> *but
<mikdusan> ntgg: looks like stack memory is escaping. not a compiler bug. Value.Object is a _really_ just a pointer to other storage. and you set it on stack, then poof stack is gone.
FireFox317 has quit [Ping timeout: 260 seconds]
<Sahnvour> scientes: really strange
tgschultz has joined #zig
rappet has quit [Quit: -]
<emekankurumeh[m]> scientes: have you tried adding a signal handler for sigfpe?
<scientes> yeah I am going to
<scientes> but do you know how to change stacks in gdb?
<scientes> cause it would be useless unless you can examine the main stack
<emekankurumeh[m]> no, my gdb knowledge is extremely rudimentary
<emekankurumeh[m]> what do you mean by the "main stack"?
<scientes> when you catch a signal
<scientes> you end up with a differn't signal-handler stack
<scientes> and when you return from the signal handler the kernel puts the stack pointer back to where it was
<ntgg> mikdusan: thank you, I think that makes sense. I just make it into an ArrayList or something to fix it, right?
utzig has joined #zig
<mikdusan> ntgg: yes, ArrayList is a good choice
Ichorio has joined #zig
<emekankurumeh[m]> well how does handle that for the segfault handler because stack traces work fine with those if I'm not mistaken
sourgrasses has joined #zig
<scientes> that's becase gdb is catching the signal
<scientes> it never reaches the signal handler of the problem
<scientes> *program
<hryx> scientes: BTW I responded on the github issue. I know that unicode validation was part of your original PR. why not make a PR with just the validation stuff?
<scientes> yes i saw that response
<scientes> Its because the last and most important of my patches is triggering a compiler bug
<scientes> but yeah that is a reasonable response
<ntgg> If i'm storing a thing in a `HashMap(..., <Heap allocated type>)` do I need to loop through and call deinit on all the things inside the hashmap?
<scientes> zig of stage1?
<scientes> in stage1 we don't free memory at all
<emekankurumeh[m]> yes
<Sahnvour> ntgg: yes you do
rappet has joined #zig
<scientes> if this is zig you can also just use a arena allocator
<scientes> and then you don't need to deinit all of them
<Tetralux> Indeed, that would be better than deinitting every single one.
<Tetralux> Esp if you have a lot of them.
<Tetralux> And if your program is about to quit anyway, then just don't deinit.
<scientes> you could also use a tree allocator
<scientes> i don't think zig has that
<ntgg> I'm making a library, so I don't want to just use an arena allocator
<scientes> then yes
<scientes> but you could also force the caller to use the same allocator for all members
<scientes> and then you could stack allocators
<scientes> and then you can just free the outer allocator to free it all
<scientes> especially given that all members will likely be the same size
<scientes> i think this is a reasonable approach
<scientes> you also have to get fancy like this if you want to do a lockless hash table
<scientes> freeing memory is very complicated in lockless structures
<scientes> (in fact impossible)
<emekankurumeh[m]> you have several options for youe deallocation schemes
<emekankurumeh[m]> i.e. hazard pointers, epoch based reclamation to name a few
<Tetralux> .. none of which mean anything to me - I might add xD
<emekankurumeh[m]> tbh they are just more or less buzzwords to me as well
<emekankurumeh[m]> i was just researching threadpools and how to to implement them because without deallocation you memory usage would increase unbounded as you pushed more tasks to the pool
<Tetralux> The allocation comes from copying the "task" into the pool?
<Tetralux> And the deallocation is expected to happen when the thing is done?
<Tetralux> .. and you've copied the answer out?
wootehfoot has quit [Read error: Connection reset by peer]
sourgrasses has quit [Quit: leaving]
<emekankurumeh[m]> well I never got as far as returning stuff from tasks and I never implemented any of those algorithms
<emekankurumeh[m]> i was also going to use async to implement a future like system but async is getting rewritten so I didn't bother
ntgg has quit [Quit: Lost terminal]
_whitelogger has joined #zig
oats has left #zig ["WeeChat 2.5"]
<scientes> ok so there is a caching bug once I fixed my own bug
<scientes> stage0 called stage2_DepTokenizer_init
<scientes> oh it just means that we need to turn off the cache for zig0
<mikdusan> is this manifesting as sporadic floating point exception?
<scientes> so i fixed that
<scientes> also using a debug llvm would have caught it
<scientes> maybe....
<scientes> actually i'm confused, but i fixed it
<mikdusan> yeah zig0 can't use zig userland.
<scientes> so zig0 should just turn off caching
<scientes> so it doesn't craash like that
<mikdusan> so i have a lead on that floating point exception on macOS...
<scientes> so the trick in gdb was turning back on aslr
<scientes> because gdb turns off aslr so its more deterministic
<scientes> but that can change behavior
<Tetralux> wAIT
<scientes> set disable-randomization off
<Tetralux> Turning it OFF changes behavior? XD
return0e_ has quit []
return0e has joined #zig
<Tetralux> Oh - Because the error was only happening on a specific seed that turning it off did not have.
<scientes> that's why it was sporatic
<scientes> anyways,the bug was that I wasn't properly checking the zig types
<Tetralux> Sounds like ASLR is a bad thing then. ;)