<daurnimator>
andrewrk: an idea I had about linux errors: lets make 4095 errors, and have all the low level syscall wrappers return that error set? would make it so the e.g. `try linux.mmap()` is the resolution to the MAP_FAILED thing.
<daurnimator>
would also let us annotate the syscall return values better. e.g. that mmap actually returns a `[*]align(4096)u8` instead of a usize that the caller always has to cast.
<scientes>
daurnimator, yeah I already proposed that
<scientes>
the problem is that setting error values requires that the compiler know about those error values
<scientes>
but it can be done
<daurnimator>
scientes: linux only has 4096 error codes.
<daurnimator>
we can just enumerate them all
<scientes>
yes
<scientes>
but that has to be done in the compiler
<scientes>
because of the way errors work in zig
<andrewrk>
doesn't that defeat the purpose of error sets? I don't want errors in the error sets that are not actually possible
<daurnimator>
andrewrk: a raw linux syscall can return any error with use of e.g. syscall-bpf
<scientes>
andrewrk, but we can't control Linux
<daurnimator>
andrewrk: we then should wrap the syscalls in high level function that have `unexpected` or @panic for undocumented errors
<andrewrk>
we already do that
<andrewrk>
I do like the idea of @panic instead of Unexpected for some cases though
<scientes>
even with the switch optimization i am working on for LLVM that would take 8KB per syscall
<daurnimator>
^refactor the 'low level' operation to something like that?
<daurnimator>
scientes: huh?
<scientes>
daurnimator, LLVM can't optimize that yet
<scientes>
it would have to be written
<scientes>
large switches
<scientes>
with lots of redundancy
<scientes>
well actually it would work fine, you just can't write it that way
<daurnimator>
scientes: can it be written as a lookup table instead? `const errortbl = []error{error.EPERM, error.ENOENT, .....}` fn linuxError(sr: usize) !void { if (sr < std.math.maxInt(usize)-4096); return errortbl[std.math.maxInt(usize)-4096]; }
<scientes>
daurnimator, thats what my optimization is doing
<scientes>
but you still have to peel the low and high end off
<daurnimator>
^ code there is wrong; I copy pasted the wrong bit. but you should get the point :P
<scientes>
or you end up with 8KB per switch (2 bits each)
<scientes>
anyways, I'll probably write that optimization so it wont matter, but you wouldn't write it that way anyways.
<daurnimator>
scientes: "peel off"?
<daurnimator>
andrewrk: so if e.g. linux.close() was that example above, posix.close could be: `fn close(fd: i32) (error.EBADF||error.EINTR||error.EIO)!void { switch (builtin.os) { .linux => linux.close(fd) catch |err| switch(err) { error.EBADF,error.EINTR,error.EIO => return err; else @panic("unexpected error from linux syscall"); } else . ....... }
coolreader18 has joined #zig
<tgschultz>
I don't think there's any reasonable way to account for things like syscall-bpf. You can arbitrarily return errors for things that are invalid and for things that "can't" fail. If the system is intent on lying to the program, I think @panic is not an inappropriate response.
<daurnimator>
tgschultz: yeah. though syscall-bpf is just the most blatent case. often new functionality gets added (e.g. new file desciptor types or new file systems) that introduce new returnable errors for some calls
<scientes>
^^^
<scientes>
we have to tolerate new errors for most syscalls
<daurnimator>
I think @panic is a fine behaviour for unexpected errors. but unreachable isn't.
<scientes>
generally unreachable will just be 0 in the LLVM too for switches, so it will think it succeeded
<scientes>
there is no speed benifit
<daurnimator>
are @panic strings de-duped?
<scientes>
yes
<scientes>
the linker does that
<daurnimator>
scientes: so only thing you think we're missing to make this work well is optimizing switches on errors?
<scientes>
no, if we match the error codes it won't need much optimizing
<scientes>
cause we are just passing the error through
<daurnimator>
scientes: yep. Is there a way (and it is worth it?) to tell the compiler that it would be "really good" if EBADF is represented internally as error number 1?
<scientes>
actually error numer -1
<scientes>
i think it is
<scientes>
coolreader18, I couldn't find any documentation which version of arm they have
<hryx>
I'm messing around with porting the #define translation and it's apparent these other maps are needed
<andrewrk>
hryx, yes, I think it became a bit of a mess in stage1 - I was hoping to re-evaluate the usage of those tables
<hryx>
andrewrk: currently I'm struggling to understand the exact role of decl_table vs global_table
<andrewrk>
let me take a look and refresh my memory
<hryx>
thanks. I'm cool with rethinking the tables entirely, or only adding things as needed, rather than blindly porting over the C++ source. just need to grasp the requirements a little better
<hryx>
does translate-c only work on one translation unit? or rather, does one Context correspond to one translation unit?
<andrewrk>
yes, if my understanding that translation unit means "object file"
<andrewrk>
*if my understanding is correct
<hryx>
'tis my understanding too
<hryx>
(BRB in 15 minutes)
coolreader18 has quit [Quit: Leaving]
coolreader18 has joined #zig
coolreader18 has quit [Client Quit]
coolreader18 has joined #zig
<tgschultz>
...I have some concerns with how how DirectAllocator handles alignments with VirtualAlloc, but I'm not sure it's actually a problem or my understanding of how it works is incorrect. I'll get back to you.
shritesh has joined #zig
<daurnimator>
Has anyone looked into non-exhaustive enums for zig?
shritesh has quit [Quit: segfault]
<hryx>
oops, I gotta go - no worries about the translate-c thing for tonight, I'll approach it with a fresh head in the next couple nights!
shritesh has joined #zig
kristoff_it has joined #zig
scientes has quit [Ping timeout: 258 seconds]
coolreader18 has quit [Ping timeout: 245 seconds]
jevinskie has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
jjido has joined #zig
nikki93 has quit [Read error: Connection reset by peer]
jzelinskie has quit [Read error: Connection reset by peer]
nikki93 has joined #zig
jzelinskie has joined #zig
affinespaces has quit [Read error: Connection reset by peer]
odc has quit [Read error: Connection reset by peer]
r1b has quit [Read error: Connection reset by peer]
cbarrett has quit [Read error: Connection reset by peer]
r1b has joined #zig
cbarrett has joined #zig
affinespaces has joined #zig
odc has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kristoff_it has joined #zig
kristoff_it has quit [Remote host closed the connection]
wilsonk|3 has joined #zig
wilsonk has quit [Ping timeout: 252 seconds]
avoidr has quit [Quit: leaving]
very-mediocre has joined #zig
hio has joined #zig
coolreader18 has joined #zig
coolreader18 has quit [Ping timeout: 245 seconds]
neceve has joined #zig
* daurnimator
would love docs on fences to be completed
scientes has joined #zig
Aransentin has joined #zig
<tgschultz>
never mind about my DirectAllocator/VirtualAlloc concerns. I was too tired to see that the race condition was accounted for by a retry loop.
<TheLemonMan>
and it'd be sweet if you could send me somehow the .a and .o files mentioned in the last few lines before the grim reaper takes the process away
<jjido>
33%
<TheLemonMan>
at some point it will print a line saying `ar rcs ...`, that's what I need
<jjido>
do I need to install cmake?
<TheLemonMan>
yup
<jjido>
sorry, that will be a minute
<TheLemonMan>
no problem, take your time
<jjido>
huh it does not take the system llvm. Installing it through brew
<TheLemonMan>
yeah you need llvm-8
<jjido>
it's installed llvm.
<jjido>
still getting: unable to find llvm-config
<jjido>
:-(
<shritesh>
jjido: did you pass in -DCMAKE_PREFIX_PATH?
<TheLemonMan>
hmm, I need the libuserland.a libuserland.o and compiler_rt.o files
<jjido>
yeah they are the ones in the ar command
<TheLemonMan>
can you upload those somewhere?
kristoff_it has joined #zig
mikdusan has quit [Read error: Connection reset by peer]
<tgschultz>
ah, that moment where you've finished changing all the things, but haven't started the integration test yet so you're still blissfully ignorant of all the stuff you unwittingly broke.
<TheLemonMan>
just rm the failing tests and you're good to go
<jjido>
TheLemonMan are you fixing the linker errors?
kristoff_it has quit [Remote host closed the connection]
<TheLemonMan>
yup, I'm trying to understand what's wrong
mikdusan has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
very-mediocre has quit [Ping timeout: 256 seconds]
coolreader18 has joined #zig
<donpdonp>
for (str) |char, idx| { var s = switch(char) { ... values of type 'comptime_int' must be comptime known
<donpdonp>
im not sure where the comptime_int is coming into play. str is []const u8.
<marijnfs>
Hi, can anyone point me to how to add a c-include directory? I have headers in a place other than /usr/local/include
<marijnfs>
donpdonp: thanks, that addExecutable doesn't directly start compiling i guess? Otherwise that order wouldn't to work?
<marijnfs>
donpdonp: it works! But I'm confused how the order exactly works when a exe is built
TheLemonMan has quit [Ping timeout: 244 seconds]
jjido has joined #zig
halosghost has quit [Quit: WeeChat 2.4]
* donpdonp
shrugs
avoidr has joined #zig
<donpdonp>
how do i get a []u8 from a []const u8
<donpdonp>
i think i have to alloc then mem.copy
wootehfoot has quit [Read error: Connection reset by peer]
<tgschultz>
It's possible to drop a const from a pointer, but I wouldn't recommend it unless you're very sure.
<donpdonp>
heh yeah im fine going with safe but not-as-efficient.
<donpdonp>
mem.dupe() looks to do the thing.
coolreader18 has quit [Remote host closed the connection]
wilsonk has joined #zig
<Aransentin_>
Struggled a while with making WebAssembly imports/exports work... until I noticed that it's all been fixed a few days ago and I hadn't updated. Nice :)
wilsonk|3 has quit [Ping timeout: 258 seconds]
wilsonk|2 has joined #zig
wilsonk has quit [Ping timeout: 258 seconds]
<Aransentin_>
Also may I recommend supporting the wasm bulk memory extension? It works in Chromium (and Firefox soon) and makes memcpy and friends sanic fast
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<shritesh>
Aransentin_: that sounds cool. I will take a stab at it.
<Aransentin_>
Oh, nice. Thanks a bunch!
<shritesh>
We might have to wait for LLVM to add support for those instructions first 😅
<shritesh>
Ooh. Looks like it’s already there (along with other proposals).
<Aransentin_>
I've been using it with C+clang with the "-mbulk-memory" flag... Through admittedly on llvm 9!
<shritesh>
Gotcha
<shritesh>
Have you tried out any of the SIMD stuff? It might just work out of the box
<Aransentin_>
Not sure, I don't think I do anything SIMD-ish that would trigger it just yet
<scientes>
shritesh, simd needs alot of work
<scientes>
it generally doesn't work with zig
<scientes>
some stuff just works
<scientes>
and wasm does have simd
<shritesh>
Yeah. The tests for LLVM Wasm simd looked the same as regular SIMD.
<shritesh>
So once Zig has good support for SIMD, it might work right away with WASM
<scientes>
but even LLVM support for SIMD is meh meh, but has alot of promise
<scientes>
in the long run using a compiler is def better than hand rolling
<scientes>
but since this stuff is generally only used in performance critical chunks it is hard to get the momentum behind strong compiler support
<shritesh>
It is fair to expect that you’ll have to drop down to raw assembly for not-meh SIMD?
<scientes>
not at all
<scientes>
the compiler should generate better simd
<scientes>
unless you heavily tune it
marijnfs has quit [Ping timeout: 258 seconds]
<scientes>
because it can do alot of optimizations
<scientes>
and reduce the amount of work required
<scientes>
what i'm saying is that the status of the optimizations is meh
<scientes>
and also the register allocator is meh
<scientes>
actually the register allocator is absolutely horrible in some cases