02:02 <scientes> is there a way to tell if you are running in a co-routine, or on the main thread?

02:03 <scientes> Thorn, someone got it to compile for avr https://github.com/ziglang/zig/issues/1373

02:04 <scientes> Thorn, it should work for any arch that llvm supports

02:05 <scientes> Thorn, and there is a OS written in Zig https://github.com/AndreaOrru/zen

02:22 <andrewrk> scientes, that's probably a code smell

02:22 <andrewrk> can you explain your use case?

02:26 <scientes> I'm trying to write a go-like async-io, where read adds to a epoll (or equiv.) list

02:26 <scientes> and then resumes when the fd is ready to be read

02:27 <scientes> but i can do it without that

02:28 <scientes> *without knowing if thread is a co-routine

02:29 <scientes> I can use duck typing

15:14 <wink_> I've created zig-benchmark: https://github.com/winksaville/zig-benchmark comments suggestions welcome!

15:32 <andrewrk> wink_, volatile doesn't block optimization

15:32 <andrewrk> in order to prevent optimizations from ruining your benchmark, you have to output the data that you calculated

15:33 <andrewrk> doing a volatile store of data is a form of output though

15:41 <wink_> Not sure what you mean by "you have to output the data that you calculated" but volatile does remove some optimizations, because if I use constants the add operatoin will be, correctly hoisted outside the loop, where as using volatile I see loads and stores.

15:45 <wink_> I found that I need to look at the assmebly output so I can see what's actually being measured.

16:01 <andrewrk> volatile makes loads and stores considered to have side effects, but that's all it does

16:02 <andrewrk> the optimizer is free to do anything as long as all the volatile operations are preserved and in the same order

16:23 <wink_> yep, which is why I looked at the assembly output to verify the loads and stores were inside the loop. Of course the loop has been unwound to 8 times and the upper 64 bits of the r: u128 isn't stored until after the loop :)

16:43 <wink_> I've updated the test to do u128 add and README.md to include how to generate the asm as well as having the asm loop.

20:42 <MajorLag> andrewrk, I'm not sure what can be done about it, but comparing two tagged unions for equality is especially nasty. Getting the active tag of each is simple enough, but using that to get and compare the value rquires an inline for over the typeInfo UnionFields comparing the tag values. Anything else I've tried has lead to `unable to evaluate constant expression`.

20:42 <andrewrk> I noticed this the other day

20:42 <andrewrk> we can open an issue to track our discontent even if we don't have a proposal yet

20:52 <MajorLag> problem is, the error isn't wrong. without the comparison between the fields taking place inside the inline loop, it can't work. Only thing I've come up with is to abstract the nastiness and use some kind of callback to a generic function, but that takes more lines of code to set up than you end up abstracting away.