ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
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> like, way off? or +1 line?
<MajorLag> Let me check
<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
<kristate> spoke to a room full of young jp programmers about zig -- I have been going around the country lately trying to get more people interested in zig
<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> but yeah needs lots of docs
DutchGh0st has joined #zig
<DutchGh0st> is this function safe?:
<DutchGh0st> pub fn itern(comptime size: usize) [size]void { return undefined; }
<DutchGh0st> since it's void's anyway
jzelinskie has quit [*.net *.split]
cgag has quit [*.net *.split]
diginet has quit [*.net *.split]
diginet has joined #zig
<scientes> the llvm docs are not clear that a co-routine reading on a promise can be destroyed
<scientes> i don't think there is any need for that however
clownpriest has quit [Quit: clownpriest]
clownpriest has joined #zig
<dbandstra> is there an issue for removing the implicit cast from `T` to `*const T` ?
<dbandstra> i saw it mentioned here
<dbandstra> that cast is pretty evil
<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> dbandstra, I'll make an issue for it
<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…]
<andrewrk> I think I mentioned this race condition here:
<scientes> the way to fix it is to make co-routines simpler, not more complicated
<scientes> and handle the rest of it in user-space as i described
<andrewrk> scientes, I don't think your understanding of the situation is accurate
<andrewrk> every coroutine destroys itself
<scientes> with the final suspend
<scientes> but thats not how the llvm docs describe it: destroy is called in the caller
<scientes> i think i am thinking too much of threads, I get threads
<scientes> see, the caller calls destroy, not the co-routine
<andrewrk> it doesn't matter who calls it
<scientes> ok
<andrewrk> it just has to be at a suspend point
<andrewrk> this stuff is really tricky to understand
<andrewrk> even when I'm working on it I spend hours just reminding myself how it works
<scientes> and if a co-routine returns without calling suspend, it does a final suspend?
<scientes> (and then destroys itsself)
<andrewrk> first it does an atomic xchg with the coroutine handle in its own frame
<andrewrk> the other half of the atomic xchg is await
<andrewrk> if the await got in first, then the return destroys itself then tail resumes the awaiter
<andrewrk> if the return got in first, it goes to final suspend, and then the awaiter grabs the return value and then destroys the coroutine
<andrewrk> however now there's even another atomic xchg it does having to do with cancel
<scientes> so can we just get rid of `cancel` without replacing it with anything?
<andrewrk> which is going to have to change, as described by 1363
<scientes> and make that the suspender's responsibility?
<andrewrk> so what happens if you async, but then don't await
<andrewrk> it's a leak
<andrewrk> or what happens if you suspend, but then you decide not to resume it?
<andrewrk> same thing
<scientes> then i proposed a suspendnotfinal, but that requires looking at the promise bits to know if is_cancelled is set, which is UGLY
<andrewrk> what problem are you trying to solve? I think my proposal is sound
<andrewrk> I'm reading this issue again and I don't even see the problem that I wrote
<andrewrk> it can't be in the epoll set and executing at the same time
<scientes> why not?
<andrewrk> it suspends and then puts itself in the set. so if it's in the set then it's suspended
<andrewrk> the proposal is still necessary, I just need a better example