<andrewrk>
ok pixelherodev *now* the branch is ready to be merged into master
marijnfs_ has joined #zig
<pixelherodev>
Okay cool
<pixelherodev>
andrewrk: rebasing now.
marijnfs has quit [Ping timeout: 240 seconds]
<pixelherodev>
andrewrk: you changed Execution to be stdout only?
<pixelherodev>
Yeah, okay
<pixelherodev>
andrewrk: Mind letting me finish up my PR tonight before you merge yours?
<pixelherodev>
I just need to rebase against yours, and do a bit of cleanup (fix docs, clean up tests, etc; it's listed in my PR)
nephele_ has joined #zig
nephele has quit [Ping timeout: 260 seconds]
nephele_ is now known as nephele
<pixelherodev>
andrewrk: why are obj tests the default for errors, and not exes?
<pixelherodev>
I think it came up for me, and I needed to switch it back at some point, but I can't remember why
st4ll1 has quit [Ping timeout: 265 seconds]
st4ll1 has joined #zig
<pixelherodev>
Okay, just about done rebasing and cleaning up
<pixelherodev>
Done!
<pixelherodev>
andrewrk: mind if I ask what the problem is with the cleanup commit I posted?
<andrewrk>
I was about to take a look
<andrewrk>
did you close it?
<pixelherodev>
No, you did?
<pixelherodev>
Ohhh
<pixelherodev>
I rebased it against your branch :P
<pixelherodev>
GitHub closed it
<pixelherodev>
When you merged yours?
<andrewrk>
oh I see, github says that I closed it because I deleted the branch it was based on
<pixelherodev>
Yeah
<andrewrk>
ok, finally, you should be able to base your PR on master branch :)
<pixelherodev>
Yeah, but I can't reopen it :P
<pixelherodev>
andrewrk: if you reopen it, it should be good
<andrewrk>
which one?
<pixelherodev>
#5704
<pixelherodev>
I renamed it after your last commit
<pixelherodev>
I rebased it (`git rebase origin/zig-ast-to-zir`) and fixed collisions
<andrewrk>
I can't reopen it either. I suggest to `git checkout -b new_branch_name` and then open a PR against master with that
<pixelherodev>
It ended up just being a cleanup of the harness you added instead of adding an entirely new one, so I renamed it
<pixelherodev>
Gotcha
<pixelherodev>
Better yet, rebase against master now first :P
<pixelherodev>
#5708
<pixelherodev>
One of the biggest improvements is replacing `catch unreachable`s with `try`s :P
<pixelherodev>
There's a lot of deduplication, too
<pixelherodev>
Going to be doing a bunch more on this
<pixelherodev>
andrewrk: did you not like the idea of a Compiles stage?
<pixelherodev>
I mean, I could just add a wrapper TBH
<pixelherodev>
An error test with zero expected errors, for instance
penguinicus has joined #zig
<andrewrk>
I didn't have an opinion on it, it was just dead code
<pixelherodev>
Gotcha
* leeward
is very happy that @call has an .always_tail option.
<pixelherodev>
Todo list added to the PR
<andrewrk>
trivial to add back if the need arises
<pixelherodev>
Nah, the error wrapper's a better idea
<pixelherodev>
Code paths that aren't actually needed shouldn't be added
<pixelherodev>
That's also why I merged the Zig and ZIR paths
<andrewrk>
ah so we did the same thing? :)
<pixelherodev>
Largely :P
<pixelherodev>
Half my PR vanished with your last commit :)
<andrewrk>
beautiful
<pixelherodev>
Ended up replacing it with the cleanup
<andrewrk>
I'm sincerely sorry you had to rebase so much
<pixelherodev>
I'm sincerely not
<pixelherodev>
I learned a lot :)
<andrewrk>
but yeah I gotta reserve the right to do work in my own branch :)
<pixelherodev>
I'm going to be asking many questions about stage2 tonight and tomorrow :)
<pixelherodev>
For instance, when are positionals analyzed?
<andrewrk>
in the call graph that starts at analyzeInst
<pixelherodev>
That'll point me in the right direction, thanks :)
<pixelherodev>
Huh
<pixelherodev>
I could probably use `watch` in GDB to find it :P
<leeward>
Of course, that's a language feature, not necessarily a thing I can use: broken LLVM module found: cannot guarantee tail call due to mismatched ABI impacting function attributes
<pixelherodev>
If GDB liked Zig types a bit more
<andrewrk>
leeward, we don't have zig compile errors hooked up for that, so be very careful using it
<leeward>
andrewrk: Yeah, it looks like it's not working correctly. I have an implementation of the same function with `while` so I'll just use that until Zig is more implemented. I'm still super happy it's in the language though.
<leeward>
Trying to tail call a function that has comptime arguments...I would kinda have been surprised if it worked.
<leeward>
(also runtime args)
<andrewrk>
pixelherodev, I'm pretty particular about how I want the files which contain test cases to look like
<pixelherodev>
Righty
<andrewrk>
these files are advertisements
<andrewrk>
"put your test cases here!! it will be easy and won't take a lot of time, it will be worth it!!"
joey152 has quit [Quit: Leaving]
<pixelherodev>
Gotcha, makes sense
<pixelherodev>
hmm
<pixelherodev>
andrewrk: in that case, how about e.g. `ctx.exe` / `ctx.obj` which are the same as addExe(.Zig)?
<andrewrk>
now we're talking :)
<pixelherodev>
One of the checkboxes /is/ `add convenience wrappers` ;)
<pixelherodev>
Hmm, should the context be made static?
<pixelherodev>
There's only ever going to be one context, clearly
<pixelherodev>
we could make it `usingnamespace @import("src-self-hosted/test.zig")`
<pixelherodev>
e.g. `exe(` instead of `ctx.addExe(.Zig`
<andrewrk>
nah
<andrewrk>
that's not really the purpose of usingnamespace
<pixelherodev>
True :P
<pixelherodev>
ooh, addressing PRs I see
<pixelherodev>
I should work on other stuff and try to ddrive PR count to the triple digits lol
<pixelherodev>
andrewrk: I think `catch unreachable` *does* make sense, you're right; they should genuinely be unreachable
<pixelherodev>
also, why is chaining method calls an antipattern?
<pixelherodev>
Kakoune is definitely making `try` -> `catch unreachable` much easier
<pixelherodev>
Multi-selections = <3
<andrewrk>
a function does not need to return a parameter, the callsite already has access to the parameter, by definition
<pixelherodev>
True
<andrewrk>
it would be changing the semantics of a function to work around the language's syntax
<pixelherodev>
Well, more like to avoid paying attention to a value that is fundamentally temporary
<pixelherodev>
e.g. `case.addExe` <- we don't actually care about the returned value
<pixelherodev>
We just want to modify it a bit before moving on
<pixelherodev>
Chaining works for single-use cases though
<pixelherodev>
e.g. `case.addExe(...).addCompareOutput`
<andrewrk>
"We just want to [care about] it a bit before moving on"
<pixelherodev>
True
<pixelherodev>
I think this is actually good
icyphox has joined #zig
<pixelherodev>
Going to be getting back to real stage2 work soon
<pixelherodev>
Going to get more of the currently-disabled tests passing :)
doublex has quit [Remote host closed the connection]
doublex has joined #zig
<pixelherodev>
andrewrk: we don't care if it's more annoying to add ZIR tests than Zig ones?
<pixelherodev>
That is, `.exe` for Zig, but addExe(.ZIR) for ZIR?
<andrewrk>
.exeZIR()
<pixelherodev>
Gotcha
<pixelherodev>
Oh hey!
<pixelherodev>
Down to 48 PRs!
<pixelherodev>
That means I'm now responsible for more than 10%!
<pixelherodev>
/s
<leeward>
47 by my count
<pixelherodev>
Ah, true
<pixelherodev>
andrewrk: the PR still says Zag, the commit doesn't.
<pixelherodev>
:P
<pixelherodev>
Rebased and pushed, we'll find out the test failure shortly
satchmo has quit [Ping timeout: 246 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
cota has joined #zig
icyphox has left #zig ["WeeChat 2.8"]
dddddd has quit [Ping timeout: 258 seconds]
aerona has quit [Quit: Leaving]
ur5us has quit [Ping timeout: 240 seconds]
ur5us has joined #zig
reductum has joined #zig
doublex has quit [Ping timeout: 260 seconds]
opDispatch has quit [Quit: Konversation terminated!]
cole-h has quit [Quit: Goodbye]
ur5us has quit [Ping timeout: 265 seconds]
<wilsonk>
Ugh, my daughter spilled nail polish remover on her Macbook Pro 13" keyboard (the A1708), and I just spent hours tearing it apart and getting the new keyboard set in place!! What a pain in the ass those things are! Now I need to wait for another part and then see if I can figure out where all those microscopic screws go again...sheesh :)
watzon has quit [*.net *.split]
ky0ko has quit [*.net *.split]
rom1504 has quit [*.net *.split]
reductum has quit [Quit: WeeChat 2.8]
ur5us has joined #zig
<leeward>
That does not sound fun.
ky0ko has joined #zig
<leeward>
At least it's clean on the inside.
rom1504 has joined #zig
<torque>
I thought nail polish remover was mostly acetone, does that really screw up the keyboard? (I guess it would if the keycaps are ABS)
emekankurumeh has quit [Ping timeout: 264 seconds]
<wilsonk>
torque: yeah, they pretty much melted (looked like bad orange peeled paint). No real damage on the inside or corrosion that I can see...thankfully. It still turned on the day after the accident (after the acetone had evaporated) so hopefully things are going to work out here ;)
ur5us has quit [Ping timeout: 264 seconds]
mattmurr has quit [Ping timeout: 272 seconds]
dermetfan has joined #zig
Biolunar has quit [Quit: leaving]
r4pr0n has joined #zig
cow-orker has quit [Remote host closed the connection]
marnix has joined #zig
nycex has quit [Remote host closed the connection]
nycex has joined #zig
greenfork has quit [Ping timeout: 264 seconds]
greenfork has joined #zig
aruniiird has joined #zig
aruniiird has quit [Ping timeout: 260 seconds]
cow-orker has joined #zig
doublex has joined #zig
mattmurr has joined #zig
greenfork has quit [Ping timeout: 256 seconds]
greenfork has joined #zig
nikita` has joined #zig
mattmurr has quit [Ping timeout: 260 seconds]
recombinant has joined #zig
mattmurr has joined #zig
waleee-cl has joined #zig
dddddd has joined #zig
Snetry has quit [Ping timeout: 264 seconds]
dermetfan has quit [Ping timeout: 240 seconds]
jmiven has quit [Quit: reboot]
jmiven has joined #zig
r4pr0n has quit [Ping timeout: 240 seconds]
r4pr0n has joined #zig
<tgschultz>
I have a usage of async code that works as intended in debug and release-safe, but segfaults in release-fast. This leads me to believe I'm relying on undefined behavior, but I can't see what. https://godbolt.org/z/guD-_G
<tgschultz>
It might be a compiler bug, but I feel like it is much more likely a gap in my understanding of how async works. I'd be appreciative of insight.
decentpenguin has joined #zig
penguinicus has quit [Remote host closed the connection]
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
<marler8997>
andrewrk, new allocator interface is done, PR still needs work but the interface should be done if you want to take a look
<tgschultz>
nevermind about the above. I think I see what I missed: I made an assumption about the funcWrapper stack frame that wasn't necessarily true.
heitzmann has quit [Quit: WeeChat 2.8]
heitzmann has joined #zig
blinghound has joined #zig
<mq32>
funky things that don't make sense:
<mq32>
return return x; // is valid syntax
marnix has quit [Ping timeout: 240 seconds]
radgeRayden has joined #zig
recombinant has quit [Quit: Leaving]
<ifreund>
whut
marmotini_ has joined #zig
<marler8997>
I would expect the type of the expression "return x;" to be "noreturn" (ironically)...so I wouldn't expect return return x; to pass semantic analysis...is this the case?
aruniiird has joined #zig
<marler8997>
yeah I get "unreachable code detected" with return return x
<marler8997>
if we restricted "return" to only be a statement (not an expression) then we could make return return x a syntax error, but then you wouldn't be able to return in the middle of an expression
josias has joined #zig
<mq32>
marler8997: i thik it's just a quirk in the semantic analysis
<mq32>
current behaviour is 100% fine
dermetfan has joined #zig
penguinicus has joined #zig
decentpenguin has quit [Quit: decentpenguin]
rzezeski has quit [Quit: Connection closed for inactivity]
gazler has joined #zig
* mq32
just found a curious miscompilation
<mq32>
@field() assumes that "status" and "deleteallexcept" are equal?
gazler_ has quit [Ping timeout: 265 seconds]
<ifreund>
>Call this request with the magic received from drmGetMagic()
<ifreund>
graphics stuff is magic all the way down it turns out
<mq32>
mroe magic
Snetry has joined #zig
Snetry has quit [Read error: Connection reset by peer]
Snetry has joined #zig
rzezeski has joined #zig
Snetry has quit [Read error: Connection reset by peer]
Snetry has joined #zig
r4pr0n has quit [Quit: r4pr0n]
josias has quit [Ping timeout: 245 seconds]
cole-h has joined #zig
josias has joined #zig
kaun_ has joined #zig
kaun_ has left #zig ["chalo"]
<marler8997>
not sure if this is correct, but the Linux Azure build with the new allocator interface only took 1h 25m, it seems like before it was consistently taking over 1h 55m
<marler8997>
oh wow, and the dron CI only took 29 minutes, it usually take around 1h 15m !!!
blinghound has quit [Remote host closed the connection]
<marler8997>
sourcehut took 30 minutes, not sure how to see build times for other runs on sourcehut, anyone know?
<marler8997>
the big change here is that arraylist now takes advantage of the full capacity of allocations, if we really got this much performance boost from just that it will be incredible
penguinicus has quit [Ping timeout: 245 seconds]
<fengb>
Wow
<andrewrk>
hmm that's suspicious
<andrewrk>
seems too good to be true
<mq32>
respect
<mq32>
so, ArrayList now uses the fact that when we allocate 4 bytes, but the allocator returns 8, we don't need another allocation when we only need an additional 4 bytes more?
wootehfoot has joined #zig
<andrewrk>
right that's the main purpose of marler8997's changes
marmotini has joined #zig
<mq32>
\o/
<andrewrk>
well and avoiding double-copying for some other operations
<mq32>
awesome
<mq32>
gotta go fast
<shachaf>
whoa, is this the thing I was talking about a while ago?
* shachaf
looks at the new interface.
<tgschultz>
normally wouldn't realloc do that anyway? looking at the implementation, testing code uses a ThreadSafeFixedBufferAllocator, which unconditionally reallocs instead of seeing if it can grow in place.
<tgschultz>
what I mean is, it seems like the speed increase is an artifact of the testing allocator implementation not handling growing in place, not a direct result of the API change.
<marler8997>
yes seems suspicious to me as well...that seems like to much performance gain
penguinicus has joined #zig
<mq32>
tgschultz: this is still a sign that the optimization works
<shachaf>
Neato, I'm glad people are trying this kind of allocator API.
<mq32>
it may be less significant for other allocators, but still relevant
<marler8997>
the only other thing I see that could explain it is that I had to disable the "recursive async function" test, but I would be surprised if that one test took 30 minutes
greenfork has quit [Quit: WeeChat 2.8]
josias has quit [Ping timeout: 245 seconds]
aruniiird has quit [Quit: Leaving]
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
<leeward>
Trying to link to a Zig library from C, I'm getting errors about Zig not generating position independent code. How do I get -fPIE into ZBS?
<mq32>
grep -i "pie|pic" build.zig
<mq32>
will yield the answer
<mq32>
its a property on the libexeobjstep
<andrewrk>
foo.force_pic = true
<leeward>
Ah, pic. I was looking for pie.
<leeward>
Hmm, bundle_compiler_rt works fine, but if I set disable_stack_probing to true instead I still get undefined references to __zig_probe_stack.
<leeward>
Ah, release-fast
<leeward>
Obviously it doesn't work in safe build modes :P
<marler8997>
tgshultz, the previous API didn't allow the client to say how much data should be copied, so if an allocator needed to move memory, it would always copy the entire buffer. The new API allows the client to decide when to move memory and how much to copy
<gonz_>
More control is nice
<gonz_>
This reduction in build time is something else, though. Has anyone been able to see what it comes down to? Is it actually believable that it's from the change?
<marler8997>
the new API also allows the client to know how much is available without having to try every size. For example, if you ask for 100 bytes, but the allocator has to give you 4096 (like mmap), then there was no way for you to know that you actually had 4096 bytes available, you would just have to keep resizing until it moved memory
<marler8997>
I'll let you know if I find anything else about the build times
<shcv>
what's the right way to test that a computed string is the same as a test string?
<shcv>
though I guess the test itself may be mostly pointless
<shcv>
testing.expectEqual complains of [44]u8 vs *const[44:8]u8; I presume I need to cast one of them?
<marler8997>
std.testing.expectEqualSlices?
<ifreund>
or testing.expect(mem.eql(u8, foo, bar));
<ifreund>
which is probably what expectEqualSlices does :D
<leeward>
shcv: You have an 8-terminated slice?
<ifreund>
that does seem unusual :D
<fengb>
I never thought about it... but we can start leveraging sentinel termination with things like `const lines: [][:'\n']u8`
<leeward>
Yeah, I've been wondering if it will be useful for tokenizing.
<ifreund>
that is a good idea
<shcv>
er, sorry
<shcv>
typo
<leeward>
There's a problem if the last line of your file doesn't end with a newline though.
<marler8997>
might not be useful though because any code that takes a string ending in newline would usually also have to handle it not ending ina newline
<fengb>
Yeah, that file is wrong :P
<ifreund>
I'm rather disappointed that there isn't a valid use case for an 8-terminate slice
<leeward>
fengb: And anyone who has it deserves buffer overflows!
<leeward>
I can imagine something like a [:0xffff]u16 being useful somewhere.
<fengb>
ASCII 8 = SOH. What's SOH?
<leeward>
Um, 8 is BS.
<leeward>
SOH is 1
<leeward>
(Start of Heading)
<fengb>
... I'm reading this chart wrong
<shcv>
SOH would be a particularly odd terminator
<shcv>
BS is kinda funny though
<companion_cube>
there's a bunch of useless junk in ascii
<leeward>
It's like the ascii version of <h1>
<leeward>
er, <head>
<fengb>
Yeah it's BS. Ones are vertical in this chart
<leeward>
That chart is BS.
<marler8997>
lol
<fengb>
"ASCII was developed from telegraph code."
<marler8997>
ok speed boost is gone, I don't know what happened, both dron and azure showed speed boosts but now the latest run doesn't have them
<ifreund>
too bad
<fengb>
It was a one time turbo feature
<marler8997>
too good to be true
<leeward>
It was a taste of the future.
<leeward>
Maybe they let you run on their super-secret good silicon by accident.
<shcv>
hmm, still getting "expected type '[]const u8', found '[44]u8'"
<shcv>
need to read more about the type system I guess
<fengb>
That's an array. Gotta convert to slice using `&array`
<marler8997>
leeward, yeah they did it just to tease me
<shcv>
magic
nycex has quit [Remote host closed the connection]
nycex has joined #zig
<fengb>
Arrays are raw bytes in Zig. When you pass around an array, it's actually (sorta) copying the bytes directly
wootehfoot has quit [Ping timeout: 265 seconds]
<tgschultz>
marler8997: i'm not disputing the utility of the new allocator API, only the degree to which it is responsible for any improvement in speed in CI. Seems I was wrong anyway.
dermetfan has quit [Quit: WeeChat 2.7.1]
wootehfoot has joined #zig
dermetfan has joined #zig
<shcv>
how do I construct a Reader from a buffer? Or is there a better way to split one into an ArrayList by newlines?
<leeward>
.reader
<leeward>
oh
<leeward>
a buffer
<mq32>
shcv: std.mem.separate()
<mq32>
apply it to ArrayList.items
<shcv>
ok
<leeward>
Do what mq32 said, but if you ever want to get a reader from a buffer, make a FixedBufferStream and call .reader() on it.
<mq32>
or just call ARrayList.reader() :D
<mq32>
when you have an arraylist anyways
<leeward>
Right, if you have an ArrayList.
<mq32>
#justOneObviousWayToDoThings
<shcv>
heh
<leeward>
I was thinking a [_]u8
<shcv>
it's apparently been renamed from separate() to split()
<leeward>
That's a good name.
<mq32>
ah, finally
emekoi has quit [Ping timeout: 240 seconds]
ur5us has joined #zig
<andrewrk>
see also tokenize()
<shcv>
how do I use the iterator with a loop?
<andrewrk>
while (it.next()) |item| { ... }
<shcv>
ah
<andrewrk>
`while` and `if` support the same syntax regarding optionals and error unions
<ifreund>
do we not have a setenv implementation yet?
<ifreund>
maybe I should add one
marmotini has quit [Ping timeout: 240 seconds]
<shcv>
how do I append to a file?
nikita` has quit [Quit: leaving]
<andrewrk>
ifreund, what for? the child process API supports passing a different environment set
<leeward>
shcv: file.seekTo(try file.getEndPos)) then write to it?
<leeward>
er, file.getEndPos()
<andrewrk>
file.seekFromEnd(0)
<shcv>
I tried file.seekFromEnd(0)
<shcv>
so I think I must have opened it wrong?
<leeward>
Mm, that does seem like it would work.
<andrewrk>
what happened instead of the expected behavior?
<shcv>
I did createFile with exclusive = false, seeked to the end, and used file.outStream.print(); it overwrite the file with the line I printed
<shcv>
so if I call the function twice, the file only contains the second line
<andrewrk>
exclusive = false is the default, so that didn't change anything. you need to do .truncate = false
<shcv>
ok
<shcv>
that worked; thanks
<andrewrk>
np
<ifreund>
andrewrk: so it does, though it's a little more conveniento set it once so that I don't have to remember every time I spawn a child
<andrewrk>
that affects global state in a potentially problematic and tricky to debug way
<marler8997>
you might want to be able to call setenv if you are calling an external library that uses getenv for configuration (this is pretty common in libraries)
<andrewrk>
sure if you're interacting with C code then the C environment block becomes part of the API
<marler8997>
ok that workds
<ifreund>
hmm, so my options are calling libc's setenv (what I'm doing right now), modifying std.c.environ manually, or setting it for each child process
wootehfoot has quit [Quit: Leaving]
<ifreund>
I agree, it make sense not to have a way to do this when not linking libc
slowtyper has quit [Ping timeout: 256 seconds]
neptunepink has quit [Ping timeout: 256 seconds]
neptunepink has joined #zig
Biolunar has joined #zig
shcv has quit [Ping timeout: 240 seconds]
<Snektron>
andrewrk, do you know which part in stage1 analyzes tuple to array cast in parameters? The general implementation is a TODO, but `fn a(b: [3]u8) void {} a(.{1, 2, 3});` seems to compile fine
dermetfan has quit [Ping timeout: 260 seconds]
dimenus has joined #zig
<dimenus>
i very much appreciate how seamless it is to use Zig on my pbp :)