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/
dermetfan has joined #zig
dermetfan has quit [Ping timeout: 260 seconds]
<andrewrk> this zig build integration with std.log is improving my debugging process big time
<andrewrk> great. I just accidentally pressed the hexchat keyboard shortcut for hiding the gui menu and now I can't figure out how to get it back
<ronsor> this is why I stick with irssi :)
<ronsor> anyway: /gui menu toggle
<andrewrk> nice thank you
waleee-cl has quit [Quit: Connection closed for inactivity]
klltkr has quit [Ping timeout: 264 seconds]
<andrewrk> brainstorming: what kind of DWARF .debug_info tags can be used as "NOP" padding?
<andrewrk> example: https://clbin.com/HX8ri there has got to be some kind of DW_AT_foo which can be used to just take up space in the ELF file and do nothing else
<andrewrk> maybe DW_TAG_lo_user will be properly ignored by gdb and other debug info consumers
squeek_ has quit [Ping timeout: 240 seconds]
<fengb> “As a long way as Zig is anxious, the predominant advantages of the original LLVM version are worm
<fengb> fixes”
<fengb> Looks like someone double translated the English
<ronsor> yep
<mikdusan> yup double trans
<ronsor> `take a look at "coerce array pointer to reduce" {`
<ronsor> lol
<fengb> “Now now we grasp Zig as a incorrect compiler.”
<ronsor> not sure how they translated it
<ronsor> random code is translated too
<mikdusan> this is an excellent reference on how not to say anything: "This purpose will seemingly be thought to be deprecated by an legitimate occasion"
<ronsor> So that's how the suits manage to say so much and mean so little
<torque> one pudgy-time developer
<torque> this is rude
<andrewrk> hahaha
<andrewrk> "That is the finest pickle"
corvid has quit [Quit: ZNC 1.6.5+deb1+deb9u2 - http://znc.in]
<ronsor> it's interesting because when I first saw the article, I didn't really read it and it seemed fine at first glance.
<ronsor> i thought it was just copied from the site
<ronsor> then I began to read
<torque> man this entire website is like this, bizarre
<andrewrk> "For that reason I determined to open the Zig Tool Foundation"
<ronsor> > Anandkumar is a frequent supporter of initiatives for the equitable medication of ladies.
<ronsor> it is weird
<andrewrk> "unblocking contributors from conducting their dreams"
<andrewrk> $ zig take a look at json_parse_struct.zig
<ronsor> RISC-V toughen in Zig is now improbable! We even grasp
<ronsor> riscv64 binary tarballs now on account of the Bootstrap Tarball.
<ronsor> all "test" has turned into "take a look at"
<andrewrk> I do like how "Let’s reboot programs programming" calls out the fact that "systems programming" is kinda redundant
<ronsor> ATM machine
<andrewrk> that's why I say "ATM achine"
<andrewrk> how about that stock photo of someone writing release notes onto a piece of paper with a pen? maybe I should try that next time
<andrewrk> might take a while. the 0.6.0 release notes are 94 pages printed
<ronsor> I wonder if the stock photo is stolen too
pmwhite has quit [Remote host closed the connection]
pmwhite has joined #zig
<andrewrk> ifreund, i'm solving a similar problem as you in DWARF with regards to a list of types. my plan right now is to duplicate all the dwarf type information for each Decl. e.g. if there is `fn foo() *i32 {...}` and `fn bar() *i32 {...}` then it will emit the dwarf type info for the `*i32` type once per Decl. this will allow updating them each independently
<andrewrk> however, something like `const T = struct {...};` is its own decl; in this case `fn foo() T {...}` and `fn bar() T {...}` could both point to the T Decl. In theory. This might require some improvements to stage2 to make it work
cole-h has joined #zig
<pixelherodev> How good *is* the new GPA?
<pixelherodev> Do we have numbers yet?
<pixelherodev> Curious whether it consistently beats, say, c_allocator
pmwhite has quit [Ping timeout: 260 seconds]
<andrewrk> it's bad
<andrewrk> next step is to establish some benchmarks and put them into ziglang/gotta-go-fast
craigo has joined #zig
<andrewrk> the debug mode (and testing) experience just got a huge upgrade though
<andrewrk> one neat thing is it even works in freestanding mode, if your freestanding project provides a page allocator
marnix has joined #zig
cole-h has quit [Quit: Goodbye]
qazo has quit [Ping timeout: 240 seconds]
craigo has quit [Quit: Leaving]
craigo has joined #zig
aruniiird has joined #zig
<aruniiird> Hey Ziguans, a newbie question,
<aruniiird> how will you reverse traverse a string, I tried something like
<aruniiird> var curNumIndex = num.len - 1;
<aruniiird> pub fn multiply_2(num: []const u8) void {
<aruniiird> while (curNumIndex >= 0) : (curNumIndex -= 1) {
<aruniiird> <do something here>
<aruniiird> }
<aruniiird> }
<aruniiird> I am getting an integer overflow, as curNumIndex is an unsigned type.
<aruniiird> Any easier way to reverse traverse an array ?
<andrewrk> aruniiird, var i: usize = num.len; while (i > 0) : (i -= 1) { ... }
<andrewrk> oops. var i: usize = num.len; while (i > 0) { i -= 1; ...; }
<aruniiird> andrewrk: Thanks, trying it out...
<aruniiird> So we have to use `num[curNumIndex-1]` to access the array, right?
<aruniiird> Oh! sorry , now I got your difference in the second line...
dermetfan has joined #zig
dermetfan has quit [Ping timeout: 246 seconds]
<danyspin97> const Self = struct { ... };
<danyspin97> is this valid?
<danyspin97> I am trying to avoid the redundant @import("Struct.zig").Struct;
<ifreund> danyspin97: you files are structs, you can use toplevel fields
<danyspin97> ifreund: yup, I am reading your source cod
<danyspin97> ah, I see
<danyspin97> but this way I can't add neither extern or packed
<ifreund> no, that's true
<ifreund> I have yet to use either in river though at least
<danyspin97> I see, thanks!
drewr has quit [Ping timeout: 260 seconds]
drewr has joined #zig
Ashpool has joined #zig
waleee-cl has joined #zig
cren has joined #zig
wootehfoot has joined #zig
<cren> This isn't quite a Zig question, but I'm getting an error trying to create a receiving socket bound to localhost when I run the binary without root
<cren> as root it works
<cren> the error is "Access Denied"
<cren> should I be expecting this?
<andrewrk> cren, I believe you need root for lower port numbers but for higher port numbers (try a 5 digit number) it shouldn't need root
<cren> thanks andrewrk, that seems to work.
wootehfoot has quit [Ping timeout: 256 seconds]
<lemmi> cren: for ports below 1024 you need at least CAP_NET_BIND_SERVICE (see man 7 capabilities)
<cren> lemmi: thanks
wootehfoot has joined #zig
dermetfan has joined #zig
cren has quit [Ping timeout: 260 seconds]
marnix has quit [Ping timeout: 246 seconds]
_whitelogger has joined #zig
hspak has quit [Ping timeout: 240 seconds]
pmwhite has joined #zig
<ifreund> uh, if I want to get a [*] pointer to an arbitrary element in an array, is there a clean way to do it withoug @ptrCast()?
<pixelherodev> &array[index] ?
<pixelherodev> Ahh, right
<pixelherodev> array[index..end][0..].ptr?
<ifreund> that's just a * pointer not [*] yeah
<pixelherodev> Slice it first, then take the slice's ptr
<ifreund> why slice twice there
<ifreund> but yeah that's probably the way do to id
<ifreund> that sentence got away from me at the end :D
<ifreund> looks like what I really wanted was arr[i..(i + 5)]
<ifreund> which gives a *[5]u8
<pixelherodev> :)
marnix has joined #zig
<ifreund> andrewrk: RE stage2 type handling for DWARF/wasm, that sounds very reasonable to me, and is in line with what I've implemented so far
marnix has quit [Ping timeout: 256 seconds]
<ifreund> what's important imo is that each entry in the types section is tied to exactly one Decl, otherwise the lifetime management becomes far more complicated
rzezeski has joined #zig
Ashpool has quit [Quit: Leaving]
marler8997_ has joined #zig
marler8997_ has left #zig ["Leaving"]
marler8997_ has joined #zig
Biolunar has quit [Ping timeout: 244 seconds]
<marler8997_> what does the new return address parameter to the allocator functions do?
factormystic has joined #zig
Biolunar has joined #zig
<Sahnvour> marler8997_: it's used to save 2 stack levels in the gpa when collecting allocation stacktraces
wootehfoot has quit [Ping timeout: 256 seconds]
pmwhite has quit [Remote host closed the connection]
pmwhite has joined #zig
bastienleonard has joined #zig
FireFox317 has joined #zig
marnix has joined #zig
<danyspin97> is `# define SCHED_BATCH 5` correctly handled by @cImport?
<marler8997_> Sahnvour, thanks
<leeward> danyspin97: It should be.
<danyspin97> leeward: it isn't though
<leeward> Because of the space?
<danyspin97> I think so
<danyspin97> this include is guarded by #ifdef __USE_GNU, but I have used @cDefine("__USE_GNU", {})
<danyspin97> i am using @cImport("sched.h") on Linux
<leeward> Maybe try a minimal test case, and if it's the space report a bug?
<oats> are packed unions still borked, or am I thinking of something else?
<danyspin97> leeward: how though?
<danyspin97> I am trying but no luck importing a custom file
<danyspin97> sometime I forget that zig do not compile what isn't used
<danyspin97> nope, `# define` works
cole-h has joined #zig
<leeward> Must be the __USE_GNU isn't making it in?
<oats> can one write down tuple types yet?
<oats> like `struct { u16, bool }`
<ronsor> shameless hack: const MyType = @TypeOf(.{ @as(u16, 0), false });
<oats> dirty, I love it
<oats> thanks <3
<oats> also, why don't packed unions support enum tag types?
<fengb> Need a packed enum
<fengb> Or extern enum?
<fengb> Enums, like structs, don't have well defined memory
<fengb> ronsor: the typeof hack doesn't actually work. It takes quite a bit more effort to make a real type, unfortunately
<fengb> Zig converts that into a `struct { 0, false }` — comptime known values so the struct itself is 0 sized
<oats> I was trying to do something like this
<oats> I can't apparently just do `packed union(packed enum(u16))...` either
<fengb> tagged unions can't be packed
<fengb> What are you trying to do?
<oats> was kinda hoping I could make this super packed so I can go directly from some bytes to this nice data structure :P
<oats> I'm doing the synacor VM challenge thing
<fengb> It'll take manual effort if you want to pack everything
<danyspin97> leeward: __USE_GNU shouldn't be used, I used _GNU_SOURCE and it workid
<danyspin97> worked*
<oats> wooooooooo general purpose allocator \o/
<oats> congrats everyone
<oats> but mostly andrew I think :P
<ronsor> wait we have that now?
<leeward> \o/
_whitelogger has joined #zig
<oats> ooh, the starship shell prompt thingy also shows you what zig version you're using :D
aruniiird has quit [Quit: Leaving]
<pixelherodev> Neat
craigo has quit [Ping timeout: 240 seconds]
xackus has joined #zig
<xackus> has there been any proposal to allow error set subtraction?
<xackus> I can't find one
<andrewrk> xackus, switches operate as error set subtraction if you capture the value in the else. I think there's a proposal to allow error set types to represent a group of errors in a prong. that would provide subtraction on a value
<xackus> I guess I just encountered a bug where it didn't work
<andrewrk> I'm not aware of any such bug
<xackus> andrewrk but it would still be useful for functions with explicit error sets
<andrewrk> yeah I think it's worth proposing
<xackus> would be handy with copy_file_range to remove error.SystemOutdated from error set and use fallback
<andrewrk> that really should work, we do it in a bunch of other places. can I see the code snippet?
<andrewrk> in my opinion error.SystemOutdated should not be in any of the write/copy_file_range/read error sets in the first place
<xackus> you mean implementing fallback in syscall wrapper?
<andrewrk> yes in os.zig
<andrewrk> we already have the fallback code right? all we need is the real code path to be attempted first
<xackus> yeah fallback just uses pread, pwrite
FireFox317 has quit [Remote host closed the connection]
FireFox317 has joined #zig
<xackus> but then you will attempt and get ENOSYS every time in the loop in copyRangeAll
<andrewrk> yes we have an established pattern for os.zig eliminating some error codes by doing fallback implementations
<andrewrk> 2 things on that. (1) utilize the target os version range to make some of the logic comptime instead of runtime where possible. (2) as for wasted syscall getting ENOSYS, write a TODO comment and link to https://github.com/ziglang/zig/issues/1018
<andrewrk> I can elaborate more on (1)
marnix has quit [Ping timeout: 246 seconds]
<xackus> andrewrk thanks, i will restructure the code, write some tests, and copy_file_range should be ready
marnix has joined #zig
<xackus> and make the proposal
<ifreund> ugh, how do I ensure that freeDecl() cannot fail if I want to maintain a free list and need to allocate to do so
<ifreund> I could just ensure that the free list always has enough capacity to hold all the things that could be free'd, but that seems wasteful
dingenskirchen has joined #zig
<andrewrk> ifreund, I solved it by making the freelist heuristics based only. so if it doesn't make it onto the free list, it's fine, it just means possibly less efficient allocation
<andrewrk> because there's always the fallback of adding the new thing to the end, right?
<andrewrk> we really are solving the exact same problem over and over again
<ifreund> well if it doesn't make it into the free list it's essentially leaked no?
<ifreund> It wouldn't break anything, just lead to more bloat in the binary
<andrewrk> the way I did it, a free list entry does not point to empty space. it points to objects that have extra capacity. here read this: https://github.com/ziglang/zig/blob/fd47839064775c0cc956f12a012f0893e1f3a440/src-self-hosted/link.zig#L352-L366
stripedpajamas has joined #zig
<andrewrk> point being here that the free list is denormalized data, meaning you could delete the free list and re-create it based on scanning over the text blocks if you needed to
ur5us has joined #zig
<ifreund> I see
<andrewrk> which means that failure to add items to it is not really a problem
<ifreund> Yeah that doesn't map too well to my current implementation unfortunately
<ifreund> wasm is a bit less flexible it seems, which makes things awkward
<ifreund> I guess I could also just maintain a ArrayList(bool) or equivalent
<andrewrk> are you sure? as long as you can put padding after an object, it should be possible to model it this way
<ifreund> I can't pad the types no
<andrewrk> can't you put a bunch of unused types in the list?
<andrewrk> also in case this wasn't clear: we don't absolutely need to have incremental compilation for every architecture. if you just wanted to make the wasm one simpler and write everything in a final pass at the end, that would be an improvement over status quo. however if you're interested in the challenge, that's great and I'm happy to help
<pixelherodev> We should probably have an `option` for whether we should use incremental compilation
<andrewrk> options shmoptions
<andrewrk> that option would not precisely communicate the user's intent
marnix has quit [Ping timeout: 260 seconds]
traviss has quit [Quit: Leaving]
traviss has joined #zig
<ifreund> sorry, a friend called. Yeah having a bunch of unused types is fine, but they all have to be in a single list with no padding
<andrewrk> isn't unused types padding?
<andrewrk> they take up space in the wasm file, and you can overwrite them with something else
<ifreund> not really, as you can't add new ones to the middle without shifting the indexes
<andrewrk> does an unused type take up an index?
<ifreund> so you just have a bunch of dead types, and keep track of which entries are dead so you can overwrite them and reuse the index
<ifreund> yes it does
jeko has joined #zig
FireFox317 has quit [Remote host closed the connection]
FireFox317 has joined #zig
<andrewrk> I see, so the problem is overwriting bytes both has a byte alignment problem and an index alignment problem
<ifreund> yeah, you have to search for a "dead" type of exactly the size you want or otherwise append to the list
<ifreund> I think I'll just waste some memory for the free list for now, it's hard to review without the context of the rest of the code I think
<andrewrk> if you had a way to represent dead types with different byte sizes it would help a lot. because then you could turn multiple large dead types into an alive one, followed by small dead types to take up the same number of indexes
<ifreund> that's true, there's a lot of room for optimizations like that here
<andrewrk> essentially you need the ability to waste bytes without wasting indexes. if you have that, you have solved the problem
<andrewrk> it's a fun puzzle :)
<ifreund> the way I've structured things stuff like that should be easy to implement without leaking all over the code
<andrewrk> nice
<xackus> andrewrk should i check for unknown flags in fallback code?
<ifreund> and yeah I realize that we may not *need* incremental compilation for wasm, but it's been a nice challenge
<ifreund> I've never done any work on a compiler before :D
FireFox317 has quit [Ping timeout: 246 seconds]
<xackus> sendfile fallback doesn't check flags
cole-h has quit [Quit: Goodbye]
<pixelherodev> Woot, got parameters working in the C backend
<pixelherodev> `exit(0);` translates now :)
<pixelherodev> Also made it a bit easier to debug
<ifreund> nice!
<pixelherodev> how would I find argument *names* from a Decl?
<pixelherodev> I *could* just do `arg{}` but that feels wrong
dermetfan has quit [Ping timeout: 260 seconds]
<pixelherodev> The Value.Function just has the Module.Fn, which itself just has the instructions + Decl reference
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
<ifreund> don't think the memory taken by storing argument names in a Decl directly would be worth it
<pixelherodev> Where *are* they stored, is the real question?
<ifreund> maybe have a look at astgen?
<ifreund> that's probably when they get stored, and you could look where they go
Kingsquee has joined #zig
<pixelherodev> Good call
<pixelherodev> I don't think they *do* get stored
<ifreund> that could very well be the case
<ifreund> if so, I'd just to arg1, arg2 etc. and leave proper names for a followup PR
<pixelherodev> Yeah
<ifreund> anyhow, I'm off to bed. Got super basic functions implemented, just need to implement exports then I can see if any of this stuff actually works :D
<pixelherodev> Night :)
stripedpajamas has quit [Quit: sleeping...]
<pixelherodev> Almost... https://pixelhero.dev/tests
bastienleonard has quit [Ping timeout: 244 seconds]
<pixelherodev> Works!
<pixelherodev> Hmm, that asm support seems to be a GCCism (Clang doesn't support it)
<pixelherodev> That'll require more work
<Kingsquee> is there a way of finding what version of glibc zig is using?
<pixelherodev> You can target any glibc version you want
<pixelherodev> (terms and conditions apply)
<pixelherodev> There's a limit to how far back you can go
<Kingsquee> that'd be a setter flag, which I'd also like to know
<Kingsquee> but what about a getter
<pixelherodev> ? What do you mean?
<pixelherodev> What do you want to "get"?
<pixelherodev> The default?
<Kingsquee> zig build, build.zig says use libc, I want to know what version of libc it's using
<pixelherodev> There's no specific version there, that's based on target IIRC
<pixelherodev> e.g. `native-linux` uses musl by default, not glibc
<Kingsquee> that's..odd
<pixelherodev> `native-linux-glibc` would use the default glibc, presumably
<pixelherodev> Nah, glibc doesn't support static linking
<pixelherodev> musl is the only option there
<pixelherodev> `native-linux` builds by default produce fully static binaries
<pixelherodev> Pretty sure I have the same behavior on glibc systems, but I *could* be wrong
<Kingsquee> okay, so if I'm on x86_64 linux, and I just run zig build with standardTargetOptions specified in build.zig, the target should be "x86_64-linux-musl"?
<pixelherodev> I *think* so, I could be wrong
<pixelherodev> I use musl systems 99% of the time, so I don't really remember what the behavior is on glibc systems TBH
<Kingsquee> because my project uses gl and x11, and when I actually pass `-Dtarget="x86_64-linux-musl", I get X11.h not found
<Kingsquee> I also get the same for passing x86_64-linux-gnu
<pixelherodev> How are you linking X11?
<Kingsquee> linkSystemLibrary("x11");
<pixelherodev> I don't have X11.h anywhere in /usr/include
<pixelherodev> Are you sure your code is right?
<pixelherodev> `test -z $(find /usr/include -name X11.h) && echo Not found` outputs `Not found`
<Kingsquee> when I don't pass -Dtarget it works fine
<pixelherodev> Maybe I just don't have the header installed
<Kingsquee> so I am assuming my code is right
<pixelherodev> Ah, right
<pixelherodev> linkSystemLibrary doesn't really make sense for cross-compilation IIRC
<pixelherodev> So with any explicit target, they aren't actually linked (?) Not sure
<Snektron> I think i'm gonna make a binding generator for spir-v. This should be significantly easier than vulkan as its registy is a standard json file
<Kingsquee> how would you deal with that then
<Kingsquee> afaikt it doesn't make sense that x11 and gl would be statically linked
<Kingsquee> so all it needs is the header files
<Kingsquee> (if my understanding of os shenanigans is correct)
<Kingsquee> if it finds the header in one case what's wrong with find it in another
<Kingsquee> in any case, still not seeing how to find the glibc version
<Kingsquee> pixelherodev: how do you target whatever libc version you want?
<Kingsquee> asking because I'm trying to solve some symbol errors that llvm dudes say would only come up if the libc version is ancient
qazo has joined #zig
Ashpool has joined #zig
<pixelherodev> Kingsquee: I think it's part of the target?
<pixelherodev> e.g. -gnu-VERSION ?
<pixelherodev> Best way to check is to read the source