ChanServ changed the topic of #zig to: zig programming language | https://ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
_whitelogger has joined #zig
<pixelherodev> how much would break if I tried adding a target with an 8-bit usize?
<pixelherodev> :P{
<pixelherodev> On an unrelated note, all that's left for my LLVM parser to work with a basic Zig test is function parsing and the backend :)
<mq32> pixelherodev: what would be 8-bit usize?
<mq32> or better question: what is the zig definition of usize?
<pixelherodev> pointer size, right?
<pixelherodev> I'm contemplating adding a z80 backend to my parser :P
<mq32> well, z80 would have an 16 bit pointer size, but 8 bit register size
<mq32> whereas 8086 has 24 bit pointer size, but 16 bit register size
<mq32> so for a 8086, the following c types would be: sizeof(uintptr_t) >= 3, sizeof(size_t) == 2, sizeof(void*) == ??
<mq32> ah
<mq32> usize is defined as a uintptr_t equivalent
<mq32> so yeah, z80 has 16 bit usize ;)
<pixelherodev> The question is whether or not it would actually be remotely usable :P
<pixelherodev> The answer is "probably, but it wouldn't be worth it"
<mq32> yeah, true
<pixelherodev> Same way that you can compile C for z80, but it's horribly inefficient
<mq32> would still be cool to program games for TI calculators with zig :D
<pixelherodev> True, true
<pixelherodev> Just for that use case I'm going to do it.
<mq32> i think compiling for z80 is inefficient because of bad compilers
<pixelherodev> Not entirely
<mq32> z80 is not that much different from an 8088 :D
<mq32> hm, well :D
<pixelherodev> It's very hard to efficiently generate code for Z80
<pixelherodev> Not *impossible*
<pixelherodev> But very difficult
<mq32> yeah it's an architecture made for humans, not for compilers
<mq32> :D
<pixelherodev> Z80's alternate register sets are much much harder to use efficiently
<mq32> :D
<Pistahh> oh.. Z80. I haven't done any Z80 programming since 1994 :(
frmdstryr has joined #zig
return0e_ has joined #zig
return0e_ has quit [Remote host closed the connection]
return0e_ has joined #zig
dimenus has quit [Remote host closed the connection]
dimenus has joined #zig
frmdstryr has quit [Ping timeout: 268 seconds]
marmotini_ has joined #zig
marmotini_ has quit [Ping timeout: 240 seconds]
<Snektron> I havent done any living since 1998
<Snektron> Also, pixelherodev, you would basically have to make another llvm
<Snektron> There are some which target Z80 i think
<Snektron> I think there was some intent to add more code generation backends anyway
<Snektron> If thats in place you could pobably get it to work
<Snektron> But i think that requires some kind of stable IR
casaca has joined #zig
return0e_ has quit []
frmdstryr has joined #zig
casaca has quit [Ping timeout: 265 seconds]
casaca has joined #zig
jokoon has quit [Read error: Connection reset by peer]
casaca has quit [Ping timeout: 246 seconds]
waleee-cl has joined #zig
<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.
<fengb> But... my life would be nonexistent
<mq32> sparse tile map rendering written in zig
<mq32> using sparse quad tree
<Snektron> Very nice
<mq32> yeah
<mq32> the core implementation is also completly recursion-free
<mq32> tree query and insert is iterative
knebulae has joined #zig
frmdstryr has joined #zig
<mq32> it got pretty good *happy*
<gonz_> Hmm
<gonz_> Array literals; now you're supposed to use `&` to coerce them into slices?
ntgg has quit [Read error: Connection reset by peer]
casaca has quit [Ping timeout: 250 seconds]
casaca has joined #zig
qbradley has joined #zig
<gonz_> I see
wootehfoot has joined #zig
lunamn has joined #zig
mforney has quit [Ping timeout: 250 seconds]
<stratact> was there a build flag that allowed zig to check specific lib files for errors without having to add them to the test suite?
<lupine> > error: struct 'Entry' depends on itself
<lupine> I mean, I know, I'm trying to create a linked list :p
<lupine> ah, I see, pointer-to, d'oh
<stratact> I too, found my pebkac ;)
stratact has quit [Remote host closed the connection]
Akuli has joined #zig
lunamn_ has joined #zig
lunamn has quit [Ping timeout: 240 seconds]
wootehfoot has quit [Quit: Leaving]
lunamn_ has quit [Ping timeout: 250 seconds]
<fengb> At least it gives you an error :P. There was a recently logged bug that had the compiler take up infinite memory instead
wootehfoot has joined #zig
<lupine> hehe
<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
<andrewrk> jonathon, https://github.com/ziglang/zig/issues/2070 would require you to put #include <foo.h> or #include "foo.h"
<andrewrk> anyway, I do think it's worth proposing to allow @cImport-local include paths
<andrewrk> fengb, implementing result locations was brutal in terms of opportunity cost
<andrewrk> that was a long and dark tunnel
<jonathon> I think exe.addIncludeDir(".") (https://github.com/ziglang/zig/issues/2070#issuecomment-473403050) will probably already do the job... let me test
<andrewrk> oh your WasmPageAllocator is ready!
<andrewrk> nice use of 1 bit enums
<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> "Use '0xFFFFFFFF' as a _missing_ sentinel / This saves ~50 bytes compared to returning a nullable" -> https://github.com/ziglang/zig/issues/3806
<fengb> Yep I added a todo to follow up
<andrewrk> jonathon, there's exe.addLibPath
<andrewrk> if you're producing the .so in the build.zig, an even better option is exe.linkLibrary(the_lib)
<andrewrk> fengb, oh, if I only read 2 more lines down :)
<andrewrk> so would you want to use this as the backing allocator for WeeAllocator for FunDude?
<fengb> I tested it out and it's about ~1 kb larger than the dirt simple version I'm using
<fengb> I was hoping to get it even smaller but not sure what else to do
<fengb> But... maybe I'm overly concerned since 1 kb uncompressed isn't really too big in the grand scheme of things :P
<jonathon> andrewrk: ah, nice, thank you! more reading to do. :D
<fengb> Oh... just using it directly? I didn't think about that
<andrewrk> using it directly seems problematic, 64K for every allocation
<fengb> Working as intended™
<fengb> FunDude only makes like 3 allocations so it's not actually terrible
<andrewrk> ah good point
<fengb> +700 bytes though compared with master :(
<andrewrk> I suppose for your use case we could have NeverFreeingPageAllocator, with the trade-off being smaller binary size
<andrewrk> I also suspect that the cost we're paying in https://github.com/ziglang/zig/issues/3840 has the same root cause as the binary bloat here
<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
<andrewrk> ¯\_(ツ)_/¯
<andrewrk> those c compilations will all be cached too, so once you get past the first build the second one should be near instantaneous
<jonathon> whoa :O
<jonathon> Mine's only a paltry 32 lines :D
<andrewrk> I copy pasted these lines once and never had to deal with them again
<gonz_> Has there been progress (or did it even get finished, perhaps) on the comptime allocator idea?
<andrewrk> gonz_, nothing to report as far as I remember. the issue is https://github.com/ziglang/zig/issues/1291
<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
<WendigoJaeger> andrewrk: thanks!
<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/3802 https://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 tried putting an os.read there https://gist.github.com/frmdstryr/617710ab4eface00cc4681e85556e401#file-readtest-zig-L270 and it was stil half the readRaw speed
<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? :)