<andrewrk>
v0idify, you can always write lower level code that interacts more tightly with the event loop
<v0idify>
andrewrk, how would i go about doing that?
daafu has joined #zig
<daafu>
Hello, I'm poking at Zig for the first time, absolute noob, coming from C. I'm starting with the raylib example. It seems when raylib.h is imported "bool" is converted into: const enum_unnamed_1 = extern enum(c_int) { @"false", @"true", _, }; What is happening here? Its an enum of c_int type with string values?
<mikdusan>
daafu: if an identifier is in conflict with language-builtin, like `true` and `false`,
<mikdusan>
then zig let you say @"false"
FireFox317 has joined #zig
<daafu>
mikdusan so then something like this should work?: while(ray.WindowShouldClose() == @"false") { .. }
<FireFox317>
andrewrk, do you have some time to answer a question regarding astgen in stage2?
<andrewrk>
FireFox317, drop it here and I'll answer when I can
<FireFox317>
sure!
<mikdusan>
daafu: enum matching is done with enum literals. so if it wasn't a reserved word, you could do `== .false` but since reserved, you can do `== .@"false"` <-- not that we still use `.` in front because it was needed there anyways.
<mikdusan>
s/not/note/
<daafu>
mikdusan thank you the "." is what I was missing
<mikdusan>
and that's use a very convenient enum_literal (just the dot with a name). you can always prefix it (though it's rare you have to), and in this case it would be `== enum_unnamed_1.@"false"`
<FireFox317>
i tried to implement `var foo = blk: { <etc> }` in stage2 and i managed to implement this by not touching any of the `.block_ptr` result locations. Resolving the peer types of the break values happens with the same mechanism as the inferred allocs that andrewrk implemented. Now i was wondering if there is a usecase where the current inferred alloc strategy does not work with blocks.
<FireFox317>
i can PR the stuff that i currently did to show what i mean if it is not logical.
<andrewrk>
FireFox317, I don't have an answer to this, I think I just need to look at the code and try to make sense of it all
<FireFox317>
andrewrk, yeah that makes sense :) I think this will be a good topic to discuss during a stage2-meeting
<andrewrk>
agreed
leon-p has quit [Quit: leaving]
<v0idify>
"dumb" question: does the different stages of compilers mean that zig essentially has two implementations for it's compiler?
<andrewrk>
yes
<andrewrk>
stage1 in C++ that uses LLVM; stage2 in zig that has a handful of different backends including but not limited to LLVM
<v0idify>
cool!
wootehfoot has quit [Quit: Leaving]
rinfo has joined #zig
rinfo has left #zig [#zig]
kbd_ has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
kbd has joined #zig
rinfo has joined #zig
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
kbd has joined #zig
kbd has quit [Client Quit]
_whitelogger has joined #zig
daafu has quit [Quit: Ping timeout (120 seconds)]
cole-h has joined #zig
wilsonk__ has quit [Ping timeout: 256 seconds]
factormystic has quit [Ping timeout: 256 seconds]
factormystic3 is now known as factormystic
shirty has quit [Quit: Going offline, see ya! (www.adiirc.com)]
freshmaker666 has quit [Read error: Connection reset by peer]
freshmaker666 has joined #zig
osa1_ is now known as osa1
notzmv has joined #zig
camconn has quit [Quit: Leaving]
mokafolio has quit [Quit: Bye Bye!]
<v0idify>
for some reason, with this code https://codeberg.org/void/ircbay-bug and evented io_mode enabled, things read from any stream has some bytes chopped from the start (i think?)
<v0idify>
0.8.0-dev.976+2b0e3ee22
mokafolio has joined #zig
<v0idify>
it was working fine a few revisions ago
<v0idify>
to reproduce: `socat stdio tcp-listen:<port>`; `zig run main.zig -- localhost <port> anything`; typing anything into either stdin will show with removed bytes on either side
<v0idify>
even though when printing each string before sending it shows that it's fine
notzmv has quit [Ping timeout: 272 seconds]
xackus has joined #zig
marijnfs has quit [Read error: Connection reset by peer]
marijnfs has joined #zig
xackus has quit [Ping timeout: 260 seconds]
notzmv has joined #zig
semarie has quit [Ping timeout: 264 seconds]
semarie has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
gazler_ has quit [Remote host closed the connection]
gazler_ has joined #zig
<kandinski>
Could some zigger that also uses nix help me get out of a small hole? I was working on this last October, at 0.6, and could run `impls/zigzug$ zig test re.zig` and it would work, but now I upgraded my channels, got zig 0.7 and I see this error: https://termbin.com/y09z. Could any of you with zig and nix experience give it a look-see? https://github.com/candeira/mal/tree/zigzug-wip
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
adsr has quit [Quit: WeeChat 3.1-dev]
<kandinski>
I mean, maybe someone has seen this issue and it has to do with cInclude lookups, or maybe I've messed up something else.
<sebonirc>
kandinski: it says ur not linking with libc during compilation. try `zig test -lc re.zig`
<kandinski>
sebonirc: ah, sure, thanks
<sebonirc>
np
<kandinski>
same error though, minus the note
<sebonirc>
it says pcre2.h isn't found still?
<kandinski>
yes, only the "note: libc headers not available" disappears, rest of the trace is the same
<sebonirc>
i know this is a simple thing, but just to check, is pcre2 actually installed?
<kandinski>
well, I did put it in shell.nix, but I don't know how to check :/
notzmv has quit [Ping timeout: 256 seconds]
<sebonirc>
i dont know what the include path in nix is, id assume its probably just /usr/include though. if that's the case, runnign `find /usr/include -name pcre2.h` should print something like "/usr/include/pcre2.h".
<sebonirc>
unless nix handles includes differently
<kandinski>
nixos doesn't follow the LFS/LFH
<kandinski>
so no /usr/include
<sebonirc>
do u know where other include files are? like standard stuff like stdio.h
<kandinski>
everything is in /nix/store and then gets symlinked
<kandinski>
I know some zig developers use nix/nixos, so I thought I'd ask
<sebonirc>
does including pcre2.h work in c, or does that also fail to compile? try just making a test.c with `#include <pcre2.h>` and `int main() { return 0; }` and see if that compiles, that way we can figure out whether its a problem with zig or a problem with ur setup
<sebonirc>
yeah, sorry, i dont have much experience with nix/nixos. thought i could still help but apparently not lol. good luck though
<kandinski>
I've never programmed in C. I'm pretty sure this setup worked well in October, and I'm now picking it up again.
adsr has joined #zig
<kandinski>
No worries, sebonirc; thanks for trying :)
<kandinski>
Hi, I'm using lorri and I would like to know how to check that a library (pcre2 in this case) is actually available for include. This is my shell.nix, and zig can't find pcre2.h, algthough it's clear that entering the directory tree makes zig and python executables available: https://github.com/candeira/mal/blob/zigzug-wip/shell.nix
cole-h has quit [Quit: Goodbye]
<kandinski>
(oops, that was for the lorri channel)
drp has quit [Remote host closed the connection]
leon-p has joined #zig
frett27 has joined #zig
xackus has joined #zig
drp has joined #zig
xackus has quit [Ping timeout: 256 seconds]
semarie has quit [Quit: WeeChat 3.0]
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
semarie has joined #zig
xackus has joined #zig
wootehfoot has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
karrick has quit [Quit: Connection closed for inactivity]
braket has quit [Read error: Connection reset by peer]
braket6 has joined #zig
wilsonk has joined #zig
jensln has joined #zig
<jensln>
I'm confused; I've a simple attempt at implementing a stack, but pop() returns garbage values and I don't see why
<jensln>
I'm (obviously, looking at my code, I think) very new to low-level programming, but I thought I might as well learn it through Zig rather than C
<Nypsie[m]>
`new_node` is allocated on the stack. Meaning its lifetime is only as long as the scope it lives in (the push() function in this case). You could allocate it on the heap using an allocator or better: Have the user handle its lifetime and allow them to pass in the Node to the push() function instead.
<jensln>
Aha, so that's why LinkedList does that as well (take Nodes instead of just the data)
<Nypsie[m]>
Yes, correct
<jensln>
Thank you very much, Nypsie[m]
<Nypsie[m]>
You're welcome! Also, welcome to Zig :) It's my first time with manual memory management as well
* jensln
^^
<semarie>
isn't possible for the compiler to warn about storing or returning stack's pointer ?
zagz has joined #zig
<zagz>
Hi all
<zagz>
In a video by Andrew, he did warn("{}\n", list.items.len); but that doesn't compile for me on 0.7. I have to do .{list.items.len}, which is a bit more verbose. Was this a language change, or am I missing something?
<zagz>
That discussion makes sense. I noticed some discussions about adding lambdas, but not clear to me if that'll happen or not. I often miss that when going from a modern language back to C :)
<zagz>
Anyone here using zig in production? Looks like the core is relatively stable/solid now right?
nvmd has quit [Ping timeout: 256 seconds]
<zagz>
Nypsie[m]: unfortunately the example no longer seems to work properly, it ends up launching a zig process that takes 100% cpu forever. Not easy to see why as no errors are reported.
<Nypsie[m]>
I see. I tend to use gdb manually or use a simple debug.print() statement
Akuli has joined #zig
<zagz>
Yeah I'm simple, if I can't get debugging going in vscode, I move on :D I'll for a while.
<zagz>
try* for a while
freshmaker666 has quit [Quit: ZNC 1.8.2 - https://znc.in]
freshmaker666 has joined #zig
<zagz>
ah, switching to lldb worked
<zagz>
that's amazing, stack trace and pretty printing worked right off the bat
<Nypsie[m]>
Great to hear!
<zagz>
now I like zig again :D
<marijnfs>
what happened to serialize.zig?
<Nypsie[m]>
It was moved to orphonage
<marijnfs>
I'm trying to make a local serialize function and wanted some inspiration
<v0idify>
okay i'm not sure if this is supposed to happen
<v0idify>
essentially i'm calling a function in a loop that gets some data into it's own buffer and returns a slice of it, the caller is supposed to use it as an iterator so before the next call, however when using evented I/O i guess what's happening is that it's trying to use that slice after it already got replaced by undefined by the next call, but the way i'm writing my call it should first write it to the socket and then do the next call
fritchie has joined #zig
ur5us_ has quit [Ping timeout: 260 seconds]
<v0idify>
https://del.dog/raw/yhuvorrype this is the most minimal example i can come up with; i know how to solve it (passing a buffer in the params and using that) but i want to understand why it happens. it works just fine without evented I/O
a_chou has quit [Remote host closed the connection]
<v0idify>
notice how when using std.debug.print works fine but writing to stdout doesn't
<ugla>
v0idify: isn't that returning a slice of stack memory? That's invalid once the function returns?
<ifreund1>
^
<v0idify>
this confuses me a bit but it makes sense
<v0idify>
why does it work fine all the time in blocking i/o mode but not in evented tho?
<ifreund1>
it just happens to work. It's UB, anything can happen
<v0idify>
right
<ugla>
Nothing managed to overwrite it maybe? Too low-level for me.
ifreund1 is now known as ifreund
<v0idify>
is there a list of undefined behaviour gotchas for zig yet?
<v0idify>
i know this is pretty obvious for someone who has worked with manual managed memory, not for me though :)
<ifreund>
Yeah this is pretty obvious once you have a good mental model of how the call stack works
<ifreund>
it helps to have implemented a (shitty) one yourself at some point
<ugla>
I've made similar mistakes. It just takes some practice, around "where does this memory live" in particular.
<v0idify>
i mean i realized it can break if the function was called before the return value was used again because i thought the way this works is that the compiler knows how much memory untilChar will use, so it just stores it alongside whatever main uses
<v0idify>
but now i see this is clearly not how the stack works :)
<v0idify>
that part of the documentation only shows undefined behaviour that causes compile or runtime (only on safe modes ofc) errors, i'm precisely looking for the other side of the coin, the ones that are not detectable
<ifreund>
yeah, we don't have a complete spec yet sadly
<v0idify>
well, i want to return an array and a slice to that same array (the rest of the array will be `undefined`); is there a nice way to do that?
<ifreund>
v0idify: you could use a static buffer (i.e. a global not a local variable) or you could allocate
<ifreund>
you could also return an array by value in a struct with the array and slice
<nkoz>
there is something equivalent to Go channels in zig stdlib?
<v0idify>
I think I'll do that
<v0idify>
i just realized that i was doing it right before (making a struct with a buffer and a function to call it) and I broke it when "simplifying it" lol
<v0idify>
i was so proud of it too
<ugla>
You learned something though, so it wasn't a failure. :)
<v0idify>
true
<v0idify>
thanks for helping!! hopefully i don't blame it on zig next time
<v0idify>
btw i'm trying to do as few allocations as possible, that's why I didn't go with that approach
<ugla>
Letting the caller supply the buffer you could still have it on the stack and it wouldn't result in more allocations.
<ifreund>
^
<ifreund>
that may also avoid copying the buffer around in some cases
<ugla>
In your paste you would declare the buffer above the while loop, and pass a pointer into untilChar
<v0idify>
yes, i ended up doing a equivalent approach: wrapped the method into a `SplitIterator` (which is a better suited name anyway)
<v0idify>
it is a bit weird to initalize (var iter = SplitIterator(4096, @TypeOf(reader), '\n'){ .reader = reader }) but it works well and is even simpler to understand imo
midgard_ has joined #zig
<ugla>
You can also get one out of std.mem.split IIRC
midgard has quit [Ping timeout: 256 seconds]
<v0idify>
ugla, ?
<v0idify>
oh of cours
<v0idify>
nvm i was about to rage quit thinking that it was already made; no, mine operates over readers instead of memory
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 264 seconds]
xackus has quit [Ping timeout: 240 seconds]
xackus has joined #zig
kbd has joined #zig
<kbd>
hey https://ziglang.org/documentation/0.7.1/std/#std;io.Mode should be mentioned in the section of the docs on async/await. I didn't know why my code wasn't behaving as expected (and spent some time flailing thinking I was doing it wrong) until I searched youtube and watched Andrew's RedisConf video (https://youtu.be/zeLToGnjIUM)