ChanServ changed the topic of #zig to: zig programming language | https://ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
dimenus has joined #zig
jjido has joined #zig
clktmr has joined #zig
ltriant has joined #zig
dimenus has quit [Remote host closed the connection]
ltriant has quit [Ping timeout: 276 seconds]
wootehfoot has quit [Read error: Connection reset by peer]
<bhansconnect> Is the current for of async await in zig limited to one core/system thread?
clktmr has quit [Ping timeout: 240 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lunamn_ has joined #zig
lunamn has quit [Ping timeout: 268 seconds]
leeward has joined #zig
dantix has quit [Remote host closed the connection]
dantix has joined #zig
kllr_sbstn has quit [Quit: leaving]
lunamn_ has quit [Quit: leaving]
waleee-cl has quit [Quit: Connection closed for inactivity]
<pixelherodev> Thought experiment: what happens if you have two `defer return VALUE;` statements? :P
ltriant has joined #zig
<leeward> Can you return in a defer?
<leeward> It's supposed to happen when you leave the stack frame, right?
doublex_ has quit [Ping timeout: 240 seconds]
<pixelherodev> Exactly
ltriant has quit [Ping timeout: 240 seconds]
dimenus|work has quit [Read error: Connection reset by peer]
<bhansconnect> error: cannot return from defer expression
<pixelherodev> Makes sense :)
<bhansconnect> that is what the compiler will tell you
doublex has joined #zig
crimson_penguin has quit [Ping timeout: 264 seconds]
crimson_penguin has joined #zig
<leeward> Yeah, that's what I figured.
<andrewrk> bhansconnect, no, the default is to use a thread pool with number of threads equal to cpu core count
<andrewrk> zig's async/await language features are thread safe
muffindrake has quit [Ping timeout: 264 seconds]
muffindrake has joined #zig
ltriant has joined #zig
mahmudov has joined #zig
achaninja has joined #zig
ltriant has quit [Ping timeout: 240 seconds]
chemist69 has quit [Ping timeout: 246 seconds]
chemist69 has joined #zig
ltriant has joined #zig
kenaryn has joined #zig
<kenaryn> Hi, does anybody know how to deal with user input?
<wilsonk> kenaryn: I think there is a guess_number example in test/standalone/guess_number that should serve as an example
gsomix has joined #zig
<bhansconnect> andrewrk, So for the fun of it, I converted my go multi goroutine factorial program to zig. In zig it will end up only using pinning to only one cpu for most of the computation and not use many of the threads. Not sure why.
<bhansconnect> this is the code: https://pastebin.com/ueLUtdha
ltriant has quit [Ping timeout: 268 seconds]
<bhansconnect> It should asynchronously multiply each chuck of the factorial, so I am not sure why it would be only using 1 thread for most of the computation.
<gsomix> hey, everyone. I'm novice in zig, could you please review a very small program? thanks!
<achaninja> gsomix i think you should abort or return an error instead of issue a warning on failure
<achaninja> generally you want a non zero exit code on failure
ntgg has quit [Ping timeout: 268 seconds]
<gsomix> achaninja thanks!
gsomix has left #zig [#zig]
gsomix has joined #zig
<gsomix> I've just installed hexchat. haven't been in IRC in ages :)
<achaninja> :)
ltriant has joined #zig
<bhansconnect> andrewrk, I actually just realized the issue. Zig does not consider primitives like u64 as thread safe even if they are constants. Using a chan of u64 to send the parameters causes everything to run in parallel.
<kenaryn> Thank you wilsonk.
ltriant has quit [Ping timeout: 240 seconds]
<wilsonk> no problems kenaryn :)
<kenaryn> Perhaps do you know a way to write into an external file instead of standard ouput? I do not see how to proceed, neither in the official documentation, nor the 'test' ghitub repository.
<achaninja> kenaryn, have you found https://ziglang.org/documentation/master/std/
<achaninja> I found this https://ziglang.org/documentation/master/std/#std;fs.File.openWrite
<achaninja> maybe its what you need
<kenaryn> Many thanks! I just finished reading the master documentation a few hours ago, but didn't know about standard library's one, you are very kind.
<achaninja> no problem , i just found it too
<achaninja> it was linked from the page, but I missed it too
<kenaryn> ahah yeah... silly me :)
dantix has quit [Quit: Quit]
ltriant has joined #zig
<andrewrk> bhansconnect, ah, interesting, nice to see people playing with evented I/O
<andrewrk> it's very new in the std lib, I'm sure there are issues
dantix has joined #zig
ltriant has quit [Ping timeout: 276 seconds]
dantix has quit [Quit: leaving]
<achaninja> im curious about using it to avoid needing 'self pipe' trick in my process supervisor
<achaninja> basically only react to signals in an event loop somehow
<achaninja> and block signals while doing any calculation
<achaninja> pretty interested in zero allocations regardless, zig is looking fun
mahmudov has quit [Remote host closed the connection]
<achaninja> does zig anticipate many big upcoming language changes?
<andrewrk> achaninja, have you seen the 0.5.0 release notes?
<andrewrk> I recommend at least reading the table of contents and the roadmap section
<achaninja> thank you
<achaninja> will read
<andrewrk> short answer: language is not stable yet, but the remaining issues are numbered, and I fully intend to keep the language small & simple
<andrewrk> some of the planned changes come with deleting features, so it's not even really making the language bigger, just different
<kenaryn> achaninja Walter Bright, the creator of Dlang, speaks about allocation by no-allocation strategy (i.e. using chain) at 00:45:00 if the topic interest you: https://www.youtube.com/watch?v=_PB6Hdi4R7M&feature=youtu.be
<andrewrk> thanks, I'll put this on my "watch during lunch breaks" playlist :)
<achaninja> sure, im interested, thank you
<achaninja> I wrote this a while ago in rust: https://github.com/andrewchambers/orderly
<achaninja> just addressing the flaws makes me consider zig
<andrewrk> if you're aware of the downsides: instability due to immaturity, and tradeoff of safety to gain simplicity, then you're in the right place
<andrewrk> the best way to get changes that you want around here is to have a good use case, so I love that you're already having a project in mind
dantix has joined #zig
<achaninja> Yeah, I accept those problems. zig already seems to have more backing than lots of the other software we all depend on daily anyway.
<achaninja> so one regard its wise :P
<achaninja> btw andrewrk , have you considered doing a 'merch' shop for zig
<achaninja> so people can buy a t shirt or something
<achaninja> dunno if it would be a success, but just throwing it out there
<andrewrk> I've considered it, but it's hard to be motivated to spend time on that when there is so much to do on the actual zig project itself
<achaninja> Yeah, that's a support role required with lots of logistics I guess.
soveran has joined #zig
ltriant has joined #zig
ltriant has quit [Ping timeout: 240 seconds]
kenaryn has quit [Quit: WeeChat 2.3]
<andrewrk> btw bhansconnect just so you know - the std lib is not fully hooked up with evented I/O. as a proof-of-concept, reading is integrated, but writing is not yet. and for example these are also not integrated yet: sleeping/timing, child processes
<andrewrk> by "not integrated" I mean that even when you select evented I/O, writing currently still blocks
<andrewrk> oh, also file system stuff is not integrated yet
bhansconnect has quit [Ping timeout: 260 seconds]
<pixelherodev> Out of curiousity, what's needed to implement a new backend to the event loop?
<dantix> There is a thin wrapper around gmp for go. I guess using it will be more apples to apples comparison performance wise.
<soveran> hi there, I'm just starting with zig and I'd like to know what's the fastest way to print to stdout lines read from stdin
<soveran> (I tried std.io.readLineSlice(...), but I'd like to know if there's a faster approach)
<pixelherodev> In theory you could use raw `std.os.read`/`std.os.write`
<pixelherodev> That's what `std.fs.File` methods do under the hood
<pixelherodev> So e.g. `std.os.read(std.os.STDIN_FILENO);` IIRC
<pixelherodev> Not sure what other arguments you'd need
<andrewrk> soveran, https://clbin.com/g2BPE
<soveran> perfect :-)
<soveran> is there a way to read lines from the buffer, or I have to search for newlines myself?
<pixelherodev> You could read one byte at a time, and if it's a newline continue
<soveran> excellent, thanks a lot
<pixelherodev> Keeping in mind that this isn't exactly the fastest method
<pixelherodev> Suggestion: look at the source for readLineSlice
<pixelherodev> Keep in mind the first rule of optimization
<pixelherodev> The flowchart definitely helps
<soveran> yep :-)
<soveran> actually I wanted to port a simple C program I have
<soveran> but the result I got was much slower than the C version
<pixelherodev> Um. std.mem.copy is annotated with `dest.ptr must be <= src.ptr`
<pixelherodev> Is - is that accurate?!
<pixelherodev> soveran, profile it!
<pixelherodev> Are you sure it's the I/O bogging it down?
<pixelherodev> ... wait, does e.g. callgrind work with Zig?
<soveran> no idea, you are talking to a one-day n00b
<soveran> here's the C version: https://github.com/soveran/hi/blob/master/hi.c
<soveran> (I know the zig version can be improved because I'm using readLine)
<soveran> and there may be some other optimizations, but readLineSlice seemed like the low hanging fruit
<pixelherodev> How much slower is it?
<pixelherodev> Did you build in debug mode or in ReleaseFast mode?
<pixelherodev> I really doubt that readLine is a bottleneck
<soveran> I tried fast, safe, and small
<pixelherodev> Also, your strstr implementation could be improved
<pixelherodev> See std.mem.eql
<pixelherodev> The inner loop could probably be replaced with `if (std.mem.eql(u8, str[i..i+s.len], s))`
<soveran> zig version: 0.472u 1.068s 0:01.55 98.7%0+0k 0+0io 0pf+0w
<soveran> c version: 0.013u 0.003s 0:00.01 100.0%0+0k 0+0io 0pf+0w
jjido has joined #zig
<pixelherodev> Definitely try running under a profiler then
<soveran> where can I learn more about std.mem.eql?
<pixelherodev> Should be in e.g. /usr/lib/zig/std/mem.zig IIRC
<pixelherodev> A word-matching search for eql shows the source
<pixelherodev> I don't think it'll make a performance difference though
<pixelherodev> Again, always rely on a profiler to tell you what's really slowing your programs down, don't try guessing
<andrewrk> soveran, have a look at the readUntilDelimiter functions in std/io/in_stream.zig
<andrewrk> pixelherodev, yes callgrind works with zig. zig actually has valgrind integration, emitting valgrind-specific annotations for undefined memory
<soveran> interesting
_whitelogger has joined #zig
<soveran> yea, readLineSlice was the culprit. Thanks a lot :-)
<pixelherodev> Suggestion: try using readLineSliceFrom with a constant stdin?
<pixelherodev> i.e. `const stdin = try std.io.getStdIn(); const stream = std.inStream().stream; readLineSliceFrom(&stream, slice);`?
<pixelherodev> Ah, never mind - the usage of a Buffer slowing it down makes some sense
<soveran> good, good :-)
<pixelherodev> I'd think a lot of this would optimize away...
<soveran> I'll see if I can build a readLineFromBuffer or something like that
<pixelherodev> I'll probably profile that test later if you leave it up and see if I can improve the stdlib's performance in this regards
<soveran> great
<soveran> that would be great, actually
dantix has left #zig ["Bye"]
dantix has joined #zig
lucus16 has quit [Ping timeout: 240 seconds]
ltriant has joined #zig
ltriant has quit [Ping timeout: 240 seconds]
ltriant has joined #zig
ltriant has quit [Ping timeout: 240 seconds]
lucus16 has joined #zig
jokoon has joined #zig
jokoon has quit [Ping timeout: 276 seconds]
jokoon has joined #zig
ltriant has joined #zig
soveran has quit [Remote host closed the connection]
ltriant has quit [Ping timeout: 265 seconds]
jokoon has quit [Quit: jokoon]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
clktmr has joined #zig
return0e has joined #zig
return0e_ has quit [Ping timeout: 240 seconds]
lunamn has joined #zig
dimenus has joined #zig
ltriant has joined #zig
ltriant has quit [Ping timeout: 240 seconds]
lunamn has quit [Ping timeout: 246 seconds]
Ichorio has joined #zig
lunamn has joined #zig
wootehfoot has joined #zig
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ltriant has joined #zig
ltriant has quit [Ping timeout: 276 seconds]
bhansconnect has joined #zig
return0e_ has joined #zig
return0e_ has quit [Read error: Connection reset by peer]
<mq32> hello
jjido has joined #zig
soveran has joined #zig
doublex has quit [Ping timeout: 276 seconds]
marijnfs has joined #zig
clktmr has quit [Ping timeout: 240 seconds]
ltriant has joined #zig
ltriant has quit [Ping timeout: 250 seconds]
hoppetosse has joined #zig
doublex has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
kapil_ has joined #zig
dantix has quit [Quit: Bye]
ltriant has joined #zig
ntgg has joined #zig
doublex has quit [Ping timeout: 246 seconds]
ltriant has quit [Ping timeout: 240 seconds]
doublex has joined #zig
soveran has quit [Remote host closed the connection]
ntgg has quit [Ping timeout: 240 seconds]
mahmudov has joined #zig
dingenskirchen has joined #zig
kllr_sbstn has joined #zig
<mq32> is it possible to construct a "slice" out of a single element?
<mq32> something like
<mq32> var byte : u8 = 'A'; printString(byte[0..1]);
<pixelherodev> Yes
<pixelherodev> Just take the address of the element
<pixelherodev> That gives you a pointer, which you can slice normally
<pixelherodev> So something like `(&byte)[0..1]`
<fengb> You can’t slice a single pointer. Need a ptrCast
ltriant has joined #zig
<pixelherodev> ...I'm fairly certain I've done it...
<mq32> hmm
<mq32> have to try :)
dantix has joined #zig
<pixelherodev> Though I may have done it for an *array* or something like that
<fengb> There’s a few examples in std. IIRC it’s @ptrCast([*]T, &val)[0..1]
jjido has quit [Quit: Textual IRC Client: www.textualapp.com]
<mq32> std.mem.copy(u8, this.target[this.offset .. this.offset + @sizeOf(T)], @sliceToBytes(@ptrCast([*]T, &value))[0..]);
<mq32> this is wondefully ugly :D
<fengb> pixelherodev: yeah arrays cast to array pointers seamlessly
<pixelherodev> Yeah, that makes sense
<pixelherodev> This is fun. Trying to determine the correct way to read arbitrary data from an ATA drive given a working readSectors function :)
<fengb> There was a long discussion about pointer reform before my time. It’s a pretty interesting read
<mq32> pixelherodev: ATA is kinda cool to work
<mq32> it's the base of pretty much every "Storage I/O" nowadays
<mq32> everything uses sectors/blocks instead of singe-byte-access
ntgg has joined #zig
lunamn has quit [Ping timeout: 264 seconds]
lunamn has joined #zig
mahmudov has quit [Remote host closed the connection]
bjorob has joined #zig
bjorob has quit [Quit: leaving]
bjorob has joined #zig
ntgg has quit [Ping timeout: 268 seconds]
ltriant has quit [Ping timeout: 276 seconds]
dingenskirchen has quit [Remote host closed the connection]