04:42 <achambe> Just had an idea

04:42 <achambe> that json parser by tiehuis

04:43 <achambe> I wonder if coroutines would be cleaner than the switch based state machine

04:44 <achambe> I guess it would need to wait for the stacksize reflection

10:26 <alexnask> @acahmbe Why would we need the stacksize reflection to use coroutines in that case (the json parser)?

10:27 <alexnask> Isn't the only error we need to worry about the allocation failure on the coroutine's state?

10:27 <achambe> alexnask: well the current json parser is zero allocation

10:28 <alexnask> I assume the coroutine's stack is also allocated by the async allocator

10:28 <achambe> yeah, it would work, but it is actually a downgrade

10:28 <alexnask> I'm pretty sure it uses an ArrayList to store the values

10:29 <alexnask> I agree, I was just wondering why you talked about the stacksize reflection, if I was missing something about LLVM/zig coros

10:29 <achambe> Hmm, I was just thinking it was needed to make a fixed size coroutine stack

10:29 <achambe> or however it works

10:29 <achambe> as a struct

10:29 <achambe> meh, im just talking nonsense :)

10:29 <alexnask> I'm not too familiar with the coroutine implementation to be honst

10:30 <achambe> there are plenty more parsers needed in the future anyway.

10:30 <alexnask> I'd have to make sure

10:30 <alexnask> I'm pretty sure you would end up with similar codegen, LLVM is really good at optimizing the coros away

10:31 <achambe> yeah, I am a bit curious about them, haven't had a chance to see even the C++ coroutines

10:32 <alexnask> There are a couple of interesting cppcon videos thawt talk about the C++ coro proposals + some low level implementation details in the LLVM size

10:32 <achambe> used for anything big**

10:32 <alexnask> in the LLVM side**

10:33 <alexnask> Basically the coros get compiled down to state machines anyway, so with inlining + memory allocation elision I'm confident you'd get back something similar to the original state machine

10:34 <alexnask> If LLVM can elide the allocator calls, which I'm not sure it can if the allocator is not malloc/free

10:41 <GitHub65> [zig] tiehuis pushed 1 new commit to master: https://git.io/vpwKa

10:41 <GitHub65> zig/master d7b0299 Marc Tiehuis: Fix bigint multi-limb shift and masks

17:29 <alexnask> I'm getting really weird behavior with my ZigList sbo implementation

17:30 <alexnask> I suspect some buffer is written to without a resize but this should crash with the current implementation too

17:55 <alexnask> Or perhaps we are copying a small buffer then writing to the copy, that should probably work (although it sounds like a bug in the original implementation too, each buffer should own its own memory)

21:15 <MajorLag> Given that there is no official documentation for the build system, where's the best place to see what my options are? I want to pre-process some files and embed the results (using @embedFile or some other mechanism). Unfortunately I can't just use comptime for this due to the lack of most pointer stuff working in comptime.