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/
schme245 has quit [Remote host closed the connection]
ltriant has joined #zig
_Vi has quit [Ping timeout: 245 seconds]
<daurnimator> mq32: yeah under atomic I think
<daurnimator> uh wait, it might not be lockfree
<mq32> yeah isn't that important i think
<mq32> still got what i wanted :)
<mq32> std.atomic.Queue
mahmudov has quit [Ping timeout: 240 seconds]
Astronothing has quit [Read error: Connection reset by peer]
doublex has quit [Ping timeout: 260 seconds]
lunamn___ has quit [Quit: Reconnecting]
lunamn has joined #zig
<lunamn> is there an answer about why std.os.kill considers ESRCH a race condition?
<daurnimator> lunamn: it means you tried to kill a process that doesn't exist
<daurnimator> which implies that you were in a race scenario: because someone else killed it first!
<lunamn> why wouldn't it return an error instead, for my scenario: I'm reading a PID from a file, and well, yes, someone could've killed it first, but having a panic isn't productive..
<pixelherodev> Or it finished executing on its own
<pixelherodev> Yeah, I second that
<pixelherodev> Panicking doesn't seem a reasonable response there
<daurnimator> lunamn: PIDs are reused. if you do that then you might be killing some random other process
<daurnimator> lunamn: your reaper should be cleaning up your PID files; and your reaper should have a lock file of some sort so that it knows if itself was killed.
<pmwhite> Is there a way to use translate-c, but exclude all the included header files? I have a mix of C and Zig in my project as a workaround to a bug in the compiler, but I think the bug has been fixed, so I'd like to switch it all to Zig.
<daurnimator> pmwhite: no... but I wish there was!
<pmwhite> Is it feasible?
<mikdusan> linux reaper can kill stuff off, should this process panic? it's sensible to say "ok it's already gone, continue..."
<daurnimator> mikdusan: the OOM killer can kill; but it doesn't reap.
<pmwhite> I guess I could just run translate-c on all of it, and then extract the small percentage that is my own code.
<daurnimator> pmwhite: could diff just the #include to the whole thing and remove the shared definitions?
<daurnimator> mikdusan: well it partially reaps memory: but the process id itself still needs to be wait()'d on.
<pmwhite> hmm...good idea.
<mikdusan> daurnimator: wow poor choice of words on my part. it's exactly NOT a reaper. thanks for clarifying
ltriant has quit [Ping timeout: 265 seconds]
marijnfs has joined #zig
<pmwhite> how do prevent zig from printing the failed command after a failed build. I'm using nixos, and I have several dependencies, so the command takes up about 35 lines on my full-width terminal. Thus, I always have to scroll up to see the error messages.
marijnfs has quit [Remote host closed the connection]
mahmudov has joined #zig
ltriant has joined #zig
ltriant has quit [Ping timeout: 265 seconds]
<pmwhite> I want to say `var str = "hello-xxxxx";` but I want to be able to mutate it. Is that possible with string literals, or do I have to resort to a u8 array?
<pmwhite> i want to pass the last 6 bytes as a buffer to a random number generator so that they can be replaced with random bytes.
dddddd has quit [Ping timeout: 260 seconds]
<hryx> Philip White: String literals are immutable because they point to a const array https://ziglang.org/documentation/master/#String-Literals-and-Character-Literals
<hryx> there might be an easy way to accomplish what you want but it escapes me right now
_whitelogger has joined #zig
<pmwhite> I'm converting a wayland shared memory snippet into zig. I decided to forget about the prefix and just generate 30 random characters.
<pmwhite> Simpler code in the end.
<terinjokes> not exactly what you're looking for, but if you have an Allocator, there's `std.fmt.allocPrint`
<pixelherodev> you could probaby u
<pixelherodev> wow
<pixelherodev> beat me to it
<pixelherodev> :)
<pixelherodev> But there's a better option
<pixelherodev> There's std.fmt function that takes an existing buffer
<pixelherodev> So you could do `var buf: [16]u8 = undefined; std.fmt.ICantForTheLifeOfMeRememberWhatThisFunctionIsCalled(buf, "hello-{}", .{randomlygeneratedstuff{);`
* terinjokes opens fmt.zig
<terinjokes> `std.fmt.bufPrint` ?
schme245 has joined #zig
andrewrk has quit [Quit: ZNC - http://znc.in]
andrewrk has joined #zig
euantor has quit [Ping timeout: 245 seconds]
strmpnk has quit [Ping timeout: 245 seconds]
<terinjokes> ^ worked where I tried it
schme245 has quit [Ping timeout: 268 seconds]
strmpnk has joined #zig
euantor has joined #zig
gonz_ has quit [Ping timeout: 245 seconds]
<pmwhite> pixelherodev: that would require already having a buffer filled with random stuff. I could do a `std.mem.copy` on the string literal and then pass the rest of the string as a slice to the random number generator, which is how `std.rand` generates bytes.
<pixelherodev> If it generates to a slice then it's even easier
gonz_ has joined #zig
<pixelherodev> Can literally initialize the buffer once
<pixelherodev> Then randomize a slice of the end
<terinjokes> is your random function not returning a slice now?
<pmwhite> Yup, that's what I'm doing, except I decided to not care about the prefix and just randomize the whole thing, which means I don't even have to initialize the slice.
<daurnimator> pmwhite: var foo = "something".*;
<pmwhite> daurnimator: thanks, that's exactly what I was looking for.
swoogan has quit [Ping timeout: 260 seconds]
ltriant has joined #zig
_whitelogger has joined #zig
<hryx> mikdusan or andrewrk, a question if you have a sec. I made a change for #2146 and it seems to do the job. Ok, great. But now the test "compile-error switch with overlapping case ranges" fails, and I can't see why it should be affected.
<hryx> The only explanations I can imagine so far are a) this numeric comparison code affects range expressions, or b) my implementation is buggy
<hryx> I made a draft in case anybody familiar with stage1 knows what's up: https://github.com/ziglang/zig/pull/4155
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
schme245 has joined #zig
ltriant has joined #zig
ltriant has quit [Ping timeout: 240 seconds]
<pixelherodev> There a convenient way to access the caller function using a stack trace?
<pixelherodev> Or would a hacky method involving getting the function name and then `dlsym(NULL, sym)` be needed?
<daurnimator> pixelherodev: "access" the caller function?
<pixelherodev> Find it's address
<pixelherodev> s/'//
<pixelherodev> Which would allow for e.g. `if (caller() == specific_func)`
<daurnimator> sounds like a bad idea.... what are you trying to do?
<daurnimator> A better idea might be to have your function take a @returnAddress() (like dlsym secretly does on glibc)
<pixelherodev> Nah,
<pixelherodev> Basically, the idea is that a UI function should add a button which calls itself
<pixelherodev> Except that that function has various callers
doublex has joined #zig
_whitelogger has joined #zig
FSX has quit [Quit: WeeChat 2.3]
schme245 has quit [Remote host closed the connection]
ltriant has joined #zig
ltriant has quit [Ping timeout: 245 seconds]
wootehfoot has joined #zig
<Astronothing> is there a way to copy from a *u8 to a u64? I'm trying @ptrCast(*u64, &bytes[0x18]).* but I'm getting "error: cast increases pointer alignment". If I try @ptrCast(*u64, @alignCast(64, &bytes[0x18])).* I get a runtime error "incorrect alignment". I understand why neither works, but is there a way to make it work?
schme245 has joined #zig
<mikdusan> Astronothing: see std.mem.bytesToValue()
<Astronothing> that. is. awesome.
<Astronothing> thanks!
<gonz_> Astronothing: `*T != []T` in zig, by the way
<Astronothing> yes, one is a pointer to one element, one is a slice
<Astronothing> pointer to one item* (from the documentation)
<mikdusan> Astronothing: another way would be to ptrCast addr of u64 (buffer) to *u8 and memcpy; this way you are decreasing ptr alignment
<Astronothing> and *T is not *[N]T which is why std.mem.bytesToValue(u64, &bytes[0x18]) doesn't work either
knebulae has quit [Read error: Connection reset by peer]
knebulae has joined #zig
moo has joined #zig
wootehfoot has quit [Ping timeout: 265 seconds]
<daurnimator> Astronothing: do you mean from *u8 to *u64? or actually to u64
<daurnimator> Astronothing: if the latter, @ptrToInt
dddddd has joined #zig
ltriant has joined #zig
<Astronothing> daurnimator: I have a []u8, I want to take 8 bytes from it and copy them to an u64 verbatim (no endianness change)
<betawaffle> wow, zig is so awesome
<betawaffle> andrewrk++
<daurnimator> Astronothing: okay sounds like you want @bytesToSlice
ltriant has quit [Ping timeout: 260 seconds]
bsrd has joined #zig
<Astronothing> daurnimator: I didn't think of that, but it worked, thanks!
<scientes> ugggh, what about alignment?
<scientes> so slices can have non-natural alignment type?
<daurnimator> scientes: []align(1) u64
<scientes> yes i see
<Astronothing> since I'm just using it to initialize a u64 aligned type, does it matter what the RHS alignment is?
frmdstryr has quit [Ping timeout: 260 seconds]
<scientes> just copy it
<scientes> then you don't have to worry about alignment
marijnfs has joined #zig
<marijnfs> array literal requires address-of operator to coerce to slice type '[]const []const u8'
<marijnfs> const full_in = try path.join(b.allocator, [_][]const u8{ dirname, in_file });
<marijnfs> was ist los
<daurnimator> ?
FSX has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 268 seconds]
<betawaffle> i think they are asking what the error is
<schme245> marijnfs_: put a & infront of it
FSX has left #zig [#zig]
<schme245> marijnfs_: &[_][]const u8{ dirname, in_file }
<mikdusan> hryx: looks like IrInstructionCheckSwitchProngs never gets (comptime) executed because tautological-PR makes previous runtime conditional now a comptime and block is never hit
<mikdusan> i think it's this way as sort-of a comptime optimization where checks are only needed as last resort
<marijnfs_> schme245: ow there, i was trying to put it in from of other parts
<marijnfs_> this is a confusing one i must say, could it be more descriptive?
<marijnfs_> also what happened with c-strings, you don't need c"sdf" anymore?
<mikdusan> sentinal terminated arrays, slices and (c ?) pointers are a thing now
<marijnfs_> I'm looking at the vulkan-triangle example and issues with it
<marijnfs_> error: expected type '[*:0]const u8', found '[*]const u8'
<marijnfs_> what is that :0 type, that's zero terminated?
<mikdusan> yup
<marijnfs_> how do i cast to it, or create one with a string literal? c"sdf" doesn't work anymore
<schme245> marijnfs_: const slice: [:0]const u8 = "hello";
<schme245> sorry, [_:0]u8 instead of [:0]u8
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 268 seconds]
<mikdusan> marijnfs_: string literals are now null-terminated. so you get immediate interop with C.
<marijnfs> mikdusan: ah, as in all of them? Ok good to know
<marijnfs> expected type '[*:0]const u8', found '*const [256]u8', a similar one
<marijnfs> how do i cast between these types?
<Snektron> The type you provided doesn't have a null terminator
FSX has joined #zig
FSX has left #zig [#zig]
schme245 has quit [Remote host closed the connection]
<marijnfs> yeah it comes from a c-struct, so it's zero terminated but the type is not explicit in that
<marijnfs> how do i cast it or something
<Snektron> i think you should be able to use @ptrCast
<mikdusan> @ptrCast(*const [256:0]u8, my_256_buffer);
FSX has joined #zig
<marijnfs> mikdusan: that seems to work
<marijnfs> whats up with readFileAllocAligned, now it's a function of Dir? and still takes a path
<mikdusan> hmm anon list literals field names `args.@"0"` is weird -- it's always going to be a number. Did we ever discuss array-syntax instead? `args[0]`
<betawaffle> is it possible to get the stdlib docs for a non-master and/or non-linux build?
_Vi has joined #zig
<Snektron> i think you can use the docs target or something like that when compiling yourself
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 260 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 265 seconds]
lunamn has quit [Ping timeout: 265 seconds]
metaleap has joined #zig
metaleap has quit [Remote host closed the connection]
ltriant has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 240 seconds]
ltriant has quit [Ping timeout: 268 seconds]
lunamn has joined #zig
metaleap has joined #zig
FSX has quit [Quit: Leaving]
metaleap has quit [Client Quit]
metaleap has joined #zig
___ has joined #zig
<betawaffle> is there currently a way for zig to tell me how much stack space is needed by a function (and anything it may call), at least in the case of no recursion?
___ has quit [Client Quit]
metaleap has quit [Client Quit]
<mq32> betawaffle, yeah, you can use @sizeOf(@Frame(func))
<mq32> it's not exactly the stack space, but pretty close to it
marijnfs_ has quit [Ping timeout: 240 seconds]
marijnfs has joined #zig
<betawaffle> is there a way to see *what it actually is*?
<betawaffle> (i'm just trying to better understand how zig works)
mahmudov has quit [Ping timeout: 268 seconds]
<marijnfs> betawaffle: maybe @frameSize?
<mq32> betawaffle: it's not that easy. there's an upper limit for "stack space" used, but that depends on how zig actually compiles that functions
<mq32> i don't know what "extra" fields are contained in an async frame, but it's at least "required stack space" large and has only a (constant) overhead
<betawaffle> is the size it comes up with trustworthy?
<mq32> (at least to my knowledge and understanding)
<mq32> @frameSize is just a shorthand for @sizeOf(@Frame())
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 268 seconds]
metaleap has joined #zig
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 265 seconds]
metaleap has quit [Client Quit]
metaleap has joined #zig
<betawaffle> is it expected that @frameSize seems to return weird values for non-async functions?
<metaleap> betawaffle: for your earlier question, you probably already saw https://github.com/ziglang/zig/issues/157 ?
<betawaffle> oh hey, found a compiler bug, it seems?
<betawaffle> "when analyzing .../main.zig:6:30: assertion failed. This is a bug in the Zig compiler."
<scientes> betawaffle, those are commong, you need to put in the debugger
mahmudov has joined #zig
<betawaffle> seems to happen with `var frame: @Frame(foo) = async foo();` but not `var frame = async foo();`
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 268 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 268 seconds]
_whitelogger has joined #zig
marijnfs has quit [Ping timeout: 240 seconds]
marijnfs_ has joined #zig
swoogan has joined #zig
schme245 has joined #zig
ltriant has joined #zig
SimonNa has joined #zig
marijnfs_ has quit [Ping timeout: 240 seconds]
marijnfs has joined #zig
schme245 has quit [Remote host closed the connection]
ltriant has quit [Ping timeout: 265 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 258 seconds]
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
doublex has quit [Ping timeout: 260 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 258 seconds]
<metaleap> newb question (coming not from c but from go / ts / c# / hs) --- I assumed I'd be allowed to keep every local `const` if I never re-assign to it, but I *need* to keep the return of `std.heap.ArenaAllocator.init()` in a `var` to be able to call its `.deinit()`. looks smelly to me as I never re-assign to the name. what's the subtlety at play here that I'm missing as someone who knows pointers in "fisher-price edition" from go / pascal but not from c / c++
<metaleap> / d? sure: zig compiler explains that it "expected type '*std.heap.ArenaAllocator', found '*const std.heap.ArenaAllocator'" but the `deinit` doesnt seem to directly re-assign any of `self`s immediate members. sure the stuff gets `free`d and might be invalid from then on but in terms of names being assigned, no "mutation". suppose `const` has meanings/implications beyond "bound name can be / cannot be re-assigned / overwritten", right? what would be the
<metaleap> elevator summary for those for non-C newcomers for whom the concept of pointers isn't entirely foreign on the whole?
<fengb> const also means memory never changes. deinit() updates the memory in the struct
<fengb> It’s different from JS where it only implies no reassignment
moo has quit [Quit: Leaving]
wootehfoot has joined #zig
<metaleap> fengb: thx for confirming! good to know
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
doublex has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 268 seconds]
metaleap has quit [Quit: Leaving]
<Snektron> Is it me or is the error trace sometimes wrong?
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 258 seconds]
<mikdusan> sounds serious if that's the case
<mikdusan> ( friendly reminder it's easy to forget runtime traces lookup source code. and source code changes even if binaries don't )
metaleap has joined #zig
<betawaffle> oh, the trace info isn't embedded in the binary?
<mikdusan> oh wait I am uncertain about that statement. I was thinking about other handlers that sometimes show file-not-found .
<mikdusan> ok I'm certain now. Moving an exe to another machine and this is what I get: `Unable to dump stack trace: FileNotFound` so at least it's pretty clear.
mahmudov has quit [Read error: Connection reset by peer]
mahmudov has joined #zig
marijnfs_ has joined #zig
mahmudov has quit [Remote host closed the connection]
marijnfs has quit [Ping timeout: 268 seconds]
<betawaffle> so, does that mean traces become useless if you build on one machine and run on another?
<metaleap> next noob quest. so you go looking for the equivalent of strconv.itoa or int.toString or some such. you glimpse at the `std.fmt` and see signatures such as:
<metaleap> fn formatInt(value: var, base: var, uppercase: var, options: var, context: var, comptime Errors: var, output: var) var
<metaleap> fn formatIntBuf(out_buf: []u8, value: var, base: var, uppercase: var, options: var) var
<metaleap> fn formatIntValue(value: var, comptime fmt: var, options: var, context: var, comptime Errors: var, output: var) var
<metaleap> well guess i gotta look at the source here, but if anyone has a 1-liner for me in their head from prior battles, shoot!
ltriant has joined #zig
mahmudov has joined #zig
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 258 seconds]
<euantor> metaleap: look at std.fmt.bufPrint: https://ziglang.org/documentation/master/std/#std;fmt.bufPrint
<euantor> You supply a buffer to write into, a format string and any variables
<fengb> That signature will be changing soon™
<mikdusan> this 1 liner punts to arena... and ain't pretty: `const s = (try std.Buffer.allocPrint(arena, "{}", .{499})).toSliceConst();`
<metaleap> marvellous, thx! from knowing at comptime that I'm passing an int, calling this with a format-string will be as runtime-efficient as some direct "formatInt(n)"-of-sorts would be, I guess?
<fengb> There’s a lot of comptime layers but it should resolve to a direct function call yes
<metaleap> i'm used to avoiding string-format-calls in other langs for overhead reasons when i want toString just a single val of known type and go for the explicit formatInt / formatFloat / etc builtin usually
ltriant has quit [Ping timeout: 268 seconds]
<metaleap> nice
doublex has quit [Ping timeout: 240 seconds]
<fengb> Hmm this might be worse with my generator changes. I’ll make a note to do some profiling
doublex has joined #zig
BaroqueLarouche has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 268 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 265 seconds]
<wjlroe> Am I doing something wrong here where I try to list files in the current directory, but after the scope exists, and dir.close() runs, the first path in the slice becomes blank/null?: https://gist.github.com/wjlroe/4042b3a6307c02cab6896a22b3d4f8a4
<marijnfs> entry.name is probably owned by dir and deleted?
<marijnfs> you probably need to allocate and copy or something
<wjlroe> Yeah I thought it would be something like that, but it was strange to me that it was only the first one (consistently) that ends up blank (no matter how many files it's listing). I shall have to mem.copy into the ArrayList I guess
<marijnfs> that is indeed curious
<wjlroe> std.mem.dupe(allocator, u8, entity.name) fixed it
<wjlroe> Thanks @marijnfs @mikdusan
marijnfs has quit [Remote host closed the connection]
lunamn has quit [Quit: leaving]
lunamn has joined #zig
ltriant has joined #zig
<betawaffle> am I correct that a mem.Allocator is not required to be thread-safe?
<hryx> mikdusan: thanks for the tip about IrInstructionCheckSwitchProngs. I'll take a look later today.
ltriant has quit [Ping timeout: 268 seconds]
<metaleap> my code traverses deep into a `std.json.ValueTree`, switching on tagged-union `Value`s where the switch is always exactly one expected union member or `else => return error.Foo`. so a lot of braces / indenting where all `switch`es have exactly only one success case or failure. do we have a `try`able alternative to coercing/extracting some input tagged-union member into a single expected tag or-else-error?
<metaleap> would be mere sugar of course and kinda violate "have one obvious way to do sth" zigzen
swoogan has quit [Ping timeout: 260 seconds]
<fengb> There’s potential for sugar if it consistently improves code
<metaleap> just made a comptime fn that does it... fun stuff! my first comptime :D
<fengb> There’s std.meta.activeTag()
<metaleap> neat, will check
frmdstryr has joined #zig
<mq32> metaleap: what's the problem with
<mq32> fn(x: Union) !Stuff { if(x != .myField) return error.Wrong; return x.myField.foo; }
<mq32> you are always allowed to directly access a union member as long as it's the active one
<fengb> You can compare directly to the enum like that?
<mq32> yep
<mq32> afaik that is even documented behaviour :)
<mq32> there we go
<metaleap> mq32: crikey you're right, i read about that scanning the main lang doc, then forgot!
<fengb> Well I should refresh myself with the docs :P
<mq32> fengb, do your chores and read the manual once a week!
<fengb> I still haven’t rtfm :(
metaleap has quit [Quit: Leaving]
ur5us has joined #zig
<Astronothing> anyone know why `std.os.argv` isn't available on windows? https://ziglang.org/documentation/master/std/#std;os.argv
schme245 has joined #zig
<mq32> because windows arglists work differently from unix ones
metaleap has joined #zig
<daurnimator> metaleap: sounds like you might like my autojson branch. https://github.com/daurnimator/zig/tree/auto-json
<metaleap> @daurnimator parses into a given struct type, eh? if that lands it'll definitely be a much-welcomed addition enabling awesome use-cases. i won't need for current scenario at-hand (the json is actually a sort of "byte-code" of a custom FP-IL with arrays-of-arrays-of-ints-or-arrays-of-ints so if anything would have to auto-parse-into union rather than struct --- would btw be a common situation for various real-world json-schemas in the wild! though in
<metaleap> current-case the format is trivial enough to just walk the std.json.ValueTree manually. but there are crazy-enough schemas out there were codegen or comptime will be needed for feasible unmarshaling)
<Astronothing> mq32: it makes not difference to C, the stdlib takes care of it
<metaleap> daurnimator: so I hope you're shooting for that branch to be eventually PR'd into master of std.json
<daurnimator> metaleap: yes it was already open (3155), I need to polish a bit then will reopen
<daurnimator> metaleap: currently unions aren't handled for decoding: I need to figure that out...
<daurnimator> metaleap: if you do want to give it a try and point out any issues I'd be grateful
<metaleap> daurnimator: tricky indeed with the unions. might need additional "hint attribute" // comments. a given json node could succeed for more than one union-member-tag, which to choose? first success? based on member ordering? tricky, tricky. tho better to have some opinionated default that one can work with by structuring/ordering one's type hierarchy of structs-and-unions towards it, than not having such at all.
<metaleap> as for trying, am headed to bed actually but keeping the tab open so I'll remember to check it out next day after work
kotey has joined #zig
<kotey> Hi, I'm new to Zig. I've installed 0.5.0 version(Linux) zig binary to PATH
<kotey> but nothing works
<kotey> zig build-exe hello.zig
<kotey> Unable to find zig lib directory
metaleap has quit [Quit: Leaving]
schme245 has quit [Remote host closed the connection]
schme245 has joined #zig
lunamn_ has joined #zig
ltriant has joined #zig
lunamn has quit [Ping timeout: 265 seconds]
schme245 has quit [Ping timeout: 240 seconds]
<Astronothing> kotey: what does `which zig` print?
<daurnimator> kotey: also you might want to try master; 0.5.0 is getting a bit old now. Much has changed.
<kotey> Thanks, everything worked with latest `which zig` shows /home/kotey/zig-linux-x86_64-0.5.0+c4770e7aa/zig and `zig version` 0.5.0+c4770e7aa
dingenskirchen has quit [Quit: dingenskirchen]
_Vi has quit [Ping timeout: 245 seconds]
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
dingenskirchen has joined #zig
kotey has quit [Remote host closed the connection]
wootehfoot has quit [Quit: Leaving]
ltriant has quit [Ping timeout: 240 seconds]
ltriant has joined #zig
<pmwhite> I wish I could name multiple parameters to a function `_`. It would be nice if Zig disallowed `_` as a variable name and reserved it to mean "ignore this value". Not only would it be a convenient name for parameters I don't care about, but it would also be more consistent with the result ignoring syntax.
benjif has quit [Remote host closed the connection]
benjif has joined #zig
<andrewrk> pmwhite, I invite you to open a proposal for that
hspak has quit [Ping timeout: 240 seconds]
ltriant has quit [Ping timeout: 245 seconds]
hspak has joined #zig
rankao has joined #zig
wootehfoot has joined #zig
marijnfs has joined #zig
<pmwhite> andrewrk: I think I will.
marijnfs has quit [Ping timeout: 240 seconds]
marijnfs has joined #zig
<daurnimator> andrewrk: from translate_c.zig, how can I get the current target?
<andrewrk> daurnimator, it looks like the target is not communicated to translate-c zig code directly; it's passed on the clang arg line though
<pixelherodev> It's amazing how much slower Zig is when running under a load average of ~9 :P
<andrewrk> it's something the zig code should have access to if it needs it. out of curiosity what do you need it for daurnimator?
<daurnimator> andrewrk: to figure out the size of e.g. 'long' on the current target
<andrewrk> daurnimator, ah yes, in this situation, it would be better to avoid looking at the target I believe
<daurnimator> andrewrk: okay.... what do I do instead?
<Snektron> Was there any plan on resolving duplicate enum fields in C enums?
<daurnimator> Snektron: I thought that was fixed by making them `pub const` fields?
<andrewrk> daurnimator, you can ask questions like "is this integer bigger than that one" without knowing the target
<andrewrk> what's the test case you're working on?
<andrewrk> as an example look at integer casting
<daurnimator> andrewrk: bit fields: need to know the number of bits used up so a can insert the right sort of padding
<Snektron> daurnimator, thats a possibility yeah
<Snektron> i suppose it works for this since the aliases are usually just FLAG_NAME_KHR and FLAG_NAME
TheLemonMan has joined #zig
<andrewrk> daurnimator, in some cases it may be necessary to emit target specific code. but consider that the C code is probably *supposed* to be portable. if we could translate it portably that would be ideal
<andrewrk> bit fields might depend on the C ABI. I'm not sure
<Snektron> no wait, not always
<TheLemonMan> daurnimator, you probably want to get & use a ASTRecordLayout
<Snektron> For this i've just made a small struct for bit fields
<daurnimator> TheLemonMan: huh.... and now I feel over my head
<Snektron> `Flags(QueueFlagBits).init({.Compute, .Graphics})`
<andrewrk> note that zig uses the "C ABI" part of the target to overcome inconsistencies in different C compilers. that might or might not be relevant for bit fields
<daurnimator> andrewrk: note that bit fields are underspecified by the C ABI and differ between compilers
<daurnimator> which means that any C code that exposes bit fields as ABI requires you use the same compiler for both building and using the library
<TheLemonMan> daurnimator, that object contains all the offsets (in bits) of each field as computed by clang
<TheLemonMan> but that's not the ideal solution if we aim for a target-independent translatio
<Snektron> ngl writing that Vulkan generator is more work than i thought
<andrewrk> daurnimator, that's my point - the "C ABI" is part of the target in zig. we overcome the inconsistency by having "which C compiler should we target?" as part of the target
<andrewrk> target-independent translation may not be possible, but we should shoot for that if it is possible
<TheLemonMan> hmm, I think we've already given that up since we work on the expanded code
<TheLemonMan> eg. every ifdef has already been expanded
<daurnimator> andrewrk: you'd sort of have to provide this info on a per-symbol level
<daurnimator> andrewrk: e.g. its possible to link an object compiled by gcc and an object compiled by clang: one symbol could use GCC bit layout; another symbol could use clang layout
<andrewrk> TheLemonMan, that's true but we do translate, e.g. `long` as `c_long` rather than `i64`
<andrewrk> daurnimator, clang also solves this with "C ABI" as part of the target. you can tell clang to match gcc
<andrewrk> in fact I believe that is the default
<TheLemonMan> that may be too little, too late :)
<daurnimator> TheLemonMan: would it be possible for us to convert #if/#endif to comptime conditions?
<andrewrk> not really
<TheLemonMan> we're already struggling with basic macros so I guess not heh
<daurnimator> yeah I figured
<andrewrk> maybe if zig was actually the c compiler, but not using clang as an API
<daurnimator> One thing I'd like us to do is to generate different zig files for different C includes: for now before/after each #include we could do a diff
<andrewrk> TheLemonMan, you're correct with regards to producing target-specific code, but it is also true that most translated C code is target-independent. code that is not from an #ifdef for example, I would expect to be generally portable
<TheLemonMan> you can pull some shenanigans on the clang ast and recover the original macros but it's too cumbersome to be practical
<TheLemonMan> andrewrk, as long as people stick to @cinclude (instead of shipping a translate-c generated file) our assumptions are fine
<pmwhite> Just wrote the proposalhttps://github.com/ziglang/zig/issues/4164
<daurnimator> pmwhite: depending on the calling convention the types need to be known
<hryx> TheLemonMan: thanks for the tip on #4155. No time to solve it right this moment but I left a note for later
<pixelherodev> Uh - why wouldn't ifdef -> comptime be possible?
<pixelherodev> Not necessarily a 1:1 conversion
<andrewrk> thanks pmwhite - accepted
<pixelherodev> But if you have e.g. a comptime map of strings to strings, it should be possible
<TheLemonMan> hryx, np, switch + ranges is a deadly combo (see #3988 and a few other tickets)
<pixelherodev> For instance, when `@cImport`ing, the returned structure could have a map of definitions
<daurnimator> pixelherodev: for now translate_c has two phases: one where clang has fully done the preprocessing step and C parsing; the other where zig tries to understand macros
<pixelherodev> And then ifdef becomes `if (@T` - oh
<pixelherodev> Hmm
<pixelherodev> So basically, we'd need a self-hosted C preprocessor replacement?
<daurnimator> pixelherodev: yup.
<pixelherodev> Seems a worthwhile thing to have anyways though
<pixelherodev> If integrated with translate-c, it *should* be possible to emit a comptime definitions map (e.g. named `translation_define_maps`) and then have #defines modify the map and #ifdefs be comptime comparisons
<pixelherodev> I don't think that would be too much work actually
<pixelherodev> Assuming we only support a subset (e.g. no #pragmas)
<pixelherodev> #include #define #if #ifdef #else and #endif should be pretty simple
<TheLemonMan> you're forgetting that the C preprocessor operates on plain text
<pixelherodev> Doesn't have to.
<pixelherodev> If this is specifically for translation to Zig anyways, the preprocessing doesn't have to be a distinct step
<TheLemonMan> I mean, the directives may be in places that are actually illegal in Zig code
<TheLemonMan> a "dumb" textual translation is not enough
<TheLemonMan> unless you aim for "60% of the times it works all the times"
<andrewrk> btw TheLemonMan did you see how impressive c2rust is with regards to goto? https://c2rust.com/
<andrewrk> (change the dropdown and hit "load sample")
<andrewrk> I believe we don't need anything as sophisticated, because unlike rust we can break from blocks, which is essentially a goto
ur5us has quit [Ping timeout: 260 seconds]
<pixelherodev> If they're in places that are illegal in Zig code, then preprocessing beforehand wouldn't change that
<pixelherodev> If the goal is match current behavior, it should be simple enough
<pixelherodev> From there, converting to comptime comparisons would be pretty simple
<TheLemonMan> andrewrk, damn that's cool
<andrewrk> pixelherodev, zig's translate-c is translating already-preprocessed-by-clang code. the second phase daurnimator mentioned is trying to turn *the macros themselves into an API*
rankao has quit [Remote host closed the connection]
<andrewrk> which, in my opinion, is always a poorly designed C API. macros should almost never be part of the public API. please make an actual C ABI, thank u
<TheLemonMan> if you want to do such elaborated transforms you need to go to an intermediate (and possibly typed) AST before going to the "renderable" AST
<andrewrk> yes
rankao has joined #zig
<andrewrk> so far we've gotten away with skipping a lot of steps
<pixelherodev> Right, but I'm talking about something entirely different
<pixelherodev> I'm talking about replacing the preprocessing clang does with a self-hosted preproc
<daurnimator> so... I really want to try and get bitfields working within the next few hours
<andrewrk> I bet you could hack something that works for your use case together in a couple hours
<daurnimator> AFAIK its the remaining major blocker on an MVP for zig kernel modules
<daurnimator> andrewrk: I've been trying... but keep getting compiler crashes :(
<andrewrk> ah bummer
<andrewrk> I hate when that happens
<TheLemonMan> daurnimator, this may be helpful https://gist.github.com/LemonBoy/3e185207ab072fb52e0a8d6f1b75fbd2
<TheLemonMan> when the compiler crashes it means you've found the next yak to shave!
<andrewrk> haha
<daurnimator> TheLemonMan: I don't suppose I can give you a sample to work on for a couple of hours? are you on linux?
ur5us has joined #zig
<andrewrk> daurnimator wants to demo a linux kernel module at a conference he's going to
<daurnimator> andrewrk: I'm already here :P
<andrewrk> oh :)
<TheLemonMan> in the next few hours I'm supposed to get some sleep, tomorrow's already looking bleak
<andrewrk> sorry to hear that
<andrewrk> sleep is great, love sleep
<Astronothing> daurnimator will it be recorded? :D
<TheLemonMan> it _should_ be relatively easy to get a PoC starting from that gist
<Snektron> hmm
<TheLemonMan> you have the bit-offset of each field and can get the type size
<Snektron> Would it be possible to move the code to parse C into std?
<Snektron> I'm almost thinking its easier to parse vulkan.h with that and generate the source from a Zig ast
<Snektron> as opposed to this ungodly spec
<TheLemonMan> andrewrk, speaking of `switch`, does the language ref state what kind of types one can use ?
<andrewrk> TheLemonMan, I think that is not specified yet
<TheLemonMan> Snektron, I wonder if it's even worse than xcb thousand xml files containing the protocol definitions
<Snektron> I haven't seen those
<andrewrk> I was thinking recently that it would make sense to start on a draft of the language specification
<companion_cube> is there nested pattern matching 😏
<Snektron> But if theyre as ""language agnostic"" as the Vulkan ones i fear the worst
<TheLemonMan> Snektron, https://xcb.freedesktop.org/XmlXcb/
Astronothing has quit [Quit: Leaving]
<Snektron> yeah similar
<TheLemonMan> "whatever the compiler accepts" is the best specification at this point IMO
marijnfs has quit [Remote host closed the connection]
<Snektron> i'm completely confused about why this structure was chosen
<Snektron> it doesn't make any sense
<andrewrk> TheLemonMan, I agree that's status quo, but that's less than ideal for folks who want to depend on the project
<Snektron> andrewrk, did you see my questions about std.zig from yesterday?
<Snektron> to reiterate: Why is ast.Tree returned as a pointer to memory owned by itself, and why are nodes a knock-off union(enum) instead of an actual one?
<andrewrk> Snektron, the second question is shorter to answer, so starting there: it's different in memory. union(enum) takes up a constant amount of memory regardless of the node type, but it allows preallocation of nodes. the way std.ast is done does not allow pre-allocation of nodes, but nodes only take up as much memory as the specific kind requires
<andrewrk> it's two different and valid ways to do polymorphism
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<andrewrk> for the first question, it's because the parser uses an arena allocator as the strategy for freeing memory