<mq32>
okay, using Zig for C libraries kinda feels more natural than C ^^
<mq32>
although this has a thin layer of wrapper around itself
<mq32>
(namely packing event ints into a tagged union)
casaca has joined #zig
casaca has quit [Ping timeout: 268 seconds]
casaca has joined #zig
<gonz_>
It's super nice indeed
<mq32>
if my code would work, i could show something super nice :D
<mq32>
infinite 2D tilemapping
casaca has quit [Ping timeout: 276 seconds]
<mq32>
but it looks like my quadtree is still broken
casaca has joined #zig
casaca has quit [Ping timeout: 240 seconds]
casaca has joined #zig
<Snektron>
But other than that
<Snektron>
Wasm will never be as fast as native
<fengb>
Wasm is ~50% speed right now
<Snektron>
On such low level code you need to differentiate betwren architecture anyway
<Snektron>
I wouldnt trade in 50% performance just for wasm tbh
<Snektron>
Its better than the 90% you lose with JS
<fengb>
I'm more curious from an architectural standpoint
<Snektron>
So its accepyable for browsers i suppode
<Snektron>
What would you gain from it?
<Snektron>
You need architecture dependent code anyway so you cant run it in just wasm
<Snektron>
Youre suddenly going to need to implement previleged instructions too
<Snektron>
(idk if wasm has a model for that, but considering its target i wouldnt expect so)
<fengb>
It has host "syscalls"
<fengb>
But I mean more like the userland is only wasm based. That'd eliminate the need for privileged instructions
<fengb>
I dunno. I'm taking Birth and Death of Javascript to the next level :P
frmdstryr has quit [Ping timeout: 240 seconds]
<gonz_>
I think WASM as a non-browser runtime might be useful for edge cases. It could replace Docker for many users' development workflows, for example.
<mq32>
gonz_: i think pretty much any place where script languages are used right now can be replaced with a good Wasm interface
<mq32>
e.g. scripts in games could be written with any language then
<Snektron>
Userland only is something different
<Snektron>
gonz_ docker is still much faster than vm
<fengb>
So... I think wasm is inevitable as a "native" target, or at least a much wider deploy than any other VM language
<Snektron>
And i think that virtualization is still nuch faster than that 50% performance loss
<fengb>
At the very least, I'm hoping it can fix some of the Electron bloat that's getting really pervasive
<gonz_>
Snektron: 50% is what you get in a browser right now, AFAICT.
<gonz_>
I don't think it's uniformly the case for non-browser runtimes.
<Snektron>
So unless you use wasm as some kind of IR and then compile that to native, similar to ART, i dont think you want to do it
<gonz_>
Even so, "now" doesn't matter much. It's effectively the starting point.
<fengb>
But maybe that won't matter and RISCV will eat the world :P
<mq32>
Snektron: afaik wasm is designed to be JITted
<Snektron>
I dont think wasm should be used as a hammer for every nail you can find
<mq32>
true dat
<Snektron>
fengb, personally im rooting for the comeback of vliw cpus
<fengb>
Wasm design is closer to an IR; it's a stack machine
<Snektron>
Yeah, thats similar to java bytecode
<Snektron>
If android is still using that
<Snektron>
Wasm os would just be an OS with an official interpreter
<Snektron>
Or jit compiler, if you will
<mq32>
tip of the day: Don't do stupid things. It will work, then.
<andrewrk>
just merged #3856. emekankurumeh[m] your PR #2598 is finally unblocked. And now there are only 2 prerequisites left until var args can get deleted from zig
<jonathon>
Is it possible to point @cImport() at an arbitrary location, e.g. if I want to keep vendored libraries? Or, do I have to override the include search path?
<andrewrk>
that's an interesting use case. @cImport-local include paths, relative to the file that contains @cImport
<andrewrk>
currently your options are the CLI flags to zig which globally affect all @cImports
<fengb>
Oh boy, this release cycle has a million features
<andrewrk>
I was able to remove 3 builtins with that merge though :)
<jonathon>
andrewrk: OK, thank you! I wonder whether replicating something like the current @import() behaviour might work, e.g. @cImport("mosquitto") searches the system include path but @cImport("mosquitto.h") looks for a file relative to the importing file.
<jonathon>
.. if it's suitable for a feature request
<andrewrk>
@cImport takes an expression which can have branching logic in it
qbradley has quit [Remote host closed the connection]
<jonathon>
(Hang on, I might be looking at the wrong thing and confusing cImport and cInclude)
<fengb>
Oh I'm happy with these changes so far. I'm just surprised since the only 2 cycles I've followed didn't have this much activity
<fengb>
I couldn't get the output as small as I had hoped but this should be okay enough
<jonathon>
(That option does let me specify a path to a vendored library header, so I think that should work; I need to see if I can point exe.linkLibrary or exe.linkSystemLibrary to a local so file)
<fengb>
Those tests were a bit tricky. It depends on global state so those internal tests must run first. Behaviorally it shouldn't make a large difference, but that's where I caught my [256]u8 == [2]128 logic bug
<andrewrk>
need to teach llvm how to deal with our interface pattern, or pick a different interface pattern
<fengb>
Yeah, that's what zee_alloc has hacked together
<fengb>
The new WasmPageAllocator can theoretically free any manually fetched page so I could attach a separate deinit to zee_alloc
<fengb>
But I'm not quite sure what that'd look like
<fengb>
If WasmPageAllocator never did a shrink, most of the complicated code can theoretically just disappear
<andrewrk>
well either way, after I give this a PR sanity check, I think it's at least an improvement over status quo
<andrewrk>
nice work
<fengb>
Thanks
<fengb>
I'd like to enable wasi for CI next. Seems like we're getting close
<andrewrk>
that's a good goal
<fengb>
Last batch I actually got stuck because the wasm vm didn't support one of the syscalls we needed lol
<andrewrk>
shritesh mentioned the other day he might be interested to start the project of zig wasi interpreter using the std lib abstractions
<andrewrk>
I really think our std lib abstractions have done most of the work of a wasi interpreter
<fengb>
Yeah I've been thinking about doing that too
<andrewrk>
the wasmer guy (or was it wasmtime? I can't remember the difference) mentioned they don't support freebsd yet
<andrewrk>
this is all the same problem that we're already solving
<fengb>
So... I actually downloaded a C++ based wasm engine because the Rust ones had terrible memory performance (lol)
<andrewrk>
I'm pretty sure the part where it has to decode wasm instructions is like 1% of the task. the rest is cross platform OS abstractions
<andrewrk>
and IMO the goal if this was under the zig project umbrella would not be to JIT or go crazy with speed, but just to provide a simple, reliable (debuggable, even?) interpreter for running tests
<fengb>
The C++ one could call `memory.grow` much quicker so something is weird with the Rust implementation
WendigoJaeger has joined #zig
<gonz_>
I was about to ask "What's the best way to ensure via the types that a parameter is a string literal?"
<gonz_>
And then I remembered we literally have a keyword for exactly that type of thing. :D
<gonz_>
The mind is not always fast...
<jonathon>
Oh, my word, I can just add all the C files from the library I was linking against into build.zig and Zig will compile it all into the output executable. No need to link against a system library (or require it for deployment), I can just include the C sources directly into the Zig-compiled executable. That's __awesome__. (Now to look for a better way to add C files in build.zig than a long list of addCSourceFile()...)
<andrewrk>
jonathon, yes that is completely intended
<andrewrk>
I don't think I added any glob functions to build.zig yet
<andrewrk>
but you can put your long file list in another file and @import it if you want to keep things a bit cleaner
<gonz_>
Thanks, this is the second time I don't find it. Literally searching for "comptime allocator", I don't know what's going on.
<andrewrk>
it's all good. looking at it again, I do think we're actually kinda close to that working
<gonz_>
I wonder if I'm overestimating its usefulness. It seems like suddenly you could have access to all sorts of things for precompiling resources from files, etc.
<gonz_>
Or can we already process OBJ files at compiletime, for example?
<andrewrk>
inline for (@embedFile("foo.OBJ")) |byte| {}
<andrewrk>
the biggest blocker to any of that stuff is bugs
<andrewrk>
much of stage1 is at "proof of concept" quality. I'll be taking a much more disciplined approach to self-hosted
<gonz_>
I should try to work out what the limitations are currently. I guess it's likely that most of it's already covered in principle already.
<gonz_>
I was staring at some C preprocessor magic yesterday just marvelling at how insane it is that it's still a thing.
<gonz_>
My tolerance isn't exactly high, I guess, but all of that particular one is solvable with functions and filling in a struct manually.
<frmdstryr>
How do I make the exe work with `valgrind --tool=callgrind` ? It just shows "unknown" for the locations
<andrewrk>
frmdstryr, that should work - unless you pass --strip, zig builds binaries with debug info
Akuli has quit [Quit: Leaving]
<WendigoJaeger>
Hi, I'm doing a little experiment, I am wondering two things right now. First, is there a better to use enum as flags parameters without casting them ? And second is there a way to mark a function Always inline ? ref code: https://godbolt.org/z/Jcg8wr
<fengb>
Hmm, smells like an emulator 🙃
<gonz_>
WendigoJaeger: You can have a `packed struct` with members with size u1, then have a method on it to read it as an int.
<WendigoJaeger>
fengb: nope, making a GBA ROM directly
<andrewrk>
zig's enums don't really map to flags, I suggest to use unsigned integers, or if you want extra type safety, then yes, packed structs with u1 members. if you go the packed struct route, be aware of the following issues: https://github.com/ziglang/zig/issues/3802https://github.com/ziglang/zig/issues/3133 there are currently some bugs if your packed struct fields don't add up to bit count divisible by 8
<frmdstryr>
Still getting unknown with debug builds...
<andrewrk>
sorry, not u1 members, bool members
<andrewrk>
frmdstryr, maybe try a newer valgrind version
<andrewrk>
what version is that
<frmdstryr>
3.13.0
<andrewrk>
yeah that's pretty old. they recently fixed some things related to llvm/lld debug info generation
<frmdstryr>
Whatever 18.04 has
<gonz_>
andrewrk: As in you wouldn't recommend the u1 version?
<andrewrk>
frmdstryr, it's, perhaps surprisingly, a pretty straightforward project to build from source
<andrewrk>
gonz_, I would recommend whatever is the correct type. flags usually implies bools
<gonz_>
Yeah, fair point
<frmdstryr>
?
<frmdstryr>
oh valgrind
<frmdstryr>
any ideas why the streams slow down so much?
<andrewrk>
if align(0) proposal is accepted, best type for flags will be a struct with align(0) fields
<andrewrk>
frmdstryr, does the "llvm can't optimize our interface pattern" not explain everything?
<andrewrk>
genuine question
<frmdstryr>
Sort of, that still doesn't explain the drop from the readRaw to readBufferedReaderDirect though
<frmdstryr>
I'm almost thinking it's more something with the stack
<andrewrk>
interesting
<andrewrk>
could it be our memcpy implementation? have you tried building with -lc ?
<andrewrk>
there's -lc with musl ABI which is one implementation. -lc with gnu ABI which is glibc implementation. and finally no -lc is zig's implementation
* daurnimator
waves
<frmdstryr>
Using lc doesn't seem to make much of a difference
<daurnimator>
andrewrk: re: @call. can there not be e.g. a tailcall that is also a no-async call?
<daurnimator>
I thought that enum you have would be a struct....
qbradley has joined #zig
<frmdstryr>
valgrind 3.15 works, thanks!
WendigoJaeger has quit [Ping timeout: 276 seconds]
<daurnimator>
oh I got confused about the CallOptions vs Modifer. comment left.
<daurnimator>
andrewrk: so re: that getrusage PR.... I'm always afraid about relying on unreachable like that (for unknown errors): in release-fast mode couldn't that end up being undefined behaviour (nasal demons) if someone use e.g. using seccomp? shouldn't it be e.g. a @panic instead?
<fengb>
daurnimator: did you end up getting the job? :)