ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
steveno has quit [Quit: Leaving]
m4ge123 has joined #zig
fsateler has joined #zig
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
davr0s has joined #zig
m4ge123 has quit [Read error: Connection reset by peer]
m4ge123 has joined #zig
davr0s has quit [Quit: Textual IRC Client:]
steveno has joined #zig
davr0s has joined #zig
SimonNa has quit [*.net *.split]
allan0 has quit [*.net *.split]
presiden has quit [*.net *.split]
commander has quit [*.net *.split]
Summertime has quit [*.net *.split]
so has quit [*.net *.split]
commander has joined #zig
Summertime has joined #zig
allan0 has joined #zig
so has joined #zig
SimonNa has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
<bheads> interesting talk on coroutines
<andrewrk> bheads, ah, this is the person who implemented LLVM coroutines
<bheads> the one your having issues with being slow?
<andrewrk> yes and buggy
<andrewrk> we have to put "optnone" on all coroutines
<andrewrk> hmm I wonder what his point is about nano-coroutines beating straightforward hand-crafted state machine
<andrewrk> my understanding is the llvm coroutines are equivalent to a hand-crafted one (and looking at the LLVM IR it appears to be so)
<andrewrk> maybe he's talking about vaporware
<andrewrk> I'll have to watch this in full later
<bheads> no its more about the algorithm
<bheads> the big thing he adds is prefetching
<bheads> which coros make writing easy
<bheads> the state machine code works fine, its just a lot more code to write and maintain
<andrewrk> I see. yes that's certainly true
<andrewrk> in the coroutines rewrite, zig will be generating the state machine
<bheads> have you come up with a plan for generators?
<andrewrk> either as a switch or an array of function pointers
<andrewrk> I can't remember where I landed on generators
<andrewrk> either way the rewrite brings us closer to generators if anything, not farther away
<bheads> interesting, could you also put the yeild return on the top of the frame?
<andrewrk> with the rewrite, you could construct a coroutine frame and initialize it statically without invoking it
<andrewrk> e.g. your coro frame could be global static data that you initialize, and it gets initialized pre-suspended
<bheads> yeah I like your plan for dealing with the call frame, opens up lots of safty and performance options
<bheads> on a side note it looks like you got a good chunk of the copy elision work done!
<andrewrk> yeah it's coming along. I'd say the concept is proven and now it's just the marathon of code changes
<andrewrk> here's a nice example:
<andrewrk> note the fewer number of alloca and memcpy instructions on the right
<andrewrk> it's a good thing this is early in the release cycle though. it's unavoidable that this will introduce new bugs
<bheads> just need a few projects to help find them
<bheads> I had a small project I was going to write but the coro rewrite and the parser rewrite put that on hold
<andrewrk> yeah sorry about that. and is there a 0.3.0 issue blocking you too?
<bheads> Oh I understand, nothing in .3 is blocking other then having to deal with possible lang changes to rewrite. I am destracted with a bathroom remodel at home (ie I should be finnishing that over working on side projects :)
<bheads> Oh and now I remember, that code I was writting was dealing with GUI, so interfaces was missing, I got it working but wasn't very clean
<andrewrk> fair point, I haven't tried to make a gui with zig yet
<bheads> and the last thing I tried was using zig with godot and ran into
<andrewrk> ah right
<andrewrk> I should take another pass at that
<andrewrk> so much to do
<bheads> lol no pressure
tobbez has quit [Ping timeout: 252 seconds]
tobbez has joined #zig
porky11 has joined #zig
m4ge123 has quit [Ping timeout: 245 seconds]
m4ge123 has joined #zig
porky11 has quit [Ping timeout: 264 seconds]
steveno has quit [Quit: Leaving]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
DutchGh0st has joined #zig
<DutchGh0st> is it sound to do this?: return @ptrCast(*T, @alignCast(@alignOf(T), &slice[0]));
<DutchGh0st> slice is a slice of bytes, with the size of @sizeOf(T)
davr0s has joined #zig
<DutchGh0st> if it is, I might have just created my first mini allocator that builds on top of another allocator \o/
<DutchGh0st> expected type 'fn(*Allocator, []u8, usize, u29) Error![]u8', found 'fn(*Allocator, []u8, usize, u29) Error![]u8'
<DutchGh0st> what's the difference :O
<andrewrk> DutchGh0st, does that error message have hints? I added hints to that error
<andrewrk> as far as alignment, zig will catch at runtime if your alignment is wrong
<DutchGh0st> well
<DutchGh0st> I just yanked the realloc function from std's arena allocator
<DutchGh0st> that just worked
<DutchGh0st> huh
<DutchGh0st> now I changed my error types
<andrewrk> DutchGh0st, congrats on your first allocator :) what does it do?
<DutchGh0st> and I get the same in `alloc`
<DutchGh0st> its a linked list, that allocates 1024 bytes using another allocator, and it just uses an index to track how much of the slice is used
<DutchGh0st> and if the slice would go full, it allocates a new one
<DutchGh0st> its perhaps not production ready, but at least I could write it :)
<andrewrk> what does it do on free() ?
<DutchGh0st> nothing
<andrewrk> this sounds a lot like ArenaAllocator
<DutchGh0st> it sort of is haha
<andrewrk> that's neat though. if it's better for your use case, then great
<DutchGh0st> if I look in the strace, I see 2 mmaps, and 2 munmaps...which should happen looking from main
<DutchGh0st> This was easier to write in Zig that in Rust, which is funny
<DutchGh0st> oh gosh, you can even see zig sourcecode in gdb's text user interface? o.O
<andrewrk> :)
<DutchGh0st> oh andrewrk, a question,
<DutchGh0st> when you open up Stdin, using the function in getStdIn() from,
<DutchGh0st> should you close it? or is that not needed because its stdin?
<andrewrk> it's not needed
<andrewrk> I should add that to the doc comments
<DutchGh0st> Ohh okey haha, I didn't know that ^^
<DutchGh0st> yeah that'd be nice
<andrewrk> on posix, getStdIn is basically return 1
<DutchGh0st> ahh
DutchGh0st has quit [Quit: - A hand crafted IRC client]
<andrewrk> my stream today will be a short demo of the Copy Elision branch of Zig, live coding a small standard library bugfix or feature, and Q&A. 13 minutes from now.
porky11 has joined #zig
porky11 has quit [Ping timeout: 276 seconds]
wilsonk has quit [Read error: Connection reset by peer]
m4ge123 has quit [Read error: Connection reset by peer]
tolitius has joined #zig
m4ge123 has joined #zig
emekoi has joined #zig
tolitius has quit [Quit: zzz...]