<pixelherodev>
I will *do* CBE development now, but that's just a coincidence ;P
RoguePointer has quit [Quit: <>]
RoguePointer has joined #zig
CodeSpelunker has joined #zig
<pixelherodev>
wait *What*?!
<pixelherodev>
Kakoune supports `a|b` in regexes?!
<pixelherodev>
I keep accidentally discovering things that make life easier :P
<CodeSpelunker>
lol :)
<CodeSpelunker>
is there a good resource out there that describes differences between Rust and Zig?
<pixelherodev>
Maybe?
<CodeSpelunker>
I heard about Zig through someone else on a Rust discord, and it sounds really cool!
<pixelherodev>
Here's how I like to put it, if this helps:
<pixelherodev>
Zig is like a better C
<pixelherodev>
Rust is like a better *C++*.
<CodeSpelunker>
ahhh neat
<pixelherodev>
That's my way of casually insulting Rust :P
<pixelherodev>
all subtle-like :P
<CodeSpelunker>
I can definitely get behind that
<CodeSpelunker>
hey, better is better
<pixelherodev>
Sure
<pixelherodev>
But it's also about where we set the bar ;)
<CodeSpelunker>
mhm
<CodeSpelunker>
After a couple years now of hacking on Rust, I'm looking forward to learning some Zig too
<leeward>
Zig has less general-purpose algebraic types, and no Hindley-Milner, and no RAII, and is generally lower level than Rust. On the other hand, it has many fewer features, so it's reasonable to keep most of the language in your head.
<CodeSpelunker>
I like the idea of that
<fengb>
If you know C, you can pick up Zig in a weekend. If you know C++, you can pick up Rust in a month :P
<pixelherodev>
lol
<CodeSpelunker>
heheh
<CodeSpelunker>
I went into Rust having never touched C++
<CodeSpelunker>
so, what do % and %% correspond to in Zig?
<CodeSpelunker>
that is the first thing that stands out to me looking at some Zig code
<companion_cube>
I went into rust having barely touched C++ (and hating it)
<CodeSpelunker>
hehehe
<fengb>
Um that’s probably really old Zig
<CodeSpelunker>
ah I see
<fengb>
%return was switched out for return error, and %% was swapped out for try?
<pixelherodev>
andrewrk: figured out why I switched on the tag and not zigTypeTag: this is a *Value*, and we have no way to find the Type of a Value
<pixelherodev>
The value's tag is all I've got in some places, I think
<pixelherodev>
Ah, nope; can pass it from the caller :)
<pixelherodev>
andrewrk: 6007 is now done on my end, ready for review whenever you're ready to look at it ;D
<pixelherodev>
"C compare output tests shouldn't use 'zig cc', but the equivalent API in the compiler" <- stage2 doesn't *have* `zig cc`, so it'd have to go through stage1's `zig cc` for now, no?
rzezeski has quit [Quit: Connection closed for inactivity]
<andrewrk>
pixelherodev, ah my bad let me take another look
<andrewrk>
hmm I suppose stage2 CBE compare output tests are blocking on a few things
_whitelogger has joined #zig
epmills has joined #zig
epmills has quit [Client Quit]
CodeSpelunker has quit [Quit: CodeSpelunker]
reductum has joined #zig
reductum has quit [Client Quit]
<andrewrk>
pixelherodev, you there?
<andrewrk>
if you do the anyerror fix and then tell me that test-stage2 passed locally I'll merge #6007 straight away
<andrewrk>
ok I did it and merged it
<pixelherodev>
Was out running, sorry :P
<pixelherodev>
andrewrk: how far down the line are packages / @import?
<pixelherodev>
(as a priority to you; assuming nobody just shows up and submits a patch :P)
<andrewrk>
I have a relatively high confidence of those things working smoothly, so, low priority
<pixelherodev>
CBE CO tests are on back burned for now?
<pixelherodev>
Or should I implement them via stage1?
<pixelherodev>
We can always switch it over later
<andrewrk>
the path to implement them is to pass the path to the zig executable to the test runner, and then the stage2 compare output tests would use that in a child process to compile & run the tests
<andrewrk>
so there's a bit of work to do to set this up, but I think it's worth it
<andrewrk>
I can do that setup
<pixelherodev>
How straightforward would basic @import support be to add, if I wanted to tackle it before returning to the CBE?
<pixelherodev>
No matter how many files we've got, it'll still produce a single ZIR output IIUC
<pixelherodev>
So it probably only depends on structs and dot access thereof?
ur5us_ has quit [Ping timeout: 260 seconds]
<andrewrk>
yeah that's right, struct types is a prereq and it also has implications for debug info
<pixelherodev>
I can just do it all in one file for now :P
<pixelherodev>
Or, the dumb option, use std.zig to hack together a program which analyzes multiple files and automatically concactenates them
<pixelherodev>
(replacing e.g. `a = @import("b.zig"); const c = a.b;` with `[contents of b.zig here] const c = __aa__b;` :P
<pixelherodev>
)
<andrewrk>
sounds like a local maximum
<pixelherodev>
andrewrk: is the end goal for CBE to emit one file total or one per Zig input?
<andrewrk>
one file total
<pixelherodev>
Presumably we want one *header* per input header
<pixelherodev>
input file*
<pixelherodev>
gotcha, that makes life easier :)
<pixelherodev>
andrewrk: mind elaborating on your second comment on 6007?
<pixelherodev>
Which part belongs in a separate function?
<andrewrk>
pixelherodev, in codegen.zig that's resolveInst
<pixelherodev>
Ahhh right
<pixelherodev>
Gotcha
<andrewrk>
in zir_sema.zig it's resolveInst
<andrewrk>
there's a pattern here
<pixelherodev>
:P yep
<pixelherodev>
andrewrk: is there any way to map a decl to its source file?
<pixelherodev>
Thinking ahead for header generation
<andrewrk>
are you looking at the decl struct?
<pixelherodev>
Scope.File is the source file?
<andrewrk>
yeah
<pixelherodev>
I figured as much, but I wasn't 100% sure if it was the root file or something
<pixelherodev>
I've started questioning my assumptions a bit more to avoid another ELF16 incident :P
<andrewrk>
decl.scope is either a Scope.File or Scope.ZIRModule
<pixelherodev>
Yeah, I know that; wasn't 100% sure if Scope.File was the containing file or not
<pixelherodev>
Is there a way to check if it's public from the Decl?
<pixelherodev>
I know exports are handled separately, but for CBE, `pub` might as well *be* an export IMO
<andrewrk>
export and pub mean very different things
<andrewrk>
pub is irrelevant to CBE
<pixelherodev>
K
<pixelherodev>
Anywho, gnight :)
<pixelherodev>
More CBE (or maybe HEX) work incoming tomorrow :)
<andrewrk>
good night
craigo has joined #zig
pfg_ has quit [Quit: Leaving]
lunamn has quit [Read error: Connection reset by peer]
lunamn has joined #zig
linuxgemini9 has joined #zig
linuxgemini has quit [Read error: Connection reset by peer]
linuxgemini9 is now known as linuxgemini
shachaf has quit [Ping timeout: 260 seconds]
shachaf has joined #zig
xackus_ has joined #zig
cole-h has quit [Quit: Goodbye]
xackus_ has quit [Ping timeout: 264 seconds]
ur5us_ has joined #zig
ronsor has quit [Ping timeout: 256 seconds]
ronsor has joined #zig
_whitelogger has joined #zig
ur5us_ has quit [Ping timeout: 260 seconds]
ifreund has quit [Read error: Connection reset by peer]
ifreund has joined #zig
jorge-jbs has joined #zig
st4ll1 has joined #zig
dddddd_ has joined #zig
dddddd__ has joined #zig
dddddd has quit [Ping timeout: 246 seconds]
dddddd_ has quit [Ping timeout: 240 seconds]
tsujp has quit [Read error: Connection reset by peer]
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
waleee-cl has joined #zig
KoljaKube has joined #zig
<KoljaKube>
Can I rely on copy elision to store pointers to the constructed struct in `init()` that will be used after `init()` has returned?
<KoljaKube>
As far as I understand I would need to wait for https://github.com/ziglang/zig/issues/2765 since I would need to instantiate the struct before the return, right?
xackus_ has joined #zig
forgot-password has joined #zig
<forgot-password>
When I use std.build.Builder to execute "git -C /path/to/repo status" I get an error that it's an unknown option, but everything else like "git --version status" works fine. Is the "-C" option treated differently?
<forgot-password>
And yes, my git version supports this option
<forgot-password>
Aha! I need to pass the path as a separate argument and not together with "-C"...
<KoljaKube>
Hm, interesting. #1717 is still open, but function aliasing like `pub const makeReceiver = @import("./call.zig").Receiver.init;` already work
<andrewrk>
KoljaKube, that's the idea, but there are a couple more issues left to solve before that will work
<andrewrk>
oh you followed up with that yourself :)
<KoljaKube>
Then I will be passing in an out parameter until then
<KoljaKube>
I try to do my homework, but I usually fear that my code experiments fail because of some unrelated reason, that's why I ask to make sure ;-)
<andrewrk>
regarding 1717, it's syntax sugar only, really. you can already get functions inside functions by wrapping it in a struct
forgot-password has quit [Ping timeout: 264 seconds]
<Nypsie[m]>
Does that mean it only needs to be implemented by the parser?
<Nypsie[m]>
(regarding 1717)
<andrewrk>
hmm no there are lots of considerations regarding the implementation. I just meant from a programming perspective, there's not really much of a difference other than convenience
<Nypsie[m]>
Ah I see, thanks
<sqwishy>
I can't have `fn Foo(n: u32) type { return struct { foo: n[u32] } }` and invoke it like `Foo(only_known_at_runtmie)` right? The type stuff has to be comptime?
<Nypsie[m]>
I assume you mean foo: [n]u32, in your example? But yes, n needs to be comptime in this case.
<Nypsie[m]>
andrewrk: Btw, I was just wondering the other day. Is Zir only for Zig? Or, could some arbitrary compiler build zir to build their binaries using the Zig compiler (if there was some way to hook in)? Not sure if this makes any sense but I was just toying with the idea that another language could use zig/zir instead of llvm.
<Nypsie[m]>
(or instead of their own backend)
<andrewrk>
I'm not designing it with that use case in mind, but it's in theory possible
<Nypsie[m]>
Cool, all I needed to know :)
<andrewrk>
you'd have to decide whether to target untyped ZIR which is heavily coupled to zig semantics, or the in-memory, typed IR instructions which are less coupled to zig but you have to provide the types of everything and some other guarantees
<Nypsie[m]>
Aaaaaah got it
<Nypsie[m]>
Thanks
rzezeski has quit [Quit: Connection closed for inactivity]
<andrewrk>
oh damn I missed the 10,000 commit party
<leeward>
Gotta wait until 16,384 to have the big party then.
cole-h has joined #zig
<scientes>
leeward, but that isn't even a power of 2
<scientes>
you mean 24k
<scientes>
err
<scientes>
ahh my bad ,I'm thinking all funny
reductum has joined #zig
knebulae has quit [Quit: Leaving]
forgot-password has joined #zig
knebulae has joined #zig
knebulae has quit [Client Quit]
Akuli has joined #zig
reductum has quit [Quit: WeeChat 2.9]
cren has joined #zig
<pixelherodev>
Drats
<pixelherodev>
Major CBE work is still blocked on astgen for now
<pixelherodev>
I'll focus on HEX today instead, I think
forgot-password has quit [Quit: leaving]
mikdusan has quit [Quit: WeeChat 2.6]
KoljaKube has quit [Ping timeout: 244 seconds]
nvmd has joined #zig
cren has quit [Ping timeout: 264 seconds]
Snetry has quit [Quit: left Freenode]
Snetry has joined #zig
zippoh has quit [Remote host closed the connection]
zippoh has joined #zig
klltkr has joined #zig
cole-h has quit [Quit: Goodbye]
ur5us_ has joined #zig
Akuli has quit [Quit: Leaving]
<andrewrk>
astgen is pretty straightforward
<pixelherodev>
andrewrk: I mean e.g. enums and structs
<pixelherodev>
The big stuff :P
<pixelherodev>
Wow CI takes forever
<pixelherodev>
It might legitimately be worth writing something with git + zig integration to detect which tests have actually changed and only run those :P
<pixelherodev>
Even if that took, like, ten hours to write, it'd save hours and hours of run time *every single build*
<andrewrk>
given that the CI is for the benefit of the reviewer, and reviewers tend to look at PRs after many hours after the PR goes up, we can conclude that the CI is actually instant ;)
<pixelherodev>
Extremely inefficient though :(
<pixelherodev>
One reallllllly inefficient instant
<pixelherodev>
Plus, it could come in handy locally too
<pixelherodev>
e.g. when working on stage2, if we cache everything between tests and quickly diff them, we can only run tests that have had dependents changes
<pixelherodev>
changed*
<andrewrk>
the test suite already does that to some degree
<pixelherodev>
Really?
<pixelherodev>
I haven't noticed...
<andrewrk>
all you have to do for stage2 development is `./zig build test-stage2` which takes about 10 seconds to build the test harness and then a few ms to actually run all the tests
<pixelherodev>
As opposed to?
<pixelherodev>
Ah, I see what you mean
<pixelherodev>
I'm basically talking about incremental testing, except instead of tracking generated code, tracking successful and unsuccessful tests out-of-band, and caching the state of all of their dependents
<andrewrk>
I'd rather just work stage2 progress
<pixelherodev>
For sure
<pixelherodev>
This is one of those "if I had infinite time" ideas :P
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen1 has joined #zig
dingenskirchen1 is now known as dingenskirchen
blinghound has joined #zig
dimenus has joined #zig
nycex has joined #zig
dimenus has quit [Quit: WeeChat 2.9]
nvmd has quit [Quit: Later nerds.]
<sqwishy>
A comptime assert I wrote is failing since some value isn't what I expect; is there a good way to display/inspect the value I have?
blinghound has quit [Remote host closed the connection]
<sqwishy>
I think my reasoning is sound here but packed structs aren't doing what I expect with respect to byte order? Or am I sutpid. https://paste.centos.org/view/raw/2f0e69d9