00:33 <dbandstra> andrewrk, what are you working on these days? i've been out of the loop

00:34 <dbandstra> copy-elision-2?

01:12 <andrewrk> dbandstra, that's right. the first attempt turned out to be the wrong approach, I think. I'm not happy with how the code turned out so far

01:12 <andrewrk> it's a prerequisite for fixing coroutines

01:24 <andrewrk> I took off friday and yesterday to travel for a national arcade game tournament, but now I'm back in action on Zig

01:49 <dbandstra> haha cool

01:52 <dbandstra> i haven't even looked at the async/coroutine side of zig yet, am i right in thinking they're totally in flux atm, even the syntax?

01:52 <andrewrk> yes

01:54 <dbandstra> was there some proposal where the read/write functions of std streams would become asynchronous functions?

01:54 <dbandstra> meaning i guess you wouldn't be able to use a stream without an allocator?

01:54 <andrewrk> in the coroutines rewrite, coroutines no longer require allocators

01:55 <dbandstra> oh cool

01:55 <andrewrk> the memory has to go somewhere; but it becomes very simple to have the memory go into the current stack frame (or current coroutine frame)

01:55 <andrewrk> and it is equally simple to have the memory be in a struct, preallocated, or globally allocated, etc

01:56 <dbandstra> do coroutines execute synchronously till the first yield?

01:56 <andrewrk> yes

01:56 <andrewrk> if you want to not execute till the first yield, you can just do: `var frame: @Frame(coroutine_function) = undefined`

01:57 <dbandstra> so that means that, if base instream/outstream read/write was async, and you had a simple implementation (like SliceInStream) which returns right away, there'd be no extra overhead?

01:59 <andrewrk> there would be overhead because `return` in an async function does an atomic rmw so that a thread racing for `return` and a thread racing for `await` have the desired effect. however for an async function that has no suspend points, zig could make an optimization to omit that. because it would be impossible for that situation to occur

01:59 <andrewrk> an async function that returns right away has no suspend points

02:00 <dbandstra> ok

02:01 <dbandstra> i guess the optimization wouldn't work if you have a function which just takes a poitner to an std.io.InStream, but then again such a function needs to be written async style anyway

05:48 <dbandstra> andrewrk, do you know why my audio mixing callback might not be getting called at all? https://gist.github.com/dbandstra/34472f9608d8846abb151072b0367434

05:49 <dbandstra> if you don't see anything wrong with the "extern" then i'll keep trying myself to diagnose it

05:49 <andrewrk> dbandstra, it looks fine to me. it seems most likely to be an SDL API thing

05:49 <dbandstra> ok

05:49 <dbandstra> i'll have to do a c equivalent of this and see if that works

05:50 <andrewrk> bummer

05:50 <dbandstra> i was using SDL_Mixer formerly, but now i want to do a custom mixer

05:52 <andrewrk> is there perhaps an error log that you are not seeing that can be enabled?

05:52 <dbandstra> not that i know of

05:55 <andrewrk> if you're not getting a segfault, it seems extremely unlikely to me that there is a zig compiler bug causing a function to not get called

05:55 <andrewrk> but your code does look correct too

05:55 <dbandstra> all i know is i hear no sound, std.debug.warn in the callback does nothing, nor does @panic

05:59 <dbandstra> c version seems silent too, i'm doing something stupid :p

06:05 <andrewrk> I apologize for the fact that I am relieved :)

06:05 <dbandstra> hehe

06:05 <dbandstra> i'm also glad that nothing's wrong with zig here

06:09 <dbandstra> the problem: i was using SDL_OpenAudioDevice (new fangled api) instead of SDL_OpenAudio, and should have been using SDL_PauseAudioDevice instead of SDL_PauseAudio

06:10 <andrewrk> ah. I remember that now. apologies for not spotting it

06:10 <andrewrk> (that said, it's a shame the SDL API couldn't catch it too)

06:11 <andrewrk> I think the concept of "debug mode runtime checks" is under-valued

06:13 <dbandstra> this is kind of spooky actually, SDL_OpenAudio returns device ID 1, where SDL_OpenAudioDevice (with device name = NULL) returns ID 2

06:13 <dbandstra> if those are actualyl different devices, then this bug only manifested because of my hardware config

06:13 <dbandstra> SDL_PauseAudio(x) just runs SDL_PauseAudioDevice(1, x)

06:16 <dbandstra> anyways

13:30 <Hejsil> andrewrk, I'm finding a handful of syntactic ambiguities: fn(comptime a: {}) void (comptime param or comptime labeld block?)

15:38 <MajorLag> Can anyone tell me if bitfields in Zig begin at LSB always or if it is machine endianess dependant? My guess is that it relies on LLVM for this and that LLVM uses MSB on big endian, but I am having trouble verifying.

17:12 <andrewrk> MajorLag, machine endianness dependant

17:58 <MajorLag> Thanks, now I think I know enough to add arbitrary packed struct reading w/ endian correcting.