ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<adrusi>
What's the recommended way to do networking in zig? Should I just use libc?
<MajorLag2>
Oh man, I can't believe I didn't try this sooner: loading large structs with data from a file using a generic function and @typeInfo. You might think "couldn't you just cast a slice of bytes directly?", but no, not in this case because the file is BE. So much tedious boilerplate just dissappeared.
darithorn has joined #zig
<MajorLag2>
@adrusi I think the basic socket handling syscalls might be in the posix portions of the stdlib, at least for linux, but yeah you should probably call C right now.
<adrusi>
alright, thanks
<MajorLag2>
Andrewrk has been working on getting a basic HTTP server running using the async functionality, but I'm not sure where he's at.
tiehuis has joined #zig
<MajorLag2>
On the subject of @typeInfo though, this does raise a question: does @typeInfo report fields in the order they are writen, or in the order they are in memory? IIRC Zig doesn't actually do any struct re-ordering right now, but what should the behavior be?
<GitHub80>
zig/master e514454 Marc Tiehuis: Make zig fmt exit with error on any parse errors...
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
return0e has quit [Ping timeout: 260 seconds]
davr0s has joined #zig
return0e has joined #zig
return0e_ has joined #zig
return0e has quit [Ping timeout: 265 seconds]
return0e has joined #zig
return0e_ has quit [Ping timeout: 256 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
darithorn_ has quit [Ping timeout: 268 seconds]
darithorn_ has joined #zig
davr0s has joined #zig
xenial64-user has joined #zig
xenial64-user has quit [Read error: Connection reset by peer]
cenomla has joined #zig
cenomla has quit [Quit: cenomla]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Ichorio has quit [Ping timeout: 260 seconds]
king_button has joined #zig
davr0s has joined #zig
<king_button>
Hi. Can Zig do incremental builds, or are there plans for them like stated in jan 2017 on github? I'd like to build a game that has subsecond recompilation of small changes. I believe this is possible in C if you keep your header dependencies small and controlled.
qazo has joined #zig
s455wang has quit [Quit: WeeChat 1.6]
s455wang has joined #zig
kicking_tires has joined #zig
<king_button>
..but I don't want to have a secondary job as a header hacker, so I guess I'll try this language. I know a compilation from barely nothing does take a full second, but that's fine.
kicking_tires has left #zig ["Leaving"]
king_button has quit [Remote host closed the connection]
king_button has joined #zig
qazo_ has joined #zig
qazo has quit [Read error: Connection reset by peer]
qazo_ is now known as qazo
<andrewrk>
king_button, that's planned to be implemented only in the self-hosted compiler, which so far we have a parser, but no codegen
<andrewrk>
we don't have fast compilation yet but it will be a primary focus soon
<andrewrk>
I'm also thinking about hot code swapping
qazo has quit [Read error: Connection reset by peer]
Ichorio has joined #zig
<n_1-c_k>
Could someone help me with my toy program? I managed to get the compile error "cmd-line-args.zig:17:48: error: expected type '?NextError![]u8', found '?NextError![]u8'", https://pastebin.com/YjU5aiga
<andrewrk>
n_1-c_k, I'm looking
<n_1-c_k>
andrewrk: thanks! It does work if I remove ": ?NextError![]u8", so I guess I should...
<MajorLag2>
hmmm... the NextError types are considered different maybe?
<andrewrk>
yeah I've been meaning to improve the error message hints for these kind of errors
<n_1-c_k>
Is it better to let the type be implicit? I was hoping to be able to tell from the source what type I'm dealing with, if possible?
<MajorLag2>
It is more common to leave the type implicit, better is a matter of opinion.
<n_1-c_k>
I'd tend to prefer explicit, or is it considered bad style? Is it even possible?
<MajorLag2>
Ok, so what happened here is you declared the NextError error set as a different type than the NextError that the iterator returns.
<MajorLag2>
NextError is just `error {OutOfMemory};` so `const NextError = error {OutOfMemory};` should also work.
<n_1-c_k>
Oh that's better! I wonder, should I have found out that declaration? Is it a matter of going through the stdlib source?
<MajorLag2>
but then if we ever change that your code would break
<MajorLag2>
yeah, there are no docs for the stdlib yet (should be coming soon via automated doc generation I think), but the stdlib source is pretty easy to read.
<n_1-c_k>
MajorLag2: thanks, I'll try to hunt it down.
<andrewrk>
n_1-c_k, you can also do @compileLog(@typeOf(foo)) anywhere to find out what type something is
<n_1-c_k>
andrewrk: cool, thanks!
<andrewrk>
n_1-c_k, if you want to have an explicit error set, you can start by declaring an empty one, and then see what compile errors you get
<n_1-c_k>
Ah OK, thanks
<andrewrk>
the ? in front is more advanced than the error hinting system can do at the moment, but here I'll show you