<nrdmn>
panicking is another thing I don't know how to proceed with. panic and all the functions it calls expect stderr to be a file with a file handle and everything. In uefi, stderr has something you could call a handle, but the operations you can do on it are very different from those you can do on actual files
<andrewrk>
what's different about stderr in uefi?
<andrewrk>
if it's ok with you - at some point here I'm going to have a look at your fork and merge everything into master that I think makes sense, and then try to work with you on the rest of the stuff, so that you can be building your projects against upstream and be happy with it
<andrewrk>
I've been neglecting this for a week or two, been really focused on async functions
<nrdmn>
in uefi, stderr is of type EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL which is a struct that has methods to set the screen resolution and output strings. Files are represented by EFI_FILE_PROTOCOL structs which can be open()ed and have write() and read() methods, all o
<nrdmn>
f which EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL does not
<nrdmn>
the handles are basically just pointers to these structs
<nrdmn>
so to distinguish between them, our efi fd_t would have to be a struct that carries information about the type of struct
<andrewrk>
could it be a global constant with fd_t being a pointer to it??
<andrewrk>
oops, didn't mean to add an extra '?' there.
<nrdmn>
what do you mean? stderr is globally available
<nrdmn>
I'm just not sure how to fit efi text output, efi files, efi block devices etc. into structures that are meant for unix files which are all of these in one
<andrewrk>
fd_t can be any type depending on the target
<andrewrk>
I see the problem
Ichorio has quit [Ping timeout: 264 seconds]
kristoff_it has quit [Remote host closed the connection]
kristoff_it has joined #zig
<nrdmn>
also stderr is only available as long as the application is in boot mode. uefi applications are supposed to tell the firmware that they're done initializing. After that, they have to use their own drivers to access devices
<andrewrk>
hmm yeah that's an interesting problem
laaron has quit [Remote host closed the connection]
<andrewrk>
that's why I'm tempted to say ok everybody should just provide their own panic function for UEFI
<andrewrk>
I guess in that case the default should assume that it's not done initializing. and then when someone's project gets sophisticated enough to pass that point, they "graduate" by supplying their own panic function
<nrdmn>
in theory we could probably read the pdb file that zig generates and print pretty stack traces
<nrdmn>
Is it possible yet to add a panic function during runtime? Or would we have to write something to do that specifically for uefi?
laaron has joined #zig
kristoff_it has quit [Ping timeout: 258 seconds]
<andrewrk>
no, what that looks like is an if statement inside the global function
<andrewrk>
well - the default panic handler could use @hasDecl to look at the root source file for multiple different panic handlers. e.g. maybe it looks for panicBoot and panicWithDrivers
<andrewrk>
that seems a bit overengineered to me though
marijnfs_ has quit [Quit: WeeChat 2.4]
<rsdimenus>
andrewrk: not sure if you mentioned this in IRC yesterday, but what CPU did you go with for the new build?
laaron- has quit [Remote host closed the connection]
laaron has joined #zig
Tetralux_ has quit [Ping timeout: 258 seconds]
Tetralux has joined #zig
omglasers2 has joined #zig
firefox317 has joined #zig
<firefox317>
andrewrk: In tools/update_glibc.zig you are also using a `std.AutoHashMap([]const u8`, but you didn't add the compile error in that file. Maybe you should also add it there
andersfr has joined #zig
<Tetralux>
I cannot seem to run the http.headers tests that the CI runs from my working copy.
<Tetralux>
Am I doing something stupid or can I actually not do that?
<Tetralux>
Also - I may have found a compiler bug.
<sarna>
hi, I want to build a program that uses stuff from std.c and I get "dependency on library c must be explicitly specified in the build command" - how do I do that?
<sarna>
I tried searching in the docs, but found nothing
<Tetralux>
Add `--library c` to the command line
<Tetralux>
Or `b.addSystemLibrary("c")` to build.zig, if you're using that.
Ichorio has quit [Ping timeout: 264 seconds]
<sarna>
Tetralux: now I'm getting "no member named 'addSystemLibrary' in struct 'std.build.Builder'"
<Tetralux>
Oh right
<Tetralux>
My bad
<Tetralux>
It's linkSystemLibrary
<sarna>
also, where to put it? at the very start, after setting the mode, somewhere else? is there any convention
<Tetralux>
I believe that you can use extern fns without libc though.
<sarna>
sorry I'm a dummy when it comes to system programming :)
<Tetralux>
The one that Zig builds on the fly for your system that is packages as source with Zig.
<Tetralux>
packaged*
<sarna>
I see
<Tetralux>
(This is much more flexible and reliable than using the one on the machine.)
<Tetralux>
And means you don't have to maintain libc versions and things.
<sarna>
well, I couldn't use system() when I didn't have it linked
<sarna>
yeah that's cool!
<sarna>
let's see if I can use puts without linking libc
<Tetralux>
I don't think so, because that's part of libc.
<sarna>
yup, can't do it
<Tetralux>
BUT
<Tetralux>
You shouldn't need it
<Tetralux>
Because you have std :)
<Tetralux>
std.debug.warn especially.
<Tetralux>
That's the printf of Zig.
<sarna>
oh yeah, I just wanted to check if I can call C functions
<Tetralux>
I don't know if you need libc to do that. I haven't tried it.
<sarna>
I'm rewriting a disfunctional C program I wrote a month ago for practice :D
<Tetralux>
But I suspect you can if the fn you are calling doesn't use libc in any way.
<Tetralux>
Ah-ha!
<Tetralux>
A noble goal xD
<sarna>
it keeps segfaulting and I don't know why :D I want to find out
<Tetralux>
When you rewrite it, pay close attention to times where you do `= undefined` and then don't set a field.
<Tetralux>
That'll bitecha.
<sarna>
yeah, this one should help
<Tetralux>
When you set to undefined, it does NOT set fields to their default values that you declared them to have in the struct definition.
<sarna>
along with optionals
<Tetralux>
That's bitten me a couple of times.
<sarna>
yeah, it's an invalid value then, right? using it is an error
<Tetralux>
Nope.
<Tetralux>
It's just not initialized.
<Tetralux>
No error.
<Tetralux>
It'll prob crash.
<Tetralux>
Or hit unreachable somewhere.
<Tetralux>
That's why when you use `undefined`, it's like doing `int x;` in C.
<sarna>
isn't using an uninitialized value a programming error :)
<Tetralux>
You cannot trust anything about the value it has until you fully set everything about it.
<Tetralux>
I mean yes.
<Tetralux>
But thinking that it has the default value you provided and it actually not because undefined ignores them.... :)
shritesh has quit [Quit: Goodbye World!]
<Tetralux>
You have to either do `= { .field1 = value1, ... }` or `= undefined`.
<Tetralux>
And if you do the latter, be wary.
<Tetralux>
xD
<sarna>
yeah, thanks :)
shritesh has joined #zig
<Tetralux>
The number of times I've thought "Oh, I gave them specific default values, so undefined will only no initialize the ones I HAVENT given defaults to" has bitten me is... more than I'd like to admit.
<sarna>
yeah I see how that would unfold :D you'd get a compile error though, right?
<Tetralux>
Nope.
<Tetralux>
Because I did `var x: T = undefined;`
<sarna>
oh darn
<Tetralux>
See - I like the idea of undefined - if you're about to set the fields to values anyway, or a function call will or something, it makes sense to do that.
<sarna>
do you use C-style for loops in zig? don't see any in the docs
<Tetralux>
You _can_... but not with `for`.
<Tetralux>
They look this instead:
<Tetralux>
`var i: usize = 0; while (i < n) : (i += 1) { // code }`
<sarna>
oh my
<Tetralux>
Personally, I'd rather something like `for (var i: 0..n-1) { // code }`
<Tetralux>
Bu that was rejected I believe.
<Tetralux>
Or rather, it'd be:
<Tetralux>
`for (0..n-1) |i| { // code }
<sarna>
if you created an array of voids and for'd over them.. :^)
<Tetralux>
I'm not sure that even works xD
<Tetralux>
Or is fast, if it does work.
<Tetralux>
`const ITR: [n]void = undefined; for (ITR) { } // no `i`
<fengb>
Andrew mentioned he’s open to for loops over generators
<sarna>
foo() is called on comptime (I think) and it's 0 bits.. :>
<sarna>
it's still an awful piece of code though :D even if it was fast
<fengb>
You could probably do const range: [5]void = undefined
<sarna>
zig has ranges?
<fengb>
Not yet but there’s some discussion for standardizing generators / iterators
<fengb>
Range would probably be a generator like Python, not a first class construct
<sarna>
I see
sarna has quit [Quit: Leaving]
<Tetralux>
Yeah - I'm never liked Python's range xD
<Tetralux>
RIP.
Akuli has joined #zig
wootehfoot has joined #zig
SimonNa has joined #zig
Ichorio has joined #zig
firefox317 has joined #zig
curtisf has joined #zig
<firefox317>
I'm trying to build zig using msys2 which uses mingw-w64. Can I use the prebuild binaries of llvm for Windows or do I have to built them myself? And
<DutchGh0st>
look at the 2 functions at the bottem
<DutchGh0st>
comment the `foo` function and it compiles
<fengb>
"export" means use C ABI, but slices don't exist in C so there's no way to properly return it
<DutchGh0st>
but because I use a packed union that basically wraps directly around any T, it works?
<fengb>
That should be a bug
<DutchGh0st>
hehe
<DutchGh0st>
sooo do I report it?
<fengb>
I don't think slices have packed representation
<Akuli>
this online thing supports zig? :D
<nrdmn>
fengb: why wouldn't they?
<DutchGh0st>
it has for quite some time
<DutchGh0st>
but you need `export fn` to see the asm, which is kinda sad
<fengb>
Okay this is a little weird. Slices are not allowed in packed structs but just fine in packed unions
<fengb>
DutchGh0st: it's because Zig is lazy. If there's no reference to a specific definition, Zig doesn't bother compiling it
<nrdmn>
also seems like you can't choose the target architecture for zig in godbolt
<DutchGh0st>
probably a commandline option?
<fengb>
nrdmn: I don't think Zig has defined the slice ABI yet, so the compiler can arbitrarily choose to put the pointer first or last. There's a proposal: https://github.com/ziglang/zig/issues/2201
<DutchGh0st>
So but is slices in packed unions a bug or not?
<DutchGh0st>
and probably other normally non-exportable types as well
<fengb>
I'm not sure... I'd expect it to be but I don't know if packed unions and packed structs should be semantically identical