<pixelherodev>
Assuming CI doesn't catch anything else, that means I can move on to the Next Big Thing :)
<gruebite>
:)
<pixelherodev>
Except that for some reason it's now detecting `wasm64-unknown-wasi-musl` for the triple for wasm32-wasi. Oops.
ur5us has quit [Ping timeout: 260 seconds]
<fengb>
64 is basically 32
gert_ has joined #zig
<pixelherodev>
Lol
<pixelherodev>
Seems to be good now, at any rate :)
<pixelherodev>
The enum in std.Target is also used as the value given to LLVM
<pixelherodev>
So by inserting a new one into the middle, LLVM's "wasm32" value and Zig's "wasm32" value were no longer the same
<pixelherodev>
Yay, passing! :)
<fengb>
Ah order matters :P
<gert_>
hey I'm having trouble debugging this error message "cannot assign to constant" it's really stopped me in my tracks, I'm trying to run a self-mutating update method but all my self.vars give me this on assignment
<gert_>
and the instance is var, not const
<leeward>
gert_: Can you paste a snippet somewhere?
<gert_>
it's a little large, where do we like zig snippets? godbolt sadly doesn't have it
<leeward>
godbolt does support Zig
<leeward>
It kinda sounds like you're trying to mutate a function parameter though. If that's the case, pass in a pointer.
<gert_>
even if it's like self.x ?
<gert_>
oh my godbolt has a lot of languages I just haven't looked around proper
<pixelherodev>
At least this time it's an assertion failure and not an infinite loop.
<pixelherodev>
Stupid LLVM.
<gruebite>
zig. is. amazing.
waleee-cl has quit [Quit: Connection closed for inactivity]
B4s1l3 has joined #zig
pmwhite has quit [Ping timeout: 244 seconds]
B4s1l3 is now known as opDispatch
gert_ has quit [Quit: WeeChat 2.8]
marnix has joined #zig
marnix has quit [Ping timeout: 246 seconds]
marnix has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
ur5us has joined #zig
opDispatch has left #zig ["Konversation terminated!"]
marnix has quit [Ping timeout: 240 seconds]
ur5us has quit [Ping timeout: 244 seconds]
_whitelogger has joined #zig
marnix has joined #zig
jjido has joined #zig
nycex has quit [Ping timeout: 240 seconds]
_whitelogger has joined #zig
knebulae has quit [Ping timeout: 240 seconds]
moo has quit [Read error: Connection reset by peer]
dermetfan has joined #zig
nikita` has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gazler has joined #zig
neptunepink has quit [Ping timeout: 265 seconds]
craigo has joined #zig
neptunepink has joined #zig
marnix has quit [Read error: Connection reset by peer]
Ashpool has joined #zig
jjido has joined #zig
knebulae has joined #zig
ofelas has quit [Ping timeout: 258 seconds]
ur5us has joined #zig
marnix has joined #zig
<ifreund>
agreed
<Snetry>
Zig is the best C compiler :)
<ikskuh>
<gruebite> zig. is. amazing.
<ikskuh>
+10
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ggVGc has joined #zig
<ggVGc>
hi, I just started looking at Zig, and I'm specifically looking for something "like C", but with local continuations. the async functionality in zig seem to fit the bill, but I'm wondering if there's a way to check if an async function has returned, based on the frame?
<ggVGc>
I am basically asking for a "select" rather than await, I hguess
<ifreund>
ggVGc: something like that is indeed planned, one sec I'll find the issue
<ifreund>
zig's async/await is currently at functional proof of concept stage, and probably wont progress beyond that in the stage1 compiler. Stage2 is the current focus of development
dermetfan has quit [Ping timeout: 272 seconds]
<ggVGc>
yeah, I understand. I really like what I see currently though, as I've been looking for a language where I can easily make sure I don't have heap allocations, but also have local continuations
<ggVGc>
currently I do it with very hacky macros in C...
<ifreund>
heh, yeah zig does seem to fit that use-case
<ikskuh>
ggVGc: you can just do something like that:
<ikskuh>
note that the pointer requires lifetime management
craigo has quit [Ping timeout: 256 seconds]
<ggVGc>
yeah, that's what I do currently, and after reading the github issues, I realise this is basically what a language-supported implementation would need to do also
<ggVGc>
except that every async function would pay the price of having the has_returned flag
<ggVGc>
which isn't great
<ggVGc>
so maybe passing in the flag manually is actually the right thing
ur5us has quit [Ping timeout: 244 seconds]
Sahnvour has joined #zig
pmwhite has joined #zig
waleee-cl has joined #zig
<pixelherodev>
ikskuh, andrewrk: all that remains for the initial SPU II support is testing, and I'm not sure the best way to do that. Should we integrate either ikskuh's or my emulator the same way as e.g. WINE / wasmtime? Should the test harness be extended to support raw byte-wise comparison of the output?
craigo has joined #zig
dermetfan has joined #zig
<ikskuh>
pixelherodev: i think running a modified version of the emulator would be wise
<ikskuh>
so one that is tailored for the test harness
dermetfan has quit [Ping timeout: 260 seconds]
jjido has joined #zig
marnix has quit [Ping timeout: 240 seconds]
<pixelherodev>
Hmm, maybe
zigusr has quit [Remote host closed the connection]
<pixelherodev>
ikskuh: in the same way as with e.g. wasmtime, as a ChildProcess, right?
<pixelherodev>
I could extract the interpreter from mine and make it so we feed it the binary over stdin or something
<pixelherodev>
ikskuh: better yet, if we can standardize a way of providing the input, we can make it so that the tests can run with *either* installed
<pixelherodev>
(given a standardized path, perhaps, or have the test harness check for both)
<ikskuh>
pixelherodev: why as a child process?
<ikskuh>
we can just link that as a library and use it directly from zig
<ikskuh>
you still think in terms of "defined systems", like wasmtime uses wasi (probably)
<ikskuh>
SPU Mk II doesn't have *any* defined OS layer
<ikskuh>
so you cannot even test input/output without having any kind of definition how to do these
<pixelherodev>
True
marnix has joined #zig
<pixelherodev>
gtg back later
<ikskuh>
so we have to define a I/O layer anyaways
<ikskuh>
and we still have undefined instructions that can be used for this :)
<ikskuh>
so for example you can write tests that verify that the code emitted a struct in a certain memoryspot
<ikskuh>
and the test itself will end with a "struct_here 0x1234" instruction
<ikskuh>
which will tell the test harness that the compiled placed the structure at this position
marnix has quit [Ping timeout: 264 seconds]
marnix has joined #zig
dermetfan has joined #zig
marnix has quit [Read error: Connection reset by peer]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
marnix has joined #zig
jjido has joined #zig
<pixelherodev>
ikskuh: for those, we could just analyze the produced binary directly
<pixelherodev>
No need to actually execute it
<ikskuh>
i'm talking about instruction access, not serialization
<pixelherodev>
Heck, mind going to a private chat and I'll just bother you with WASM questions? :P
Nypsie has joined #zig
<fengb>
Sure, not guarantees I'll respond though >_>
<pixelherodev>
That's fine :)
<pixelherodev>
andrewrk: any objections to the plan ikskuh and I were discussing re: integrating an interpreter for testing?
protheory8-new-m has joined #zig
<protheory8-new-m>
Hi, if I want to accept string as function argument should I use `[]const u8` or `[:0]const u8`? Both seem to work.
<ifreund>
protheory8-new-m: []const u8 unless you need the terminating 0
<ifreund>
(e.g. if you need to pass it to a C function)
<protheory8-new-m>
Thanks, that makes sense. Also, what does `const` mean in `[]const u8`?
<protheory8-new-m>
Does that mean that I can't change u8 values in array?
<fengb>
Yeah, "slice of constant u8s"
<ifreund>
[] means its a slice, which is like a struct with ptr and len fields
<ifreund>
const means you cant modify the memory being pointed to
<protheory8-new-m>
It seems like default string type in Zig is `*const [6:0]u8`?
<ifreund>
that's the type of string literals yes
<protheory8-new-m>
Is that constant pointer to array of `u8` with 6 elements and a 0?
<ifreund>
yep
<protheory8-new-m>
Thanks, so I'm wondering why is pointer needed here?
<ikskuh>
protheory8-new-m: it's a array, so writing const str = "foo"; would create a copy of that array instead of referencing the literal
<ikskuh>
also arrays don't coerce to slices, but pointers to arrays do
<ifreund>
also you usually don't want to pass arrays around by value everywhere
<ikskuh>
so if you have a function foo(slice: []const u8) you can pass a "foo" in there, but you cannot pass a array directly
xackus has joined #zig
<protheory8-new-m>
Thanks!
nvmd has joined #zig
<fengb>
Zig optimizes arrays-by-value into a reference if it'd be faster
<fengb>
The bigger problem is that arrays must have a known fixed size
marnix has quit [Ping timeout: 264 seconds]
Yardanico is now known as yardanico[ok]
yardanico[ok] is now known as Yardanico
daex has quit [Ping timeout: 240 seconds]
<scientes>
fengb, on --release-fast that shouldn't matter
<scientes>
(however llvm doesn't understand what slices are, so maybe...)
<scientes>
MLIR however could probably be taught what slices are
cren has joined #zig
Biolunar has quit [Quit: leaving]
Biolunar has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
Akuli has joined #zig
WilhelmVonWeiner has joined #zig
pangey has quit [Ping timeout: 256 seconds]
pangey has joined #zig
marnix has joined #zig
waleee-cl has joined #zig
ofelas has joined #zig
pangey has quit [Ping timeout: 260 seconds]
pangey has joined #zig
cole-h has joined #zig
cren has quit [Ping timeout: 256 seconds]
marnix has quit [Ping timeout: 240 seconds]
frett27 has joined #zig
nikita` has quit [Read error: Connection reset by peer]
Nypsie has quit [Quit: WeeChat 2.8]
frett27_ has joined #zig
marnix has joined #zig
frett27 has quit [Ping timeout: 264 seconds]
frett27_ has quit [Ping timeout: 260 seconds]
<leeward>
Am I just failing to find path manipulation utility functions, or do they not exist?
<leeward>
ah, fs/path
zie has joined #zig
marnix has quit [Ping timeout: 246 seconds]
ur5us has joined #zig
Akuli has quit [Quit: Leaving]
<pixelherodev>
andrewrk: any objections to including a tiny interpreter with which to test the SPU backend?
<pixelherodev>
it passes CI now, the last thing to do is figure out testing
<andrewrk>
pixelherodev, no objections. let's put it in the std lib
<pixelherodev>
andrewrk: I'm not sure stdlib is right for this
<andrewrk>
wouldn't you want to use it with `zig build` to run SPU Mark II tests?
<andrewrk>
same deal with WASI
<pixelherodev>
Ah, true
<pixelherodev>
I think that we're getting close to the point that ZBS should be extracted from stdlib
<andrewrk>
what does that mean, in practice?
<pixelherodev>
If we're keeping it in the same repo, probably moving it from lib/build{/,.zig} into lib/build/
<pixelherodev>
lib/std/build *
<pixelherodev>
From lib/std/build into lib/build
<andrewrk>
what problem is that intended to address?
<leeward>
So then `const build = @import("build")`?
<pixelherodev>
Yeah - it's mostly that I don't think that an interpreter for a single target belongs in the *standard library* - it's not something the average program is going to wan
<pixelherodev>
want*
<pixelherodev>
That's not to say it shouldn't be considered a part of Zig proper the way stdlib does, but that it should be treated as its own library
<andrewrk>
what you are proposing has no impact on the user and basically amounts to pointlessly moving files around
<pixelherodev>
It's mostly about keeping things clean
<pixelherodev>
`ls lib/std | wc -l` -> 88
<pixelherodev>
But it's really not a big deal
stripedpajamas has joined #zig
pystub has joined #zig
<pixelherodev>
andrewrk: so, keeping future targets in mind, should this be part of std/build/targets or something?
<shakesoda>
it's not really strictly a problem if there are a lot of things in a folder
<shakesoda>
subfoldering things a lot is a great way to lose track of where anything is anymore
<pixelherodev>
True
<andrewrk>
pixelherodev, if there's one thing I've learned in 19 years of software development, it's to solve the hard problems first, and the easy problems last. where to put the .zig file is one of the easy problems. let's talk about this once you have a working emulator
<leeward>
The standard library has tons of target-specific code. See std.os (-> std.posix)
<shakesoda>
especially for those among us who are prone to losing things
* shakesoda
coughs
<andrewrk>
the biggest problem with discussing the color of the bike shed is the opportunity cost of the energy spent on it, that could have been spent on anything else
xackus has quit [Ping timeout: 256 seconds]
<andrewrk>
for example, here I am taking a break from stage2, typing 3-4 sentences about where to put files in the file system
<shakesoda>
are we expecting to take some passes at cleaning stdlib out in future pre-1.0 versions
<pixelherodev>
leeward: true
<pixelherodev>
andrewrk: very good point
<andrewrk>
shakesoda, yes
<pixelherodev>
To be fair, I can have a working interpreter in like ten minutes
<leeward>
But what will the bureaucrats do? That committee to revise the color of the folder that holds the regulations are in needs to generate minutes.
<pixelherodev>
It's really not that hard :P
<shakesoda>
andrewrk: cool
<andrewrk>
great. put it somewhere that makes sense to you, open a PR, and then we'll figure out what to do
pystub has left #zig [#zig]
<leeward>
I would argue that "naming things" qualifies as a hard problem, but that doesn't justify spending tons of effort on it before the "things" work.
<pixelherodev>
It's part of the SPU II PR
<leeward>
</pedantry>
<pixelherodev>
Coming shortly
<leeward>
It's one of the top 2 hardest problems in computer science.
<shakesoda>
leeward: it's especially bad when the piece is either really abstract or really specific
<fengb>
andrewrk: is there a plan on standardizing `@import("build_options")` more? It feels awkward to need a separate flow for running tests
<shakesoda>
or there is no name you could possibly use which is semantically valuable anyways
<andrewrk>
fengb, yes - that API is barely beyond proof of concept at this point, and it needs some love
<shakesoda>
(this happens constantly in math)
<fengb>
Ah okay
<andrewrk>
but it is very intentional that you can pass values on to your code from the build system
<fengb>
Right, it just feels a little awkward that it crashes when not enabled so there needs to be internal juggling
<pixelherodev>
For now, going to have it be part of stage2 and integrate it with the test suite; I'll need to shuffle some other pieces into stdlib with it afterwards anyways
<pixelherodev>
Actually...
<pixelherodev>
I'd bring in my JIT support, but that would mean a much bigger dependency :(
<andrewrk>
hmm I'm at the point in stage2 where I'm deciding between making `@as(u32, foo) = bar;` work or emit a compile error "cannot use @as expression as L-Value"
<andrewrk>
probably the latter :)
<andrewrk>
`@bitCast(T, foo) = bar;` on the other hand 🤔
<pixelherodev>
?
<pixelherodev>
Why would the former be allowed?
<pixelherodev>
Why would *either* be allowed, rather?
<pixelherodev>
`@blah(T, foo) = bar`?
<ikskuh>
@bruh(T, foo)
<leeward>
Yeah, I don't see an advantage of `@bitCast(T, foo) = bar;` over `foo = @bitCast(U, bar);`
<lemmi>
on the other hand, why wouldn't you allow it?
<fengb>
This would look slightly less gross with @bitCast lhs
<fengb>
Arguably it should be gross looking
<leeward>
lemmi: I think the burden on including a new feature should be on the introducer to justify its existence, and casting l-values would be a pretty big departure from other languages.
<leeward>
s/burden on/burden when/
<leeward>
fengb: That should definitely look gross.
<lemmi>
leeward: maybe. to my mind not allowing it on the left side looks like a exception to me
<pixelherodev>
andrewrk: is there a specific reason to be considering it?
<leeward>
`value = expression` is pretty universal, and keeping the type of value fixed to the type of expression makes sense.
<pixelherodev>
I think @as in LHS *could* be good, but it's not intuitive, because it's never existed
<pixelherodev>
Whether that's in and of itself a reason to not support it is up for debate
sqwishy has quit [Ping timeout: 260 seconds]
Snetry has quit [Ping timeout: 265 seconds]
Snetry has joined #zig
marnix has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
sqwishy has joined #zig
ur5us has joined #zig
dermetfan has quit [Ping timeout: 246 seconds]
marnix has quit [Ping timeout: 256 seconds]
V has joined #zig
<ronsor>
I think zig might be the only thing that could replace C for me