<andrewrk>
mahmudov, if you want a small hello world you can pass --strip --release-small to build-exe
<mahmudov>
hm ok
<andrewrk>
default is debug. it is big because it has debug symbols and stack trace printing code
<mahmudov>
can i cross building?
<mahmudov>
can i compile a source for different target?
samtebbs33 has quit [Ping timeout: 258 seconds]
<Tetralux>
Pass `-target <target>` to `zig build-exe`
<Tetralux>
You can do `zig targets` for a list IIRC.
<Tetralux>
You can omit the last part of the triple for the default ABI.
<Tetralux>
Like `zig build-exe hello.zig -target x86_64-windows`
kristoff_it has joined #zig
<mahmudov>
yes i tried,it worked
<mahmudov>
+1
<mahmudov>
ty,lemme poke docs and help
D3zmodos has quit [Remote host closed the connection]
vegai has quit [Remote host closed the connection]
fengb has quit [Remote host closed the connection]
jzck has quit [Remote host closed the connection]
BitPuffin has quit [Remote host closed the connection]
Snektron has quit [Remote host closed the connection]
Demos[m] has quit [Remote host closed the connection]
kristoff_it has quit [Ping timeout: 258 seconds]
SimonNa has joined #zig
BitPuffin has joined #zig
shritesh has joined #zig
<curtisf>
is there a rational for why some of the flags have one `-` and some have two `--`?
<andrewrk>
yes, they're copied from other projects' CLI args rather than trying to be self-consistent
<mikdusan>
should probably just accept both '-' and '--' for all options
kristoff_it has joined #zig
<Tetralux>
mikdusan: That would probably be my first though.
<Tetralux>
thought*
<curtisf>
The inconsistency is really strange to me, not knowing why some are one way and the other. Being permissive is probably the easiest way to be consistent if you still want to be 'compatible' with other tools, but permissiveness is also not ideal
kristoff_it has quit [Ping timeout: 252 seconds]
<Tetralux>
curtisf: Why is permissiveness not ideal? Clarity?
<Tetralux>
If so, I'd suggest that if it errors because you used one '-' and not two, or whatever, then it informs you of the right number.
<Tetralux>
error: unknown argument '--target'
<Tetralux>
note: .. but '-target' exists.
<Tetralux>
f.e.
<shritesh>
andrewrk: I'm trying to implement js/wasm callbacks interop using suspend/resume and keep getting "LLVM ERROR: function sections must contain one function each"
Demos[m] has joined #zig
vegai has joined #zig
D3zmodos has joined #zig
jzck has joined #zig
fengb has joined #zig
<andrewrk>
shritesh, interesting. let me have a look at that
<andrewrk>
samtebbs, I resolved one of your bugs (https://github.com/ziglang/zig/issues/2791) and thoroughly documented the troubleshooting steps because you were asking for tips
<andrewrk>
samtebbs, let me know what other bugs are blocking you from getting from 0.4.0 -> master on pluto
<shritesh>
andrewrk: reduced case https://pastebin.com/grHe1AqN compile with `zig build-lib main.zig -target wasm32-freestanding`
<andrewrk>
ok I'm reproducing it easily enough. let me see wtf is going on
<andrewrk>
hmm I wonder if it's the "prefix data"
<andrewrk>
shritesh, ok I reproduced it with LLVM 9, and confirmed it's "prefix data". This is annoying because I had it working without prefix data already, then rewrote it using this PrefixData feature
<andrewrk>
they didn't mention that it wasn't available on all targets
<andrewrk>
I can make it work without this easily enough, but not before tomorrow
<shritesh>
That's no fun
<shritesh>
That's fine
<shritesh>
sidenote: If this works, we might be able to have some really "nice feeling" JS interop. async/await just fits with callbacks and such
<andrewrk>
yeah that's a great point
return0e has quit [Remote host closed the connection]
<andrewrk>
the annoying thing is that even if they implemented prefix data for wasm right this minute, we wouldn't get it until llvm 10, which is 7 months away
<shritesh>
I was inspired by daurnimator's fengari LUA in JS project
<andrewrk>
this is really annoying. I'll have to do a workaround for 0.5.0 for this.
<mikdusan>
andrewrk: i'm trying to find a twitch.tv session you did for me showing some walkthrough on IR to troubleshoot a bug. are they pruned automatically?
<andrewrk>
yes twitch.tv deletes them after a while. was that the one that I didn't upload to youtube?
<mikdusan>
i'll check on youtube. was going to link it in an FAQ answer. no big deal if it's not there.
<andrewrk>
I can do another one of those streams and archive it
<mikdusan>
no no I just want to take what is handy. if another comes up i'll add it to FAQ.
<Tetralux>
mikdusan: I've never looked into how to run wasm code. Can you point me to a resource of choice? Or is it easy to find?
<andrewrk>
shritesh, the sad thing about this is that if you don't call @frameSize then you don't even need the prefix data. That would actually be a pretty quick fix I could do. If you don't call @frameSize then it would avoid this issue
<andrewrk>
and you only need @frameSize for async function pointers
<shritesh>
Honestly, I don't know why I'd use @frameSize or async function pointers :D. I was just going to use async, await, @frame, suspend and resume to make a fetch callback happen across wasm boundaries.
<mikdusan>
Tetralux: i've never targeted wasm. sorry. but that sounds like a good zig wiki faq or document to have
<shritesh>
That means I can just resume amain_frame
<andrewrk>
technically in this case you can
<shritesh>
And it works
<andrewrk>
but it would still be advised for the caller (`start`) to not be aware of the details of how suspend/resume are happening
<andrewrk>
because you could for example, introduce another suspend, that gets resumed a different way
<shritesh>
makes sense.
<shritesh>
I think in this case, the JS event loop itself acts as our event loop which is nice.
<andrewrk>
yes
<andrewrk>
it would be nice if we could have debug safety for that footgun though
kristoff_it has joined #zig
<shritesh>
With this working and fengb's zee_alloc, Zig might actually be the only language able to compete with Rust's WASM ecosystem.
<andrewrk>
so I think you could use this to make a zig function that calls a javascript async function
<andrewrk>
the new fetch() is one right?
<shritesh>
Yes. Even in this example, the callback is being called after the previous promise has been resolved.
kristoff_it has quit [Ping timeout: 244 seconds]
<andrewrk>
oh, and since js is single threaded, you can always use a global for the frame. that's easy and pretty ideal memory usage
<shritesh>
Music to my ears
<andrewrk>
uhh sorry. that doesn't work with recursion (direct or indirect). never mind that last thing
mahmudov has quit [Remote host closed the connection]
<shritesh>
Can I use the heap for that?
<andrewrk>
yes
<andrewrk>
that's kinda the only option you have for recursion
<shritesh>
Only when it's async right?
<andrewrk>
well here's the thing. we want safe recursion in normal blocking code too. and I have a simple plan to do that: when a call graph cycle is detected, zig makes all the functions in the cycle async.
<shritesh>
Ah.
<andrewrk>
this will cause an error like this: error: '@Frame(fib)' depends on itself. note: when analyzing type '@Frame(fib)' here. (continued for every call in the cycle)
<andrewrk>
so this would both cause an error for recursion, as well as start the programmer down the path to solving it - because now that those functions are "async", heap-allocating their stack frames will solve the compile error, and solve the unsafety of the recursion
<andrewrk>
plus - the heap allocation of a frame would only have to happen for 1 function in the cycle - all the other calls would have the callee's frame inside their own. so this would be what you want - 1 allocation per cycle, not per call
<andrewrk>
1 heap-allocation breaks the cycle
<shritesh>
And wasm implicity has 4K of heap available by default
<shritesh>
Unless, explicitly stated by the environment
<andrewrk>
the main idea here is that "the stack" has a fixed upper bound that has to be known at compile-time, while the heap can be adjusted at runtime, depending on user input
<andrewrk>
I'm confident in this plan. Which is exciting, because it was one of the big unsolved research areas. And the async/await redesign brought in the solution for free
<andrewrk>
I believe that Rust has memory safety for stack overflow - it will at least crash rather than undefined behavior. But zig would be bringing this to the next level: compile-time verification of stack size upper bound. That's especially important for embedded and OS dev
<andrewrk>
it's not a complete solution. there is still function pointers to solve. but I have a plan for that, too
<shritesh>
I don't see why a try before await won't work here
<andrewrk>
it would but you would potentially leak the other resource
<shritesh>
Ah. But, we're in JS land here :D
<andrewrk>
actually it's worse than that. if you `try await ip_frame`, and the `try` returns, your bacon frame is still going, but main() returns. you've yanked the stack frame out from underneath the fetch call
<andrewrk>
same situation as the earlier example with start() and callback()
<shritesh>
Oof. So a scheduler and pseudo-GC are in order
<andrewrk>
nah, just the idioms outlined in the linked code earlier. and the `cancel` feature can still be up for discussion, but there are some difficult design problems to solve for that
<andrewrk>
you can also arrange it so that the awaits are together. as long as there are no `try` or `return` in between async and await. but I do recommend the original example I provided
<shritesh>
Gotcha
<shritesh>
I think it can be handled centrally for wasm
stratact has quit [Remote host closed the connection]
<shritesh>
Like a global promise store
<shritesh>
And we can probably assume that the JS function will always callback whether it's success or failure so that resources get cleaned
<andrewrk>
what about application-level resources though?
<andrewrk>
your code calls wasm_allocator.free() which means the application manages the resource
<shritesh>
Ah. I didn't consider that.
<andrewrk>
status quo is a bit of boilerplate. but it does not cause indentation, and it allows you to use the familiar `try` everywhere
kristoff_it has joined #zig
shritesh has quit [Quit: Leaving...]
kristoff_it has quit [Ping timeout: 245 seconds]
kristoff_it has joined #zig
return0e_ has joined #zig
return0e has quit [Ping timeout: 244 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 258 seconds]
<daurnimator>
andrewrk: I think you're going in the wrong direction with 3157
curtisf has quit [Remote host closed the connection]
<daurnimator>
I'll need to do a write up on my thoughts
rivten has quit [Remote host closed the connection]
kristoff_it has quit [Ping timeout: 246 seconds]
nitram91 has quit [Remote host closed the connection]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
<daurnimator>
bgiannan: 'embed'?
<bgiannan>
daurnimator, see pm
<bgiannan>
it boils down to the fact that, for macOS, i need `-pagezero_size 10000 -image_base 100000000` but i don't know that i can pass those options to zig
<daurnimator>
andrewrk: I would propose that *all* operations use an event loop with pluggable "backends"
<mq32>
fixed point was just an example ;)
<mq32>
same is for bfloat16, …
<daurnimator>
mq32: I think the point is that there is a very limited set of numeric types that should be supported.
<mq32>
yes, i don't doubt that
<mq32>
my point is that to write generic code we would require some wrapper types for builtin arithmetics
<daurnimator>
mq32: currently we have signed+unsigned integers + floats. we should maybe gain fixed point integers and bfloat16. maybe unums? but it shouldn't be something that arbitrary library code can invent IMO
<mq32>
so i can use
<mq32>
f32.add(a, b);
<daurnimator>
andrewrk: something like debug stack trace printing can: 1. create new event loop. 2. use that event loop to print the stack trace. 3. destroy that event loop (or I guess for a panic, just abort()
<daurnimator>
mq32: I believe that is on purpose
<mq32>
same here
<mq32>
but i see me writing a
<mq32>
WrappedType(f32) which is a struct that exports those .add functions
<mq32>
so i don't have to write to different functions that emit literally the same byte code later
<andrewrk>
daurnimator, why is that better?
<daurnimator>
mq32: I started delving into some crypto code the other day... also sorts of fun arithmetic groups I was trying to translate from C++.... I don't think operator overloading made it particularly more readable
<andrewrk>
then it won't be able to print a stack trace if the event loop code panics
<daurnimator>
andrewrk: that's not really different to if open() panics (though I guess that's more unlikely)
<andrewrk>
it's different because there's hundreds of lines of userland code in an event loop. 0 lines of userland code in open()
shritesh has joined #zig
<mq32>
daurnimator: yeah that's a valid argument. i'm i fan of operator overloading for reasonable use (numeric values with arithemtic semantics), but i can understand that they don't fit zig
<daurnimator>
andrewrk: there's at least the errno handling code; but yes: 20 lines vs 1000.
<mq32>
but i want to solve the problem that i cannot write fully generic code that uses both userland numeric types and builtin numeric types
<andrewrk>
also if there are more than 1 event loop, and now they're fighting over writing to stderr? with 1 global event loop, a lock can participate in the event loop. if you have more than one then you need stop-the-world mutexes for some things such as stderr
<andrewrk>
here's what I'm saying: *even if we want nested event loops* this concept of `noasync` is still a missing building block
<daurnimator>
andrewrk: even with a single event loop you can have multiple descriptors to stderr open: this doesn't change much there.
<daurnimator>
andrewrk: I don't think it is: I think we can solve it without the additional complexity you're proposing
<daurnimator>
(well: the complexity is elsewhere: but IMO much more useful/reusable/more general)
<andrewrk>
with a single event loop you can use std.event.Lock, which has a function suspend until the lock can be obtained
<daurnimator>
andrewrk: do you recall the demo I gave you that led to the creation of 1778? where doing e.g. a read operation *actually* checked if there was a current event loop object; and if not: created a new event loop; did a read; and then destroyed that event loop?
torque has quit [Remote host closed the connection]
torque has joined #zig
Ichorio has joined #zig
_whitelogger has joined #zig
marmotini_ has quit [Ping timeout: 264 seconds]
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 258 seconds]
marmotini_ has quit [Ping timeout: 258 seconds]
nrdmn has joined #zig
marmotini_ has joined #zig
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 258 seconds]
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 244 seconds]
marmotini_ has quit [Ping timeout: 264 seconds]
marmotini_ has joined #zig
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 258 seconds]
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 245 seconds]
jrudolph has quit [Ping timeout: 264 seconds]
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 245 seconds]
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 246 seconds]
qazo has joined #zig
marmotini_ has quit [Ping timeout: 245 seconds]
nitram91 has joined #zig
marmotini_ has joined #zig
marmotini has joined #zig
marmotini has quit [Remote host closed the connection]
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 246 seconds]
ky1ko has quit [Read error: Connection reset by peer]
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 245 seconds]
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 258 seconds]
marmotini has quit [Ping timeout: 244 seconds]
ntgg has joined #zig
ofelas has quit [Remote host closed the connection]
Yardanico has joined #zig
Akuli has quit [Quit: Leaving]
casaca has quit [Ping timeout: 244 seconds]
casaca has joined #zig
<nitram91>
andrewrk why do the Elf and Dwarf librairies use streams ? wouldn't it be much more efficient to mmap the file into memory then get the data from that ? (The cost of seeking and reading is very high, whereas as a read-only mmaped file is very efficient)
<andrewrk>
nitram91, yes it would be better to do that for the stack trace dumping use case
<andrewrk>
that code has undergone many changes, and never been fully redesigned/reworked now that all the use cases / cross platform support are clear
<nitram91>
ok, ill remove the pull request I did this morning, and try to move from streams to mmap (I'm not gonna lie, using mmap would also fit my use case of a dynamic linker much better)
ntgg has quit [Ping timeout: 245 seconds]
ky0ko has joined #zig
<nitram91>
andrewrk some elf constants are missing from elf.zig, should I just add them manually or is there a reason for them to be missing (EI_MAG0..3, ELFCLASS32, ELFCLASS64, .....) ?
<scientes>
nitram91, just add them if you need them
<andrewrk>
you can add them manually
<nitram91>
ok thx
<andrewrk>
nitram91, this area of the std lib has been contributed "as needed", there hasn't been a conscious effort to make it complete yet
<andrewrk>
that's most of the std lib, really
<nitram91>
I'll do my best to try and complete it (the elf part)
nitram91 has quit [Remote host closed the connection]
samtebbs has joined #zig
<samtebbs>
andrewrk: Hi Andrew, thanks for the PR :) I see that when I do `zig build run` it also builds the kernel rather than just running it
<samtebbs>
Do you know why that could be? I don't see a dependency between the run step and build step
waleee-cl has quit [Quit: Connection closed for inactivity]
mahmudov has joined #zig
<andrewrk>
hi samtebbs - you're welcome :) run -> qemu_cmd -> iso_cmd -> cp_elf_cmd -> addArtifactArg
<andrewrk>
addArtifactArg automatically adds a dependency
<andrewrk>
it's still not quite ideal - it would be better to do stuff in a temporary directory and then "install" to the install path
<andrewrk>
but I would argue this is an improvement from status quo
Ichorio has quit [Ping timeout: 264 seconds]
samtebbs has quit [Read error: Connection reset by peer]
qazo has quit [Ping timeout: 264 seconds]
ltriant has joined #zig
return0e has joined #zig
return0e_ has quit [Ping timeout: 245 seconds]
marler8997_1 has joined #zig
<marler8997_1>
Am I supposed to be able to pass "-target ..." to "zig build"?
<andrewrk>
marler8997, no, any target configuration has to be exposed by the project's build script
samtebbs has joined #zig
<samtebbs>
andrewrk: That makes sense, cheers. I'll experiment with it a bit
<marler8997_1>
ok, so every target you're project supports needs to be configured in that targets build script
<marler8997_1>
*that project's build script
shritesh has joined #zig
<andrewrk>
marler8997, yes, and there is a new option b.standardTargetOptions, which has a reasonable API, but it needs to be improved with how it surfaces the options to the CLI
laaron- has joined #zig
laaron has quit [Remote host closed the connection]
shritesh has quit [Remote host closed the connection]
<marler8997_1>
This seems to be creating a native executable, not a cross-compiled one...? zig build-exe hello.zig -target aarch64v8-linux-gnueabihf
<andrewrk>
what makes you think that?
shritesh has joined #zig
<marler8997_1>
because I can run it on my host machine :)
<marler8997_1>
hmmmmm, but the elf header says it's compiled for AARCH64....how in the heck is this working?
qazo has joined #zig
<marler8997_1>
maybe it's calling qemu under the hood with some miscelaneous exec handler!
<marler8997_1>
oh my gosh it is!!!!
shritesh has quit [Client Quit]
<marler8997_1>
and it runs on my ARM asic!!!
<andrewrk>
I love it when stuff just works
<marler8997_1>
So do you think the "-target" option will be added by default at some point?
<andrewrk>
what do you mean?
<andrewrk>
the default target is native
<marler8997_1>
Do you think "-target" could be one of the default options in standardReleaseOptions at some point?
<andrewrk>
oh, yeah, sure. the API of standardTargetOptions lets the build script specify a set of supported targets, with the first one in the list being the default
<andrewrk>
how that gets exposed to the CLI is not in its final state. probably -target is good
<marler8997_1>
gotcha
<marler8997_1>
so much to do with zig
return0e_ has joined #zig
return0e has quit [Ping timeout: 246 seconds]
samtebbs has quit [Ping timeout: 246 seconds]
return0e has joined #zig
return0e_ has quit [Ping timeout: 244 seconds]
<Aransentin>
Playing around a little with Zig, and wrote a network analyzer experiment using AF_XDP: https://github.com/Aransentin/ZNA
<Aransentin>
(if anybody is interested in looking at it...)
<Aransentin>
Right now it just goes "Oh, it's an IPv4 UDP packet" and not much more, though 🙂
curtisf has joined #zig
<curtisf>
As of this morning I have a working allocator that takes a fixed buffer and can re-use space as it is freed, with log(n) frees and allocs, which was pretty exciting to write and see work
<curtisf>
I feel like once Zig has a language server, it will be the most pleasant language to write code in, even given that I have to manually manage memory