<mq32>
support for links, images and internal refs is still missing, but the "rest" of my planned feature set works
<pixelherodev>
Weird Zig bug with my kernel: if try/catch are used in kmain, backtracing fails
<pixelherodev>
Weirdest part is, this happens even with a catch that literally never triggers
<pixelherodev>
Fortunately, once i realized the cause, it's really easy to work around :P
<mq32>
if you "try" in your entry function, it will probably fail because of an invalid return type
lunamn has quit [Ping timeout: 268 seconds]
<pixelherodev>
Correction: if I do, for instance, `_ = serial.setup() catch null;` backtracing fails
<pixelherodev>
If I change the return type of serial.setup to bool and have it catch memory allocation errors internally, suddenly backtracing works again
<pixelherodev>
It's very easy to demonstrate the causal link
<pixelherodev>
Oh yeah - on that note, my kernel now supports serial using a stream opened with `std.fs.File.openWrite("/dev/ttyS0")` :D
<pixelherodev>
But yeah, even just writing a shell function that does `catch return` and calling that works
<pixelherodev>
As long as I don't have `catch` in kmain, it's fine
<pixelherodev>
Deliberately set a slice too small to read just to see the stack trace :P
wootehfoot has joined #zig
utzig has quit [Read error: Connection reset by peer]
utzig has joined #zig
_whitelogger has joined #zig
cmrs has joined #zig
chemist69 has quit [Quit: WeeChat 2.3]
cmrs has quit [Read error: Connection reset by peer]
mahmudov has joined #zig
sossy has joined #zig
mahmudov has quit [Ping timeout: 268 seconds]
chemist69 has joined #zig
knebulae has joined #zig
stratact has quit [Remote host closed the connection]
Akuli has joined #zig
mahmudov has joined #zig
utzig has quit [Quit: leaving]
RagingDave has joined #zig
RagingDave has quit [Client Quit]
oats is now known as h4rdb455
h4rdb455 is now known as oats
wootehfoot has quit [Read error: Connection reset by peer]
ForLoveOfCats has joined #zig
sossy has quit [Remote host closed the connection]
<andrewrk>
pixelherodev, nice. no color though?
<andrewrk>
you can also use @panic("blah")
keithdc has joined #zig
clktmr has joined #zig
ForLoveOfCats has quit [Quit: Konversation terminated!]
doublex has quit [Ping timeout: 245 seconds]
<nrdmn>
speaking of that topic... std currently expects stderr to be a file, i.e. something that has a file descriptor and implements a file interface. in UEFI, file handles and character devices have different interfaces. a write operation on a file is a completely different operation than a write on stdout or stderr.
<nrdmn>
should we just have a wrapper structure around file descriptors for uefi that contains a flag whether it's a regular file or something else, which then decides internally which interface to call?
knebulae has quit [Ping timeout: 240 seconds]
<andrewrk>
on posix std.os.fd_t is i32, on windows std.os.fd_t is std.os.windows.HANDLE. Is there a sensible value that fd_t could be for UEFI?
<nrdmn>
andrewrk: simply a pointer to the struct representing the file or character device would come clostest to a "file descriptor"
<nrdmn>
but a write() would have to do different things to write to a file or to a character device
<nrdmn>
so we'd have to put type information on that pointer
<andrewrk>
so it could be a tagged union
<nrdmn>
that could work
riba has joined #zig
<riba>
what does "pointer type child x cannot cast into pointer type child y" mean
<riba>
i re-declared a struct i need to pass to C code because annoyingly some things were not const there and i just wanna pass static strings
<riba>
otherwise i just copied the generated definition so it should fit
occivink has quit [Quit: WeeChat 2.5]
wootehfoot has joined #zig
<andrewrk>
riba, that is telling you why the types don't match
<andrewrk>
more notes might follow
knebulae has joined #zig
clktmr has quit [Ping timeout: 250 seconds]
doublex has joined #zig
Ichorio_ has joined #zig
Ichorio has quit [Ping timeout: 245 seconds]
clktmr has joined #zig
ltriant has joined #zig
<riba>
andrewrk: thanks, but it seems i simply was not paying attention. i cast the wrong variable and imagined the output to be different from before
<riba>
too tired for this rn, i think :D
<pixelherodev>
andrewrk, only color there is foreground/background color; I'm not doing anything fancy just yet
Akuli has quit [Quit: Leaving]
riba has quit [Ping timeout: 265 seconds]
wootehfoot has quit [Read error: Connection reset by peer]
<andrewrk>
if zig is below C in any benchmark, it's a bug in the code somewhere
<andrewrk>
I'm not kidding
<pixelherodev>
On a different note, thanks for reminding me about `catch unreachable`
<pixelherodev>
A lot more useful in a kernel where a lot of operations can *technically* error except not raelly
<andrewrk>
yeah. use it with caution, but it definitely has places where it is the correct thing to do
<pixelherodev>
Yeah - for instance, my overridden I/O stuffs. `std.fs.File.openWrite/openRead` are guaranteed to succeed on my target, so instead of using an optional type an unwrapping whenever I want to print, I can just do `var ttyS0 = std.fs.File.openWrite("/dev/ttyS0") catch unreachable`
<andrewrk>
that checks out
<fengb>
It’s like they’re intentionally making zig much harder -_-
<pixelherodev>
Though I'm starting to think that while this is cool, it might not be worth having to manually update my standard library periodically
porky11 has joined #zig
<pixelherodev>
Well, Zig *is* a complete paradigm shift, it takes some getting used to
<pixelherodev>
I spent a few days trying to program it as if it was C also
<fengb>
I suppose HeapAllocator kinda sounds correct heh
<andrewrk>
ugh. this person who did the benchmarks repo is a V community member. so of course they wrote a shitty zig benchmark and then ranked zig lower than v in the results
<andrewrk>
when the fixed benchmark is actually faster than their reference C code...
<andrewrk>
it's hard not to feel a little bit hostile when someone is being actively deceitful about performance
<jaredmm>
Trying to replicate WNDCLASSA wndClass = { 0 }; in Zig turns into something like...std.mem.set(u8, ([]u8)(&wndClass)[0..1], 0), right?
<andrewrk>
jaredmm, that should work, if the type checker lets you do it
<pixelherodev>
Wow, yeah, did not know that
<pixelherodev>
It's not just faster than the reference implementation, it's faster than the *optimized SSSE version*
<pixelherodev>
... and unlike V, it doesn't need *2GB of RAM that's insane*
<fengb>
Wow
<pixelherodev>
This is honestly incredibly impressive. How *does* Zig beat the SSSE version? Does the encoder use SIMD instructions or something?
<andrewrk>
pixelherodev, zig is great at cross compiling right? so when you're not cross compiling, zig knows OK, this is the native target for sure, if they were cross compiling, they would have told me
<andrewrk>
so it does the equivalent of -mcpu=native for the native targets
<pixelherodev>
...
* pixelherodev
is stunned
<andrewrk>
it does this if you use zig as a C compiler as well
<pixelherodev>
That - that should probably be in the docs, right?
<pixelherodev>
Now the real question is how does it compare to the C example under -mcpu=native
<pixelherodev>
I wouldn't be surprised if it's still faster, but it's probably closer
<pixelherodev>
ah well, not important. At least, not to me. Performance is a really nice bonus, but it's probably, like, #3 or 4 on my list of favorite parts of Zig :)
<andrewrk>
the adjusted zig example code is faster, because they use malloc() in the hot path in the c example...
<andrewrk>
the person is complaining that zig is hard to use, citing issues with allocating memory, but then goes and puts malloc() in the hot path of a base64 benchmark. it's almost like the language is providing friction for doing it wrong
<emekankurumeh[m]>
for that "benchmark" couldn't we just get zig to do that at comptime, with a static buffer?
<pixelherodev>
Probably, but I think that would violate the point
<pixelherodev>
The point isn't "embed statically calculated base64 encoding", it's do it at runtime and see how quickly you can
<andrewrk>
technically the benchmark does not actually utilize the results of the computation, if llvm were smart enough it would delete all the loops
<emekankurumeh[m]>
but their example is more or less asking how fast the allocator is :/
<andrewrk>
it should be called test-allocation then instead of test-base64
slice has quit [Ping timeout: 268 seconds]
<andrewrk>
does windows have the equivalent of AT_FDCWD? for use with NtQueryDirectoryFile
* pixelherodev
knows nothing about Windows beyond "it nightmare stay away"
<pixelherodev>
sorry
<emekankurumeh[m]>
wouldn't you just get a handle for the cwd and just call it with that>
<andrewrk>
emekankurumeh[m], yes but AT_FDCWD for example is an integer so it can be initialized at comptime, whereas getting the handle for cwd (which function is that, btw?) would have to be done at runtime, protected by a lock, or before main()