ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
atk has quit [Quit: Well this is unexpected.]
atk has joined #zig
<MajorLag>
<3
<andrewrk>
MajorLag, can you confirm that it works for you in your setup?
<andrewrk>
there might be a couple easily fixable issues
<MajorLag>
Sure, let me see what I can find
<MajorLag>
Gotta wait for the Artifact though.
<andrewrk>
oh yeah. I hope it finishes in time
rain1 has joined #zig
<andrewrk>
part of my motivation for #1416 is to make the CI runs faster
<MajorLag>
Yeah, I saw the discussion about hitting the limit
<andrewrk>
I think we got lucky
<andrewrk>
it just finished
noonien has quit [Quit: Connection closed for inactivity]
<MajorLag>
hmm... it doesn't always seem to be pointing to the correct lines.
<andrewrk>
oh nice! I didn't remember that you got png lib done
<MajorLag>
It's usable but the code is in a sorry state.
<MajorLag>
I'm working on it, along with some other tooling. I'm using it as a tesbed for the other tooling actually, because it exposes the pain points in the API when I start incorperating it. Anyways...
<MajorLag>
Sorry, I'm not at home and there's a lot of latency on this RDP session. This will be a minute
<andrewrk>
MajorLag, oh, this is an error return trace
<andrewrk>
so it's showing you all the places that error.InvalidDistance was returned from a function
<andrewrk>
I would expect the carot to point at the try's and return's
<andrewrk>
sometimes I noticed it points at the next line
<MajorLag>
The second link is a failed assert
<MajorLag>
It looks like it is off in debug/index.zig by a line or two, but the next line reported is off by about 8
<andrewrk>
hmmmm
<andrewrk>
I'm reproducing it and will investigate. thanks!
return0xe has quit [Remote host closed the connection]
return0xe has joined #zig
davr0s has joined #zig
clownpriest has quit [Quit: clownpriest]
reductum has joined #zig
kristate has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
_whitelogger has joined #zig
return0xe has quit [Remote host closed the connection]
return0xe has joined #zig
kristate_ has joined #zig
kristate has quit [Ping timeout: 252 seconds]
btbytes has joined #zig
btbytes has quit [Ping timeout: 252 seconds]
reductum has quit [Quit: WeeChat 2.2]
kristate_ has quit [Ping timeout: 252 seconds]
dbandstra has quit [Quit: Leaving]
kristate has joined #zig
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
kristate has quit [Ping timeout: 272 seconds]
kristate has joined #zig
kristate has quit [Ping timeout: 240 seconds]
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
clownpriest has joined #zig
noonien has joined #zig
clownpriest has quit [Quit: clownpriest]
davr0s has joined #zig
clownpriest has joined #zig
ManDeJan has joined #zig
kristate has joined #zig
<kristate>
andrewrk is working hard -- good to see the forward progress
<scientes>
cool! If I patched the linux kernel adding a futex2() that works on byte-sized arguments there would only be a need for something like WTF::ParkingLot on non-Linux platforms
<scientes>
probably think about that later however, #1363 and #1457 for now
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<scientes>
kristate, get some sleep :)
<scientes>
I wish i could see async, cancel, ans suspend in zig, instead of in compiler-speak
<scientes>
*await
<andrewrk>
me too
<scientes>
even the self-hosted compiler will have that problem
SimonN has quit [Remote host closed the connection]
SimonNa has joined #zig
atk has quit [Quit: Well this is unexpected.]
atk has joined #zig
davr0s has joined #zig
redj has quit [Disconnected by services]
redj has joined #zig
hooo has joined #zig
<hooo>
we need automated docs from the std library
reductum has joined #zig
dbandstra has joined #zig
<scientes>
hooo, do it!
<hooo>
scientes: the problem is that the functions themselves arent really commented
<hooo>
I think there should be a convention inside the std library that each function has a unit test to show basic usage and then I could include those in an std library documentation
<hooo>
because right now it's hard to figure out how to do anything, how to split a string, how to open a file, how to [xyz]
<scientes>
if you know how to do it in C you can usually figure it out
<scientes>
reading the llvm co-routine docs I feel like promises wern't ever designed to work between threads, as that would require llvm creating calls to futex() and equilivent
<scientes>
but if llvm can do that, then its designed to be optimized in a way go-routines cannot
DutchGh0st has quit [Ping timeout: 252 seconds]
hooo has quit [Quit: Page closed]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
reductum has quit [Quit: WeeChat 2.2]
davr0s has joined #zig
kristate has quit [Remote host closed the connection]
<andrewrk>
scientes, llvm coroutines are just function calls
<andrewrk>
suspend is return; resume is function call
<andrewrk>
await is zig's concept
<scientes>
but what about reading from a promise
<andrewrk>
it's just a struct
<andrewrk>
the coroutine function reads/writes from memory that it allocates for itself (the coroutine frame) and you can put other stuff in there too. it's just memory that has the same lifetime as the coroutine
<scientes>
if the promise is being fufilled from another thread you have to use futex()
<andrewrk>
not true - zig has lock-free thread-safe async/await
<scientes>
otherwise you will spin waiting for the other thread
<andrewrk>
that's not how it works
<andrewrk>
await suspends itself, and puts its own handle in the frame of the target
<andrewrk>
when the target returns, it sees if someone put a handle in it, if they did it resumes them with a tail call after destroying itself
<andrewrk>
otherwise it suspends, and doesn't destroy itself until the await happens
<scientes>
but when await suspends where does execution go?
<scientes>
(if it doesn't block on futex_wait())?
<andrewrk>
same place execution goes if you do suspend - either to the function which called async or the function which called resume
<andrewrk>
when you async, the function immediately executes - like a function call - and control flow returns at the first suspend point, which is either suspend or await
<andrewrk>
futexes are only needed for the thread-safe queue that std.event.Loop uses
<andrewrk>
zig coroutines have no OS dependencies - they can be used in OS programming
<andrewrk>
scientes, oh, are you talking about the fact that threads sharing memory must use mutexes?
<scientes>
when you multiplex co-routines onto threads
<scientes>
thats what i'm getting confused about
<andrewrk>
i'm happy to explain more, what part are you confused about?
<scientes>
i think i understand await better now, should i still generally assume co-routines are running concurrently (even when they arn't)
<andrewrk>
I think the zig std lib should generally assume that
<scientes>
so the allocator is for the stack of the co-routine?
<scientes>
and do you see the race condition that cancel with the is_cancelled bit gets us into when we use co-routines in a multi-threaded context?
<scientes>
where you have an event that needs to be handled and cant
<andrewrk>
yes the allocator is for the stack *frame* (only the one frame, not an entire stack)
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]