<andrewrk>
ifreund, I went down a rabbit hole and messed with astgen for `and` and `or`: https://clbin.com/rgRCc
<andrewrk>
pushing shortly
<andrewrk>
side note, it might be nice to have --verbose-ir print all the const @ values at the beginning
craigo has quit [Quit: Leaving]
<ifreund>
andrewrk: nice, I noticed the inefficiency there and left a nonsensical TODO comment you probably saw but didn't try the step of making dedicated zir instructions for them
<andrewrk>
yeah you baited me with that comment haha
<ifreund>
:D
layneson has joined #zig
layneson has quit [Quit: WeeChat 3.1]
<andrewrk>
I wonder if my changes were enough to convince LLVM to inline the switchbr into each prong in analyzeBody
<ifreund>
andrewrk: why are bool_and and bool_or still around when we have bool_br_and/or?
<andrewrk>
they're unused and can be deleted
<andrewrk>
I think we use those ops in stage1 tho
<andrewrk>
which is to say, if you want to play the YAGNI card and delete them, I won't argue, but maybe it would be ok if they stay too
<ifreund>
yeah just realized that I didn't use them for the previous and/or astgen either
<ifreund>
My take is if we need non-shortcircuiting and/or semantics somewhere in zir, we've found a very odd edge case in the language that maybe shouldn't exist
<andrewrk>
feel free to delete them, always easy to resurrect
<ifreund>
I do love deleting code :)
<ifreund>
nicely done on GenZir.setBlockBody() by the way, that's so much cleaner than copyBodyNoEliding()
<andrewrk>
thanks
brzg has joined #zig
Snetry has quit [Ping timeout: 260 seconds]
Snetry has joined #zig
brzg has quit [Quit: leaving]
Snetry has quit [Ping timeout: 265 seconds]
Snetry has joined #zig
Snetry has quit [Ping timeout: 244 seconds]
<powerofzero>
andrewrk: Re C dependencies: I am working on bundling a C library into a zig wrapper, and that C library has a number of dependencies that need to also be built, as I want to not have any system dependencies, and I was wondering if there was a convienient way to do this.
<andrewrk>
powerofzero, ah, yes, there isn't a good way to do this yet. it's one of the main motivating use cases of the (so far vaporware) package manager
<andrewrk>
you might have a chat with matt nite or meghan (both on the discord) and see if a community package manager can fill the gap for you for now
<powerofzero>
That might be a good idea. I haven't looked at either very well. Doing it manually as I have benn will be annoying for all the recursive dependencies. Do you happen to know off the top of your head if either of them supports logic that can inject config macros into the C projects?
<andrewrk>
I vaguely recall that meghan's can do that (zigmod)
<powerofzero>
Ok, I'll look at that first. Thanks!
<FireFox317>
ifreund, i'm a bit confused by the different functions in GenZir, like addBoolBr and addUnNode etc. Some return a Inst.Ref, however other return Inst.Index. Do you know why there is a difference?
<ifreund>
FireFox317: for addBoolBr you need to set the body later using the returned index
<ifreund>
see: setBoolBrBody()
<ifreund>
same with addBlock()/setBlockBody()
<FireFox317>
ifreund, okay. But for example addCall() returns a Inst.Index and addFnType() returns a Inst.Ref, however the code in the functions seems to be doing the same thing (casting it to an Index etc)
<ifreund>
FireFox317: oh the return type of addCall() should be a ref I'm pretty sure. I'll audit the rest and push fixes
<ifreund>
andrewrk: we really need distinct types...
<FireFox317>
ah okay, yeah that clears up my confusion thanks! They are all just u32 and the compiler doesn't know that we use them as different types
<FireFox317>
i see
sord937 has quit [Remote host closed the connection]
sord937 has joined #zig
<ifreund>
I'm going to give the non-exaustive enum trick a try, it can probably be better than the status quo
jokoon has quit [Quit: Leaving]
WilhelmVonWeiner has joined #zig
<FireFox317>
ifreund, just for your knowledge, i implemented typeof (#8343)
<g-w1>
where is that proposal for non-distinct-types?
<daurnimator>
non-exhaustive enums make sense as long as you never need to do math or bitwise operations on the values
<ifreund>
we don't need to do much math, so it might be acceptable
<ifreund>
it requires adding a bunch of explict casting, but I think it might be worth it
<g-w1>
oh definently
<daurnimator>
ifreund: distinct types would also require explicit casting
<ifreund>
of course
<ifreund>
daurnimator: if distinct types only enforced explict coercion in one direction (from u32 to distinct type) that would give pretty much all the safety we want with much less casting
<ifreund>
i.e. they could still be used to index arrays
<daurnimator>
huh?
<ifreund>
but passing a u32 or zir.Inst.Ref where a zir.Inst.Index is required would be a compile error
<daurnimator>
indexing arrays would be the opposite
<ifreund>
indexing arrays is coercion from disinct type to usize
<daurnimator>
right
<daurnimator>
but you suggested "from u32 to distinct type" above
<ifreund>
that's the other direction
sjums has joined #zig
sjums has quit [Client Quit]
nycex has quit [Remote host closed the connection]
nycex has joined #zig
sjums has joined #zig
<ifreund>
that was a dumb idea though, as it wouldn't catch indexing with an Inst.Ref which is a footgun we need to prevent
<ikskuh>
g-w1: this is actually used often in the computation of checksums
<ikskuh>
for(data) |c| { checksum +%= c; }
<ikskuh>
write(-%checksum)
<g-w1>
interesting, cool
<ikskuh>
although i despise this pattern, especially in C
<ikskuh>
it feels scary
<ikskuh>
i prefer
<ikskuh>
for(data) |c| { checksum -%= c; }
<ikskuh>
now
<ikskuh>
especially because "-unsigned" makes no sense at all
<txdv>
when my app is experiencing a load of cache misses, the cpu usage is still shown to be 100% ?
<ikskuh>
yes
<ikskuh>
a cache miss doesn't mean the CPU is halting
<ikskuh>
or another thread could do work in that time (possible in theory, but no idea if actually possible)
<txdv>
afaik the cpu tries to execute other instructions which are not waiting for data
<ikskuh>
yes, true
<ikskuh>
but how do you measure CPU usage
<txdv>
cpu perf counters work in mysterious ways and change even between architectures
<ikskuh>
yep
<ikskuh>
or between CPUs
<ed_t>
The std thread primitives are in a sorry state. Are there plans in the works to fix this?
<g-w1>
protty on discord is working on all the sync stuff i think
<ikskuh>
ed_t: what are you missing?
<ikskuh>
std.Thread itself cannot be much more beautiful
<ed_t>
in my books zig async and Threads are two different domains. And its really had to use threads without the basic tools. Async is another story, while the two domains intersect, they are different each with their own strengths.
<ifreund>
there is definitely work being done to improve the situation
<ifreund>
that stuff isn't exactly easy though
<ed_t>
I would like to be able to use Rwlocks, which require Conditions to work (they don't as it stands now, for instance in fn wait(cond: *AtomicCondition, mutex: *Mutex) mutex.unlock lock are used instead of release and acquire)
<ed_t>
and yes that stuff is NOT easy. Though it much easier to working with Threads when the lib functions work... (this is just a observation - I know and understand zig is still in a state of flux and far from complete)
<ikskuh>
i hopy king will just write the whole std.Thread and std.event thingy
<ed_t>
king?
<ikskuh>
protty
<ifreund>
ed_t: there is an rwlock implementation on that branch I linked by the way
<ifreund>
though it looks like the branch has grown some conflicts
<ed_t>
yes
<ed_t>
linked as in added the import to Threads.zig to export it?
<ifreund>
?
<ed_t>
Sunday's build of zig-git (arch) does not have RwLock exported. if I understand the code Thread.zig should have a pub const RwLock = @import("Thread/RwLock.zig"); in it if RwLocks are available.
<g-w1>
is it just const instead of pub const?
<ifreund>
ed_t: that pull request is not yet merged
<ed_t>
ifreund yes, I realized that
<ed_t>
g-wl comments from protty yesterday was not RwLocks as they exist now in std are not buggy
<ed_t>
ifreund what process does a pull request follow to get integrated into zig. I looks like protty has done a lot of work that is pending.
<ifreund>
ed_t: ah yeah I see now, RwLock was added in a9667b5a but not exposed in std.thread
<ifreund>
ed_t: it needs to be reviewed and tested by someone with commit access to the ziglang repo and who feels up to the task
<ifreund>
smaller PRs are *way* easier to merge than large ones
<ed_t>
in my case I am just trying to optimize some code. It usings thousands of threads per second, is pretty well lockless but does not gain me much and it should. From experience with other langs, creating threads costs. I could use a threadpool but its overkill for this program, so I tried the primitives, which would make things simple.
lyhokia has joined #zig
<ifreund>
andrewrk: so while working on using non-exhaustive enums for zir.Inst.Ref/Index I have found many minor screwups and a pretty major one that I'm not 100% sure what to do about
<g-w1>
ifreund: what is the major one, I thought i kind of saw one in varDecl, but wasn't sure
<ifreund>
GenZir.instructions currently claims to be a list of Refs but we only insert indexes indo it
<g-w1>
ok
<ifreund>
when reading from it we usually treat it as indexes, even if something say we are treating it as refs, except in the case of function arguments where we really do treat it as refs
nvmd has joined #zig
<ifreund>
actually wait, function arguments aren't using GenZir.instruction directly, there's not problem except that we are using the wrong type for the list
<ifreund>
I need to take a break from this and come back, my head is swimming with indexes but things are looking quite promising
<FireFox317>
g-w1, still something is wrong tho (with result location stuff). `const x: i32 = foo();` still emits an alloc instruction whereas that shouldn't be needed
<g-w1>
why shouldn't an alloc be needed?
<FireFox317>
because its const and the type is a i32, thus there is no stack space needed
<g-w1>
an i32 takes up space
<FireFox317>
you remember `nodeMayNeedMemoryLocation`?
<g-w1>
yes
<g-w1>
on call, it returns true
<FireFox317>
yes, but the alloc should be removed afterwards, because after we generated the call and everything, we know that we dont need a memory location, and thus the alloc can be removed
<FireFox317>
andrewrk, implemented that and it worked before this rework
<g-w1>
you are talking after sema?
RadekCh has quit [Quit: Connection closed]
<g-w1>
also, i still dont see how i32 doesn't need a memory location
<FireFox317>
g-w1, look at the TZIR for `fn foo() i32 { return 1; } export fn main() c_int { const x: i32 = foo(); return x }`. You can see in the TZIR that there is a intcast and in the intcast it only uses %2, %1 (the alloc) is never used, so it should be removed
<FireFox317>
or i'm confused by blocks vs function. Because blocks actually remove the allocs, but i thought that was also the case for functions.
bitmapper has joined #zig
midgard_ has joined #zig
midgard has quit [Ping timeout: 245 seconds]
<g-w1>
FireFox317: im getting some other assertions related to src locs when I try that, can you pastebin the ir that you get?
<FireFox317>
ifreund, again Inst.Ref vs inst.Index
<ifreund>
Oh I'm already convinced that we *need* distinct types for those two. It wasn't anywhere near as problematic during the ast rework as there was only one Index type, not Ref as well
<g-w1>
is it worth touching stage1 for?
<ifreund>
zir.Const and Ref are a very good optimization though, so they definitenly shouldn't go anywhere
<ifreund>
g-w1: I've got a WIP fix using non-exhaustive enums
<g-w1>
ok
<ifreund>
just need to get my other work done so I can get back to it and hopefully finish up tonight
Miaourt has quit [Quit: Ping timeout (120 seconds)]
tjammer[m] has quit [Ping timeout: 265 seconds]
duck2 has quit [Quit: Ping timeout (120 seconds)]
washbear is now known as racoon
protheory8-new-m has quit [Ping timeout: 265 seconds]
<g-w1>
cepheus: probably, it already uses in-binary lld for things too
<noam>
That's actually a realllly nice source file
Sumera[m] has joined #zig
<cepheus>
my understanding is upstream's opinion on macOS frameworks is "use system ld" and as such lld's framework support is seemingly non-functional on recent versions of macOS
<mikdusan>
right now zig prefers to use lld which has elf,macho,coff flavours; the lld macho flavour is lacking greatly,
<mikdusan>
so as a temp workaround we have an env var to use apple system linker
cole-h has joined #zig
<mikdusan>
and the short-med term solve for that is zig is rolling it's own macho flavoured linker mostly implemented by 1 person so far and the pace of development is strikingly fast.
<danyspin97>
does std.Thread.spawn only accept functions with one argument?
<g-w1>
put the arguments in the context
<cepheus>
i do like zig's niche of "multi-purpose cross-compiler toolkit that comes with a free programming language"
<danyspin97>
g-w1: like..?
<g-w1>
spawn(fnwithonearg, .{ arg })
<cepheus>
anyway i did see that zld is getting mach-o support, but i got the feeling that framework support is something of reasonably high complexity and would be a lower priority/longer term feature (or potentially not supported)
<danyspin97>
g-w1: @compileError("expected function with single argument
<mikdusan>
cepheus: the difficulty is not with frameworks but that many/most SDK frameworks (and dylibs) do not ship with binaries. they ship .tbd files intsead
rom16384 has joined #zig
<mikdusan>
so like it or not, moving forward, one needs to use SDK to build stuff. and therefore _something_ is going to have to parse .tbd files
<mikdusan>
right now apple system linker is the only thing that does it for _both_ system libraries and frameworks
<mikdusan>
iirc, llvm's lld does it _only_ for system libraries but does not have any framework+search logic for .tbd files
<mikdusan>
and I think zld as of now does not yet parse .tbd files
waleee-cl has joined #zig
<dutchie>
danyspin97: you can simulate multiple args by passing a struct
<danyspin97>
dutchie: can I get the return value from a function?
<dutchie>
not from one you've spawned in a thread, no. you'll have to use a global (protected by a mutex) or channels or something
<danyspin97>
can I contribute to zig for this? :)
<danyspin97>
they are all suboptimal and I'd rather contribute
<g-w1>
what is subopimal?
<dutchie>
i'm not sure there even is a portable way to return a value from a separate thread
<dutchie>
and multiple args to a thread function would require varargs which got removed anyway
<g-w1>
? isn't context a tuple with all the args
<danyspin97>
g-w1: using a global rather than passing 2 values from a thread
<cepheus>
yeah, i didn't expect it would be easy or simple to reimplement framework support, and i'm not demanding people go support it or anything, i was just curious about the evolution of this
<mikdusan>
can the context have an out field set by thread?
<danyspin97>
g-w1: doesn't work
<g-w1>
hm
<danyspin97>
I mean, that's the basics of threading
<cepheus>
i'm not really disparaging lld for this either, apple is not really interested in shipping this into lld and lld are not really interested in maintaining parallel support for feature-equivalency for mach-o
<mikdusan>
cepheus: there was some hint of promise for lld macho getting new development, but whatever work has been done, it hasn't been enough to keep up with Big Sur development needs
<cepheus>
which is understandable given that the macos linker has source releases and the only big use case commercially for its support would be building iOS apps without a Mac, which is difficult given the non-existence of an SDK with supportive licensing terms
<mikdusan>
the interesting thing tho, is because of .tbd files, all you need is headers+tbd and cross compile can work with a functional macho linker
<cepheus>
i assume the issue is that TBD is undocumented and subject to change between OS releases
<cepheus>
well, at least it's got a befitting name
<mikdusan>
it's yaml that describes symbols and versions found in .dylibs
<mikdusan>
and no public spec, BUT apple has released tapitools (I have not have the right tarball basename there) that has sources for reading and manipulating those files
<mikdusan>
so while it's not public spec I think it's managable to implement our own parser
<cepheus>
so sort of like a more featureful version of .def files from MSVC, in essence
<mikdusan>
so here's an example. this is the webkit framework that is shipped with SDK. no binaries. just headers/tbd files:
<mikdusan>
so the linker would take `install-name` and _encode_ that right into the executable or dylib being created, and of course veryify that the symbols are satisfied by `exports` section
<rom16384>
I build an Hello World with zig build-exe -O ReleaseSmall, and it's in fact small, but the executable contains the full path from where it was build including my username?
<mikdusan>
rom16384: if you add `--strip` does it help?
<rom16384>
It does. —strip fixes that
<rom16384>
I used the strip command, but that didn't work
<g-w1>
ah
<dutchie>
that's odd, strip should do the same thing. what platform are you on?
<mikdusan>
should it?
<dutchie>
should it not?
<dutchie>
it does when i test. build -O ReleaseSmall, run strings and out pops my homedir. strip and it's gone
mokafolio has quit [Quit: Bye Bye!]
<mikdusan>
I assume a strip command only strips things it explicitly knows about. ie: if it supports up to version dwarf2 it won't strip dwarf4.
<dutchie>
yeah, that's why i asked about the platform. i probably really meant "strip version"
<rom16384>
mac os 10.15 Catalina
mokafolio has joined #zig
<rom16384>
strip from XCode Command Line Utilities
<mikdusan>
using a recent zig master?
<mikdusan>
i've seen glitches when the new zld is used (which is default) now. and strip doesn't work on a zld-artifact executable
<rom16384>
zig version -> 0.7.1 (From homebrew)
<rom16384>
the —strip works well
constatinus has joined #zig
<cepheus>
yeah i've seen similar issues w/ 0.7.1, any combination of flags with xcode strip gives "error: symbols referenced by indirect symbol table entries that can't be stripped"
<constatinus>
hello, im getting an error: "use of undeclared identifier 'ret'"; im trying to make a generic struct, and i cant get it to iymport iself; here is my code: https://pastebin.com/4DiuHmwe
<constatinus>
the code isnt that complete but it still would give the same error
<constatinus>
alright im being so dyslexic now
<mikdusan>
cepheus: catalina _began_ the no-more-/usr/include movement. I cannot recall if it hid the .dylibs as well or not, but basically catalina and higher we really need to be using SDK
<cepheus>
constatinus: you should be able to use @Self() instead of ret on line 12 of your example
<g-w1>
s/Self/This
<cepheus>
whoops sorry
danyspin97 has left #zig ["WeeChat 3.1"]
rom16384 has left #zig [#zig]
<mikdusan>
the problem is people figured workarounds and options to force CommandLineTools to install /usr/include, and even now homebrew does a CommandLinesTool install in a fashion on Big Sur that poisoned by pristine big sur system
<mikdusan>
s/by/my/
<constatinus>
alright is works now, thanks, thanks. wondering why it isnt standard practice when self: retvalue is so broken
<cepheus>
well system dylibs (including frameworks, I think) are entirely eliminated from the filesystem as of big sur now that they all live in the sealed linker cache
<mikdusan>
right but you're on catalina, for my reminder, can you verify is /usr/lib populated?
<cepheus>
you may be thinking of rom16384 , i was just butting in to echo that strip doesn't work correctly for executables output by zig 0.7.1
<mikdusan>
oh oops
<cepheus>
no worries, i am causing a bit of confusion
xackus__ has quit [Ping timeout: 264 seconds]
xackus__ has joined #zig
yeti has quit [Quit: WeeChat 3.1]
Akuli has joined #zig
yeti has joined #zig
yyp has quit [Quit: now it's safe to turn off your computer]
selby has joined #zig
constatinus has quit [Quit: WeeChat 3.1]
m4r35n357 has joined #zig
m4r35n357 has quit [Remote host closed the connection]
m4r35n357 has joined #zig
<andrewrk>
ifreund, GenZir.instructions is supposed to b be a list of Indexes
yyp has joined #zig
<andrewrk>
ifreund, btw if we make Ref an enum, we may as well merge it with the zir.Const enum, right?
<g-w1>
ooh thats nice
<ifreund>
andrewrk: I acually already did that on my branch :D I think it's pretty clean
<ifreund>
thanks for the confirmation on GenZir.instructions
<ifreund>
and when I said that the parser will parse the two things the same, this means that no later steps will see any difference between the two
<ifreund>
infact it's the tokenizer that is handling this
<ifreund>
the parser just sees a dot token followed by an identifier
<andrewrk>
noam, fyi the grammar in https://github.com/ziglang/zig-spec/ is correct (if not please file bugs) and it is compilable with that peg tool so you can use it to validate zig source
<g-w1>
zyg is actually using that (with some modifications for 1717 as the basis for the parser)
<andrewrk>
in other words we actually do have a spec for the grammar
<noam>
andrewrk: I have a copy of the grammar :)
<andrewrk>
cool
<noam>
zyg/design/grammar
<noam>
It's tweaked with 1717 and a modified asm syntax :P
<noam>
I've been looking at the grammar constantly
<dimenus>
noam: the syntax in #5241?
<ifreund>
noam: your grammar's out of date by the way, I've made a few minor changes since the AST memory rework branch
cow-orker has joined #zig
<ifreund>
and your grammar also says that `. foo` is the same as `.foo` :P
<FireFox317_>
andrewrk, thanks for clearing up the difference between Ref and Index :) I actually figure this out myself too, after i typed the message in the PR :)
<noam>
dimenus: no, though I'm considering adding that
<noam>
ifreund: I noticed
<noam>
e.g. callconv
<andrewrk>
FireFox317_, thanks for the patches!
<noam>
I use callconv(.Inline) but haven't updated the grammar
<noam>
...here's a fun bug. Removing a comment causes a compilation failure.
<FireFox317_>
pretty fun too!
<noam>
...and they give the same parse tree? Wat.
<noam>
Is there a reason that enum literals allow spacing?
<noam>
Seems way too easy to subtly introduce bugs with them
<ifreund>
write up a proposal if you feel like it, it wouldn't be terribly hard to implement
<ifreund>
or maybe it would...
midgard has joined #zig
midgard_ has quit [Ping timeout: 260 seconds]
<ifreund>
guess if you make `.foo` a single token you have to disallow e.g. `Foo. bar()` and other cases of that token as well
<ifreund>
which might not be a bad thing if we can provide good error messages
<ifreund>
zig fmt usage makes this a non-issue of course
mikdusan has quit [Quit: WeeChat 3.0.1]
selby has quit [Quit: My MacBook has gone to sleep.]
selby has joined #zig
<noam>
...that was a dumb bug. Gave the index of an identifier node instead of the string to the scope tracker so scopes didn't resolve correctly :P
<andrewrk>
looks like noam needs distinct types too
<g-w1>
yep :)
<noam>
andrewrk: lol :P
<noam>
andrewrk: I'm actually fully intending to rewrite parts of this in zig once it can
<andrewrk>
I do think it's interesting that I personally didn't run into this class of bugs until I started applying Data Oriented Design principles
<noam>
Distinct types only make that more worthwhile
<noam>
(not to replace the C, but to copy Zig's stage0/stage1, except with equal functionality for both)
<andrewrk>
ah so you plan to make zyg a hybrid, just like zig stage1 is a hybrid?
<noam>
Yeah
<andrewrk>
neat
<noam>
A self-hosted hybrid that can be bootstraped from *either* a C99 compiler *or* a Zig compiler
<noam>
I intend a C frontend inZig, too ;p
<andrewrk>
yeah the key observation there is that you have to use a C toolchain to bootstrap, which means you have a linker available, so your stage0 only has to output an object file. further observation: actually it only has to output the same language that it is written in (C)
<andrewrk>
it works :D the wrong source loc on update is fixed now
<andrewrk>
all that LazySrcLoc stuff paid off
<g-w1>
is it faster?
<andrewrk>
haven't checked, but it's no longer pointing at an incorrect line,column
<g-w1>
ooh nice
<FireFox317_>
yeah i think we are quite close too
<FireFox317_>
i can look at optionals maybe, if nobody else is doing that already
<andrewrk>
I'm about to break for lunch, got nothing WIP
<g-w1>
i have some exams for the next few days, so i probably wont start working on it again till thursday, maybe friday
<dimenus>
andrewrk: i'm in codegen.zig:genIntCast
<noam>
andrewrk: "naming is hard" that's definitely not *why* I mixed astgen and sema in mine... but I can't honestly say the thought didn't factor in at all
<noam>
It feels so good actually getting work done after talking about it for months :D
yyp has quit [Quit: now it's safe to turn off your computer]
<vent>
Is there an equivalent of sscanf in Zig's std?
ur5us_ has quit [Ping timeout: 260 seconds]
ur5us_ has joined #zig
xackus has joined #zig
mikdusan has joined #zig
xackus__ has quit [Ping timeout: 265 seconds]
paulgrmn__ has joined #zig
<andrewrk>
vent, nope, but a lot of people want it!
paulgrmn__ has quit [Ping timeout: 245 seconds]
<noam>
I need those distinct types
<noam>
I need them so much
<noam>
Ended up having to deliberately trigger a crash so I could get a backtrace which led me to realize that yes, I'm still using the wrong indexes in some places ew
powerofzero has joined #zig
<powerofzero>
Hi, if I have a small propsal for the standard library (just a couple of lines to change in one function, should I submit an issue for disscussion, or just submit a PR and have the disscussion on that?
mikdusan has quit [Ping timeout: 245 seconds]
<ifreund>
powerofzero: just submit a PR
mikdusan has joined #zig
<powerofzero>
Ok. Thanks. (also I realized that I wasn't clear that it does involve a breaking api change, does your answer stand?_
<g-w1>
you can just ask here if it is too breaking
<ifreund>
If it's something as simple as a few lines, yes a PR is better as it is much more clear exactly what change is proposed
<powerofzero>
ok. Thanks
<ifreund>
and yeah asking here if it is a good idea also doesn't hurt
<vent>
andrewrk: Ah fair enough. I imagine things like that may ease the transition from C for some people. There may be a better way than copying C's std though! Thanks for the answer :)
<powerofzero>
ifreund, g-w1: I want to change LibExeObjStep.defineCMacro to take separate macro name and value slice arguments. This makes cases where you have a known key but the value is not comptime (of the build.zig) known much easier to write, as the build.zig doesn't need to do allocations to concatanate the macro and value together.
<powerofzero>
Thee alternatives are to (a) not do it at all (b) do it in a new function (defineCMacroKeyValue?) or (c) do it, but also keep the old behavior in a different function (defineCMacroFlag?)
<andrewrk>
powerofzero, the reason to open an issue first would be to save yourself the effort of implementing it, in case we wanted to go a different direction with the use case
<powerofzero>
andrewrk: I get that, though in this case the implementation is rather small, and often small things have a different proccess.
zags has joined #zig
<g-w1>
a pr is probably fine here then
<noam>
...
<noam>
andrewrk: I actually have a printed copy of the grammar
<noam>
from when I was doing the initial pen-and-paper design :P
<andrewrk>
ha, fun
<andrewrk>
powerofzero, yep, makes sense!
<noam>
I should just hang it up in the street lol
<noam>
Would be amusing :P
<FireFox317_>
andrewrk, now i found an issue where it is not eliding the .store_to_block_ptr
<andrewrk>
darn
<noam>
Found wha tI'm pretty sureis the last scoping issue
<noam>
But I've said that three times, at least
<noam>
with e.g. `RK.foo();` in start, it's analyzing RK as a child of start instead of as a child of the root scope. Oops.
<FireFox317_>
actually there is not even a .store_to_block_ptr in the instruction list, only an as_node, alloc, and then a block
<andrewrk>
FireFox317_, want me to have a look? which test case is that?
<FireFox317_>
i was working on orelse when i ran into it, but i can repro it with a simple if test:
<FireFox317_>
so the init_scope.instructions only contain 3 instructions: as_node, alloc and a block
<FireFox317_>
so i think the problem is that the instructions that are in the block are not added to the parent block
<andrewrk>
zir_datas[src_inst].bin.lhs is a Ref, init_scope.rl_ptr is an Index
zags has quit [Quit: leaving]
<FireFox317_>
thats not the issue tho
<andrewrk>
oh?
<FireFox317_>
its not even getting into that if
<FireFox317_>
because there are only 3 instructions: as_node, alloc and a block
<FireFox317_>
the instructions that are in the block are not in the parent block (which is init_scope in this case) thats the issue i think
<andrewrk>
FireFox317_, ok so we expected the rvalue() of the expr() call on line 1295 to add a store_to_block_ptr instruction
<FireFox317_>
andrewrk, correct
<FireFox317_>
so again, that expr() has 3 instructions: as_node, alloc and a block. But the instructions in the block are not added to the list, thus we will not find the store_to_block_ptr instruction
<FireFox317_>
if that makes sense
<andrewrk>
oh I see, did ifExpr not copy the instructions to the parent block?
<FireFox317_>
ahh
<FireFox317_>
yeah something like that
dimenus has quit [Ping timeout: 240 seconds]
<andrewrk>
oh in master branch, finishThenElseBlock passes the parent scope to rvalue. I changed that here, my mistake
<andrewrk>
let me make this change because I remember what I did
<andrewrk>
don't forget the other Ref/Index issue tho
<FireFox317_>
andrewrk, yeah great! :)
<andrewrk>
the store_to_block_ptr was incorrectly in the inner block
<FireFox317_>
the other Ref/Index issue is not really an issue now, because when we create the .store_to_block_ptr instruction (Bin instruction thus it expects Refs), we always pass in block_scope.rl_ptr (which is an Index)
<FireFox317_>
which is astgen.zig:3845
<FireFox317_>
there we pass an Index into addBin (which expects a Ref)
<andrewrk>
we need to respect Ref/Index even though the type system doesn't catch it yet, to make it easier for ifreund to fix conflicts (and also to help us make sense of what's going on)
<FireFox317_>
andrewrk, you are absolutely right :)
powerofzero has quit [Remote host closed the connection]
<andrewrk>
pushed the store_to_block_ptr fix
<FireFox317_>
thanks, lets see if that fixes my orelse wip branch :)
<g-w1>
hmm, is the only difference between ref and index that ref can point to a Const?
<andrewrk>
yes, also a ref can point to a function arg
<ifreund>
andrewrk: by the way, I've decided to only make Inst.Ref an enum and leave Inst.Index a plain alias for u32
<andrewrk>
makes sense
<andrewrk>
that will go a long way
<ifreund>
yeah, and I haven't seen any screw ups that making Inst.Index an enum as well would have prevented yet
<ifreund>
note as well that this wasn't a problem on the ast-memory-layout branch, only now
<andrewrk>
the one g-w1 ran into was passing a byte offset (u32) where a node offset (u32) was expected, also he ran into passing a token offset (u32) where a node offset was expected
<andrewrk>
I agree though, the most critical one is zir.Inst.{Index,Ref}
<ifreund>
ok, s/wasn't a problem/wasn't as much of a problem/
<andrewrk>
I'm doing the @TypeOf stage2 test case
sord937 has quit [Quit: sord937]
<ifreund>
andrewrk: yeah, giving the offsets distinct types would be sweet, but using non-exhaustive enums for that would be kinda miserable due to the fact that you need to do math with them
<andrewrk>
yeah
<FireFox317_>
andrewrk, @TypeOf should be implemented :)
<FireFox317_>
but i didnt test the whole testcase xd
<andrewrk>
FireFox317_, test case is hitting an assert
<FireFox317_>
i see :P
<andrewrk>
I'm just going in order in test/stage2/test.zig :D
<FireFox317_>
ah okay, i'm doing orelsecatchexpr currently
<FireFox317_>
andrewrk, i created #8348. optional unwrapping seems to be working, however orelse results in a segfault in a Sema.zig in analyzeIsNull (looks like a type is not resolved or smth)
<FireFox317_>
its getting to late here to work on it, so i thought i just push the work i did
<FireFox317_>
you can continue my work, or otherwise i will try to solve it tomorrow :)
<andrewrk>
nice, thanks!
xackus has quit [Ping timeout: 265 seconds]
Akuli has quit [Quit: Leaving]
<FireFox317_>
andrewrk, i might have found the problem :)
<andrewrk>
do tell
<andrewrk>
I see you fell into that classic trap of trying to stop working for the evening
<FireFox317_>
I removed the makeOptionalTypeResultLoc function (because it was only used in one place) and then did a bad refactor
<FireFox317_>
andrewrk, i did indeed haha
<FireFox317_>
did not fix it unfortunately
riba has joined #zig
<ifreund>
andrewrk: if you have a minute, should GenZir.rl_ptr be a Ref or should the ResultLoc tagged union be modified?
<ifreund>
I haven't taken the time to understand the new result location code yet
<andrewrk>
ifreund, I believe rl_ptr should be an Index
<andrewrk>
uh sorry wait let me double check that
<andrewrk>
ifreund, other way. I think rl_ptr should be a Ref, to match ResultLoc.ptr
<ifreund>
cool, thanks for taking a look
<andrewrk>
here's a concrete reason why: ResultLoc.ptr could be set to be the argument of a function, which is representable as a Ref but not an Index
sundbp has quit [Ping timeout: 272 seconds]
<ifreund>
makes sense
<FireFox317_>
andrewrk, quick question: in my PR #8348. How do i make sure that the `const cond = try parent_gz.addUnTok(cond_op, operand, op_token)` ends up in the block? currently it is added to the parent
<ifreund>
FireFox317_: use something other than parent_gz
<FireFox317_>
ifreund, yeah make sense lol, its late xd
ur5us_ has quit [Ping timeout: 268 seconds]
<ifreund>
I know the feeling, I can feel my self slowing down as well as the clock approaches 1am :D
<andrewrk>
ifreund, nice, with your clarifications about rl_ptr I can get rid of the AsIndex variants
<andrewrk>
that was a well-timed question heh
<FireFox317_>
nice, fixed the issue :))
<ifreund>
andrewrk: All I did was report this nice new compile error I got :D Glad it was helpful :)
<andrewrk>
who would have thought, type safety would be helpful
<noam>
hmm, practically, @This() just returns the innermost container, right?
<noam>
(finally fixed all the stupid scoping bugs... that I'm aware of)
<andrewrk>
noam, correct, it returns the innermost struct, enum, union, or opaque
riba has quit [Ping timeout: 260 seconds]
<noam>
Neat - can just rise through the scopes, map to decl, check if container...
<andrewrk>
FireFox317_, are you looking for a review? or still have something to push?
<noam>
I'm not quite supporting duck typing just yet, but `define = fn(base: u32) @This() { return @This() { .base = base,};};` ... `UART0 = UART.define(0xFF110000);` is still nice :D
<FireFox317_>
andrewrk, one moment, still something to push
<andrewrk>
we are passing quite a few tests at this point
<andrewrk>
ah here we go. I'm on while loops now
<g-w1>
we still dont have those at compitme right?