protheory8-new-m has quit [Ping timeout: 246 seconds]
jaens[m] has quit [Ping timeout: 246 seconds]
BaroqueLarouche has quit [Ping timeout: 268 seconds]
Nypsie[m] has quit [Ping timeout: 264 seconds]
jicksaw has quit [Ping timeout: 264 seconds]
ugla has quit [Ping timeout: 260 seconds]
Bastian[m] has quit [Ping timeout: 268 seconds]
jicksaw has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
BaroqueLarouche has joined #zig
protheory8-new-m has joined #zig
pafmaf[m] has joined #zig
ziguana[m] has joined #zig
ifreund_ has joined #zig
xackus_ has joined #zig
BaroqueLarouche has quit [Ping timeout: 246 seconds]
pafmaf[m] has quit [Ping timeout: 268 seconds]
protheory8-new-m has quit [Ping timeout: 244 seconds]
ifreund_ has quit [Ping timeout: 268 seconds]
ziguana[m] has quit [Ping timeout: 268 seconds]
ur5us has joined #zig
Bastian[m] has joined #zig
ugla has joined #zig
siraben has joined #zig
jaens[m] has joined #zig
ifreund_ has joined #zig
pafmaf[m] has joined #zig
fengb has joined #zig
BaroqueLarouche has joined #zig
Snektron has joined #zig
mtiljeset[m] has joined #zig
ziguana[m] has joined #zig
protheory8-new-m has joined #zig
Nypsie[m] has joined #zig
ur5us_ has joined #zig
ur5us has quit [Ping timeout: 258 seconds]
alvv___ has quit [Quit: Leaving]
<marler8997>
off topic, I just finished 4 days of triaging a locale issue. The problem ended up being that I was using glibc 2.25 but the yocto tool to create the archive was newer, which added some new entries to the LC_TIME locale...whoever decided not to version the locale-archive binary has caused the world sooo much pain
<marler8997>
and I don't understand how glibc doesn't have proper error handling...this could have taken 10 minutes if glibc would have just logged a proper error message when it found the unexpected data
ltr has quit [Quit: leaving]
bitmapper has joined #zig
<kameliya>
alright!!! aarch64 kernel boots and uses the uefi-provided framebuffer as a console to print a greeting/version
<kameliya>
i had to disable mmu but i'm still really proud i got this far :<
<kameliya>
debugging panics was "fun", since it just crashed qemu. but the registers showed the pointer to the panic message which i could grab out of the image.
sebonirc has quit [Quit: sebonirc]
<pixelherodev>
kameliya: you can override the panic handler to dump message over UART
<pixelherodev>
I've done it, and andrewrk did it on a Pi IIRC
osa1 has quit [Ping timeout: 240 seconds]
<kameliya>
i'm sure i will at some stage! i am so far behind having UART :)
<kameliya>
have just worked out how to force strict align since i'm running with no MMU still
gazler has quit [Ping timeout: 260 seconds]
gazler has joined #zig
shirty has joined #zig
shirty has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<v0idify>
Hey! How do I cancel (stop) a handle? context: I have a connection running in main(), and a different function run as `async func()` that takes stuff from stdIn. I want it to stop when the connection closes.
<v0idify>
tbh I'm struggling a bit with zig's async model
camconn has joined #zig
<andrewrk>
v0idify, there's no way to cancel an async function, the same way there is no way to cancel a regular function call. There's an open proposal to discuss the possibility of adding this: https://github.com/ziglang/zig/issues/5913
<andrewrk>
it's unlikely to be accepted I think, it's quite tricky to implement into the language in a way that is simple and easy to reason about
<v0idify>
andrewrk, what would be my option then? I can't do a check of "did the connection end?" because .read is forever
<v0idify>
i don't like the idea of "cancelling" a function call either but I don't know how to do this in any other way
<andrewrk>
this is an area that is not well-trodden yet, so you're not going to get a satisfying answer
<andrewrk>
if you're using async functions you're using evented I/O mode right? so reading is non-blocking
<v0idify>
yeah, but in the code itself i'm just awaiting something from stdin
<andrewrk>
yeah ok I see
<andrewrk>
let's see, how is this going to work when everything is finished... (thinking)
<v0idify>
context: i'm building an irc client, although i stripped basically all irc components from that
ur5us_ has joined #zig
sebonirc has joined #zig
<justin_smith>
there are some patterns that help - for example, if possible only have one block of code using a resource (eg. have a dedicated async reader, and if there are other consumers that reader should push the data to them)
<justin_smith>
v0idify: it's also common to have some "signal" - whether that's a literall kill -N signal via the OS or a lock that you await or a latch or whatever - something that tells the other thread you are done
<ifreund>
communcation with pipes is much better than using signals IMO
<justin_smith>
and agreed that killing things from the outside usually creates more problems than it solves, it's usually worth the extra complexity to have a thread voluntarily exit
<ifreund>
signals are the worst part of posix
<justin_smith>
ifreund: that's another good one, yes
<justin_smith>
IMHO file handles being ints is pretty bad too (but less likely to lead to disaster)
Akuli has quit [Quit: Leaving]
Akuli has joined #zig
Akuli has quit [Quit: Leaving]
notzmv has quit [Ping timeout: 240 seconds]
ur5us_ has quit [Ping timeout: 264 seconds]
yrashk has quit [Read error: Connection reset by peer]
shurane has quit [Read error: Connection reset by peer]
shurane has joined #zig
yrashk has joined #zig
ugla has quit [Ping timeout: 246 seconds]
siraben has quit [Ping timeout: 246 seconds]
ugla has joined #zig
Cadey has joined #zig
siraben has joined #zig
kushalp has quit [Ping timeout: 268 seconds]
dputtick has quit [Ping timeout: 268 seconds]
tdeo has quit [Read error: Connection reset by peer]
tdeo has joined #zig
tracernz has quit [Read error: Network is unreachable]
procnto has quit [Read error: Connection reset by peer]
betawaffle has quit [Read error: Connection reset by peer]
r0bby has quit [Read error: Connection reset by peer]
dputtick has joined #zig
r0bby has joined #zig
procnto has joined #zig
kushalp has joined #zig
betawaffle has joined #zig
tracernz has joined #zig
heitzmann[m] has quit [Ping timeout: 268 seconds]
lucus16 has quit [Ping timeout: 268 seconds]
Snektron has quit [Ping timeout: 268 seconds]
jaens[m] has quit [Ping timeout: 268 seconds]
lucus16 has joined #zig
mtiljeset[m] has quit [Ping timeout: 260 seconds]
BaroqueLarouche has quit [Ping timeout: 260 seconds]
ziguana[m] has quit [Ping timeout: 260 seconds]
marijnfs has joined #zig
<marijnfs>
how do I fmt to a buffer?
<andrewrk>
std.fmt.bufPrint
<andrewrk>
if you want to heap allocate: std.fmt.allocPrint
Snektron has joined #zig
<marijnfs>
ah allocPrint
<marijnfs>
somehow I can't find bufprint
<marijnfs>
and how would one read line by line from stdin?
<marijnfs>
basically like a console
racoon has quit [*.net *.split]
rowbee has quit [*.net *.split]
neptunepink has quit [*.net *.split]
johnLate has quit [*.net *.split]
tughi has quit [*.net *.split]
greeb has quit [*.net *.split]
lemmi has quit [*.net *.split]
mla has quit [*.net *.split]
jaredmm has quit [*.net *.split]
doublej41 has quit [*.net *.split]
johnLate has joined #zig
jaredmm has joined #zig
lemmi has joined #zig
tughi has joined #zig
racoon has joined #zig
jaens[m] has joined #zig
freshmaker666 has joined #zig
doublej41 has joined #zig
<andrewrk>
we don't have a std lib abstraction for that, you need a more sophisticated terminal UI lib for that
<v0idify>
the del.dog that i sent before provides an abstraction for any kind of reader
neptunepink has joined #zig
<v0idify>
that reads line by line without alloc
<andrewrk>
if you want something really primitive, you can just call read() (not readAll)
<v0idify>
justin_smith, i am following a pattern like that, that is not my problem
<marijnfs>
andrewrk: so get the stdIn().reader() and i can do that?
<andrewrk>
nah not even a reader, just stdin.read()
<marijnfs>
I guess read() is blocking reading every character?
<marijnfs>
ah
<andrewrk>
it will give you an OS-determined amount of bytes
<andrewrk>
which for a terminal will be 1 line
<marijnfs>
thats fine
<andrewrk>
this is the primitive way to do it, if you want something more user friendly, you gotta get fancy
<marijnfs>
yeah then i would have to read every keypress
rowbee has joined #zig
hspak4 has joined #zig
mtiljeset[m] has joined #zig
<marijnfs>
I need to give read a buffer?
BaroqueLarouche has joined #zig
frett27 has quit [Ping timeout: 272 seconds]
ziguana[m] has joined #zig
hspak has quit [Ping timeout: 246 seconds]
hspak4 is now known as hspak
decentpenguin has quit [Read error: Connection reset by peer]
g_w1 has joined #zig
<andrewrk>
you don't know how much data you're going to get until you ask for it
<andrewrk>
you find out after read() whether your buffer was big enough