<andrewrk>
zig cross compiles the behavior tests, producing an aarch64 binary that is dynamically linked against glibc. I run it with qemu with -L path of a glibc for aarch64 that I happened to have sitting around
<fraktor>
So I know that there isn't currently a general-purpose allocator for Zig, and that one is in the works. In the meantime, what should I use? I know that ArenaAllocator can be good for parts of programs, but even that has to use another allocator under the hood.
<daurnimator>
I wonder how long that will make PR tests take...
<andrewrk>
should be shorter since I disabled release builds for non-native
<daurnimator>
andrewrk: why do we have all the e.g. `isNetBSD()` functions instead of just having people write: `std.getOs() == .netbsd`
<andrewrk>
fair point. it started with isDarwin
<daurnimator>
I feel like we're encouraging people to end up writing: `if (isNetBSD()) {} else if (isLinux()) {} else if (isUefi()) { ..... }` instead of the switch like they should
<andrewrk>
man. that was the least interesting part of the patch
<daurnimator>
I'm reading chunk-by-chunk :P
<andrewrk>
the linux ci build is about to start the qemu part
<andrewrk>
there it goes - aarch64. so beautiful
<andrewrk>
oh no
<andrewrk>
qemu: unsupported syscall: 278
<andrewrk>
that's SYS_getrandom
<andrewrk>
huh. so getrandom isn't available on linux ci qemu for some reason
<andrewrk>
need a newer qemu
kristoff_it has joined #zig
<daurnimator>
off_t appearing is interesting.
<fraktor>
Hey, so I know this isn't the LLVM channel, but I'm running into an issue where trying to compile LLVM 9 is exhausting all 16GB of ram that I have. Any ideas on how I can compile it / past versions of Zig I could use so I could use LLVM 8, which is available in my package manager?
<andrewrk>
fraktor, yes, do a release build of llvm and clang
<andrewrk>
and don't use -j
<fraktor>
There's my mistake; how did you know?
<andrewrk>
because I have crashed my computer countless times compiling llvm
<daurnimator>
andrewrk: SYS_getrandom was added in linux 3.17. doens't zig support linux 3.16?
<fraktor>
Also, how do I do a release build?
<fraktor>
(As opposed to debug I assume)
<andrewrk>
daurnimator, yes, we handle ENOSYS correctly
<daurnimator>
andrewrk: the issue is that qemu doesn't return ENOSYS?
<fraktor>
Thanks andrewrk
<andrewrk>
daurnimator, yeah according to the CI log it returned NoDevice
<andrewrk>
daurnimator, oh wait, look at the traceback - it fell back to /dev/urandom and got ENODEV for opening that
<daurnimator>
andrewrk: heh. sounds like you need the infamous fallback after that.
<daurnimator>
(conceptually. we haven't implemented it)
<andrewrk>
oh, it's this thing that euantor added: if (!S_ISCHR(st.mode)) { return error.NoDevice; }
<andrewrk>
if I just delete that check it will work. I'm not fully convinced this check makes sense
<daurnimator>
andrewrk: it's to prevent an exploit where someone replaces /dev/urandom with a file with known contents
<andrewrk>
so they have root? that's not an interesting attack vector
<daurnimator>
andrewrk: at one point it was a common attack for rootkits.
<andrewrk>
yeah I'm not interested in combating a root kit. if they have a root kit they win
<daurnimator>
andrewrk: what does qemu present instead of a character device?
<andrewrk>
this isn't related to qemu. qemu returned ENOSYS for getrandom, and so we fell back to reading /dev/urandom
<andrewrk>
previously we weren't falling back to reading /dev/urandom on linux ci because getrandom was working
<daurnimator>
andrewrk: but why did `if (!S_ISCHR(st.mode))` fail?
<andrewrk>
that's a good question. I don't know
<wilsonk>
fraktor: another hint...if you build clang-9 with and older GCC (my system had 5.4 as the default!) then rebuild clang with itself before working on zig. This move saves me about %20 on zig compiler build times (which adds up to a lot when working on the compiler)
<andrewrk>
wilsonk, oh nice, maybe I should do that
<andrewrk>
do you use lld too?
<wilsonk>
yes to lld!
<fraktor>
wilsonk: Thank you! I'm using clang (I believe, if cmake took advantage of it).
<wilsonk>
must use...saves about 8% on rebuilding llvm/clang over ld (that is on my big server with 64 cores and 128GB ram so YMMV)
<fraktor>
Although I'm more of a user than a kernel developer.
<fraktor>
s/kernel/compiler/
<wilsonk>
fraktor: ah, ok...but even if you build many other programs on your system then it still helps a lot in the end
<andrewrk>
I have no idea what's going on with this -faddrsig thing on freebsd
<andrewrk>
what specifically are you pointing at here?
<mikdusan>
freebsd 12.0 ddefault clang is old. version 6.0.1
<mikdusan>
pass --verbose to zig cc command line that is failing and replace "/usr/bin/cc -cc1...." command line that contains -faddrsig with a ports installed "clang80 -cc1..."
<stratact>
that's why I use freebsd-stable
<mikdusan>
this is 12.0 stable.
<stratact>
no, stable != release
<mikdusan>
ugh sorry
<mikdusan>
please help me get up to speed on freebsd terminology
<mikdusan>
i have 12.0 release installed. nothing special and all defaults. then did some pkg installs for llvm80, git, cmake, etc.
<stratact>
RELEASE is the official release, it doesn't update it's a frozen snapshot of a revision, CURRENT is the latest changes from the head of svn which can be breaking or not, STABLE only gets the necessary non-breaking changes and bug fixes from CURRENT
<mikdusan>
so how does one opt-in for "stable"
<mikdusan>
is it a re-install?
<stratact>
You can reinstall as that could be faster, but from a release install, you wanted to clone the stable directory from the svn repository and rebuild the OS like I did yesterday
<stratact>
Usually you'd want to clone the stable repository in /usr/src
<andrewrk>
this must be something inside clang deciding to execute /usr/bin/cc and we need to stop it
<andrewrk>
good night
<stratact>
night o/
<stratact>
I need to figure out if I need to import unlinkat from FreeBSD or not, std/os/linux.zig already has it though but for FreeBSD it seems that it's part of the libc than a syscall function from the man page
fraktor has quit [Ping timeout: 246 seconds]
_whitelogger has joined #zig
<daurnimator>
stratact: on bsds everything is part of libc and not a syscall
<daurnimator>
stratact: simplest option is probably to just add unlinkat to std/c.zig
<euantor>
andrewrk: just saw your message regarding the S_ISCHR issue. I have no idea what QEMU is doing if that check fails, but that’s the recommended way to use /dev/urandom according to the libsodium authors (who generally tend to know what they’re talking about)
<euantor>
I’ll spin up a Linux ARM build on sr.ht today and check what the file is being presented as out of interest
<daurnimator>
euantor: try under qemu locally to see what you get...
<euantor>
daurnimator: I’m on Mac, I’m not sure what the QEMU setup process is there and how painful it would be
<daurnimator>
ah
<daurnimator>
would be best to test qemu on a x86_64 host
<daurnimator>
*linux x86_64
<euantor>
Unfortunately I don’t have one of those lying around at the minute
<stratact>
Ah fantastic, that makes life easier.
vycb2 has joined #zig
vycb has joined #zig
vycb has quit [Quit: ERC (IRC client for Emacs 26.3)]
vycb2 has left #zig [#zig]
<stratact>
And now that I added bindings for SetFileInformationByHandle from Windows, I have zero clue how I'm going to implement the os-agnostic version of unlinkat in std/os.zig using that function when Windows is the target.
vycb2 has joined #zig
vycb2 is now known as vycb
<daurnimator>
stratact: probably similarly to how rename in std/os.zig works
<stratact>
daurnimator: question, can the flags parameter for unlinkat be used for the FILE_INFO_BY_HANDLE_CLASS parameter from SetFileInformationByHandle? Although Window documentation says its an enum but Zig defines it as a u32 which is in the same ballpark as the `flags` parameter.
<stratact>
oh wait, I don't want that...
<stratact>
I want to get the FileDispositionInfo variant of that enumb
<stratact>
*enum
<stratact>
Okay, it's number `4`... better make a comment on that
rohlem has quit [Remote host closed the connection]
<_Vi>
"Zero Bit Types" "* A union with only 1 field which is a zero bit type." What about raw (non-tagged) union with two zero-bit fields?
vycb has joined #zig
kristoff_it has joined #zig
<_Vi>
Are `comptime`things guaranteed to execute the same regardless of host and target platform?
<_Vi>
Or there can be issues e.g. when cross-compiling from little to big endian?
kristoff_it has quit [Ping timeout: 245 seconds]
<_Vi>
"Case Study: printf in Zig" This documentation section speaks about `printf`, but shows `warn` in some examples without explaining anything.
<_Vi>
As if `warn` was called `printf` in the past and only automatically checked parts got updated during the rename.
rohlem has joined #zig
<rohlem>
_Vi, regarding unions, packed unions are documented to "use exactly the bit width of [their largest member]" when used as a field within a packed struct. This would mean if their largest member has 0 bits, the packed union has 0 bits.
<rohlem>
I believe the same holds true when used on their own, and the documentation is just a little disorganized in that regard, though that is not explicitly stated.
<_Vi>
rohlem, OK. The list is just not closed.
<rohlem>
extern unions are guaranteed to be (C-)ABI-compatible. The C behaviour is similar, but the concept of "0 bit types" in general doesn't quite exist in C iirc, so it's probably an outright error to have a 0-bit member (=> non-ABI-compatible member) in an extern union. So that scenario effectively doesn't apply.
<_Vi>
`C` does get unit and bottom types right, so no surprise such types do not work well with C-compatible ABI mode.
<rohlem>
_Vi, from what I remember `comptime` fills in the target architecture's details on target-dependent matters like endianness, see section "Compile Variables" in the documentation.
<rohlem>
So for any target, your comptime code is guaranteed to execute in those regards as your runtime code would.
<rohlem>
Also from what I remember comptime execution tries to be deterministic in that all undefined behaviour leads to a direct error (as checked undefined behaviour in a safe build mode should during runtime), so in that sense they're equivalent too.
<rohlem>
And, of course, defined behaviour should be equivalent as well. So generally speaking if something works at comptime but not at runtime or vice versa, that's a bug. Although there are a couple of open bugs regarding comptime open already, so don't be surprised that not everything imaginable works yet.
<_Vi>
OK.
<rohlem>
_Vi regarding `printf`, that is the (in)famous name of the C function for formatting output according to a format string ( https://en.cppreference.com/w/c/io/fprintf ). I believe a lot of other languages adopted the name, and even though Zig doesn't, it's still the most widely known name. That's why the section is called that way, I think.
<_Vi>
rohlem, I mean the lack of bridge between `debug.warn` and `printf`. The example does well for showing off `comptime` features, but (if I am correct) it is the first time output text formatting is mentioned in the documentation.
<rohlem>
As it's meant to be a case study, "how would you implement a printf-like function in Zig", it's meant to show the power of comptime, not more.
<rohlem>
I agree that it's not the best introduction for "how to format text in Zig".
<_Vi>
For example, the suggested filename is called `printf.zig`, yet there is no `printf` inside, just `debug.warn`.
<rohlem>
Which is, as a topic, more of a standard library than a language feature. That is probably planned to be better covered as part of the (auto-html-ified) standard library documentation, see issues # 965 and #21 .
<_Vi>
Maybe that example should just avoid `debug.warn` at all and manually specify `OutStream` for the defined `printf`?
<rohlem>
I think the scope is deliberately limited to just that one function to showcase an inline while state-machine going through a comptime character array. I agree it would be easier understandable with more context about OutStream; I assume that was probably deemed too long.
<rohlem>
Oh wait, I think I see what you mean: only the second code block defines the printf function, and the initial code block doesn't refer to it directly. The semantic connection is only made in text.
<_Vi>
rohlem, Yes. And the lack of that bridge is not even mentioned in the text. As if it were obvious how `warn` becomes `printf`.
<_Vi>
(I'm trying to reconstruct the example without `warn`, but don't know where that `OutStream` is actually defined)
<rohlem>
"Let's crack open the implementation _of this_" - it indeed implies that `printf = @import("std").debug.warn`.
<_Vi>
And it has both different name and different signature.
<_Vi>
Shall a Github issue be opening about this documentation section?
<_Vi>
*opening
<_Vi>
*opened
<rohlem>
The type is defined here: https://github.com/ziglang/zig/blob/master/std/io.zig#L62 , if you have downloaded Zig master branch your local copy should be have it in lib/zig/std/io.zig around line 62 ... at least for `write`. `flush` seems to come from `BufferedOutStream` and `printValue` is missing, seems to be a simple wrapper around `(arg) => try
<rohlem>
self.print("{}", arg)`.
<rohlem>
To be fair, the docs do say it is a "proof of concept", but I agree that a compilable example would have its benefits.
<_Vi>
rohlem, `printValue` is part of the documentation example, in the next snippet.
<rohlem>
ah, right
<_Vi>
rohlem, Non-compilable snippet in documentation => bit rot when language changes and automatic tests don't catch that doc is not relevant anymore.
<rohlem>
True. 99.9% are already automatically tested, but those couple of code blocks aren't.
<_Vi>
Maybe it would be simpler with `sprintf` analogue? No output stream, just a memory buffer.
<rohlem>
The output stream is an abstraction though, and allows a memory buffer implementation. I'm not sure a memory/slice-only interface would be cleaner.
<_Vi>
Abstractions in general are also not discussed much when reaching this place in the documentation.
<rohlem>
Well, it's not meant as an introduction to programming in general.
<_Vi>
I mean how abstraction is done in Zig. Interfaces/traits/classes/whatever.
porky11 has joined #zig
<rohlem>
_Vi, I think the main reason that is not part of the documentation is that it hasn't been decided yet. See issues # 1829 and # 130 .
<rohlem>
(via `@fieldParentPtr`, there's open issues for safety and ergonomics around that if you search for it)
_whitelogger has joined #zig
qazo is now known as Guest95353
vycb has quit [Ping timeout: 260 seconds]
<_Vi>
How does Zig's async compare to: 1. Rust's async, 2. JavaScript's async?
Ichorio has quit [Ping timeout: 245 seconds]
<rohlem>
_Vi, I know neither of them, so I'm not the right person to make a direct comparison, but if you have a question about Zig's semantics, I think I understand them well enough to answer.
<rohlem>
The basic idea is that, for every suspending function, imagine its stack were a struct, with every stack variable becoming a member of that struct. Then first calling the function with `async` constructs that struct (on the caller's stack) and runs until the first suspend point. Every subsequent resume passes that struct as stack for the function
<rohlem>
to run on.
<rohlem>
Scheduling them to run on separate threads etc. would all be done in userspace. If you need an async function call to outlive (be resumed/awaited after the initial caller has already returned), you need to explicitly allocate (and eventually deallocate) its frame (available as anonymous type via `@Frame(afunction)`).
<rohlem>
The standard library will eventually provide a default event loop, `std.event.loop` I believe, and for use cases like async IO, I believe it will subscribe the async handler you submit into that queue, so that it is run when the OS signals completion. But I'm not actually familiar with any of the OS-level details regarding that.
<rohlem>
(s/outlive/outlive its caller)
<andrewrk>
euantor, I won't merge until we figure out what's going on
<euantor>
No problem, I'm trying to have a look into it and see if I can work it out
<andrewrk>
but I believe the issue could be reproduced by simply open("/dev/urandom") followed by fstat, IS_CHR
<andrewrk>
on the linux ci, not freebsd ci
<euantor>
You can even just do `file /dev/urandom` and if it doesn't return `character special` then there's a problem
<andrewrk>
one thing that would explain this is if the stat structure is not exactly correct on aarch64
<euantor>
yeah
<andrewrk>
mode and nlink were swapped. I think that might have been it
<andrewrk>
solving problems in the morning is easy
TheLemonMan has joined #zig
<companion_cube>
hey, just realized that a syntax for anon struct initialization is also the perfect solution to named parameters, innit?
<TheLemonMan>
andrewrk, at a quick glance it seems that some other fields have been swapped (and there's a missing padding field)
<andrewrk>
I got this with: zig translate-c foo.c -lc -target aarch64v8-linux-musl
<andrewrk>
where foo.c is #include <sys/stat.h>
<euantor>
nice one
<TheLemonMan>
nice, musl stat is my reference
<fengb>
companion_cube: that means named parameters don’t need to exist; we can just use anon structs 🙃
<andrewrk>
companion_cube, yes
<companion_cube>
fengb: yeah
<andrewrk>
and default parameters
<companion_cube>
I meant, a solution to the use case of named parameters
FireFox317 has joined #zig
<Sahnvour>
andrewrk: I'm interested in adding support for vcpkg libs in build.zig, iiuc this boils down to finding vcpkg's root, and adding include/lib/path dirs. Where do you advise to plug this ? Into `Builder` directly ?
<andrewrk>
Sahnvour, yes, I think either linkSystemLibrary or similar function should do this
<andrewrk>
and then eventually we will move some of this logic into stage1 via the userland thing
<Sahnvour>
assuming we have something like `Builder.useVcpkg()`, do you think it should be available to any LibExeObjtStep by default, or explicitely enabled ?
<andrewrk>
I was thinking that either linkSystemLibrary will automatically check vc pkg first, if it is available, or there would be a function LibExeObjStep.linkVcPkg(name)
<andrewrk>
oh I think I understand your question now - do you globally opt in to vc pkg via the Builder API?
<andrewrk>
my first instinct is, if it works well, I would have it on by default, with the ability to disable it via the Builder API
<Sahnvour>
yes
<andrewrk>
similarly I think that linkSystemLibrary could be augmented on a linux distribution, to suggest to install a particular package
<Sahnvour>
if it's on by default, why not do the same for conan, etc. => may be better to leave the choice to the build script
<andrewrk>
I do think there can be a choice - but by default, if it is unambiguous, I say use it
<Sahnvour>
I have little experience on this topic, just used vcpkg to get a few C packages easily
<andrewrk>
why not indeed do the same for conan, etc?
<andrewrk>
linkSystemLibrary is already into the territory where we have unpredictability of different people's systems at play. at this point the goal is "just work"
<andrewrk>
when someone wants more tight control over their dependencies they'll use the package manager, not a system dependency
<andrewrk>
oh wow mikdusan you solved the cc thing
<_Vi>
rohlem, [about sync] Transferring local variables to a struct feels like a Rust approach. The rest I'll probably understand when time comes.
<_Vi>
rohlem, What does `resume;` (without any code inside that block) does? Is it supposed to be used in actual code?
<rohlem>
_Vi, note that nothing is "transferred", I used the "struct" for exposition only. The async function is always called with the same memory buffer as ("local/private") stack.
<_Vi>
rohlem, How things just before `suspend{}` block are different from things that are inside `suspend{}` block?
<rohlem>
So from the first execution until the `async foo()` returns it's already using the same stack as in subsequent resumes.
<Tetralux>
It suspends, then runs the block.
<Tetralux>
Func hasnt suspended before suspend keywords is reached
<Tetralux>
This means the block can resume itself.
<_Vi>
How true is this clause: "every reasonable async function should call `@frame in all its suspend{} blocks and store it somewhere, otherwise the caller can't resume them"?
<andrewrk>
it has to do with race conditions. inside the suspend block it is safe to resume (possibly even from another thread)
<rohlem>
Tetralux, the suspension only takes place once the end of the suspend block is reached.
<Tetralux>
rohlem: If that was the case, you could not resume from within the function.
<Tetralux>
And that's the only use of it I've seen so far.
<Tetralux>
So it must work.
<rohlem>
Tetralux, my understanding was that that is a semantic "edge case" (sort of), note the documentation explicitly states it _doesn't_ suspend in that instance.
<_Vi>
Is self-resuming (`resume @frame();`) just a curiosity fact or a technique that is supposed to be used in actual code?
<rohlem>
_Vi, `@frame` is used to access the current frame's pointer. If it's the async function's responsibility to subscribe itself to a wakeup call, it will use that within the suspend block.
<andrewrk>
I'll ask them to merge it into the 9.0.1 branch
<Tetralux>
I think we need to do away with contrived examples, and actually give real examples of usage.
<Tetralux>
Because none of this makes much sense otherwise.
<rohlem>
_Vi, Depending on how your registration / wakeup works, maybe it's safe to assume you only need to register once to be resumed several times in succession; in that case maybe only the first `suspend` block needs to access the pointer. Of course then your subsequent wakeups need to be synchronized in a sensible fashion.
<rohlem>
Tetralux, In my understanding "actually suspending" means returning to the `async func()` caller. So you can't suspend, then cancel within the suspend-block; that would give you two concurrent threads of execution.
<Tetralux>
You can resume in the suspend block, and you can't resume before suspended, no?
<rohlem>
Entering the suspend block signals "I am ready to be resumed, either internally (by `resume @frame`) or externally". Reaching the end of the suspend block (a non-block suspend statement) actually triggers the suspension i.e. return to `async func() / resume handle` caller.
<_Vi>
Is there an example of two async functions running in parallel? E.g. one prints `"A\n"` in a loop, the other prints "B\n" in a loop and async magic makes the whole program print "A\nB\nA\nB\n..."?
<TheLemonMan>
andrewrk, yeah
<rohlem>
_Vi, that's not quite the use case of `async`. "Asynchronous" in this context doesn't mean asynchronous execution, but "decoupled call and return (with N resumes and N+1 suspends in between)".
<_Vi>
What happens to content of `suspend{}` block after `resume @frame();` call? E.g. in `suspend { resume @frame(); warn!("Hello from nowhere\n"); }`?
<_Vi>
async/await/epoll/... and coroutines/generators are usually related.
<rohlem>
_Vi, If you want concurrent execution just start two Zigs and give one the A-, the other the B-loop-function.
<rohlem>
s/Zigs/threads
<_Vi>
rohlem, That's not coroutines, that's OS-level parallelism.
<companion_cube>
please don't name threads "zigs" :D
<companion_cube>
std.concurrent.zig
<rohlem>
_Vi, exactly. `async` is not about parallelism, it's purely about decoupling the start and using the result of function call.
<rohlem>
Using that can be a useful building block in parallelism, but it doesn't start several new threads of execution on its own.
<andrewrk>
there are a few lingering issues with missed spills, but I believe there is only 1 issue left before we can really start to take advantage of async/await. And it's this thing I'm observing with segfaults on the stack that I haven't quite figured out yet
<_Vi>
If functions can pack their belongings (local stack vars) to a bag and store it somewhere, then it is invitation for coroutines.
<TheLemonMan>
andrewrk, what's the matter with the stack size & the GNU_STACK section?
<andrewrk>
(planning on updating this section soon)
<andrewrk>
TheLemonMan, ah yes I would love to pick your brain on that. Let me quickly put together an example for you
<_Vi>
Shall there be Rust's `dbg!(x)` thing in Zig; for printf debugging? It should print filename, line, "x" name and value to stderr, then return "x", allowing debugging without introducing separate labeled block with `break :blk x;`.
<_Vi>
It may be restricted to `--sloppy` mode only, but should not require any imports and so on to be useful.
<rohlem>
_Vi, I think you can already print a stack trace using std.debug.something
<_Vi>
Even with easier blocks, `{warn("myfile.c:123 v*2+3={}", v*2+3); v*2+3}` is still more cumbersome than `dbg(v*2+3)`.
<andrewrk>
TheLemonMan, the main deal is that we want the ability to specify the stack size when we link, because zig does a lot of work to keep track of stack sizes
<_Vi>
OK, with this identity function + stack querying it is almost there. The only missing piece is printing the citation from source code (`v*2+3` in my example).
<andrewrk>
TheLemonMan, hmm I actually can't reproduce the issue I was having before
<andrewrk>
I wonder if it was a different bug that got solved in the last 2 weeks
<_Vi>
Probably it should be just Zig compiler built-in to work really well in all cases.
<andrewrk>
currently have to use the gethostname branch of zig (I'll get that merged soon)
<TheLemonMan>
hah, that's cool
<andrewrk>
specifically the example/nox.zig
<andrewrk>
if you build that with `zig build nox` and then run `zig-cache/bin/nox` you can see it print OK, which was basically a pure zig x11 connecting to the default display
<andrewrk>
look at the strace of that
<andrewrk>
and then change 1 line: pub const io_mode = .evented; to pub const io_mode = .blocking;
<andrewrk>
and build, run, & look at strace again
<TheLemonMan>
oh god Xproto, I'm getting second hand PSTD heh
<andrewrk>
haha
<andrewrk>
but anyway an issue we will run into eventually is that we *know* we need more than 8 MiB stack
<rohlem>
_Vi, with # 2029 you could comptime slice the line `@getSourceInfo().line`out of `@embedFile(@getSourceInfo().file)` and output that
<andrewrk>
so we would have to set that up with GNU_STACK before main(). unfortunately I don't have a plan for if you need a lot of stack size in a library to be used by non-zig other than to document that requirement
<andrewrk>
oh right, also if you link libc, libc is in control of startup code before main() and no libcs will give more stack
<_Vi>
rohlem, How to make a userland-implemented function available for all code without any imports?
<andrewrk>
we could insert *additional* code before main in the libc case, but it's still a bit unfortunate
<andrewrk>
this might have to be an area where we fight against the status quo a bit... it's reasonable to want more stack space if you've done static analysis
<fengb>
_Vi: nothing is available without imports, not even stdlib
<TheLemonMan>
hmm, have you checked out LLVM's segmented stack?
<rohlem>
_Vi, would a single line `const dbg = @import("mydbg.zig");` really be a deal breaker to you?
<andrewrk>
TheLemonMan, a long time ago. that's a good point, zig in the library case could take a similar strategy
<_Vi>
rohlem, Such function may be debugging/"sloppy mode"-only, so this import may look always-unused in real code.
<andrewrk>
basically every exported function will know if it needs "more than normal" amount of stack space and does its thing on entry point
<rohlem>
_Vi, I guess you could hack a preprocessing step into the build system to add your "no import"-imports to the beginning of every source file in your repository. Or maybe you hook up your editor/IDE to auto-insert the line on new file. That doesn't sound like a concern of the Zig language.
<_Vi>
rohlem, Maybe. I'll probably file a proposal issue on Github for further discussion.
<rohlem>
_Vi, Zig uses lazy evaluation. Unused code doesn't get included in compilation, hence doesn't trigger "unreachable/unused code" errors. That's how the platform-specific code is "hidden" in the std lib.
<TheLemonMan>
what's up with the heavy stack usage? is it because the frames are allocated on-stack?
<andrewrk>
TheLemonMan, imagine a lot of functions that call each other and don't even care whether they are async or not
<andrewrk>
that's a call graph
<andrewrk>
the way it will work is that the frame of a is in b, frame of b is in c, etc, until at the top you have basically a struct in the frame that is the entire call stack of the call graph below it
<TheLemonMan>
oh so the compiler takes the worst case approach and spills every local?
<andrewrk>
async function pointers would either need to heap allocate the space, or "guess" how much space is needed
<andrewrk>
(this is safety protected)
<andrewrk>
I also added a tool for figuring out where frame sizes come from
<andrewrk>
-fstack-report
<andrewrk>
it outputs json which you can view in a nice gui way with firefox
<andrewrk>
oh, TheLemonMan - I reproduced the issue I was having before. master branch of zig, try this code: https://clbin.com/AoNWi
Guest95353 has quit [Quit: 345345]
<andrewrk>
it segfaults instead of printing stack trace
<andrewrk>
it segfaults in the stack probe function
<TheLemonMan>
nice and tidy heh
<andrewrk>
TheLemonMan, when I was messing with this, I printed the top of the stack pointer at main() and it appeared that the address it was segfaulting on was still within the 8 MiB stack, so that's why I was confused
qazo has joined #zig
<andrewrk>
and when I uncommented that code in start.zig that mmaps a separate stack it did fix the segfault. but then stack traces had a test failure in release builds
<andrewrk>
so, lots of mysteries to solve here
<andrewrk>
my x window example is working though
qazo has quit [Client Quit]
Ichorio has joined #zig
<FireFox317>
Are you gonna release zig 0.5 anyways andrewrk? Instead of waiting on these async fixes
<andrewrk>
yeah
porky11 has quit [Ping timeout: 245 seconds]
<andrewrk>
the only thing I would delay the release for is if anyone's actively developed project (oxid, zootdeck, pluto, etc) is failing to build with the release candidate
<TheLemonMan>
andrewrk, shit hits the fan when parseDie calls parseFormValue
<andrewrk>
I noticed that
<andrewrk>
the stack frame for parseFormValue is 4 MiB right?
<TheLemonMan>
yep
<andrewrk>
but that should be fine
<TheLemonMan>
nah, we just hit the 8mb limit
<TheLemonMan>
when we segfault the stack is exactly 8mb
<andrewrk>
oh. ok well that's a really simple explanation
<andrewrk>
wait a minute... one can do `ulimit -s unlimited` without root. can't we just do that syscall at main() ?
waleee-cl has joined #zig
porky11 has joined #zig
<TheLemonMan>
eh, letting the stack size grow without any boundary is quite scary
<andrewrk>
right in our case increase it to GNU_STACK size
<andrewrk>
which is the value chosen at link time
<TheLemonMan>
is this strategy portable to the BSDs too?
<andrewrk>
good question. I haven't investigated that yet. It may be that those kernels actually respect the requested stack size in the ELF file
<andrewrk>
that would be the best case scenario
<TheLemonMan>
I wonder why the kernel doesn't give a damn about the GNU_STACK size
<TheLemonMan>
the FDPIC ELF loader does take it into account tho while the regular ELF one doesn't
rohlem has quit [Remote host closed the connection]
<andrewrk>
the next thing that #3290 has revealed is that cross compiled macos binaries don't work if they rely on TLS
<andrewrk>
I wonder if this is another LLD linker deficiency
FireFox317 has quit [Ping timeout: 265 seconds]
<TheLemonMan>
do you have a minimal test case?
<andrewrk>
I can make one
<andrewrk>
I mean the behavior tests is the example I'm looking at
<andrewrk>
`./zig test ../test/stage1/behavior.zig -target x86_64-macos` will repro it
<andrewrk>
a binary is produced. when run: dyld: symbol not found: __tlv_bootstrap
<andrewrk>
minimal test case: threadlocal var x: i32 = 1; test "" { x += 1; }
<andrewrk>
it works without -target arg (native) causes issue with -target arg (cross compiled)
<andrewrk>
this might be another linker limitation
mahmudov has joined #zig
<stratact>
daurnimator: *pokes*, actually I don't see the need for unlinkat(), considering that I still need the fullpath to open the directory to get the file descriptor needed for it.
<stratact>
So I don't know how I would solve the mount-on-mount path length issue without dynamic allocation
* stratact
feels like he's going in circles
<stratact>
I'm starting to regret doing that issue
FireFox317 has joined #zig
<Tetralux>
stratact: You need the allocator because you need to alloc a fullpath string?
FireFox317 has quit [Remote host closed the connection]
FireFox317 has joined #zig
<stratact>
Well not usually, but from a discussion I had with daurnimator, he said that PATH_MAX is a lie and I would need to account for the possibility of longer path sizes especially when people mount-on-mount
<Tetralux>
16k seems enough to me.
<stratact>
16K it is then
<Tetralux>
But no, more seriously, I'd try using a FixedBufferAllocator on a stack-based fixed-size array to alloc the path.
<Tetralux>
I don't know if 4k is enough for all cases, but 16k probably should be xD
<andrewrk>
TheLemonMan, I tried something similar, putting it in compiler_rt and it had no effect. I'll try your example too though
<TheLemonMan>
the dynamic linker should replace it once it loads the macho image
<_Vi>
Why no underscores in numeric literals? `var q : u32 = 5000_000;`
<andrewrk>
TheLemonMan, ok that actually worked, I must have used too many underscores. now it's saying dyld: Symbol not f ound: ___error
<TheLemonMan>
tell dyld to go pound sand then
<TheLemonMan>
yeah, you need one less underscore because of the symbol mangling
<TheLemonMan>
and, iirc, if you prefix the name with \1 you can disable the mangling in LLVM
<andrewrk>
with the same trick for __error, now it's symbol not found: dyld_stub_binder
<andrewrk>
yeah we'll have to use that \1 trick for this one
<andrewrk>
I exploited a bug in zig, doing @"\x01dyld_stub_binder" and now it's hitting an assert in LLD/lib/ReaderWriter/MachO/StubsPass.cpp
<TheLemonMan>
hmm, dyld_stub_binder comes from libSystem
<TheLemonMan>
you shouldn't really define it, I guess
<andrewrk>
I think the linker expects -lSystem to be on the linker line
<andrewrk>
if you use the system linker with the original test case you get "dynamic main executables must link with libSystem.dylib for architecture x86_64"
<andrewrk>
this is zig trying to add the cross compilation use case where the existing tools aren't used to having that use case
<TheLemonMan>
this is apple being shitheads and having their own linker instead of using lld
<Tetralux>
It's kinda odd than linking takes so long.
<Tetralux>
Like
<Tetralux>
It's not exactly doing rocket science.
<Tetralux>
"What functions are we trying to call and where are they?"
<Tetralux>
Like - one pass to find all the places to fill in and make a list of them; go over the list and populate them all (which you found in the first pass)
<andrewrk>
if you're linking against debug llvm that's 2 passes over multiple GiB of data
<Tetralux>
Second pass is only the places that need filling thou gh.
<Tetralux>
And memory is >>2GB/s.
<Tetralux>
I suspect there's many missed opportunities for speed.
<Tetralux>
Like - even calling the linker takes >0.1s.
<Tetralux>
>0.7s*
<Tetralux>
And you could probably even not need to do the first pass at all -- Zig would already know all the functions that are called.
<Tetralux>
If Zig was directly in control of the linking process, you could just emit the machine code with the relocations already applied.
<mq32>
hey
<Tetralux>
mq32: o/
<mq32>
a quick question: does zig right now supports building for android
<mq32>
hey Tetralux!
<Tetralux>
Hey, MQ :)(
<Tetralux>
:) *
<mq32>
my ui system is now in a "functional" state with defined API :)
sepisoad has joined #zig
<Tetralux>
Seems good :D
<andrewrk>
mq32, android support is experimental at this time
<andrewrk>
I gotta think of something spicy to say for this release >:-] for last one it was "Zig intends to be so practical that people find themselves using it even if they dislike it."
<TheLemonMan>
"A language so good not even reddit has anything bad to say about it"
<mikdusan>
oh don't say that. that's a challenge
<_Vi>
Is there `pub(crate)` analogue in Zig? Means item that can be access from other files/modules within a project, but not from other projects?
<mikdusan>
"If Betamax used Zig it would have won the videotape format war."
<TheLemonMan>
you gotta be controversial if you aim to the frontpage
<mikdusan>
true
<mikdusan>
(unrelated; that grin you get when shunting-yard algorithm _just_ _works_)
<andrewrk>
wow, impressive
<andrewrk>
that seems like it has a lot of little details
<TheLemonMan>
damn, Oxid is such a time sink, so simple yet so good
<andrewrk>
I get discouraged after the first death, no patience to power back up
avoidr has quit [Quit: leaving]
hooo has quit []
<andrewrk>
damn the only remaining test failure for #3290 is windows and I can't reproduce it locally
<andrewrk>
previously we weren't testing cross compiling x86_64-linux-gnu in the CI
avoidr has joined #zig
<andrewrk>
let's try msvc 2019
Aransentin has quit [Remote host closed the connection]
porky11 has quit [Ping timeout: 245 seconds]
fsateler has quit [Ping timeout: 240 seconds]
fsateler has joined #zig
<andrewrk>
"D:\a\1\s\std\debug.zig(227,9): error GD01FD524: invalid builtin function: 'atomicRmw'" - weird, I wonder if hashmap is getting miscompiled with msvc 2019
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<andrewrk>
can anyone reproduce this assertion on windows? ./zig test ../test/stage1/behavior.zig -lc -target x86_64-linux-gnu --override-std-dir ../std
<andrewrk>
it passes for me locally but it's asserting in the CI
<andrewrk>
sorry, got the slashes wrong. bin\zig.exe test ..\test\stage1\behavior.zig -lc -target x86_64-linux-gnu --override-std-dir ..\std
vegax87 has joined #zig
<Tetralux>
From the build directory with a release mode zig?
<andrewrk>
that is what the ci is doing
<Tetralux>
For me, from my relwithdebinfo build directory, that skips exactly one test (because non-native) and quits normally.
<Tetralux>
Doesn't run anything.
<Tetralux>
(any tests, that is.)
<Tetralux>
I'm 0.4.0+8a15537c6
<Tetralux>
*updates to head and tries again*
<Tetralux>
Yep - same outcome.
<andrewrk>
that means it's working, it's producing a binary. the CI is tripping an assertion
wootehfoot has joined #zig
porky11 has quit [Ping timeout: 250 seconds]
Ichorio has quit [Ping timeout: 264 seconds]
knebulae has quit [Quit: Leaving]
<ceymard>
can zig infer comptime type parameters ?
<andrewrk>
ceymard, use `var` for the type
<ceymard>
isn't var going to be deprecated ?
<andrewrk>
what makes you say that?
<ceymard>
I don't know, I remember seeing some IRC log or github issue where I saw you say that
<ceymard>
I may be mistaken
<andrewrk>
that feature is pretty stable
<stratact>
ceymard: var won't be deprecated, it would only error when used improperly.
<andrewrk>
var is an overloaded keyword
<andrewrk>
in this context it means that any parameter type is allowed
<Tetralux>
nrdmn: Yep it is. So it's not fixed-size.
<Tetralux>
It's dynamically-sized.
<ceymard>
shouldn't there be a way to match arrays in switch(T) expressions though ?
<ceymard>
I mean slices are fine
<ceymard>
why can't arrays be ?
<Tetralux>
ceymard: Ah!
<Tetralux>
Yeah, without being able to fill in the N, I don't know how.
<ceymard>
[_]MyType could work ?
<Tetralux>
That's not a bad idea though.
<ceymard>
yeah but how about *not* having to give N ?
<ceymard>
var.len gives it to you anyway
<Tetralux>
Seems reasonable to me.
<nrdmn>
by "fixed-size" I meant that I'd have to choose a size for the buffer while a builtin @format(comptime fmt: []u8, comptime args: ...) could do that automatically
<Tetralux>
Since [_]T gives you an array by default, it would make sense to have that work for matching it.
<ceymard>
yes it would keep consistency
<Tetralux>
nrdmn: see allocPrint.
<andrewrk>
nrdmn, we don't have a comptime allocator yet
<nrdmn>
hm, okay
<ceymard>
should I open an issue ?
sepisoad has joined #zig
<andrewrk>
nrdmn, it's a bit verbose but you could use bufPrint at comptime to count the letters, then declare an anon struct with a global inside it with an array len equal to the count, then use that as your buf for bufPrint
<ceymard>
also, is that related to the fact that I've never been able to specify an array as an argument to a function ?
<andrewrk>
ceymard, I don't think there's an issue here
<ceymard>
ok
<andrewrk>
zig doesn't have pattern matching
<Tetralux>
andrewrk: Should you not be able to switch on a 'type' and have an arm for an array?
<ceymard>
yes I figured that much
fsateler has joined #zig
<andrewrk>
Tetralux, that already works. also arrays in parameter types works
<ceymard>
that's why I was talking of reusing the [_] construct
<companion_cube>
you mean, `switch`? :D
<Tetralux>
andrewrk: What's the syntax for matching an array?
<andrewrk>
have a look at the output of `zig builtin`, the TypeInfo type
fraktor has joined #zig
<Tetralux>
We're talking about switching on a type, not TypeInfo.
<Tetralux>
It means the _type_ of the value is comptime known.
<ceymard>
Tetralux: in the array branch, you could always do x.len
<Tetralux>
ceymard: Indeed - still would need Zig to accept [_]T as an array though.
<ceymard>
yes
<Tetralux>
Seems like a reasonable idea to me.
<Tetralux>
And seems easier to read than using typeinfo honestly.
<ceymard>
sooo easier
<Tetralux>
Well - it gets a little more complicated if it could be any type.
<Tetralux>
Because to use the array type as the arm's value, you have to provide the eltype
<Tetralux>
Which you obviously would not have if it's not an array.
<ceymard>
so when I use var and @typeOf, does this mean that the result of this expression is inlined ?
<Tetralux>
The switch is comptime-known and will not be in the exe.
<Tetralux>
You'll have a copy of the function for every type of value you pass to it.
<Tetralux>
So if you only ever pass [N]u8, you'll have only one copy.
<Tetralux>
If you pass 1000 different types to it, you'll get 1000 specializations of it.
<Tetralux>
Which is the reason the stdlib generally uses 'comptime T: type' instead of this.
<Tetralux>
.. Smaller code size.
wootehfoot has quit [Read error: Connection reset by peer]
<andrewrk>
the main reason is slices are a better type to implicit cast to
<Tetralux>
You can implicit----oh you mean `([]u8)buf` where buf is [N]u8 don't you.
<Tetralux>
I always get confused about explicit-implict-casts xD
<Tetralux>
ie. implicit casts like that, where you explicit give the type.
<ceymard>
([]u8)"my string" does not work though ?
<Tetralux>
ceymard: try ([]const u8)
<fraktor>
Hmm. I'm trying to build Zig using llvm 9 that I got from the Github mirror, but even adding '-DCMAKE_PREFIX_PATH=$HOME/local' doesn't seem to work; zig can't find llvm.
<andrewrk>
fraktor, what os?
<fraktor>
Debian
<fraktor>
I made sure that I built LLVM so it would go in $HOME/local.
<via_>
is there a better way to keep up on news/changes to the lang other than reading through the git/pr history? if, say, i miss weeks of conversation here
<andrewrk>
fraktor, I'm confused, did you get it from the github mirror (what github mirror?) or did you build it from source?
via_ is now known as via
<andrewrk>
via, 0.5.0 release notes will catch you up from 0.4.0
<andrewrk>
sept 30
<via>
wow, thats soon
<via>
yeah, release notes will, but i mean even things like the finishing of the coroutine rewrite, etc
<fraktor>
I... why was I using the other one? Thank you.
<andrewrk>
I recommend apt.llvm.org
<andrewrk>
if you build from source for development purposes I recommend leaving it in the default location, which is the build folder
<fraktor>
I'm doing it for the purpose of writing stuff with zig, not attempting to modify zig itself. I want to put it in $HOME/.local/zig
<andrewrk>
sounds like you want to set -DCMAKE_INSTALL_PREFIX to your preferred install folder
<fraktor>
Thank you. I'm not familiar with all of cmake's install variables.
<andrewrk>
oh my god, I know why the tests are failing on windows ci for #3290
<andrewrk>
they have git configured to mangle text files
<ceymard>
Tetralux: no dice
<ceymard>
oops
<Tetralux>
ceymard: xD
<Tetralux>
Yeah, I do that all the time
<ceymard>
haha
<Aransentin>
...is there something subtle messing with my nested `while` loops? I'm confused: https://godbolt.org/z/mBluoR
<Aransentin>
Check the asm output. I assumed it would be 100
<fengb>
You don’t reset x for the inner loop
<Aransentin>
Ah shit
<Aransentin>
🙃
fraktor has quit [Quit: WeeChat 2.3]
<Aransentin>
Man... the for-loops are probably the worst part of Zig for me. Either you keep a function-wide `i` and share it between loops, or you wrap every loop in a new scope. So ugly.
<Tetralux>
Yeah, I feel ya
vegax87 has quit [Read error: Connection reset by peer]