companion_cube has quit [Ping timeout: 260 seconds]
_whitelogger has joined #zig
a_chou has joined #zig
a_chou has quit [Remote host closed the connection]
a_chou has joined #zig
a_chou has quit [Remote host closed the connection]
_whitelogger has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #zig
sord937 has joined #zig
cole-h has joined #zig
<scientes>
g-w1, do you have a paste with the code
<scientes>
if this is LLVM I am intimately aware of LLVM's switch optimization code
<scientes>
but it appears it is zir
sord937 has quit [Ping timeout: 240 seconds]
sord937 has joined #zig
mikdusan has quit [Quit: WeeChat 2.5]
FireFox317 has joined #zig
x1212 has joined #zig
FireFox317 has quit [Remote host closed the connection]
FireFox317 has joined #zig
mikdusan has joined #zig
quint2 has joined #zig
quint2 is now known as quint
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
pixelher- has joined #zig
pixelher- is now known as pixelherodev
kbd has joined #zig
cole-h has quit [Ping timeout: 264 seconds]
<pixelherodev>
Is the nested expr really the best way to specify it? (I'm not saying I can do better, it's just really unpleasant in my fully subjective opinion)
<shachaf>
I'm used to AT&T syntax but maybe I should get used to Intel syntax one of these days.
<shachaf>
Even though the ideal one would probably be somewhere between them.
<pixelherodev>
Meh, the exprs are fine, I just needed my shot of tea before getting to work in the morning :)
gazler has joined #zig
kbd has quit [Ping timeout: 258 seconds]
kbd has joined #zig
kbd has quit [Client Quit]
so has quit [Ping timeout: 264 seconds]
<pixelherodev>
Am i reading the grammar wrong, or is `3 + @import("a.zig")` technically grammatically (but not semantically) valid?
<ifreund>
that's righ
<pixelherodev>
The import seems to propagate upwards into a Primar - ah
<pixelherodev>
Why?
<ifreund>
you can tell because zig format doesn't complain
<pixelherodev>
To avoid special-casing builtins?
<ifreund>
@import() just returns a type
<pixelherodev>
Huh.
<dutchie>
a struct?
<dutchie>
i guess a struct is a type
<pixelherodev>
Why is `type + 3` valid?
<pixelherodev>
TypeExpr propagates into a valid MultiplyExpr...
<ikskuh>
pixelherodev: because `type` is just a value like `false` or `1.0`
<ifreund>
I don't see anything wrong with that being valid grammer, no need for special casing types here
<ikskuh>
^=
<pixelherodev>
I guess that makes sense...
<ikskuh>
types are just values
<ikskuh>
struct{} + enum{}
<ikskuh>
is also valid
so has joined #zig
<pixelherodev>
Whelp, my imports are technically going to be a bit overstrict for now, I'll fix it later
<ikskuh>
that's also a syntactically valid type :D
<pixelherodev>
Parsers are fun :D
<ikskuh>
yes
<ikskuh>
stress-testing parsers even more
<pixelherodev>
Heh - do we have parser-specifictests in the official repo?
<pixelherodev>
... wait, dumb question
<pixelherodev>
The most we *could* have is "Does it error correctly?"
<pixelherodev>
Or, rather, "Does it *look* right?"
<pixelherodev>
Anything more requires actually testing the generated tree, which is parser-dependent (for now!)
<ikskuh>
you can just have a list of "must be accepted" and "must not be accepted"
<ifreund>
^
<ifreund>
and you can trivialy use zig fmt to check test cases
<ikskuh>
zig fmt is using stage2 parser already, right?
<ifreund>
yes
<ikskuh>
ah, nice
<pixelherodev>
ikskuh: yes, but that's partial
<pixelherodev>
"Accepted" != "parsed correctly"
<ikskuh>
right now, that's fact :D
<pixelherodev>
"Not accepted" doesn't test *why*
<pixelherodev>
ikskuh: not if the parser I want to test is mine ;)
<ikskuh>
why?
<ikskuh>
just create a random string
<pixelherodev>
because mine accepting input doesn't prove it parsed it into the right tree
<ikskuh>
check if your parser has the same acceptance as zig fmt
<ikskuh>
:D
<pixelherodev>
Fuzz test every possible string using accepted characters from zero char to 512 chars against zig fmt acceptance? ;P
<pixelherodev>
that's...
<ikskuh>
how we solved a haskell programming task at uni
<pixelherodev>
I mean, if this was a 512-bitstring that'd be 13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084096 different strings.
<pixelherodev>
but it's not a bitstring. It'dbe *so much worse* ;P
<pixelherodev>
A smart fuzz tester, changing e.g. ident->lparen->builtin would probably be feasible
<ikskuh>
other idea:
<pixelherodev>
Don't bother?
<pixelherodev>
That's my idea
<ikskuh>
generate a random AST, output it with zig fmt
<ikskuh>
parse that again
<pixelherodev>
Can't ;P
<ikskuh>
you can
<pixelherodev>
My AST isn't compatible with zig's, can't output itto fmt
<ikskuh>
you can
<ikskuh>
use stage2 ast
<ikskuh>
to generate random sources
<ikskuh>
and parse these again
<pixelherodev>
Ahhh, then test parsing them withmine?
<pixelherodev>
Gotcha
<pixelherodev>
That's what Ib was talking about re: smart fuzz tester :)
<pixelherodev>
ikskuh: that's not a bad idea, yeah
<pixelherodev>
especially if I add a naive zig backend that can replicate zig fmt lol
<sharpobject>
is someone aware of a nice json and websocket implementation
<ifreund>
sharpobject: for json see std.json
<sharpobject>
ty
<pixelherodev>
huh, uN types are just IDENTs? That's neat
<koakuma>
Debugging with gdb shows that the parameters are set correctly
<koakuma>
But as I said before, the first addition somehow returns junk
wootehfoot has joined #zig
<mikdusan>
koakuma: added a quick thing to try in your gist
<koakuma>
It returns the correct result!
<koakuma>
How come?
<mikdusan>
not sure. try the next thing in gist.
<koakuma>
It works too
<koakuma>
This is weird
<mikdusan>
smells like something to do with stack
<mikdusan>
are you on sparcv9 target?
<koakuma>
Yes
<mikdusan>
seeing if I can build your fork; and get a zig-ir dump
donniewest has joined #zig
<mikdusan>
oh old version. llvm10
<mikdusan>
yeah I'm not going to be able to easily use that... my version of macos is just not compat with older zig
<koakuma>
mikdusan: Use the sparc64-libs branch, that's where I do my work
<mikdusan>
hmm anyone recall how to disable stackprotected/stackguard
<mikdusan>
ah -fno-stack-check
<mikdusan>
koakuma: another one to try
<mikdusan>
whups had the fn named as entry. fixed now.
leon-p has joined #zig
<koakuma>
It doesn't work, prints the wrong result
<mikdusan>
it's as if there is an undefined bit(s) of memory somewhere and we just get lucky by padding the stack before first call. then it gets set during the call, and helps each subsequent call because it's the same call stack/params repeated
<koakuma>
I think I know what's the problem
<koakuma>
The SPARC ABI needs us to reserve six 64-bit words in the stack frame at startup
<koakuma>
When I wrote the startup code, I forgot to account for that
<koakuma>
If it's really stack-related then adding the required reserved area should be enough to fix it
<mikdusan>
for just the first frame or all frames?
<koakuma>
Just for the first frame, I think
<mikdusan>
probably not same thing, but TIL about sparc v9 stack bias
Akuli has joined #zig
<koakuma>
Adding the reserved area didn't seem to fix it :(
sord937 has quit [Ping timeout: 240 seconds]
wootehfoot has quit [Ping timeout: 246 seconds]
lanodan has joined #zig
sord937 has joined #zig
pfg_ has joined #zig
leon-p has quit [Ping timeout: 272 seconds]
leon-p has joined #zig
waleee-cl has joined #zig
pfg_ has quit [Quit: Leaving]
hnOsmium0001 has joined #zig
wootehfoot has joined #zig
kbd has joined #zig
a_chou has joined #zig
a_chou has quit [Client Quit]
sawzall has quit [Read error: Connection reset by peer]
sawzall has joined #zig
sawzall has quit [Read error: Connection reset by peer]
sawzall has joined #zig
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
<pixelherodev>
`while(foo) : (bar) { baz; }` is always identical to `while(foo) { baz; bar; }`, right?
<pixelherodev>
Or is the contexpr only evaluated conditionally?
<pixelherodev>
if this was C, I'd guess it wa sa shadowing thing
<pixelherodev>
but we're not
<mikdusan>
it's always evaluated; that is `continue` will not short-circuit it
kbd has joined #zig
<pixelherodev>
Ahhhh, okay; thanks!
sawzall has quit [Read error: Connection reset by peer]
<ifreund>
if it were always the same it probably wouldn't exist :P
<pixelherodev>
Hence the question
sawzall has joined #zig
cCCCCcccccCCc has quit [Ping timeout: 256 seconds]
<leeward>
I believe `while (foo) { defer bar; baz; }` is the same as `while (foo) : (bar) { baz; }`
craigo has joined #zig
<pixelherodev>
leeward: I believe so as well, yeah
<ifreund>
nope
<ifreund>
continue doesn't run defers
<ifreund>
or wait does it?
<andrewrk>
it does
<ifreund>
does break not?
<andrewrk>
what you're thinking of is that `break` will also run the defer but you don't want it to
<ifreund>
right, yeah that's exactly what I was thinking of
<pixelherodev>
Ahh,right
<pixelherodev>
andrewrk: thanks for clarifying :)
semarie_ has joined #zig
semarie has quit [Killed (egan.freenode.net (Nickname regained by services))]
semarie_ is now known as semarie
remby has joined #zig
cCCCCcccccCCc has joined #zig
<justin_smith>
am I doing something dumb here? `if (v) "#" else "."` is returning "#" for both true and false input
<justin_smith>
it's inside a print where I also print v, and I see that v does actually vary between true and false
<justin_smith>
if I use a literal true or false in the form it works as expected
<ifreund>
justin_smith: probably need to see code
<justin_smith>
maybe this is caused because it's inside a print?
<andrewrk>
wtf I just got MITM attacked by my ISP when I clicked that link
<justin_smith>
wow, weird
<leeward>
time to switch DNS providers?
<andrewrk>
they did it with http injection, I'm using 1.1.1.1
<andrewrk>
"for my protection" they said
<andrewrk>
justin_smith, you might be hitting a compiler bug with if statements inside anon tuples
<andrewrk>
sorry
<ifreund>
my ISP likes to do that too, so I started using a VPN all the time
<justin_smith>
andrewrk: OK - so I at least know a workaround then
<marler8997>
how did you find out windows CI was running out of memory?
<andrewrk>
it's one of the only ways to get killed with no error message or stack trace
<marler8997>
ah
<andrewrk>
it's also been a problem that has plagued us for months now
<marler8997>
is it possible to fix that issue on the CIs?
<andrewrk>
let's just say I'm really motivated to get this new compiler implementation off the ground
<marler8997>
no error message on OOM
<marler8997>
I'm not too familiar with how OOM works on windows...might need to research that one
<marler8997>
from a quick glance, it doesn't look like windows has an OOM killer, so how is this behavior on the Windows CI occuring? It kills processes with no errors?
<g-w1>
is there a decided struct/(tagged)union layout for stage2? or will all the backends just improvise? if I were to impliment this, are there any guidelines for this other than intuition?
<g-w1>
thinking about this for error sets, so I guess it could be a little easier since its just union(enum) { code: u16, payload: T }
<g-w1>
*error union
<ifreund>
I assume they should be laid out in whatever way makes the most sense for the backend. That's kinda the point of non having a well-defined memory layout
<g-w1>
I have no experience with laying out memory, are there any guidelines/resources?
ofelas has joined #zig
<andrewrk>
marler8997, I think you have access to the logs right? if you click the red x from master branch commit history
craigo has quit [Ping timeout: 265 seconds]
<andrewrk>
g-w1, hmm I'm trying to remember what resources I used to learn. I think I just played with a bunch of clang output to see what it did for various things
<marler8997>
I do yes, I've looked through the logs before and never saw anything about processes being killed, just that they exit with a non-zero exit code
<g-w1>
also, andrewrk: #7092 should be ready for review now. no pressure, just informing you that it is ready
<andrewrk>
thanks!
<remby>
g-w1: in general or for zig?
<andrewrk>
marler8997, the most recent failed on says "LLVM ERROR: out of memory" at the bottom
<g-w1>
general/stage2
<andrewrk>
which is presumably LLVM's malloc wrapper panicking
notzmv has quit [Remote host closed the connection]
<marler8997>
my strategy, keep rebasing until someone else fixes the CIs :)
<andrewrk>
I apologize for the churn and I do appreciate that
<marler8997>
you gotta do what you gotta do, balance between dev speed and stability
<andrewrk>
yeah. thanks for understanding
Patrice_ has joined #zig
freshmaker666 is now known as greeb
ky0ko has joined #zig
SebastianKeller has joined #zig
cole-h has joined #zig
sebonirc has joined #zig
ifreund has quit [Ping timeout: 260 seconds]
mschwaig has quit [Quit: WeeChat 2.7.1]
mschwaig has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
sord937 has quit [Quit: sord937]
mschwaig has quit [Quit: WeeChat 2.7.1]
mschwaig has joined #zig
Akuli has quit [Quit: Leaving]
kbd_ has joined #zig
mschwaig has quit [Quit: WeeChat 2.7.1]
kbd has quit [Ping timeout: 264 seconds]
notzmv has joined #zig
mschwaig has joined #zig
sawzall has quit [Read error: Connection reset by peer]
bitmapper has quit [Quit: Connection closed for inactivity]
x1212 has quit [Quit: Leaving]
donniewest has quit [Ping timeout: 268 seconds]
donniewest has joined #zig
donniewest has quit [Ping timeout: 256 seconds]
donniewest has joined #zig
donniewest has quit [Client Quit]
kbd_ has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
Patrice_ has quit [Ping timeout: 268 seconds]
remby has quit [Ping timeout: 240 seconds]
jsb has quit [Quit: .]
jsb has joined #zig
mschwaig has quit [Quit: WeeChat 2.7.1]
remby has joined #zig
mschwaig has joined #zig
<FireFox317>
andrewrk, #7700 :)
<andrewrk>
wow, both the issues! nice work!
kbd has joined #zig
<FireFox317>
yep! They were fun to figure out :)
<FireFox317>
especially the alloca hoisting one
<pixelherodev>
and it has a nice solid number :)
<andrewrk>
FireFox317, nice, I like the way you set up the functions inside the opaque context
jmiven has quit [Quit: reboot]
<FireFox317>
considering whether i should store the latest alloca instruction or store the instruction after the latest alloca instruction was a fun tradeoff
jmiven has joined #zig
<FireFox317>
andrewrk, i do think we can actually move the llvm_backend.zig file into src/codegen/. that is probably a good improvement
<andrewrk>
src/codegen/llvm.zig and src/codegen/llvm/bindings.zig ?