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
v1zix has joined #zig
dbandstra has joined #zig
v1zix has quit [Quit: Page closed]
return0e has quit [Remote host closed the connection]
return0e has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dbandstra has quit [Quit: Leaving]
quc has joined #zig
davr0s has joined #zig
quc has quit [Remote host closed the connection]
quc has joined #zig
stratact has quit [Quit: Leaving]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
quc has quit [Remote host closed the connection]
quc has joined #zig
zolk3ri has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
mahmudov has quit [Remote host closed the connection]
davr0s has joined #zig
noonien has joined #zig
Tobba has quit [Ping timeout: 260 seconds]
Tobba has joined #zig
<MajorLag1>
andrewrk, in 1291 you mention global comptime-persistent state. I think that would be generally useful for comptime, for instance being able to keep a registry command implementations for a built-in console, or building a union type of all registered entities.
<companion_cube>
weird, zig seems to be mostly expression-based, but not totally (in particular the use of `break` for returning values from blocks…)
bheads__ has joined #zig
bheads_ has quit [Ping timeout: 264 seconds]
bheads_ has joined #zig
bheads__ has quit [Ping timeout: 244 seconds]
bodie__ has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<bodie__>
reminds me of Leiningen somehow :D
<andrewrk>
MajorLag1, I think we should make note of all these use cases, and have an answer for what's the best way to implement it in zig
<GitHub61>
zig/master 5d4a02c Andrew Kelley: Merge pull request #1307 from ziglang/cancel-semantics...
Bas_ has joined #zig
quc has joined #zig
bheads has joined #zig
allan0 has quit [Ping timeout: 240 seconds]
allan0 has joined #zig
wilsonk_ has quit [Read error: Connection reset by peer]
aesl has quit [Quit: Leaving]
varion has joined #zig
quc has quit [Ping timeout: 260 seconds]
<varion>
there's no HTTP request library or anything for zig yet, right?
<andrewrk>
varion, correct
<varion>
cool, thanks. it looks like all the http stuff is planned, though
<andrewrk>
however, event-based I/O progress has been chugging along recently
<andrewrk>
correct
<varion>
i'm following zig closely. it's pretty much exactly what i wanted out of d's "better c", but.. you know... good?
<andrewrk>
lol, thanks for the compliment. let's be friendly to our D friends though :)
<varion>
i think d is great! i just can't use it for my exact purposes
<varion>
and d leaves ios/android on the floor, which is too bad
<andrewrk>
at some point here the zig package manager is going to drive the http request library
<andrewrk>
and naturally, to test the http request library, we'll want an http server library
<varion>
right, go-style minimal implementation?
<andrewrk>
certainly minimal. I'm not sure what all go-style implies
<varion>
i just meant that it comes in the std, but it's as absolutely minimal as they thought plausible
<andrewrk>
ah
<bheads>
dont forget HTTPS
<andrewrk>
yes one of the goals for the standard library is that the scope is limited enough so that the std lib can get to a point where it is "done"
<varion>
that's one of the parts i'm excited about
Bas_ has quit [Ping timeout: 252 seconds]
wilsonk has joined #zig
<varion>
i love nim, for example, but it's been chasing 1.0 for years because the std is still ill-defined. it's an amazing language, but zig is significantly smaller on purpose
<varion>
"small on purpose" is about the best thing i could say for a language, haha
<MajorLag1>
I'd generally agree with that.
<bheads>
Also I was messing with HTTP in zig this weekend and ran into issues with the current read function, it fails when sockets return EAGAIN so I have to roll my own...
<andrewrk>
bheads, now that I have a better handle on coroutines I can make the api much better
<andrewrk>
wait that sounds like a bug, not an API problem
<bheads>
It was more of a problem with async IO
<bheads>
its a nonblocking socket that wanted to wait
<andrewrk>
that's supposed to work perfectly with async I/O
<andrewrk>
when you get EAGAIN you put the socket fd in the epoll set and suspend,
<andrewrk>
then get resumed when the socket has data
<bheads>
correct
<bheads>
all that is missing in the std lib right now
<andrewrk>
oh yeah I remember I skipped a bunch of things
<andrewrk>
anyway, instead of giving an async function handler to tcp server, tcp server will create a channel of requests, that you can get() from
<bheads>
I know you were working on an async io lib so I figured you would come back to that
<andrewrk>
I think that solves the catch unreachable
<bheads>
the other read function should be fixed still
<andrewrk>
agreed
<bheads>
bot sure what the best way to fix it was though
<andrewrk>
apologies for the broken implementation. that part of the std lib is very much under construction-
<bheads>
you want it to return the bytes read and the EAGAIN error
<bheads>
no worries
<bheads>
I was just using it to learn a bit about the coro stuff you have been crancking out
<bheads>
it always tricky to design api's like this
<bheads>
multiple returns seem like an easy solution
<bheads>
but this is an odd case
<andrewrk>
I think it should return the bytes read if it has any, and only returning 0 means EOF
<bheads>
right but should the read function do that waiting?
<bheads>
in my little test I had read return the length on EAGAIN, but the read got stuck in a loop when I was testing with wget, but worked correctly with curl... not sure what I was missing
<bheads>
but not a big issue, I was just messing around while watching TV
<andrewrk>
bheads, no, the read function should never wait - but if you open the socket with non-blocking it won't block
mahmudov has joined #zig
zolk3ri has quit [Quit: leaving]
noonien has quit [Quit: Connection closed for inactivity]