<andrewrk>
when I look at this, it makes me ask the question, "wtf why is 'NotDir' one of the possible errors for getting the path to your own executable?"
<andrewrk>
...which is a good question, which leads to understanding the code deeply, and possibly improving the logic
<pixelherodev>
And with *everyone* seeing that through stdlib *while they use it* for instance...
<andrewrk>
yeah. my hope is that it will lead to more robust software, that ultimately is a better user experience for the end user
<pixelherodev>
Roughly 6.1 seconds to load the manual, longer to be able to access the table of contents in the sidebar :P
<pixelherodev>
~nine seconds until manual is usable. Every single one of my Zig projects compiles faster than that *on my laptop*, let alone with my PC builder
<pixelherodev>
Also I just wasted time modding my stopwatch script to show milliseconds just so I could measure it. This is why I never get anything done lol
<pixelherodev>
Oh, and andrewrk: my biggest takeaway from yesterday's stream is that I'm not the only one who uses gas + objdump to figure out x86 encodings :D
<pixelherodev>
That's literally how I tested my JIT initially, before I added a proper test suite
<pixelherodev>
"Does it agree with as?"
<pixelherodev>
I'm going to overcomment the codegen, so that anyone reading can use it to figure out the manual :P
<andrewrk>
haha yeah I spent a bunch of time trying to read docs and tbh basically gave up
<pixelherodev>
I figured it out, eventually
<pixelherodev>
But only because I could compare against gas to prove myself right
<andrewrk>
I'll return to it again at some point, but for now I'm unblocked to work on the other components
<pixelherodev>
Or, more often, ocmpletely and utterly wrong
<pixelherodev>
Yeah, it's really annoying
<andrewrk>
yeah... my intuition has been correct 0/3 times
<pixelherodev>
Maybe my comments will prove enlightening :)
<andrewrk>
:)
<pixelherodev>
andrewrk: is it okay if I tag the x64 register enum?
<pixelherodev>
Each register has a 4-bit id
<pixelherodev>
... wait that's a dumb question, that's literally the point of what I'm doing
<pixelherodev>
What else am I going to do, implement a giant switch? :P
<pixelherodev>
Oh wait, now I remember why I didn't do an enum for mine
<pixelherodev>
Multiple values share an id
<pixelherodev>
e.g. rax and eax both have id zero
<andrewrk>
pixelherodev, just do what seems right to do, and explain it to me in the PR and we'll figure it out
<pixelherodev>
:)
<andrewrk>
oh boy, 46 pull requests
<pixelherodev>
Sheesh
<andrewrk>
after this branch is merged I'm going to have to pay the pied piper
<pixelherodev>
That's a lot of contributions :)
<pixelherodev>
Might as well update x86 while I'm at it
<pixelherodev>
Going to turn it from an enum to a tagged union (Reg8, Reg16, Reg32, Reg64)
<pixelherodev>
Need to ensure we don't give e.g. r10l as a 32-bit reg
<GreaseMonkey>
if you're having trouble with x86 encoding, this site helps: https://www.sandpile.org/
<pixelherodev>
Interesting optimization idea that only occurred to me because of this situation: when passing a tagged union for which all values other than a single tag produce unreachable, in optimized builds, the compiler could just pass the underlying type directly and optimize out the check, correct?
<pixelherodev>
GreaseMonkey: thanks, but I'm good
<pixelherodev>
Manual is annoying, but it's worth it to me
<andrewrk>
GreaseMonkey, nice! thanks for the link
<pixelherodev>
... that does look good... no, no, I'll stick to the manual! Intel engineers must have put in the effort making it, it'd be wrong not to use it!
<pixelherodev>
Jokes aside
<pixelherodev>
Mind if I move the arch-specific stuff into a separate file?
<pixelherodev>
e.g. Reg(.x64) will return @import("arch/x64.zig").Register?
<andrewrk>
that sounds nice
<andrewrk>
are you leaving e.g. the genRet function tho?
<GreaseMonkey>
do the Intel CPU manuals have bit fields where you have a group of bits saying "reserved", followed by a single bit saying "reserved", followed by another group of bits saying "reserved"?
<pixelherodev>
Yeah
<pixelherodev>
Only focusing on register definitions and moves for now
<pixelherodev>
GreaseMonkey: I dunno, why?
<pixelherodev>
There's definitely some reserved bits that are sequential but defined
joey152 has quit [Remote host closed the connection]
<pixelherodev>
e.g. "this was reserved for X, so must be 0 for now; this is reserved for Y, so must be zero"
<pixelherodev>
But I don't see anything like that at a "quick" glance
<GreaseMonkey>
i keep thinking i've seen that phenomenon in the GPU manuals where it just says "reserved, SBZ" or something
<pixelherodev>
andrewrk: idea regarding arch-specification
<pixelherodev>
Instead of having a single genRet (as you mentioned) that switches over the arch, should there be e.g. x86.genRet / ARM.genRet in their own backends, with the main codegen just setting the backend?
<pixelherodev>
That makes it easier IMO to extend down the line
<pixelherodev>
No need to sift through the x86 code to extend the ARM backend, for instance
<pixelherodev>
That's a larger scale refactor though, so I'm definitely not doing it *now*
<pixelherodev>
That would come later
<andrewrk>
maybe, I think it's worth considering. my goal is to make the code really contributor friendly, so that it is inviting to work on adding new architectures. I'm sure the code will evolve over time to achieve that goal
<pixelherodev>
That's what I was thinking of when I suggested this
<pixelherodev>
Especially as we actually implement backends, we're going to need some form of organization
dnmllr has joined #zig
xackus has joined #zig
dnmllr has quit [Client Quit]
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk>
pixelherodev, `./zig build test-stage2` passing tests in 294bfb3321f
slice has quit [Quit: zzz]
slice has joined #zig
backwhack has joined #zig
stripedpajamas has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
slowtyper has joined #zig
metaleap has joined #zig
<pixelherodev>
:)
aerona has quit [Quit: Leaving]
stripedpajamas has joined #zig
dddddd has quit [Ping timeout: 264 seconds]
foobles has joined #zig
redj has quit [Read error: Connection reset by peer]
kenaryn has joined #zig
<kenaryn>
Hello, please in a few words, can someone explain to me why we switched from `warn("Hello, world!\n")` in zig 0.5.0 to `warn("hello, world!\n", .{})` in 0.6.0?
redj has joined #zig
<foobles>
variadic functions were removed
<foobles>
kenaryn
<foobles>
so now the arguments are passed in as a required tuple parameter
redj has quit [Read error: Connection reset by peer]
<kenaryn>
It's a clear explanation, thank you foobles.
stripedpajamas has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<kenaryn>
Does the leading dot before the curly breaces mean that the whole statement is from now on a enum?
<foobles>
it means it's an anonymous struct/tuple
<foobles>
basically it creates a new type on the spot
<foobles>
that may be able to coerce to a named tuple/struct type
<foobles>
and doing `.identifier` is an anonymous enum literal
<foobles>
that can coerce to a value of a named enum as well
<foobles>
by "anonymous tuple/struct", i dont mean its declaring a type; rather it's declaring an instance of an anonymous type, with the provided fields
<kenaryn>
I understand, you're very kind.
<foobles>
no problem :)
kenaryn has left #zig [""Have a nice day.""]
backwhack has quit [Quit: Connection closed for inactivity]
cole-h has quit [Quit: Goodbye]
halbeno has quit [Remote host closed the connection]
halbeno has joined #zig
foobles has quit [Ping timeout: 245 seconds]
dermetfan has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
dermetfan has quit [Ping timeout: 260 seconds]
pystub has joined #zig
FireFox317 has joined #zig
ur5us_ has joined #zig
alexnask has joined #zig
ur5us_ has quit [Quit: Leaving]
ifreund has joined #zig
_Vi has joined #zig
slice has quit [Quit: zzz]
ikskuh has quit [Ping timeout: 256 seconds]
mq32 has joined #zig
waleee-cl has joined #zig
dddddd has joined #zig
nycex has quit [Remote host closed the connection]
nycex has joined #zig
* daurnimator
is trying to get something working with tizen and zig..... this is not easy
<sjm>
for the line "while (try it.next()) |item| {"
<alexnask>
Your function returns void
<alexnask>
It should return !void or InsertYourExplicitErrorSet!void
pystub has quit [Quit: Leaving.]
Akuli has joined #zig
<sjm>
alexnask: ahh. thanks.
<r4pr0n>
andrewrk: hey, how did you actually do the completion in your livestream? i'm not aware that vim is type-aware or something like that and that the completion works across files (that vim knows in which files to look...)
<r4pr0n>
i also couldn't find anything about it in your vimrc
<mikdusan>
while inserting text, type a minimal amount of letter(s) and hit ctrl-x,tab
<andrewrk>
you can get surprisingly far with the simple token-based ctr+n completion
<r4pr0n>
well that doesn't search in other files for the token for me
<ifreund>
r4pr0n: it should search all open buffers by default iirc
<r4pr0n>
oh
<r4pr0n>
that makes sense
<andrewrk>
it even searches in buffers that you opened once and then closed
<r4pr0n>
good to know, thanks
bren077s has quit [Quit: -a- Connection Timed Out]
bren077s has joined #zig
<ifreund>
andrewrk: thoughts on removing the panic from std.log.fatal and letting the caller decide if a panic is needed?
<andrewrk>
ifreund, in this case, we may as well remove "fatal" entirely, in favor of err followed by panic, right?
<andrewrk>
that might make sense. we can also define the default panic handler to log an error before aborting
<ifreund>
hmm maybe fatal would still have a place as the highest tier of error than can't be filtered out
<ifreund>
i'm not sure about that though, getting rid of it completely would also make sense
<ifreund>
software written in zig hopefully wont be logging so many errors that ignoring them is desireable
<andrewrk>
we're going to want the concept of setting different log levels per package
<andrewrk>
we already want this for other things
<andrewrk>
such as optimization mode
<andrewrk>
I have some ideas on how to set this up but haven't completely solved it yet
<andrewrk>
one idea is that @import("builtin") could give you different values for each package
<andrewrk>
the problem there is when std lib accesses it on behalf of a different package
<andrewrk>
it would get its own @import("builtin") and not the callsite's @import("builtin")
<ifreund>
i'm working on adding some kind of "scope" parameter to the logging functions that would allow for more finely grained filtering
<ifreund>
i'd like to make it something more that just a []const u8, but i haven't found a way to abuse enums and comptime enough yet
<andrewrk>
idea being that you could accept a comptime parameter such as `callsite: sourcelocation`
<andrewrk>
and you would call it with log.warn(@src(), "{}", .{foo})
<andrewrk>
this is introducing a new type called `sourcelocation` which you would be able to use to access properties about the callsite, such as the optimization mode of the scope, log level of the scope, float mode of the scope, etc
<andrewrk>
possibly also put line/column/file info in the log messages
<ifreund>
that seems super powerful
<andrewrk>
yeah more consideration is needed before accepting this idea, to make sure it's not too powerful and problematic. but it might solve a few problems for us
<andrewrk>
the actual implementation would not be very difficult, I think
<ifreund>
hmm, would it give info about the callstack as well? if so we could call this internally to std.log and look at whatever called it
<andrewrk>
not sure I follow
<ifreund>
no that was a bad idea, it doesn't make any sense :D
<ifreund>
i was trying to think of some way to avoid having to pass @src() every time you log
<andrewrk>
ah I see. I understand the desire to remove it but I think it's simpler to make it explicit
<andrewrk>
it's not really possible to change this without some invasive language feature such as macros
<ifreund>
yeah, say no to macros kids
<r4pr0n>
while I don't have any better idea at the moment, changing std.debug.warn to need such an parameter makes it even longer, which it already got through the switch from varargs to tuples
<r4pr0n>
that may be a problem since it is often used as a debug tool
bren077s has quit [Quit: -a- Connection Timed Out]
bren077s has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
dingenskirchen has quit [Client Quit]
dingenskirchen has joined #zig
Nilium_ has joined #zig
dimenus|home has joined #zig
Nilium has quit [Ping timeout: 264 seconds]
Nilium_ is now known as Nilium
cole-h has joined #zig
Nilium has quit [Quit: <kristin> Cower is like... I dunno. sometimes he seems senile and other times he seems like a middle schooler.]
Nilium has joined #zig
wozeparrot has joined #zig
<alehander92>
hm, do you have currently sourcelocation-like primitive
<alehander92>
a cool thing in nim is that one can pass a parameter to `instantiationInfo`, so you can get compile time info upper in the "expanding stack" for your sourcelocation
<alehander92>
but not sure if this happens actually in zig, as you dont have templates
<pixelherodev>
where `a()` returns `!T`, `return a();` isn't mentioned there as valid
<pixelherodev>
Just about done with the x64 genSetReg rework
<pixelherodev>
All I need to do is implement ethe register type and every single register should be usablle
<pixelherodev>
s/ll/
<ifreund>
pixelherodev: oh i see what you mean, yeah it'll let you do that
<pixelherodev>
Neato
<andrewrk>
pixelherodev, in most of the code paths in codegen.zig you can fail with garbage inside the "code" ArrayList. it won't get used if you report/return an error
<andrewrk>
looks like you're doing some clean refactorings!
<pixelherodev>
The one thing that's probably going to need a few iterations is the Register type
<pixelherodev>
Currently, I'm using a structure with a `width` enum (W8,W32,etc), u4 `id`, etc
<andrewrk>
pixelherodev, regarding u128, I think you can get a sense for how that will work by looking at MCValue
<pixelherodev>
Might be worth defining an enum containing all the registers and writing an automatic converter
<pixelherodev>
So that `x64Reg(.EAX)` becomes the structure automatically or something
<pixelherodev>
andrewrk: good to know, thanks
<andrewrk>
yeah keep in mind this code is brand spanking new, so maybe some of the ideas in there, which are just the first thing I thought of, are going to be iterated on or reworked
<pixelherodev>
That's completely fine
<pixelherodev>
If anything, that means more ideas on how to improve my own backends
<pixelherodev>
Except I'm doing mine more for fun than anything else so I'm not moving nearly as quickly as you are :)
<andrewrk>
gotta go fast
<pixelherodev>
Once this is done, I might e.g. implement function calls and such
<pixelherodev>
See if I can't help finish off that merging checklist
<pixelherodev>
:)
<pixelherodev>
Actually... I can probably leave the registers as enums!
<pixelherodev>
enums can have methods IIRC, which means it can just be a giant switch internally
r4pr0n has quit [Remote host closed the connection]
<andrewrk>
one idea that I think might turn out quite nice is converting the arch tag value into a comptime parameter early on in the call stack, and so that the arch is available as comptime value pretty much everywhere in that file
<andrewrk>
that's a way of organizing a compiler backend that is unique to zig
<pixelherodev>
That would be really nice, yeah
slowtyper has quit [Ping timeout: 260 seconds]
xackus has quit [Read error: Connection reset by peer]
<andrewrk>
atomicity is *not* needed for that code arraylist, to be clear
xackus has joined #zig
<pixelherodev>
I saw
<pixelherodev>
I might still try to ensure it's atomic anyways
<pixelherodev>
Because it might be useful later anyways, and as far as I can tell it currently is atomic in most uses
<pixelherodev>
Oh, and that compiler backend organization might be unique to zig the language, but it's not unique to `zig` the compiler :)
<pixelherodev>
I'm already using it for mine
slowtyper has joined #zig
<pixelherodev>
ifreund: thanks for suggesting the static build
<pixelherodev>
auto-formatting is working again :)
slice has joined #zig
<pixelherodev>
Came up with a nice organization for the register enum that makes it efficient to check IsExtended and such
<pixelherodev>
:)
<ifreund>
nice!
<andrewrk>
pixelherodev, I'm not sure what you mean about "atomic" because it's not in any sense. the array gets resized before written to, and even appends to array lists are not atomic
<andrewrk>
if `generateSymbol` returns an error, the value in `code` is ignored
<pixelherodev>
I mean that either it returns unmodified or it returns resized and with all bytes written to it
<andrewrk>
plus it would be really easy for the wrapping code - not the individual functions - to remember the original length of the array and shrink it in case of an error