ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
<pixelherodev> Are Zig's varargs compatible with C's?
<pixelherodev> e.g. if a C function calls a zig function and passes it variable args, and the Zig function specifies `args: ...` as the last argument, will it work, or is that one of those "why would you even try that?" things
<andrewrk> zig supports var args when calling C functions. the other way around is
<pixelherodev> Alright, thanks
<saskwach> andrewrk, I found something interesting:
<saskwach> See the comments at the bottom.
<saskwach> Maybe it's not interesting.
stratact has quit [Ping timeout: 240 seconds]
<saskwach> Anyway, is there a reason other than the opportunity cost why the standard library's barely documented?
Ichorio has quit [Ping timeout: 264 seconds]
stratact has joined #zig
<andrewrk> no it's just opportunity cost
<andrewrk> well and it's unstable and changing frequently
marijnfs_ has quit [Ping timeout: 245 seconds]
marijnfs_ has joined #zig
<daurnimator> andrewrk: EAI_ are not system constants
<daurnimator> they're libc constants
<pixelherodev> Stack traces are a godsend - was able to debug ACPICA thanks to them :D
<pixelherodev> Kind of funny that it has its own less accurate traces and they're completely useless though
marijnfs_ has quit [Ping timeout: 276 seconds]
marijnfs_ has joined #zig
<andrewrk> daurnimator, yeah thanks I moved them locally, will push in a bit
<daurnimator> andrewrk: FWIW I would mostly avoid getaddrinfo; its not a good C API.
<daurnimator> I was planning on writing our own dns module in zig.
<andrewrk> yeah did you see that I'm in progress with writing a non-libc-version?
<andrewrk> the libc one was just to see how it worked, look at strace, etc
<daurnimator> (or at least hoping that someone else would; see )
<andrewrk> we need bnoordhuis to come in here and re-implement libuv in the zig std lib with async/await
<andrewrk> I wonder how successful it would be to run a fundraiser to try to hire him for a year
<lunamn> i'm unsure what would be the process of getting the structs i made for zigdig into stdlib, so i'm looking from a distance
<andrewrk> lunamn, I didn't realize that zigdig was a candidate for std lib. I'll look more closely now
<andrewrk> I've been porting musl's implementation of getaddrinfo, but adjusting it to zig std lib
<lunamn> it can do what we'd mostly want, which is resolving addresses, I haven't looked into musl's
<andrewrk> do you use poll?
<lunamn> no, all synchronous
<andrewrk> lunamn, here's my little test program, with strace attached:
<andrewrk> this is with -lc -target x86_64-linux-musl. you can see that it sends to multiple servers then uses poll() to block until any of them respond
<andrewrk> this is a good case to try using async/await and event-based I/O
<andrewrk> in blocking mode it should probably still do that poll() strategy
<lunamn> I haven't touched anything regarding async/await yet, so I'm unsure of doing something with it yet
marijnfs_ has quit [Ping timeout: 245 seconds]
<andrewrk> yeah that's fair
<andrewrk> btw you were the one who initially did the terminal cli progress implementation stuff right?
<lunamn> yes
<andrewrk> I took some liberties when merging, I hope you like it
<lunamn> yeah I noticed, it's allright
<andrewrk> thanks for getting things started on that
marijnfs_ has joined #zig
<lunamn> np! I'm also unsure about doing poll() as a dns client, it feels like doing more work than we're supposed to, as clients
<lunamn> maybe select a random nameserver, but not send to all three at once
<andrewrk> hmm, I would at least find out why musl does it this way, it's possible they have a good reason
<lunamn> that'd be good
<daurnimator> andrewrk: FWIW I've been playing with more net io abstractions...
<daurnimator> after lunch I'll go grab out my laptop with that work on it
<lunamn> oh I see musl does both v4 and v6 queries and poll()s to find whatever comes first, clever, don't know why to all nameservers though (was confused why there were 6 sendto() calls instead of 3)
<daurnimator> lunamn: see also happy eyeballs
<andrewrk> lunamn, why not to all nameservers? makes sense to me to use whichever one is fastest
<daurnimator> also note that happy eyeballs implies that you shouldn't call dns and then connect yourself
<daurnimator> instead you should at least have a connectToHostName() function that does both v4 and v6 lookups; and then as soon as each one succeeds, attempt a connect()
<daurnimator> only after a connect() succeeds do you abort the other protocol
<daurnimator> additionally: because of TCP fast-open and early data, you can send data in the first packet! this means that you actually need a connectToHostNameAndMaybeSend(host, port, early_data)
<daurnimator> and that's without bringing TLS into the situation
<daurnimator> in practice, I prefer an api where you go: S=newConnection(.TCP); S.addConnectHost("", someport); S.send("somedata"); S.flush(); // only calling flush actually guarantees making all the syscalls
<lunamn> andrewrk: was confusing udp behavior with tcp behavior where there'd be a bit more of an overhead for every send, which probably means I should sleep
<andrewrk> daurnimator, that API looks reasonable to me
<daurnimator> andrewrk: yeah I've been playing with it
<daurnimator> andrewrk: one question that comes up is error reporting...
<daurnimator> the other is lifetime of strings you pass to send()
<daurnimator> the only practical answer I've come up with (unfortunatly) is that S.send *must* copy :(
<daurnimator> one slight improvement would be enabling something like: `const buf = try S.getSendBuffer(somesize); mem.writeIntLittle(buf[0..4], 42);`
muffindrake has quit [Ping timeout: 250 seconds]
<daurnimator> in practice I'm hoping that the copy won't matter much: at least for e.g. user-space TLS connections, you can encrypt immediately....
muffindrake has joined #zig
<andrewrk> copying is really really fast
<andrewrk> more important is avoiding annoying-but-rare possibilities of error.OutOfMemory
<daurnimator> ooooo. absurd idea..... okay so I was thinking about sending large constant strings in the current binary..... could you open() yourself and use S.splice()
<daurnimator> not that large strings embedded in the binary is a common situation
<andrewrk> why do you need to open yourself? that's the same thing as const foo = "bar"; or @embedFile
<daurnimator> andrewrk: because with the splice syscall (and eventual socket method) you don't need to read() the string and then send() it on the socket: it goes directly from file on disk to in-kernel socket buffers
<saskwach> So would it be worth while for someone to flesh out the standard library's docs, or do you think it's still too unstable?
<pixelherodev> Personally, I think it'd be worth it for large parts
<daurnimator> saskwach: go for it! some parts are more stable than others
<pixelherodev> With existing docs there, it'd be simple enough to modify them when they become outdated
<pixelherodev> It's a lot easier for me personally to update docs written by others than to write them myself
<saskwach> Well that's all I needed. I don't actually know what I'm doing, but I can at least write docs for the bits of it I use as I use them.
<andrewrk> daurnimator, ah I see.
<daurnimator> so a couple of ideas in my head: sometimes you need to do one operation after the other; e.g. sendmsg with an attached FD after some other amount of data.
<daurnimator> this implies that we can either have a queue of things/writes to do.... or alternatively, that if you have something queued already, that sendmsg with an FD would fail with `error.needsFlush` or something
<daurnimator> andrewrk: `error.needsFlush` would also be relevant to your "annoying-but-rare possibilities of error.OutOfMemory" comment before
presiden has joined #zig
presiden has left #zig [#zig]
lunamn has quit [Ping timeout: 264 seconds]
lunamn has joined #zig
chemist69 has quit [Ping timeout: 264 seconds]
chemist69 has joined #zig
<saskwach> Does `Allocator.alloc()` return an uninitialized array? I'm too much of a newbie to be sure.
<pixelherodev> You can check the source :) Give me a sec to check
<saskwach> Yeah, I'm looking at the source.
<pixelherodev> 99% sure it's uninitialized
<saskwach> I'm not sure what `[*]T` means, or what `self.reallocFn(self, ([*]u8)(undefined)[0..0], undefined, byte_count, a)` does.
<saskwach> Okers, I'll assume it is.
<pixelherodev> [*]T = pointer to unknown number of T
<pixelherodev> reallocFn calls the allocator's realloc function
<pixelherodev> Hint: for C, that's literally realloc
<saskwach> I probably wouldn't have asked if not for calloc.
<saskwach> So I guess its initialization state actually depends on the allocator.
<pixelherodev> If realloc() is called with a null pointer, it's identical to malloc
<pixelherodev> Unless it's initialized *in alignedAlloc* the answer is it's not initialized at all
<daurnimator> saskwach: as a rule, zig doesn't zero initialise
<saskwach> Alright, there's a PR with a little bit of documentation. If it looks sensible I'll do some more tomorrow.
<saskwach> (3540)
jjido has joined #zig
mahmudov has quit [Ping timeout: 252 seconds]
<pixelherodev> Hmm, apparently Zig still allows SSE in freestanding for `build-obj` with C source
<pixelherodev> `movsd%xmm0, AcpiGbl_MutexInfo+8(%eax)`
<pixelherodev> s/freestanding/i386-freestanding/
<pixelherodev> Whelp, another bug to fix! ;(
mahmudov has joined #zig
jokoon has joined #zig
_whitelogger has joined #zig
<pixelherodev> Or just cheat. Added -mno-sse to `zig cc` command lines
<pixelherodev> ACPICA tables fully working now!
<pixelherodev> I cannot believe I just spent approximately *eight hours* on that :O
<daurnimator> pixelherodev: I can't imagine much ACPI related is even vaguely simple
<pixelherodev> I know, but I still want to write a full ACPI library in Zig eventually
<pixelherodev> Given that ACPICA is ~42K lines, that day is not this year :(
<pixelherodev> Kudos to them though, there's 47K line of comments to go with that :)
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<daurnimator> Anyone had an issue before where `zig test` doesn't output anything except "All tests passed"?
<daurnimator> oh wait that's intended new behaviour
<daurnimator> We don't have a circular buffer in the standard library do we...
jjido has joined #zig
Ichorio has joined #zig
<pixelherodev> I have one you can use daurnimator
<pixelherodev> Is it really useful enough to go in the stdlib? I can open a PR to add it
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<daurnimator> pixelherodev: you may want to read
<pixelherodev> ... dammit. Thanks!
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
FireFox317 has joined #zig
FireFox317_ has joined #zig
jokoon has quit [Ping timeout: 276 seconds]
jokoon has joined #zig
<mq32> hello
* mq32 ran into weird compiler bugs again :D
<daurnimator> mq32: of course :p
<mq32> yeah, but this one is crazy
<mq32> i have a packed struct
<mq32> and i want to bit-cast it to an u32 (it *should* have 32 bits)
<mq32> but
<mq32> it didn't work. now i'm checking out why and i found this:
<mq32> if i remove bits frm the struct, it gets to "size 3", if i add bits, it gets to "size 5"
<mq32> but never to size 4
FireFox317_ has quit [Ping timeout: 276 seconds]
FireFox317 has quit [Ping timeout: 276 seconds]
<mq32> yeah
<mq32> i found this
<mq32> it works when you have a field count divisible by 8
<mikdusan> does linux mmap support any way to "clone" an existing mapping just for purposes of changing PROT_ flags? ie: one map is read-only, the other is read+write
<daurnimator> mikdusan: huh?
<mikdusan> let's say i have map0 which is PROT_READ. i'd like to have map1 which is the same memory, but PROT_READ|PROT_WRITE
<daurnimator> mikdusan: I think you can open /proc/self/mem and map it again...
<mikdusan> oh that is sneaky sneaky
<mq32> daurnimator, thanks for the issue reference. seems like this is exactly my problem
<mq32> luckily the workaround is trivial
<mq32> today is not my day :D
<mq32> "oh, you fixed that bug? here are another three!"
<mikdusan> no good deed... :)
<mq32> seems to
<mq32> @bitCast fails, @ptrCast works
riba has joined #zig
jokoon has quit [Quit: jokoon]
<mq32> hmm
<mq32> can i somehow set the target CPU model?
<mq32> it looks like i386 and u64 will fail on freestanding
<nrdmn> mq32: possibly related:
<nrdmn> what are you doing on freestanding?
<mq32> trying to create some executable on a i386
<mq32> so, let's call this thing "kernel"
<mq32> but it will be just an OS-less application
casaca has quit [Ping timeout: 240 seconds]
casaca has joined #zig
<mq32> huh
<mq32> zig isn't as lazy as it seems *grin*
<mq32> if (!std.mem.eql(u8,, "flags")) { if (@field(flags, { … } }
<mq32> ah
<mq32> if(comptime !...) solves it
riba has quit [Ping timeout: 250 seconds]
Ichorio_ has joined #zig
Ichorio has quit [Ping timeout: 264 seconds]
riba has joined #zig
riba has quit [Ping timeout: 240 seconds]
<saskwach> Is it just me, or is the build broken on master?
<lunamn> depends, broken with what?
<saskwach> I'm trying to build on amd64 Linux.
jjido has joined #zig
<lunamn> i'm on amd64 as well, no problems building here though
<saskwach> We'll see what happens when this one finishes. I'm running it on a system that's built successfully before.
<saskwach> The one that's failing hasn't.
marijnfs_ has quit [Quit: WeeChat 2.6]
porky11 has joined #zig
<saskwach> yep, that worked. My other system's throwing an error with the same version of code when it tries to link zig0.
Akuli has joined #zig
erandria has joined #zig
<erandria> hi all, I'm new to zig and liking the design
<erandria> I ran into a segfault when building another lib, Vexu/routez, and thought of debugging this to maybe help
<erandria> but I'm not sure how really
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<erandria> (I could provide a repo to reproduce but I wanted to help rather than "here, fix my problem")
<andrewrk> mikdusan, you can if you use a temp file descriptor to back the mapped memory
<andrewrk> mikdusan, here's an example that creates 2 mappings that point to the same memory:
<andrewrk> and then I believe using /dev/shm/ as the directory for the temp file makes it avoid the file system
<lunamn> andrewrk: status report from yesterday, i got poll() working to a degree
<andrewrk> saskwach, you can check if the CI thinks the build is broken, look at the X and check marks here:
<andrewrk> the aarch64 and windows builds timed out. this could be a CI issue or a real problem
<andrewrk> amd64 linux is fine though
<scientes> for linux you can also use create_memfd
jjido has joined #zig
<andrewrk> ahh there we go
<saskwach> Yeah, it seems to build fine on this machine. The error I'm getting is weird; maybe I'll try reinstalling some things and rebuilding it.
<erandria> is this working...?
<andrewrk> hi erandria
<andrewrk> welcome
<andrewrk> oops meant to link to the Editing Source Code section on that last link
<erandria> thank you
lunamn has quit [Ping timeout: 240 seconds]
<saskwach> I'm trying to make a very simple library, but getting "unable to find 'foo'" on my `@import("foo");` line. The file is called foo and it's in the same directory as the file trying to import it. What am I missing?
<andrewrk> saskwach, probably the file extension
lunamn has joined #zig
<saskwach> Should it not be .zig?
<andrewrk> .zig is good. but your example does not have .zig in the @import path
<saskwach> Oh, it's supposed to be "@import("foo.zig")"?
<saskwach> Huh, so it is.
<saskwach> Is that the zig equivalent of `#import "file"`? Including the .zig in the module's name?
<andrewrk> it's very different from C's #import
<saskwach> er, include
<andrewrk> oops yes we both meant #include
<andrewrk> in zig every file is a struct
<saskwach> So why @import("std") but @import("mything.zig")?
<andrewrk> @import obtains a reference to that struct type
<andrewrk> every package has a table of mapped packages with arbitrary names mapped to files
<andrewrk> all packages have "std" mapped to the std lib
<saskwach> So the standard library's special cased in the implementation?
<saskwach> Also, is there a place I can read about this package concept? I saw the bit about @import returning structs in the documentation, but I'm having trouble finding more details. I'm guessing this will get improved when the package system stuff is done.
<andrewrk> I'm not sure what you're asking, but there are a small set of ways the std lib is special cased. 1. it's shipped with the compiler. 2. the types in std.builtin are used for some of the language features
<andrewrk> package stuff is one of the big topics of this release cycle
<saskwach> That will be good stuff.
<saskwach> I guess I'll go look at some existing libraries and how they're used.
erandria has quit [Remote host closed the connection]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
waleee-cl has joined #zig
jjido has joined #zig
<tgschultz> 3. "std" package (and "builtin") are automatically available without --pkg-begin/end
<tgschultz> ..which I guess was already covered, so nevermind
erandria has joined #zig
<erandria> andrewrk: I managed to reproduce the build bug I mentioned
<erandria> I tried using the `--verbose-ir` option, but the segfault happens before the behaviour of that option "runs"
<erandria> huh, disregard, it actually works
<mikdusan> heads-up with `--verbose-ir`, it is not fully-vetted, there are cases (especially with large reproductions) that simply using --verbose-ir cases a segfault. it is highly recommended to get a minimal reduction, and use a few tricks to reduce what the compiler is doing (like define your own panic fn)
<erandria> oh, I see
<mikdusan> here is an issue with examples of defining your own panic() and using `export fn ...` to avoid even using main. note this means you need to "zig build-obj" or similar:
<mikdusan> (see the zig source reductions therein)
<erandria> but if I build with `build-obj` it doesn't cause a segfault
<erandria> huh... this is a runtime segfault... I don't know how I missed that
<mikdusan> oh that's happened to me before too. assumption mother of all evil
<erandria> I was running `zig build` before, which runs the tests
<erandria> mikdusan: haha, agree
erandria has quit [Remote host closed the connection]
erandria has joined #zig
kllr_sbstn has joined #zig
erandria has quit [Remote host closed the connection]
<andrewrk> lunamn, hmmm if we put a fs watch on /etc/resolv.conf, then we could detect when it changes while waiting for DNS results to come back. This would allow zig programs to seamlessly work when someone loses internet and reconnects to a different network mid-request
<lunamn> andrewrk: that'd be cool
<lunamn> I was experimenting with poll() earlier but hit a compiler segfault so I went to other things
<andrewrk> damn, that's annoying
<andrewrk> I'll take a quick peek
<andrewrk> lunamn, you can do `zig build` instead of `zig build install --prefix ~/.local/ `
<andrewrk> it defaults to zig-cache as the install folder
<lunamn> sure, it became kind of muscle memory after being confused where the binaries were lol
<lunamn> still segfaults, tho
<andrewrk> lunamn, here's how you can add an assert to show how to work around the crash at least:
<andrewrk> now it outputs: when analyzing /home/andy/Downloads/zigdig/src/packet.zig:407:48: assertion failed. This is a bug in the Zig compiler.
<andrewrk> let me look into this though, it appears to be a bug with codegen of async functions
<lunamn> I was gonna say that was my wild guess
<lunamn> after commenting/uncommenting lines I got it related to io.Deserializer and being in an async fn
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wootehfoot has joined #zig
porky11 has quit [Ping timeout: 250 seconds]
<andrewrk> lunamn, this is a missing compile error for invalid async fn recursion
<lunamn> oh
<andrewrk> somehow deserializeName is async
<lunamn> yeah the deserializer is recursive, that'd make sense
<andrewrk> but it probably shouldn't be
<andrewrk> unless it calls read
<andrewrk> then it makes sense
<lunamn> it shouldn't call read, I read it before deserialization, check packet.recvDNSPacket
<andrewrk> I haven't enabled this compile error yet because it's going to be coupled with which means even non-async functions will get this error
<lunamn> so I should heap allocate deserializeName?
<andrewrk> let me work on the compile errors for this case, hopefully I can make it clear what should be done that way
<andrewrk> but I gotta go soon
<lunamn> it's allright, it isn't all that urgent
<andrewrk> lunamn, here's what I've got with my unpushed changes:
<andrewrk> yeah so your choices are to heap allocate to break the cycle, or to separate deserialization from reading
<andrewrk> I'll make a separate master branch commit with a test case adding this compile error
<andrewrk> here's an example of heap allocating an async function frame: You can also use `@typeOf(genericFn(a, b, c))`
<andrewrk> note that this chore is planned to be required for non-async recursive functions as well.
<lunamn> ooh wait in_stream even though it uses a buffer (via SliceInStream) becomes async, that makes sense
<lunamn> I'll make deserializeName heap-allocated and see what happens, thanks
<andrewrk> yeah I'll try to get this compile error into master branch soon, but I'm gonna go have dinner with friends, later!
<lunamn> cya!
<andrewrk> I pushed to branch
Akuli has quit [Quit: Leaving]
Ichorio_ has quit [Ping timeout: 264 seconds]
gustav_o has joined #zig
<lunamn> andrewrk: I tried to heap-allocate the call but yet I still get the same compiler error, maybe it's because i'm doing 'try await' to get the value from the frame?
Ichorio has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
Ichorio has quit [Ping timeout: 264 seconds]
gustav_o has quit [Remote host closed the connection]
<mq32> pixelherodev: enough for today :)
<mq32> initialisizing VGA with 16 colors/640x480 pixels works!
kllr_sbstn has quit [Remote host closed the connection]
Ichorio has joined #zig
Ichorio has quit [Ping timeout: 250 seconds]
<daurnimator> andrewrk:yes watching /etc/resolv.conf is common enough. e.g. dnsmasq does it
<daurnimator> <-- work on buffering for network operations
<pixelherodev> mq32, neat!