<andrewrk>
on the other hand if zig's fast development pace can solve the use cases before others and react to changes faster, that could give us a big advantage
<shritesh>
that's the plan
<andrewrk>
ruby was made popular by rails
<Xe>
i'm working on making the olin patch for zig support at the least all of the olin system calls zig needs
<Xe>
wonder if i can make it have better support than wasi
<andrewrk>
Xe, zig's lazy analysis should help with that. e.g. if you are only building hello world, then only write() and exit() are needed (plus the stuff depended on by default panic handler, if not overridden)
<shritesh>
I think zig also has a chance in mobile if we have a good cross-compilation story.
<Xe>
andrewrk: yeah, i just wanna be able to make HTTP calls from zig in webassembly
<Xe>
i have most of the stuff done for it
<Xe>
(my concept of file descriptors includes enough room for a HTTP client)
<andrewrk>
Xe, that invokes unchecked undefined behavior
<andrewrk>
the memory of `buf` belongs to the stack frame, and so when `get` returns the pointer to `buf` is invalid
<andrewrk>
I'd like to figure out how to safety-protect that, but haven't yet
<shritesh>
Off topic: I really appreciate how the for(i = 0; i < n; ++i) pattern in zig is a while loop instead and for loop is strictly for iteration. Tiny things like this make Zig so fun.
<andrewrk>
that's funny, I get a lot of the opposite sentiment about while/for
<hryx>
I absolutely love for and while in zig
<andrewrk>
people want all kinds of fancy syntax sugar for iteration
<shritesh>
range objects for iteration is overkill
<andrewrk>
wow, Xe, I fixed the bug with your test case, but it uncovered a deadlock race condition in LLD
<hryx>
honestly I think it's so much better without the sugar. simple & orthogonal tools, and it's not even that verbose at all
<Xe>
andrewrk: that's incredible
<hobomatic>
iteration is what has turned me off of rust
<hobomatic>
its just too much
<hobomatic>
the standard library is heaving with iterators and iterator transformers. No completion tools can even keep up with it.
<shritesh>
Iterator adapters are powerful but overused imo. I was following burntsushi's code (of ripgrep fame) during AoC2018 and I noticed he never uses any of those, just regular old mutable variables and for loops with manual indexing into stack allocated arrays
<andrewrk>
shritesh, a WASI interpreter in zig is going to be worth it for the test coverage alone that it brings to the wasm target
<andrewrk>
Xe, I'm getting the deadlock race condition in LLD about 1 / 6 times with your example. I'll open a new issue and report it to LLD too
<shritesh>
I agree. I'll work on it after like 2 weeks. Need to graduate college first lol
mnoronha_ has joined #zig
<Xe>
andrewrk: i'll follow the bug tracker
hobomatic has quit [Ping timeout: 256 seconds]
<andrewrk>
alright we'll just pass --no-threads until LLD fixes their shit
hobo has joined #zig
<shritesh>
Noob question: Are 0 sized slices a thing?
<andrewrk>
yes
<andrewrk>
also 0 sized arrays
<shritesh>
I have a pointer that i need to convert to an u8 slice of len 0. I'm getting an error: slice of single-item pointer
<shritesh>
@intToPtr(u8, @intCast(usize, mem_size(0)) * WASM_PAGE_SIZE)[0..0] is probably not the best way to do things :D
<hryx>
progress report on recursive stage2 parser: +1,824 lines, 131 instances of // TODO, 66 instances of `return error.NotImplemented`
<andrewrk>
hryx, it's a massive endeavor
<andrewrk>
shritesh, what's the original source of information?
<hryx>
sure is! but it's going pretty well so far I'd say
<andrewrk>
calling a wasi function?
<shritesh>
Yes. It returns a number of pages (mem_size(0)
<andrewrk>
why is the @intCast to usize needed?
<shritesh>
mem_size(0) returns an i32
<shritesh>
It's the current page number
<andrewrk>
what does negative mean?
<shritesh>
WASM only has {i,f}{32,64}
<shritesh>
It can never be negative
<andrewrk>
hmm. I think you can make it `u32` then because i32 and u32 are guaranteed to have the same bit pattern in the C ABI
<andrewrk>
and then that cast isn't needed
<shritesh>
okay. but how to I instantiate a zero slice?
<Xe>
shritesh: wait, what wasi functions operate on the memory info?
<andrewrk>
I would do the multiplication by page size first, and then choose the pointer type [*]u8 rather than *u8 as the @intToPtr result type
<andrewrk>
shritesh, also don't forget to update std.os.page_size for wasm!
<shritesh>
Xe: @"llvm.wasm.memory.size.i32" and @"llvm.wasm.memory.grow.i32"
<andrewrk>
I hope our comptime-ness of that decl isn't violated?
<shritesh>
This is not even WASI, this is WASM. WASM the architecture itself has malloc
<Xe>
ah okay
<andrewrk>
well more like sbrk
<shritesh>
Yes :D
<andrewrk>
shritesh, I continue to be impressed with your ability to find specifications for wasm, my searches keep leading me in circles
<Xe>
shritesh: can you do us all a favor and make a webpage centralizing all your links?
<Xe>
please and thank you
<shritesh>
Most of it came from reading the commits in rustc that added wasm support.
<shritesh>
But yeah, I will
<andrewrk>
hmm I didn't find WASM_PAGE_SIZE. where does that come from?
<andrewrk>
it's important whether or not that is a hard coded constant or not
<shritesh>
Its fixed 64 KB
<shritesh>
Background info: WASM has fixed linear memory that starts at 0. The memory can only grow. "realloc" isn't even a thing. Growing might return an error but that's it. Growing usually returns the last page size and you multiply by the page size to get effective address of your new memory.
<shritesh>
Growing returns the last page number*
keveman has joined #zig
mnoronha_ has quit [Ping timeout: 264 seconds]
<shritesh>
So WasmAllocator is technically a FixedBufferAllocator that calls the grow intrinsic when needed
<andrewrk>
ok I updated std.os.page_size
mnoronha_ has joined #zig
<andrewrk>
that's ok for a first pass - we're going to probably have to back that with a general purpose allocator so that free() can work
<shritesh>
I'm trying to wrap my head around alignment. I've never dealt with it before
keveman has quit [Ping timeout: 256 seconds]
<shritesh>
Also what do you think of #2273?
<andrewrk>
it took me a while to grok alignment too. I can fast-forward the learning process if you want, feel free to ask any questions about it
<shritesh>
Umm wait. I think what I'm trying to do won't work
<shritesh>
the allocator assumes that it owns the full linear memory
<shritesh>
But it may not. There might be multiple instances of WasmAllocators
<shritesh>
or some code somewhere else might have grown
<shritesh>
So, I think the easiest cop-out would be for WasmAllocator to take in number of pages during init and create a buffer and hand everything else to FixedBufferAllocator
<andrewrk>
what I think this will look like once the dust settles is: when linking libc: problem solved, std.heap.c_allocator is the "direct allocator" as well as the "global system allocator"
<andrewrk>
when not linking libc, nothing overridden in root source file: zig will have a general purpose allocator. an instance is created to be the "global system allocator" and has sole ownership of wasm grow/shrink functions. DirectAllocator on wasm targets will use this system global allocator
<andrewrk>
root source files will be able to override this and specify their own allocator as the "global system allocator"
<shritesh>
makes sense
<andrewrk>
side note - my work in progress general purpose allocator actually doesn't solve the problem of transforming a grow/shrink (sbrk) API into a malloc/free API, so that's another problem to solve
<andrewrk>
this would actually be pretty interesting as well because you could also use it to create an allocator based on a buffer much like FixedBufferAllocator but that actually managed free space and reused bytes
<shritesh>
But we'll have to deal with fragmentation and such right?
<andrewrk>
right
<andrewrk>
it may be that a general purpose allocator based on grow/shrink API would have a completely different implementation
<shritesh>
I need to double check if the execution environment can grow/shrink the memory in wasm. If it cannot, things might get easier.
mnoronha_ has quit [Ping timeout: 240 seconds]
<andrewrk>
it seems pretty likely that that will be possible, if not now, then in the future
<andrewrk>
it's just an obvious thing that people will ask for
<shritesh>
So I'm conflicted about the WasmAllocator. Should this even go to std?
<shritesh>
A better API would be to expose wasm.grow that returns a buffer that can be used explicity with FixedBufferAllocator
<andrewrk>
I think we should do something that is the most compatible with the "when the dust settles" thing that I described above, and then work our way towards it
<andrewrk>
I don't think wasm.grow that returns a buffer to be used with FixedBufferAllocator would necessarily be a better API. it doesn't support free()
<shritesh>
That's true. Should I name this FixedWasmAllocator?
<shritesh>
So that in case we remove it later, things don't break silently
<shritesh>
or WasmFixedAllocator
<andrewrk>
I would make all the state global variables rather than giving it a type, and then expose a pointer as `std.heap.wasm_allocator`
<andrewrk>
it's a singleton
<shritesh>
so much like c_allocator
<andrewrk>
the meaning of this declaration is: this is the global system allocator when targeting web assembly
<andrewrk>
in fact when linking libc, std.heap.c_allocator == std.heap.wasm_allocator
<andrewrk>
because presumably the libc is doing wasm.grow/wasm.shrink in the implementation of malloc/free
<andrewrk>
until some improvements are made, std.heap.wasm_allocator.free() actually doesn't give back memory. but you're supposed to free stuff according to the API
<andrewrk>
so that would start working at some future date
<andrewrk>
DirectAllocator would either: compile error on web assembly targets, or use std.heap.wasm_allocator. I'm not sure which is better
<andrewrk>
we'll need to clarify the semantic meaning of choosing std.heap.DirectAllocator in order to resolve that question
<andrewrk>
also, everywhere that you do some semantics that assumes single-threaded (a valid assumption for wasm currently) don't forget to put `comptime assert(builtin.single_threaded);`
<andrewrk>
so that if it ever changed someone would get a compile error, and you would have written a nice comment explaining why the nearby code depends on --single-threaded, saving countless hours of some future person's time
<shritesh>
I will keep that in mind
<andrewrk>
I'll tackle an allocator based on sbrk/ grow/shrink after my other GeneralPurposeAllocator project, it should be fun :)
<shritesh>
PR in
mnoronha_ has joined #zig
<shritesh>
Going with the global allocator idea, will it be undefined behavior if someone else does "llvm.wasm.memory.grow.i32"?
keveman has joined #zig
<keveman>
Hello,
<keveman>
Hello, I am attempting to compile Zig for a custom ISA.. I have LLVM built for it..
<andrewrk>
shritesh, I think that will be your choice, which you can document with your implementation. since wasm is single threaded, you theoretically could check mem size and find out the "holes" that were created by third parties. but that's pretty strange, I personally would document it as undefined behavior if any third party did that
<andrewrk>
shritesh, probably in debug/release-safe modes there would be some check to at least panic if it were detected
<andrewrk>
hi keveman
<keveman>
I am don't want to target any other backends.. but the cmake/Findllvm.cmake seems not to allow me to do that
<andrewrk>
that's correct. upstream zig is guaranteed to have all the targets in it. however you are free to fork zig and remove this guarantee. it is as simple as commenting out some cmake lines
<andrewrk>
look for NEED_TARGET
<keveman>
Hi Andrew, right.. yes, that's what I am attempting..
<keveman>
I have the llvm-config in the `build-llvm` directory.. build-llvm/bin/llvm-config.. this is the directory where I ran cmake for llvm..
<shritesh>
andrewrk: Alright. I'll modify my PR to make it global, allow dynamic growing and document the undefined behavior
<andrewrk>
shritesh, alright I will look at your PR first thing tomorrow, I need to focus on my talk for the next couple hours
<shritesh>
Thanks. Good luck
<keveman>
If I set LLVM_CONFIG_EXE to build-llvm/bin/llvm-config, the compilation is not able to find llvm/Config/llvm-config.h..
<keveman>
so I was wondering if there is a special way to install LLVM (with the custom backend) such that I can point LLVM_CONFIG_EXE to the llvm-config in the install directory instead of the build directory..
<andrewrk>
keveman, I recommend using the CMAKE_INSTALL_PREFIX feature when building LLVM/clang and the CMAKE_PREFIX_PATH feature when building Zig to detect llvm/clang
<tyler569>
is there a way to cInclude a header in my source directory? @cInclude seems to only want to do system headers with <path.h>
<tyler569>
specifically, I'm trying to compile freestanding but include other headers in the same project to create a .o file and link it in
<hryx>
tyler569: yes, @cInclude any .h should definitely be possible (though I probably can't help troubleshoot with my current experience)
<hryx>
is your header file path is relative to your root .zig file?
<tyler569>
doesn't seem to be working though, I get a note about libc headers not being available, even if I @cInclude("./path.h")
<tyler569>
yes
<hryx>
I see
<tyler569>
oh header file path, let me check that
<hryx>
by the way, I think you don't need the ./ prefix to relative paths for built-in functions
<hryx>
not sure if they are even allowed, actually. I've never checked
<tyler569>
good call, adding '-isystem .' caused it to find the file
<hryx>
oh, awesome!
sanxiyn has joined #zig
<tyler569>
though it's still doing weird things, seems to be defining __STDC_HOSTED__ in a freestanding build with no libc. That feels more like bug report territory though, and I can comment out the check for now
<hryx>
ok. I'm not sure who here has experience with freestanding, but Andrew (zig author) will be available here probably tomorrow
<hryx>
and can help with that
<tyler569>
ok, awesome
shritesh has quit [Read error: Connection reset by peer]
<tyler569>
works though! I got my kernel to print Hello from zig!
<tyler569>
just pushed to the 'zig-support' branch ^.^
<hryx>
wow, very exciting! BTW I am also in SF if you are ever around for a meetup/zig chat. (you can DM me if so)
jjido has joined #zig
<tyler569>
totally! (dm'd)
cbarrett has joined #zig
<daurnimator>
I'm in SF every couple of months, so let me know when you plan on a zig meetup there :)
<hryx>
daurnimator: definitely hit me up when you're in town. I have a great spot for co-working and hacking! :>
<hryx>
what part of the world are you in usually?
<daurnimator>
melbourne, australia
<daurnimator>
today I'm in south africa.... flying home in a few hours
<sanxiyn>
Hello from Seoul, South Korea
<hryx>
damn we got friendos all over this globe
<hryx>
greetings sanxiyn
<sanxiyn>
Melbourne is roughly in the same time zone with Seoul (1 hour difference), so that's great
<sanxiyn>
Usually nobody is in the nearby time zone...
ManDeJan has joined #zig
jzelinskie has quit [Ping timeout: 240 seconds]
hobo has quit [Ping timeout: 256 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jzelinskie has joined #zig
sanxiyn has quit [Quit: Leaving]
marmotini_ has joined #zig
ltriant has quit [Quit: leaving]
mnoronha_ has joined #zig
mnoronha_ has quit [Ping timeout: 246 seconds]
<telemach>
huh, i'm in sydney, australia, hi timezone fellows
<hryx>
👋
<hryx>
(not me per se)
very-mediocre has joined #zig
hio has joined #zig
mnoronha_ has joined #zig
mnoronha_ has quit [Ping timeout: 252 seconds]
mnoronha_ has joined #zig
mnoronha_ has quit [Ping timeout: 250 seconds]
_whitelogger has joined #zig
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 252 seconds]
very-mediocre has quit [Ping timeout: 256 seconds]
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 246 seconds]
<Xe>
daurnimator: I have now
mnoronha_ has joined #zig
<shritesh>
andrewrk: After seeing https://twitter.com/KevinHoffman/status/1117452687392563200 , I think Zig maybe be able to do what wasm-bindgen does, but even better, if we can generate a .js header file much like how we generate a .h file for build-lib
mnoronha_ has quit [Ping timeout: 255 seconds]
mnoronha_ has joined #zig
mnoronha_ has quit [Ping timeout: 246 seconds]
<bketelsen>
shritesh: hello - good timing, I joined yesterday
<bketelsen>
it's been a *hot minute* since I've used IRC though
<shritesh>
It's literally my first time
<shritesh>
First of all welcome, bketelsen
<bketelsen>
thank you!
<shritesh>
You said you had ideas for a zig/wasm bridge. Can you tell me more?
<bketelsen>
i have several loosely organized thoughts. I'll freeform them, if that's ok.
<shritesh>
Sure!
<bketelsen>
wasm_bindgen in Rust is a really nice experience. A few annotations and you get generated JS and rewritten rust functions.
<bketelsen>
That experience uses macros.
<bketelsen>
in contrast, Go's wasm support uses a lot of compiler hacks/tricks. For example returning a string in Go actually returns a stack pointer, where there are variables that include the address of the string, the length, etc.
<bketelsen>
I think the Rust route is nicer for everyone because it's got less magic, and has more potential to evolve as the wasm spec does, especially when host bindings to the DOM appear.
<bketelsen>
zig needs two things to succeed on client-side/web wasm: an easy to use bridge between js/wasm, and a dom library callable from zig code
<bketelsen>
for the bridge, I tried exploring compile-time programming, but really couldn't find enough information to understand what I needed to do.
<bketelsen>
It sounds from your message above to andrew that this is something that's well within the realm of possibility though.
<bketelsen>
once the bridge is in place, creating an idiomatic dom library shouldn't be complicated.
<shritesh>
re: Go and strings: Zig doesn't have "strings" per se, they're just u8 arrays. So I don't think that could be made better (maybe more stdlib functions) but Zig is still in it's early stazes.
<bketelsen>
one thing we should target with bridge is helping with retrieving "strings"
<bketelsen>
I can return a []u8, but unless it
<shritesh>
Ah
<bketelsen>
is null terminated, it's hard to retrieve it from JS.
<bketelsen>
so I was using c-strings, which works but looks ugly
<shritesh>
I agree.
<shritesh>
The js-header file will definitely help with that
<bketelsen>
and I don't know zig well enough to figure out a different way.
<shritesh>
Gotcha. Maybe we can overload the `export` keyword to be wasm aware and work with slices.
<shritesh>
Again, I'm just thinking out loud here. :D
<bketelsen>
I read an interesting article last night that showed how to rewrite WASM AST to support multiple return values. They rewrote the WASM AST programmatically to make return values globals
<bketelsen>
and as I was drifting to sleep i had the idea that something like that might work, where there was a global lookup table of pointers and lengths for "strings"
<bketelsen>
but I'm afraid of the concurrency problems it might create
<bketelsen>
another option, more complicated, but easier for programmers in the long-run: create a set of one or more structs/types that work over the bridge
<bketelsen>
return pointers to them, and teach the JS side how to read the memory to hydrate them.
<bketelsen>
the experience with zig + wasm has been simply amazing. It compiles so quickly and makes such tiny wasm binaries.
<shritesh>
Yes. We also need to think about how to accomodate non-web embeddings, WASI (and other runtimes) that do not follow JS's semantics
<bketelsen>
I'm over the moon excited to take this somewhere fun.
<shritesh>
That's what I love about Zig. It's such a joy to use.
<bketelsen>
I'm less worried about wasi because there's an abi to follow
<bketelsen>
wasm is sort of "everyone for themselves". So the idea that we create a specification for communicating between zig/wasm and js, then generate code on both sides to meet that spec is appealing.
<shritesh>
P.S. We are planning on having a WASM/WASI interpreter in the stdlib so that we can run tests inside webassembly without leaving Zig
<bketelsen>
wow
<bketelsen>
i'm in <3
<shritesh>
^_^
<bketelsen>
can you describe the process you talked about above with .h files?
<bketelsen>
generating code at compile-time?
<shritesh>
So zig has amazing interop with C
<shritesh>
And can generate .h files that lets C (or any C ABI compatible language) to use Zig libraries
<shritesh>
It's a step in the compiler's code generation phase
<shritesh>
We should be able to generate .js files the same way as the information is already there
<shritesh>
Stage 2 compiler is being written in Zig. This is just so that we can bootstrap.
<bketelsen>
I understand, I've just never done c++
<bketelsen>
but I'm not afraid.
<bketelsen>
much
<shritesh>
!!!
<shritesh>
But going back to the idea of autogenerating string interfaces, I think the first step would be figuring out how slices can be "returned" across JS<->Zig
<bketelsen>
can the compiler make new code that is included in the current build?
<shritesh>
The executable?
<bketelsen>
yes
<shritesh>
What would that new code be?
<bheads____>
Something like D's mixins? Where you build a string in comptime then compile that code
<bketelsen>
stubs that the JS library calls
<bketelsen>
if we have a func that returns []u8, we could generate a stub function that makes the JS interop easier.
<shritesh>
We do have powerful compile time code execution (and that's how generics and printf are implemented). We can probably do something similar
<shritesh>
We can always add more builtins to the compiler tho
<Xe>
the lack of reusing freed memory kind of worries me though
<bheads____>
not packed struct
<shritesh>
andrewrk talked about this on the channel last night. We'll have a global allocator that uses wasm_allocator as backing allocator and would do that
<shritesh>
general allocator*
<Xe>
ah
<Xe>
:+1: would like to play with it
<bheads____>
Are you trying to build a GWT like system in zig?
<shritesh>
Who was this question for? :D
<bheads____>
the WASM crew
<shritesh>
Not necessarily, we've still much to do before we can ergonomically interact with the DOM. I'll work on the stdlib next
<Xe>
i'm actually doing server side webassembly compute
<tgschultz>
wiat, why is this cstring struct necessary? it is identical to the slice struct.
<bheads____>
you cant return a slice in C
mnoronha_ has joined #zig
desperek has joined #zig
<desperek>
hi. basically, is there some sort of networking library?
<desperek>
i know theres std/net.zig but thats just parsing ip
<bheads____>
not in the stdlib right now
<bheads____>
zig is in alpha
<bheads____>
one of the goals for the next release is the zig package manager which requires client side http
<shritesh>
bketelsen: I'll play around with this and try to improve the interop and the deverloper experience. I'll keep you posted with updates. Again, welcome to the community!
<desperek>
right
<bketelsen>
thanks!
<desperek>
bheads____, but well, https is built on top of other networking, no?
<bheads____>
on tcp
<bheads____>
I am guessing basic udp will be added as well
<desperek>
bheads____, so is there tcp
<bheads____>
Not sure, might only have sockets right now
<shritesh>
Xe: Also, now that I think about it. In my PR, the extern import might never be imported until it gets referenced. Lazy semantics and all.
<Xe>
shritesh: i'm partially thinking about it because i'm used to unused imports being compile failures, but if it's really not a problem then it's all good
<shritesh>
I have also deliberately not aliased it to a local name so that we don't forget about coming up with a solution to the intrinsics problem :D
marmotini has quit [Remote host closed the connection]
halosghost has joined #zig
<shritesh>
Xe: That's awesome. What does wasm_exec.js provide?
<Xe>
shritesh: the ABI that olin uses, the same binary also works with olin's `cwa` interpreter
<shritesh>
I think Zig can accomodate wasm32-olin ;)
<Xe>
oh don't worry, i'm working on a PR
<Xe>
i'm just making sure it's feature complete first
<shritesh>
Ooooh!!!
ysgard has joined #zig
ysgard has left #zig [#zig]
ysgard has joined #zig
<Xe>
i'm working on the runtime metadata stuff now (env, args, etc), the allocator stuff is gonna help unblock it
<shritesh>
I'm glad. Can a WASI runtime (theoretically) be able to run odin binaries? Maybe under a shim or something
<bketelsen>
@shritesh: the wasm_exec.js in Go provides the common ABI for the js/wasm interop
<Xe>
yeah, it's designed to be pretty unixy and is similar to the wasi system calls by coincidence, i might clone their idea of copying the env into the child process though (olin's getenv works like getenv() in C)
<Xe>
bketelsen: i have a hacked version of the tinygo hacked version for that page
<andrewrk>
one thing that I don't understand how it would work is the filesystem. zig depends on a file system, how would that work in the browser?
bketelsen has joined #zig
<shritesh_>
Emscripten solved the FS problem a very long time ago
<shritesh_>
There's an API too now
<hio>
HTML5 even has a filesystem api but that's not what emscripten uses
<hio>
afaik
Zaab1t has joined #zig
<andrewrk>
so would you link with libemscripten or something to make that work?
<shritesh_>
emscripten has a POSIX filesystem layer somewhere
<shritesh_>
*implements a
keveman has joined #zig
Akuli has quit [Ping timeout: 264 seconds]
mnoronha_ has joined #zig
mnoronha_ has quit [Ping timeout: 255 seconds]
<shritesh_>
andrewrk: Opinions on providing a .js header file to be used with wasm?
<andrewrk>
can you elaborate? my head is in a different space right now
Akuli has joined #zig
<shritesh_>
Sorry. Like how we provide a .h for easy interop with C. We can provide a .js so that slices (strings, objects?, json?) are easily inter-op'd from the JS side
<shritesh_>
..and memory, imports, etc are handled
<shritesh_>
It's something Rust, Go, and possibly others do. But I'm hoping we can do that without changing the semantics of Zig itself and pushing the ffi outwards to this file instead
Zaab1t has quit [Ping timeout: 245 seconds]
<andrewrk>
I see. that's not an easy design question
<andrewrk>
it's the kind of thing I would want to put off solving until the use cases for it become clearer
<shritesh_>
I agree. I prefer not to have JS types bleeding into Zig.
<shritesh_>
I'm working on getting Zig's formatter working on the browser. Will report the experience of passing strings across dynamic memory
<andrewrk>
that's a great wasm project idea
<shritesh_>
once #2286 is merged ;)
<bketelsen>
I'm strongly in favor of it shritesh_, if it's not obvious. I also recognize that my vote is small :)
Ichorio has joined #zig
<shritesh_>
I also figured it's hard to come up with a solution that works for all use cases. We don't have a global allocator (yet) and will never have GC. JS can grow / access memory anytime and that'll break the invariants of the (primitive) WasmAllocator. Strings are hard. Let's see where this formatter project ends up.
<daurnimator>
Xe: any thoughts?
gunnarahlberg has joined #zig
bketelsen has quit [Remote host closed the connection]
<Sahnvour>
andrewrk, how should errors be handled in an allocator's `shrink` implementation ?
<Xe>
daurnimator: COM and other forms of RPC may have some hints, i'm treating file descriptors kinda like generic streams in olin. One of the stream types is HTTP.
<andrewrk>
Sahnvour, what kind of errors? according to the interface, shrink must not fail
<Sahnvour>
yep, I'm talking internal errors
<andrewrk>
not allowed, you have to design that to be impossible
<Sahnvour>
for example posix.munmap fails
<andrewrk>
I don't think that's actually possible
<Sahnvour>
man says `Upon successful completion, munmap() shall return 0; otherwise, it shall return -1 and set errno to indicate the error.`
<Sahnvour>
I'm actually looking at a windows API, but this is equivalent
<andrewrk>
what error do you think is possible for munmap or windows free API to return?
<andrewrk>
note that e.g. EINVAL/EBADF doesn't count; that's invalid parameters sent to the syscall, which we can assert will not happen
<Sahnvour>
I don't know really, just wondering since that is listed in the manual
<andrewrk>
in zig std lib we assert that munmap does not fail
<Sahnvour>
well, looking at DirectAllocator code, we do not check the return value
<Sahnvour>
wait, we do, but only in alloc (not shrink)
<andrewrk>
I really think it's a bug in linux/windows if munmap/HeapFree returns an error (other than for invalid parameters)
<Sahnvour>
right, so here's a PR
<andrewrk>
ah, my mistake, I expected HeapRealloc to free memory when dwBytes is 0
<Sahnvour>
no problem, that's a lot to keep in mind
<andrewrk>
shritesh_, ready for merge?
<shritesh_>
andrewrk: Aye aye captain!
meheleventyone has joined #zig
<keveman>
I am attempting to target zig for a custom LLVM backend.. I was able to get everything compiled.. it was relatively painless :)
<andrewrk>
nice keveman
<keveman>
I am trying to compile a relatively simple program :
<keveman>
var x: i16; pub fn main() void { x = 42; }
ManDeJan has joined #zig
<tgschultz>
andrewrk, why can't slices be in a packed struct?
<keveman>
I get errors like : "else => @compileError("Unsupported OS"),'
<andrewrk>
tgschultz, currently slices do not have a guaranteed in memory representation
<tgschultz>
ah, ok
<andrewrk>
I think there may be a proposal for that though
<keveman>
is there a way to not compile in the std library..
mnoronha_ has joined #zig
<andrewrk>
keveman, what is your target?
<keveman>
A custom LLVM target (not upstreamed yet).. it looks like a microcontroller..
<andrewrk>
what file/ line number is that error in
<andrewrk>
keveman, that looks like it's either in abort() or exit(). if you're using `pub fn main` then you're relying on the code in std/special/bootstrap.zig which is going to call exit()
<andrewrk>
I suggest that you directly `export fn foo() void {}` where `foo` is your entry function that the micro controller expects
mnoronha_ has quit [Ping timeout: 246 seconds]
<keveman>
This is the program I am trying to compile now : `export fn foo() void {}`, with command `zig build-obj main.zig -target <redacted>`
<keveman>
I still get the same error: `build/lib/zig/std/os.zig:205:17: error: Unsupported OS`
Zaab1t has joined #zig
TheLemonMan has joined #zig
<andrewrk>
keveman, did you perhaps use the posix/windows default panic handler rather than the freestanding one?
<andrewrk>
look at std/special/panic.zig
<andrewrk>
you can override this on a per-application basis by defining pub fn panic, or you can modify the default in your fork of zig
shritesh_ has quit [Quit: Segmentation Fault]
<andrewrk>
if you put pub fn panic next to your export fn foo, you'll override the panic function in this object only, or you can change std/special/panic.zig (and don't forget to make install)
<TheLemonMan>
hello andrewrk, do you have a minute to talk about unwinders & stack traces?
<andrewrk>
hi TheLemonMan
<andrewrk>
yes - by the way nice work on your pull request
bheads____ has joined #zig
bheads_____ has quit [Ping timeout: 268 seconds]
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<TheLemonMan>
speaking of that, I've integrated libunwind since it was readily available but I don't know if you're ok with having such an external dependency considering you're already parsing the DWARF sections by hand
Zaab1t has quit [Quit: bye bye friends]
<andrewrk>
I do want to look into it a little bit, at least reading all the code of the libunwind code
<TheLemonMan>
a pure-Zig solution is of course feasible (got a WIP that's working just fine on x86_64) but I figured it'd be quite burdensome to support and fix it for different OS/platforms, at least at this point in time
<andrewrk>
if it calls malloc for example, that would be a problem
<andrewrk>
for some targets zig provides its own libunwind code, but on others, this would be making a dynamic library call to code that could have anything in it
<andrewrk>
that's worth considering. if it's a pure zig solution, we can be sure that we know the code that is being run
<andrewrk>
and we could do neat tricks such as still being able to print a stack trace on a stack overflow, even though the stack space has run out
<TheLemonMan>
cool, I'll try to iron out the remaining kinks in the next few days then
<andrewrk>
also the things you're allowed to do inside a signal handler such as SIGSEGV is limited; easier to avoid problems if we control all the code, for e.g. https://github.com/ziglang/zig/issues/1796
<andrewrk>
so that's why I didn't just merge your PR right away
<andrewrk>
despite the clear utility of stack traces working in release modes
<TheLemonMan>
nm, I love the fact you don't just blindly merge stuff heh
keveman has quit [Ping timeout: 256 seconds]
<andrewrk>
so far all of zig fits in my head. maybe someday that won't be the case. or maybe it will!
<TheLemonMan>
one more question, I need dl_iterate_phdr but that's 1) coming from libc 2) a glibc-ism/linux-ism (but widely supported)... can I just add a wrapper to os.zig and call it a day?
<TheLemonMan>
re-implementing it avoids libc but may turn out to be a pita (especially wrt portability)
<andrewrk>
this is a missing feature, started in std/dynamic_library.zig but not very far along. how it's going to work is the same way as the pattern set by abort(), that is - if linking libc, use the libc functions, otherwise zig provides its own implementation
<andrewrk>
for your particular use case right now, does it link against libc?
wilsonk has quit [Ping timeout: 246 seconds]
<andrewrk>
if so then I recommend, for now, adding the dl functions to std/c.zig and calling them directly
<TheLemonMan>
nope, but I guess that's fine as a starting point
<andrewrk>
ah. yeah, then unfortunately it's a missing feature that is blocking you
<tyler569>
You're too efficient Andrew, I was going to try my hand at fixing the ffreestanding bug I reported :P
<tyler569>
thanks for the quick responce though
<andrewrk>
:) you're welcome
gunnarahlberg has quit [Ping timeout: 256 seconds]
<andrewrk>
alright I gotta close IRC and get some more of my talk done
mnoronha_ has joined #zig
jjido has joined #zig
hobo has joined #zig
<hobo>
yeah andrew is a beast :P
bketelsen has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
Akuli has quit [Quit: Leaving]
mnoronha_ has quit [Ping timeout: 255 seconds]
shritesh has joined #zig
mnoronha_ has joined #zig
bketelsen has quit [Quit: Leaving]
shritesh has quit [Quit: Segmentation Fault]
hio has quit [Quit: Connection closed for inactivity]
shritesh has joined #zig
desperek has quit [Quit: mew wew]
<shritesh>
I think I've figured out how the Js<->Wasm interop can work. Zig's global allocator will own the memory and JS will alloc and free by calling exposed functions. It's undefined behavior if the embedding environment manually manipulates the memory. I'm still leaning towards POSIX style fn(ptr, len) convention for slices and keeping Zig JS-convention free. Most of the ergonomics will be provided by the helper js.
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<shritesh>
Will be posting a WIP of what I'm talking about (hopefully) in the next day or two.
mnoronha_ has quit [Ping timeout: 255 seconds]
keveman has joined #zig
<keveman>
andrewrk, sorry I was afk. But thanks for the suggestion.. I was able to make some progress. I place an implementation of panic in the same source file..
<keveman>
But now I get this error: `build/test/main.zig:4:82: error: expected type 'noreturn', found 'void'` which is strange, because I clearly have noreturn
<keveman>
ah, never mind.. the error is because of type inference thinking the return type should be void..
mnoronha_ has joined #zig
mnoronha_ has quit [Ping timeout: 244 seconds]
<Xe>
ls
<Xe>
oops
SimonNa has quit [Remote host closed the connection]
hobo_ has joined #zig
hobo has quit [Ping timeout: 256 seconds]
wootehfoot has joined #zig
hobo_ has quit [Ping timeout: 256 seconds]
<andrewrk>
oh my god, I can't believe this works
<andrewrk>
exciting PR incoming
<andrewrk>
keveman, your function isn't allowed to return, but it is returning. put while(true){} in there
<hryx>
on the edge of my seat
scientes has joined #zig
redj has quit [Read error: Connection reset by peer]
wootehfoot has quit [Read error: Connection reset by peer]
<hryx>
the implications have not sunken in for me ....... yet
<bheads____>
libcompiler.a is llvm and clang?
<bheads____>
libuserland.a is the cpp zig compiler code?
halosghost has quit [Quit: WeeChat 2.4]
<bheads____>
or is userland stdlib in that case?
<andrewrk>
Cmakelists.txt has the answers to these questions
<keveman>
I have zig connected to the custom backend.. it's working wonderfully! I am especially liking what I see with packed structs containing bitfields..
<andrewrk>
keveman: good to hear that
<shritesh>
This is so cool
<hryx>
does this mean stage1 will be able to do anything stage2 can do?
<Sahnvour>
this is really nice
<andrewrk>
hryx, Yes, as long as the implementation in stage2 doesn't depend on it
<andrewrk>
E.g. we can do translate-c in userland because the translate-c implementation does not use @cImport
<hryx>
neat!
<andrewrk>
It also means we can use the zig std lib for stuff... So instead of assertion failed we could start getting stack traces
jjido has joined #zig
<andrewrk>
It also has implications for generating documentation
<andrewrk>
The results of the semantic analysis are in c++ but userland code could do the processing and HTML generation
<hryx>
oh shoot, you're right! Very relevant to my interests (after the parser rewrite is done)
<andrewrk>
Anyway, it's a nice step towards self hosting
<andrewrk>
Which hopefully can save a lot of duplicate effort
bketelsen has joined #zig
wilsonk|2 has joined #zig
<andrewrk>
wow. if this PR passes all the CI tests first try, I'm going to go find a microphone and drop it
<andrewrk>
I didn't test on mac windows or freebsd before pushing
<shritesh>
FreeBSD passed :D
<Sahnvour>
live dangerously: skip CI, and drop the mic once it works on users' boxes!
<Sahnvour>
this also implies that we might start optimizing stage1 too, after all
<shritesh>
I'm working on the poster
<shritesh>
Installing PowerPoint first lol
<shritesh>
Whoops wrong chat
<mikdusan>
if i had a nickel…
ManDeJan has quit [Ping timeout: 268 seconds]
<Sahnvour>
andrewrk, do you have some time now to look at an issue that may be a bit complicated ?
<andrewrk>
I'm sorry I actually do not. I have to get my run in at the gym and then I have a social thing this evening, and then I really really need to focus on my talk. tomorrow?
Ichorio has quit [Ping timeout: 255 seconds]
<shritesh>
andrewrk: Tests passed on my mac (and felt faster too?)
<Sahnvour>
sure, no problem
<bwb_>
andrewrk: I'm missing something. what does "userland" mean in a compiler context?
shritesh has quit [Quit: Segmentation Fault]
keveman has quit [Ping timeout: 256 seconds]
Sahnvour has quit [Read error: Connection reset by peer]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
keveman has joined #zig
<keveman>
Just curious, is there a way to implement compile time "counter" using `comptime`? Something like a function counter() that returns increasing integers every time it is called..
<hryx>
keveman: a closure? or just using global state?
keveman has quit [Ping timeout: 256 seconds]
keveman has joined #zig
<keveman>
Oh, there is more than one way ? :)
<keveman>
Either one I guess, just want to see an example