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/
<andrewrk> betawaffle, noted! let me get back to you after Release Month, if you don't mind. lots of stuff going on right now :)
<mikdusan> master on openbsd6.9 this passes: `zig build test -Dskip-non-native -Dskip-stage2-tests` with:
<mikdusan> 1. llvm/lld cherr-picked patches from openbsd base
<mikdusan> 2. disabling one stack-trace test
<mikdusan> 3. fixes to src/link/Elf.zig to do crt linking
<mikdusan> .
hiljusti has joined #zig
klltkr has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hiljusti has quit [Ping timeout: 245 seconds]
<plumm> are error traces still broken :D
<andrewrk> you mean do they have extra irrelevant stack frames at the beginning?
<andrewrk> yeah. you gotta scroll down sometimes to find the starting point
<plumm> I had an "error.UnexpectedToken" from the json parse module, and after the error I got spammed with OutOfMemory's
earnestly has quit [Ping timeout: 252 seconds]
<kiedtl> Has the feature to build C files along with a Zig project in build.zig not been fully fleshed out in 7.0.1? I've added a couple files and zig complains of not being able to find bits/*.h, stdio.h, etc
<g-w1> what os are you on?
<kiedtl> Linux, Ubuntu
<g-w1> use -lc or exe.linkLibC()
<kiedtl> Oh, I see. thanks.
bitmapper has joined #zig
notzmv has quit [Ping timeout: 268 seconds]
xackus__ has quit [Ping timeout: 252 seconds]
xackus__ has joined #zig
xackus has joined #zig
xackus__ has quit [Ping timeout: 252 seconds]
xackus_ has joined #zig
xackus has quit [Ping timeout: 252 seconds]
xackus_ has quit [Ping timeout: 252 seconds]
dyeplexer has joined #zig
notzmv has joined #zig
plumm has quit [Ping timeout: 240 seconds]
plumm has joined #zig
VFEXrt has joined #zig
<semarie> mikdusan: you were lucky with llvm12 because we (openbsd) upstreamed code in libc++{,abi} and llvm recently :)
<semarie> my zig-wip tree when starting to work on it (~0.7.1) had more patches in these areas
<andrewrk> semarie, congrats on that :)
<VFEXrt> Is it a KI that std.c.parser is broken? I thought it was maybe just a couple issues so I started fixing/replacing things but it looks like I just keep uncovering layers of more brokeness. i.e it references the std.zig.tokenizer instead of std.c.tokenizer and the are a bunch of mismatched struct keys (Guess this is the trade off of lazy
<VFEXrt> compilation?)
<VFEXrt> This simple snippet doesn't compile atm
<VFEXrt> const alloc = &gpalloc.allocator;
<VFEXrt> var p = std.c.parse(alloc, "#define HELLO 1", .{});
<mikdusan> semarie: any significant stuff? not to sound negative, but it looks like most llvm patches openbsd base applies are just to get it working for openbsd,
<mikdusan> of the 2 I cherry-picked, the .so.x.y one could result in false-positives unless in a conditional block for openbsd
<andrewrk> VFEXrt, it's about to get deleted. vexu was doing some experimental work but it bit rotted and he's been working on https://github.com/Vexu/arocc instead
<VFEXrt> Ah, so no std.c.*? The idea of the standard lib just handling that sounds amazing
<VFEXrt> Was spinning up a new project that requires me to walk the C ast at runtime and this looked like a godsend
<andrewrk> we'll see, but for now there is nothing available in std lib for C code
<semarie> mikdusan: outside additionnal support for some platforms (currently lot of work for riscv64), notable additions are documented here: https://man.openbsd.org/clang-local
<andrewrk> VFEXrt, I'll delete the bit rotted files to clear up the confusion
<VFEXrt> Not opposed to implementing my own, but I was trying to find the 'ziggy' way of streaming bytes into my lexer (peek_stream seems promising) when I stumbled onto it. Seems like a really novel idea
<andrewrk> check out arocc (the link above)
<mikdusan> semarie: I like the first point already; it irks me to this day clang (and apple xcode) play games with putting /usr/local in your search path
<VFEXrt> Will do:)
<VFEXrt> aside: might be work having an experimental namespace ala C++? something like std.experimental.c.*
<VFEXrt> also, I guess before 1.0 everything is experimental :)
<mikdusan> semarie: really like that openbsd has clang-local manpage
<semarie> mikdusan: openbsd has very good documentation
hiljusti has joined #zig
sord937 has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
tomku has quit [Ping timeout: 246 seconds]
p_____ has joined #zig
p_____ has quit [Client Quit]
p_____ has joined #zig
p_____ has quit [Remote host closed the connection]
dyeplexer has quit [Ping timeout: 240 seconds]
tomku has joined #zig
hiljusti has quit [Ping timeout: 260 seconds]
cole-h has quit [Ping timeout: 240 seconds]
[wtf] has joined #zig
tomku has quit [Ping timeout: 240 seconds]
tomku has joined #zig
Bernstein has joined #zig
<ifreund> VFEXrt: see std.x
earnestly has joined #zig
klltkr has joined #zig
zenkuro has joined #zig
zenkuro has quit [Ping timeout: 240 seconds]
zenkuro has joined #zig
xackus_ has joined #zig
meinside has quit [Quit: Connection closed for inactivity]
olabaz has joined #zig
antaoiseach has joined #zig
<antaoiseach> hey folks, newbie to zig and systems prog in general... have a basic question about alignment. In the lang ref example, we have this - @intToPtr(*i32, 0xdeadbee0), which works fine. when I change the literal to 0xdeadbeef, it complains about alignment.
<antaoiseach> The alignment for *i32 is 8 bytes, right? So my confusion is - how exactly this alignment is being used here to determine that 0xdeadbeef is invalid?
<daurnimator> antaoiseach: an i32 has a default alignment of 4 ==> they can only exist on bytes that are a multiple of 4
<antaoiseach> Ah sorry, yes, 32 bits
<antaoiseach> daurnimator: so in this case, 0xdeadbee0 is amultiple of 4, but deadbeef is not, right?
<daurnimator> correct
<antaoiseach> Ah, okay. Got it. Thanks!
<daurnimator> if you want to relax that, write `*align(1) i32` instead
<antaoiseach> daurnimator: Interesting! Let me try that out
<antaoiseach> Yes, I was trying to experiment along those lines! :-)
<antaoiseach> daurnimator: yup, worked perfectly!
<antaoiseach> very nice.
fireglow has quit [Quit: Gnothi seauton; Veritas vos liberabit]
fireglow has joined #zig
TheLemonMan has joined #zig
karchnu has quit [Ping timeout: 246 seconds]
jeang3nie has joined #zig
<antaoiseach> I have another question about alignment - what does alignment in function types entail - is it the return value that is aligned or the function address?
<antaoiseach> (sorry, still just working through the lang ref, not sure if the answer would be further ahead)
<daurnimator> antaoiseach: "in function types" I'm not sure what you mean
<antaoiseach> I mean, suppose you have: fn foo() align(4) void {}
<TheLemonMan> it's the alignment in the final binary/in memory
<antaoiseach> of the function body or the function entrypoint?
<TheLemonMan> the former, the entry point is the first byte of the body
<daurnimator> huh. I didn't actually know that
<antaoiseach> right ... oh, right, that makes sense
<daurnimator> my first guess would have been that the result location had to be aligned to 4..... which of course doesn't make sense with `void`
<antaoiseach> daurnimator: yeah, that's what I thought too (assuming "result location" is sort of an lvalue?)
<antaoiseach> Thnaks for clearing that up, guys!
<daurnimator> antaoiseach: result location is where the result is *going* to go. `x = foo();` => in zig under the hood you can sort of think of foo as secretly taking a pointer to the `x` as the place to put the result
<daurnimator> i.e. `fn foo() i32` is really like `fn foo(result: *i32) void`
<TheLemonMan> not quite, i32 is not an aggregate
<daurnimator> TheLemonMan: semantically does that make a difference?
<TheLemonMan> from a high-level POV no, from the codegen POV yes
<companion_cube> what if you have a struct with 2 u16? does it have to be handled differently than a i32?
<TheLemonMan> the logic is in want_first_arg_sret and the answer is yes
<antaoiseach> Interesting!
<antaoiseach> Sort of like references? out params?
<mikdusan> TheLemonMan: did you need me to try anything on qemu-6.0.0 ?
<TheLemonMan> RVO
<TheLemonMan> mikdusan, nope, we're better off waiting for qemu 6.0.1 heh
<mq32> companion_cube: a bit, yes. "extern struct {a:u16,b:u16}" has natural alignment 2, whereas "extern struct { a: i32 }" has natural alignment 4
<companion_cube> ah, not saying they're exactly the same, but the struct could still be copied around instead of going through an out parameter
<companion_cube> anyway it's all good, I was just curious why "aggregates" is the line, and not size
<mq32> for C abi, there's a huge difference afaik
<mq32> so "u32" can be passed in a register, but "struct" must be passed in a copy on the stack
<companion_cube> ah well. makes sense.
<companion_cube> (to follow what C does, I mean)
<mq32> if you don't have a defined ABI like zig, you can go pretty crazy, like passing a struct as two registers and so on :)
<TheLemonMan> that's also done in the C land, small in/out aggregates are shoved into a single register
<mq32> oh, they are?
<mq32> i think it depends on the system though
<TheLemonMan> yeah, it depends on the architecture/abi
<TheLemonMan> yay, got most of the test suite to run when compiled for linux/thumb
<mikdusan> 👍
<antaoiseach> exit
antaoiseach has quit [Quit: leaving]
[wtf] has quit [Quit: [wtf]]
cole-h has joined #zig
<kiedtl> Is including a local C header file with @cInclude supported? I'm trying to include foo.h (#include "foo.h") but @cInclude does "#include <foo.h>", which of course leads to a header not found error
<dutchie> can you just do `-I.`?
<kiedtl> Hm, yes, I can. It'd be cleaner to have a @cLocalInclude or something similar IMO
xackus has joined #zig
xackus_ has quit [Ping timeout: 252 seconds]
VFEXrt has quit [Quit: Connection closed]
<kiedtl> How do you add a built option to zig cc ('-I.')? Sorry for the repated questions, but I'm looking in lib/std/build.zig and don't seem to see anything of relevance
<TheLemonMan> addIncludeDir maybe?
<kiedtl> Ah, yes, that'd be what I was looking for. Thanks!
jeang3nie has quit [Quit: WeeChat 3.1]
mikdusan has quit [Quit: WeeChat 3.0.1]
B767B has joined #zig
<kiedtl> Will there ever be support for adding a pre-panic hook? It would be useful in cases where, say, ncurses has the be shutdown before the panic message can be displayed in a legible fashion
<TheLemonMan> you can already override the panic handler, stuff your pre-panic code there and then call the default handler
Bernstein has quit [Remote host closed the connection]
<kiedtl> Oh, I see, by defining a panic() function in the project root. Sorry
tomku has quit [Ping timeout: 265 seconds]
tomku has joined #zig
B767B has quit [Remote host closed the connection]
Akuli has joined #zig
daurnimator has quit [Ping timeout: 258 seconds]
ncon has quit [Ping timeout: 265 seconds]
neptunepink has left #zig [#zig]
daurnimator has joined #zig
ncon has joined #zig
mikdusan has joined #zig
<betawaffle> andrewrk: re: "... get back to you after Release Month, if you don't mind" i don't mind, sounds good!
procnto has quit [Ping timeout: 276 seconds]
r0bby has quit [Ping timeout: 245 seconds]
r0bby has joined #zig
procnto has joined #zig
pretty_dumm_guy has joined #zig
CommunistWolf has quit [Remote host closed the connection]
CommunistWolf has joined #zig
xackus_ has joined #zig
xackus has quit [Ping timeout: 246 seconds]
waleee-cl has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
motersen has joined #zig
riba has joined #zig
sord937 has quit [Quit: sord937]
<marler8997> I can't take it anymore I'm buying an overpriced graphics card today
<marler8997> Should I go $2,200 for the rx 6900 xt or $1600 for a rtx 3070?
<andrewrk> marler8997, what are your goals/plans for the hardware?
riba has quit [Ping timeout: 240 seconds]
aigoo has joined #zig
<marler8997> VR gaming
<waleee-cl> marler8997: is that US-style prices with no VAT?
<marler8997> yes
<waleee-cl> yikes
<marler8997> yeah it's been bad for a while, no end in sight
Akuli has quit [Quit: Leaving]
marler8997 has quit [Quit: Leaving]
<andrewrk> I just had an epiphany and now I understand Work Stealing and why it makes sense
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
xackus has joined #zig
xackus_ has quit [Read error: Connection reset by peer]
xackus has quit [Read error: Connection reset by peer]
xackus has joined #zig
xackus_ has joined #zig
xackus has quit [Read error: Connection reset by peer]
xackus_ has quit [Read error: Connection reset by peer]
xackus has joined #zig
notzmv has quit [Ping timeout: 265 seconds]
bitmapper has quit [Quit: Connection closed for inactivity]
<olabaz> hi are there websockets in zig?
marler8997 has joined #zig
<marler8997> andrewrk, what was your epiphany?
<andrewrk> I was confused because the whole idea is that you are trying to avoid accessing the same data structure as another CPU core, in order to avoid lock contention
<andrewrk> but if you have the capability to do work stealing at all, it requires locking on some shared state between cores!
<andrewrk> but what I have come to understand about mutexes and atomic data accessing is that, even lock-free stuff is still slow when the shared atomic state is contended, because the per-core CPU cache cannot be used, since the reads/writes must be shared by other cores. Additionally, uncontended mutexes are fast because they are just L1 CPU cache accesses at best.
<andrewrk> so the epiphany is that, yeah, each core just locks its own mutex in order to accept a job from its own queue. but since each core has its own work queue, it's super fast, because there is no contention. but when work stealing needs to happen, it works, because a CPU core grabs the mutex of another one. only then would there be the possibility of contention. and in this case it's OK because we need to steal the work
<andrewrk> the key insight is that it's contention that is slow, not mutexes
<marler8997> ah yes, that's what I've come to understand as well I think. Keeping cache lines isolated between cores is number 1 priority
<marler8997> oh interesting, so instead of 1 shared queue, work stealing means 1 queue per core, and when you run out, you iterate through all the other queues?
<andrewrk> right. that's the basic idea, and you can imagine variants of it
<marler8997> and it's fast because you're not hammering on the shared queue from all processor cores all the time
<marler8997> I recal the compiler was using one shared queue for jobs, did we switch to a work stealing strategy?
<companion_cube> andrewrk: I think it's true mostly because modern mutexes start by spinning on atomics, right?
Amun_Ra has quit [Ping timeout: 265 seconds]
<andrewrk> the std lib event loop is currently using one shared queue. the compiler is not using the event loop because it is too experimental
<andrewrk> the compiler has a thread pool and dispatches jobs based on one shared queue. I would be surprised if the shared lock here was causing any noticeable expense
<andrewrk> all of semantic analysis is single threaded anyway. it's only some stuff that is getting dispatched to a thread pool
<companion_cube> does tracy support multithreads?
tlam has quit [Ping timeout: 252 seconds]
Poorchop has quit [Quit: Leaving]
Poorchop has joined #zig
<g-w1> yes!
<companion_cube> that's nice.
<companion_cube> iirc the C stubs to start tracing are super basic, too?
Amun_Ra has joined #zig
plumm has quit [Quit: Textual IRC Client: www.textualapp.com]
<g-w1> yep, see tracy.zig in zig repo