<oats>
has anybody here done anything with running zig programs on the tomu arm board?
reductum has joined #zig
timl has quit [Remote host closed the connection]
<foobles>
what is the best way to, at comptime, unwrap an IrInstGen representing an optional?
<foobles>
I have looked at `ir_analyze_unwrap_optional_payload()`, but that only works for pointers to optionals
xackus_ has joined #zig
_Vi has quit [Ping timeout: 272 seconds]
<mikdusan>
if you're doing it from an analysis fn, why not ir_build_optional_unwrap_ptr_gen ?
<mikdusan>
it wants a ptr so give it one
<mikdusan>
A. ir_get_ref, B. get_pointer_to_type_extra, C. use A,B as arg2 and arg5, respectively
nephele has quit [Ping timeout: 265 seconds]
nephele_ has joined #zig
<foobles>
ir_get_ref!
<foobles>
i was trying to find a function like that!
<foobles>
thank you!
<mikdusan>
ir_get_ref, is the type "*?T" ? if it is,maybe you can use that value instead of B . I'm not exactly sure without checking in debugger
<mikdusan>
also try our .cpp macro `BREAKPOINT;` . just put it in your code and it should break there. note: you might need to make sure there is at least 1 stmt after it otherwise it breaks out of block/scope for me. caveat: I don't know if it works on windows.
<foobles>
oh slick
<foobles>
cool
<foobles>
thanks
<foobles>
so: ir_get_ref -> pass to the ir_build_optional_unwrap_ptr_gen -> ir_get_deref
<mikdusan>
yes arg2
<foobles>
:v feels like a bit much, but it will work
<mikdusan>
but you need arg6 . can't just give it child_type because that's not pointered
<mikdusan>
why are you deref?
<foobles>
because the optional deref returns a pointer to the unwrapped value iird
<foobles>
s/iird/iirc
<foobles>
so i need to deref it :(
<mikdusan>
hmm ok i don't know which analysis fn you're working with. assumed it was ir_analyze_bin_op_cmp
<foobles>
also i think the actually, ir_build_optional_unwrap_ptr_gen won't work at comptime. i need to use the analyze function (which for some reason takes an IrInstGen, not an IrInstSrc)
<foobles>
it is
<foobles>
thats the one
<mikdusan>
right, you won't need that for comptime. get one or the other working first is my suggestion
<foobles>
this is all supposed to be comptime
<foobles>
thats the one im doing rn
<mikdusan>
comptime has the ZigValue's so you can follow value to get payload -- value->data.x_optional
<foobles>
thats what i tried to do but andrew said that isn't quite correct
<mikdusan>
and handy function optional_value_is_null() is available to check
<foobles>
thats what i have right now '=D
<foobles>
i am also sure that they arent pointer types
<foobles>
so i thought that would be ok
<foobles>
maybe ill just submit what i have as a draft pr
<foobles>
since it works for my cases
<mikdusan>
yeah I started looking into this, I actually have the runtime side working
ifreund has quit [Ping timeout: 265 seconds]
<foobles>
maybe we can join forces then :D
<foobles>
id love to see what you have
<mikdusan>
ok I'll post a branch soon. just writing a few tests...
dimenus has quit [Remote host closed the connection]
xackus_ has quit [Remote host closed the connection]
<mikdusan>
comptime is panic'ing. but that runtime test passes
xackus_ has joined #zig
r4pr0n has quit [Quit: r4pr0n]
<foobles>
mikdusan interesting, so it just keeps reassigning to op1 and op2 until both are fully unwrapped, and then it continues down the function
<mikdusan>
foobles: but I broke something in behavior tests
<mikdusan>
yeah that was the idea I wanted to try
<foobles>
but what if both of them are null-type, for instance?
<mikdusan>
the runtime section is actually really tiny
<foobles>
do you have the whole thing on github?
<mikdusan>
that's my entire diff
<foobles>
oh cool
<foobles>
but what if both are nulltype? the case that checks for that will never be hit
<foobles>
since this is placed below it, right?
<mikdusan>
ignore the CMake stuff. I have to tell it to allow unused vars and stuff when iterating
<foobles>
oh nevermind. i see its above
<foobles>
i see another issue though: i dont think this interacts well with the comparisons between Nulltype and optionals
<foobles>
since this will unwrap the optional all the way before it continues
<mikdusan>
runtime or comptime?
<foobles>
either
<foobles>
there is a case where if one side is nulltype, and the other is optional, it has a special case
<foobles>
but that will never be hit anymore with your change
<mikdusan>
what's the special case?
<foobles>
it just returns based on whether or not the option is null
<foobles>
but if you unwrap the optional all the way, it will fall below that case and hit the one where it errors, i believe
<mikdusan>
ah yes I think I was musing about needing to do a cond_br
<foobles>
im about to push my changes to my fork if you want to take a look
<mikdusan>
what really helped me get the ir_build_optional_unwrap_ptr_gen() call correct (at least I hope it is)... was looking at this in --verbose-ir for reduction.zig that just unwraped a runtime optional:
<mikdusan>
foobles: grain of salt. I could be doing it totally wrong, and even if it gets passing all tests, keep in mind it may be rejected for "wrong way" or whatever. but still, learn alot about IR trying.
<foobles>
yeah thats what im thinking
<foobles>
maybe submit a draft pr?
<mikdusan>
feel free
<foobles>
mikdusan I found a function that does the get_ref, unwrap, and get_deref!
<foobles>
it's called `ir_analyze_optional_value_payload_value`
<mikdusan>
that might be useful. it sure does a lot of heavy lifting
<foobles>
yep!
<foobles>
it also works at comptime
<foobles>
:) i am using that now
dddddd has quit [Ping timeout: 240 seconds]
Kingsquee has joined #zig
ur5us has quit [Remote host closed the connection]
ur5us has joined #zig
frett27_ has joined #zig
frett27 has joined #zig
reductum has quit [Quit: WeeChat 2.8]
_whitelogger has joined #zig
foobles has quit [Ping timeout: 240 seconds]
darithorn_ has quit [Quit: Leaving]
layneson has quit [Ping timeout: 256 seconds]
ur5us has quit [Ping timeout: 256 seconds]
waleee-cl has joined #zig
kenaryn has joined #zig
<kenaryn>
Hello computer people. Please when I type `build-exe`, is the executable created from the source and/or from the object file? How can I know when there are both? (i.e. .zig and .o files)
omglasers2 has joined #zig
ur5us has joined #zig
cole-h has quit [Ping timeout: 264 seconds]
<omglasers2>
morning! (well, it's 9:30 here) I have this snippet https://pastebin.com/WZHn1PhB which doesn't compile on win64 (master). I guess it's a bug ?
TheLemonMan has joined #zig
Patrice_ has joined #zig
frett27 has quit [Ping timeout: 256 seconds]
frett27_ has quit [Ping timeout: 256 seconds]
frett27 has joined #zig
wootehfoot has joined #zig
<waleee-cl>
omglasers2: try moving the enum out of main() ?
dermetfan1 has joined #zig
<kenaryn>
we are one the same timeline, which country are you from omglasers2?
jjido has joined #zig
<omglasers2>
waleee-cl, seems to work; so it's not ok if it's declared in a function ?
<omglasers2>
kenaryn, Romania, you ?
<waleee-cl>
omglasers2: if it's a comptime function it would work (see how generics work)
<torque>
it also works if you capture the type using @This()
<TheLemonMan>
oh cool, yes you need sret for the first argument there
<pingiun>
TheLemonMan: so a check for ppc64le and then return true?
<TheLemonMan>
wilsonk, just use qemu's usermode emulation, that's hella fast
<TheLemonMan>
yeah, that part of codegen is a mess
<pingiun>
hey wilsonk, you're the commenter on my issue
<pingiun>
I'm trying your patch right now
<wilsonk>
pingiun: yeah, I had access to a ppc64le machine and put that diff together a while ago. Then I lost access and only downloaded the diff in time...forgot the two std/os/linux files
<pingiun>
I see, I already have the syscall numbers but I need to fill in the rest still
<wilsonk>
pingiun: the bits/linux/ppc64le.zig file can mostly be translated from the equivalent musl lib file. The syscalls also shouldn't be too bad once you get the first couple done
<TheLemonMan>
please insert the whole syscall list, don't pick only the ones you need
<wilsonk>
pingiun: when I say the syscalls I mean the inline asm for making a syscall, btw
<pingiun>
yeah, I found the file: arch/powerpc64/syscall_arch.h
waleee-cl has quit [Quit: Connection closed for inactivity]
<wilsonk>
pingiun: oh, nice I didn't even use that file for some reason when I worked on this...that is nice and clean though. Looks easier than me reading the darn POWER docs! :)
<pingiun>
wilsonk: haha I thought thas was what you meant when you said "equivalent musl lib file"
<pingiun>
but I see that you were talking about the constants
<wilsonk>
pingiun: yep, I did most of the port before finding the constants, but it was nice not to have to write out that list from the docs :)
<wilsonk>
pingiun: I will be off to bed soon, but if you get past building zig0 and things fail when building zig proper, then that is where I got to. I can't remember what the error was off hand, but if you run into a bus error then let me know what your debugging finds and it might jog my memory (I believe I was getting a bus error).
<pingiun>
wilsonk: sleep well, thanks!
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 256 seconds]
jjido has joined #zig
ur5us has quit [Ping timeout: 240 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jjido has joined #zig
pingiun has quit [Read error: Connection reset by peer]
pingiun has joined #zig
Xavi92 has joined #zig
<Xavi92>
Hello, how can I add command line parameters to 'zig build'? Is 'zig build my_flag' possible?
<ikskuh>
yes
<ikskuh>
you can either use b.option()
<ikskuh>
or use -- to pass args to build.zig
<ikskuh>
or you can add custom steps with b.step("name")
<ikskuh>
which you can depend on
<Xavi92>
Thanks! So 'zig build --a' would make 'b.option(bool, "a", "flag a");' return true? Or does b.option() only add parameters to build.zig?
<ikskuh>
it adds parameters
<ikskuh>
so you can do
<ikskuh>
-Da=true
<ikskuh>
and then b.option() will return true
neptunepink has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jjido has joined #zig
<Xavi92>
Thanks, ikskuh!
<Xavi92>
Can build.zig be debugged, BTW?
<ikskuh>
probably, yes
pingiun has quit [Read error: Connection reset by peer]
<ikskuh>
it just compiles an exe in the end that can be debugged
<Xavi92>
Oh, is there any reason why calls to stdout.print() appear in reverse order?
<nmeum>
I am seeing super strange behaviour when doing a LinearFifo write, it somehow affects other members of the struct https://tpaste.us/jx9o (after the fifo write the base_addr of the uart changed somehow) the relevant parts of my code look like this: https://tpaste.us/DDvz
<nmeum>
am I somehow using LinearFifo entirely wrong? is there an alternative explanation for the behaviour I am seeing there? I am very confused about this
<nmeum>
it's on a freestand target so it might be possible that I am doing something wrong entirely
nephele_ is now known as nephele
<pixelherodev>
I asked yesterday, but is there a way to either override the default calling convention used by Zig or somewhere I can find said CC specifi - oh wait, now I get it
<pixelherodev>
There *is* no default calling convention
<pixelherodev>
Or if there is, it doesn't matter because it's getting overridden
<pixelherodev>
A more correct question would be, how does LLVM's fastcc operate on AMD64? and that's not a questino for here
<pixelherodev>
s/ino/ion
<ikskuh>
default calling convention is zigcc :D
<ikskuh>
but as it has no ABI, you cannot export it
<ikskuh>
→ specify calling convention for every exported fun
<pixelherodev>
It's not about exporting
<pixelherodev>
It's about accessing stdlib
<pixelherodev>
ikskuh, e.g. std.debug.warn
<pixelherodev>
My JIT currently has to link libc so it can use `write`
<pixelherodev>
because in --release-fast mode std.debug.warn cannot be used
<pixelherodev>
It thrashes registers
<ikskuh>
std.debug.warn has no explicit calling convention
<pixelherodev>
and I don't know what the ABI *should* be
<pixelherodev>
That's my point
<ikskuh>
none
<pixelherodev>
I know
<ikskuh>
it needs to be instantiated for a certain architecture
<ikskuh>
and hten you can use *any*
<pixelherodev>
I need some way of calling to it using some sort of predefined ABI
<pixelherodev>
But I'm using `std.debug.warn` as a function pointer
<pixelherodev>
In debug modes it works fine
<pixelherodev>
It seems to stick to the SystemV ABI on Linux
<ikskuh>
well
<pixelherodev>
Correction
<pixelherodev>
I'm not using it as a function pointer
<pixelherodev>
I'm calling a function marked callconv(.C)
<ikskuh>
std.debug.warn cannot be called from native, only a certain instantiation of it
<pixelherodev>
Then calling std.debug.warn from within a callconv(.C) function
drp has quit [Remote host closed the connection]
drp has joined #zig
<pixelherodev>
ikskuh, so if there's no calling convention, is there any pure Zig solution you'd recommend?
<pixelherodev>
I'm not actually using formatting either
<pixelherodev>
I basically need a way to call BufferedOutStream.write from within callconv(.C) code
<ikskuh>
pass a pointer and use a callconv(.C) function
<pixelherodev>
I am using a callconv(.C) function...
<pixelherodev>
but BufferedOutStream.write isn't callconv(.C), it's zigcc isn't it?
<ikskuh>
then you can call any zig code in there
<pixelherodev>
That's my point; I can't.
<pixelherodev>
If I call zigcc code from within a callconv(.C) function, it causes a crash
<pixelherodev>
the Zig code works fine
<pixelherodev>
but after the return it crashes
<ikskuh>
huh
<pixelherodev>
Yeah.
<pixelherodev>
Here's the thing; it works in debug mode
<pixelherodev>
but not in release mod
<pixelherodev>
s/mod/mode
<pixelherodev>
my guess is it's messing with a register I didn't realize I was using or something
<pixelherodev>
but I looked at the emitter, and literally all registers are discarded before that call
Cadey is now known as Xe
<pixelherodev>
It shouldn't care about *any* values other than PC and SP
<pixelherodev>
So I'm willing to wager an optimization is resulting in SP being off or something
<ikskuh>
is your SP aligned?
jjido has joined #zig
<TheLemonMan>
check who's in charge of cleaning the stack frame
foobles has joined #zig
<AndroidKitKat>
how's zig's compatibilty with the WSL?
<TheLemonMan>
good?
layneson has joined #zig
<pixelherodev>
TheLemonMan, I can't check that
<pixelherodev>
because the ABI is undefined
<pixelherodev>
It's impossible to know
<pixelherodev>
Actually
<pixelherodev>
It's irrelevant
<TheLemonMan>
the fuck? just check the code
<pixelherodev>
Either way, it's being called by Zig-generated code
<pixelherodev>
Isn't a constraint in `{}` a literal register?
<pixelherodev>
e.g. I could use `{eax}`?
<pixelherodev>
(on x86)
<pixelherodev>
AFAIK that code sample looks correct
<ikskuh>
yes you can do that
<pixelherodev>
Right, so it shouldn't be trying to allocate output registers IIUC
<pixelherodev>
ah wait
<pixelherodev>
Unless it's saying it doesn't know the literal register "3"?
Xavi92 has joined #zig
Xavi92 has quit [Client Quit]
cole-h has quit [Quit: Goodbye]
<TheLemonMan>
pingiun, try rN
moo^ has joined #zig
<moo^>
I'm trying out 'zig cc' and trying to compile openssl. What could be the cause for this error? lld: error: zig-cache/o/.../cryptlib.o:24: unknown directive: typedef
<pingiun>
TheLemonMan: error: couldn't allocate output register for constraint '{r3}'
cole-h has joined #zig
<TheLemonMan>
worksforme
r4pr0n has joined #zig
<pingiun>
so you're positive it should be rN?
<pingiun>
I'm an absolute noob on ppc64 assembly
<pingiun>
and also on zig assembly syntax
<pixelherodev>
the bits of assembly I found implied the r shouldn't be there, but I've never used ppc64
<r4pr0n>
Could someone explain me why you would want to use `usize`s instead of `u32` or `u64` in your code?
<pixelherodev>
If you want something to match pointer size
<pixelherodev>
e.g. index into a slice
<pixelherodev>
On a 32-bit system, the index can't be 64-bit; that'd make no sense
<r4pr0n>
so you can't allocate more than 4.3 GigaBytes of ram on 32 bit systems?
<r4pr0n>
(2^32 bytes ~ 4.29 GB)
<pixelherodev>
Not even, on most
<r4pr0n>
oh, that's - interesting, i guess, thank you, this is good to know
<TheLemonMan>
even if you could allocate more than that how are you supposed to address such a huge block of memory?
<TheLemonMan>
bring back segments?
<r4pr0n>
well i guess you would be able to use a u64 for something like that, just how you are also able to use that for something else on 32-bit systems
<TheLemonMan>
pingiun, did you add the 'r' to all the registers?
<fengb>
The kernel can possibly map more than 4GB but that’s the cap available to any single process in 32bit mode
<pingiun>
yes
<TheLemonMan>
you can pull some interesting stuff with PAE, but you're limited to 48bit
<fengb>
IIRC Windows did it when first breaking the barrier
<TheLemonMan>
but then you're just using the MMU to go over the limit
<TheLemonMan>
back in the days we had bank-switched ram
<pixelherodev>
Banking!
<pixelherodev>
My custom z80 system uses that :)
<mikdusan>
funny 48bit just happens to be the initial AMD64 _usable_ addr space
<fengb>
Ah yeah banking is fun too
<pixelherodev>
Pretty sure 48-bit for AMD64 isn't a coincidence
<pixelherodev>
It's because of the the design of the paging tables
<pixelherodev>
That is, it's for the same reason PAE was 48-bit
<andrewrk>
this release cycle is going to be brutal for people proposing syntax changes
<pingiun>
TheLemonMan: I'm trying to update the stdlib for ppc64, and this register constraint error is the only useful thing I get, no line numbers or anything
<r4pr0n>
andrewrk: could you clarify what you mean with "to make the syntax work" in your close-comment of 4294?
<pingiun>
fork as in the github sense
<TheLemonMan>
eh no shit it didn't work
<TheLemonMan>
don't forget to add `-mcpu=pwr9`
<andrewrk>
r4pr0n, I'm pretty sure there is an older issue where I already tried to remove () from if/while/etc with discussion there. I don't have a link handy
<pingiun>
TheLemonMan: I'm using the build script, with ./build -j4 native baseline
<pingiun>
that should do it right?
<TheLemonMan>
no
<andrewrk>
r4pr0n, yes that looks like it
<TheLemonMan>
why are you working on the boostrap repo?
<pingiun>
because I want to bootstrap zig on ppc64
<pingiun>
I'm working on a ppc64 machine btw
<pingiun>
so native==ppc64le
<andrewrk>
any source changes to bootstrap repo should be made against the respective upstream project
<r4pr0n>
andrewrk: i'm sorry if I misunderstand something here, but wouldn't the issue with `x = if (c) a else b;` be solved by 4294 as it requires you to use `{}`?
<TheLemonMan>
focus on getting zig to target ppc64le first
<TheLemonMan>
once that's working you can focus on the boostrap thing
<TheLemonMan>
one can of worms at time
<andrewrk>
r4pr0n, x = if (c) label: { break :label a; } else label: { break :label b; }
<TheLemonMan>
you don't even need a ppc64 machine, qemu user-mode emulation is enough to port it
<companion_cube>
`if c { a } else { b }` 🤷
<pingiun>
TheLemonMan: the fun thing is that I had the ppc64 machine first, so I just wanted to test things out
<companion_cube>
but well, not explicit enough
<andrewrk>
companion_cube, that used to be zig syntax but it was removed
<companion_cube>
I know :)
<andrewrk>
all these syntax proposals were proposed by myself 5 years ago
<fengb>
if a { <-b } else { <-c }
<companion_cube>
I think your mind is set on this one, and that's ok
<r4pr0n>
andrewrk: so the problem is the readability when returning/breaking values from blocks?
<companion_cube>
I think it's that the diff between `{a; b;}` and `{a; b}` is one char only
<companion_cube>
and the second one returns a value, not the first one
<companion_cube>
(imho think type-checking makes this a non issue, but readability is a matter of taste)
<fengb>
Just always return the last statement. That hasn’t hurt anyone right? 🙃
<companion_cube>
… no ? :)
hazeycode has joined #zig
<fengb>
Mostly joking — it’s a pervasive problem in Ruby and Coffeescript
<fengb>
Less of a problem in statement-less languages but Zig isn’t one of them
<r4pr0n>
I've heard of noone having a problem with that syntax in rust
<TheLemonMan>
pingiun, your `restore` and `restore_rt` have an output constraint in the input section (and you don't need setnoat for ppc asm)
<companion_cube>
fengb: it's not a problem in typed languages
<companion_cube>
unrelated, but I wonder if async/await is too specific a name for the feature :)
<companion_cube>
it seems more like first-class continuations than something specialized for concurrency
<companion_cube>
so clearly `suspend` should become `call/cc`!
<fengb>
If it is, it’s the first continuation that I can understand
<fengb>
Like how I can use promises all day and still have no clue what monads are >_>
<companion_cube>
:D
<TheLemonMan>
hazeycode, get a debug build of the zig compiler and re-run that command
<companion_cube>
interesting how many issues are trying to address `foo: { … break :foo x }`
<hazeycode>
TheLemonMan thanks, will do
<fengb>
Mostly addressing breaking a single block
<companion_cube>
which is 99% of uses cases
<fengb>
I think what we have right now is fine for arbitrary named breaks. But it’s pretty verbose to add blk: for a semi-common problem
<companion_cube>
very common*
<companion_cube>
it's an expression language, not a statement language :)
<companion_cube>
(gosh I'm rambling so much about that9
<companion_cube>
)
<r4pr0n>
i also think there should be a better solution, but #4412 worse imo
<r4pr0n>
s/worse/is worse/
<fengb>
Split break into breakloop and breakblock? 🤔
<r4pr0n>
well maybe breaking to the innermost block/loop by default would also be an idea
<companion_cube>
that's tricky though, if you add a `if` inside your `while`, then suddenly you risk breaking from the if instead of breaking from the loop
<fengb>
That's sort of the problem. We default to loop right now and it's hard to switch to block without "breaking" from the rest of languages
<companion_cube>
… unless `{a; b}` just returns `b` 🤷
<foobles>
how do you generate short-circuiting boolean and/or instructions?
<ifreund>
honestly splitting break into breakloop and breakblock is the cleanest suggestion i've seen yet
<ifreund>
because those two really are two different things, and the zen is to be explicit
<r4pr0n>
fengb: i'm not aware that breaking from the rest of languages syntax-wise was ever a concern of zig
<foobles>
i am basically generating `((x == null) == (y == null)) && (x == null || x.? == y.?)`, but when I run it, it seems to eagerly evaluate the unwrapping
<companion_cube>
r4pr0n: you mean except for using `{}` everywhere? :p
<companion_cube>
it's definitely C-style
<ifreund>
fengb: do you want to write a proposal for that or should I?
<r4pr0n>
companion_cube: yeah, but i don't think the only reason for it to be that way is to be like c
<r4pr0n>
ifreund: i agree actually, though maybe one could use break for loops and think of a different keyword for blocks
<mikdusan>
foobles: make a reduction and look at ir for examples
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ifreund>
r4pr0n: yeah I could see that, though I'm having trouble thinking of a good non-break keyword for blocks, maybe `break` and `breakblock`
<foobles>
TheLemonMan I am trying to generate runtime instructions
<foobles>
I already handle the comptime case
<fengb>
I thought breakblk was proposed at one point
<ifreund>
perhaps, i'll do some searching
<fengb>
r4pr0n: we don't want to reuse concepts that will confuse existing users though
<TheLemonMan>
foobles, ok then check the generated IR
<fengb>
It'll add a bunch of confusing headache and scare away new users
<r4pr0n>
well, fengb, break would then be the same as in other languages basically
<r4pr0n>
so i don't think that will really cause confusion
<companion_cube>
fengb: there's at least one issue where `break :lbl x` scared a new user!
<ifreund>
companion_cube: he's talking about break vs breakloop
<fengb>
Break in any C based language (including Java and the ilk) means break a loop
<fengb>
Yes but it's explicitly different
<pixelherodev>
Maybe propagate?
<fengb>
I'm talking a bare break only doing blocks will probably confuse most people, including me
<pixelherodev>
As a breakloop keyword
<pixelherodev>
Yeah, I quite like status quo honestly
<r4pr0n>
oh, i thought you were talking about this suggestion of mine: "i agree actually, though maybe one could use break for loops and think of a different keyword for blocks"
<fengb>
Oh we're just talking past each other lol >_>
<fengb>
I'm also in a meeting so I'm half paying attention
<r4pr0n>
yeah, i agree with you on what you meant on having break use the innermost block/loop
<pixelherodev>
Yay meetings
<r4pr0n>
i think the breakloop/breakblock is better, even though I think breakloop could be continued to be called break
<ifreund>
what about `yield` for blocks?
<mikdusan>
could have implicit labels; `break` means break block no matter which block. `break :outer` and for I dunno.. `break ::outer` for 2 levels up
<ifreund>
that sounds far more complicated than a new keyword
<fengb>
break [reversed keyword]
<companion_cube>
anyone knows where I can find the original discussion about blocks not returning values by default?
<fengb>
break fi;
<fengb>
break rof;
<ifreund>
break esac;
<r4pr0n>
oh i have the best idea: use `kaerb` for blocks
<pixelherodev>
ifreund, yield is a bad idea IMO
<pixelherodev>
Given that people will confuse it with threading
<ifreund>
pixelherodev: i agree, i prefer breakloop/breakblock
<pixelherodev>
How about bikeshed?
<pixelherodev>
:P
<r4pr0n>
i kinda think this discussion is important, given that it is very unlinkly to change after 0.7.0 and blocks as expressions are a often-used concept
<ifreund>
^
<hazeycode>
TheLemonMan I'm getting the same output with a debug build. Is there something I need to do in addition to setting cmake build type to Debug?
<hazeycode>
exe.linkSystemLibrary("CoreAudio"); works without.adding the search path
<TheLemonMan>
duh, uyou should get a stack trace at least
<hazeycode>
afraid not
<r4pr0n>
what about `crush` as a keyword for breaking blocks? sounds like a joke, but it's kinda funny and thus easy to remember 🤔
<hazeycode>
note: 'CoreAudio/CoreAudio.h' file not found is what I'm actually trying to resolve
<ifreund>
`bust`
<fengb>
What does tetris call it when we clear a line?
<nmeum>
quick question regarding memory allocation: if a struct is allocated on the stack, I assign a pointer to that stack to a global variable and then the function returns this global variable will potentially point to uninitialized memory, right?
<r4pr0n>
i think it's the best if someone would propose this and we would talk about the exact keyword names in the issue thread
<ifreund>
i'll write it up, just gimme a few minutes
<nycex>
okay, great
<TheLemonMan>
hazeycode, run it under gdb then, with a backtrace at hand you can easily find what went wrong
<nycex>
i think this is a good idea
<r4pr0n>
👍
<TheLemonMan>
the FileNotFound is nasty, I guess that's because the debug infos generate relative paths
moo^ has left #zig ["WeeChat 2.7.1"]
<TheLemonMan>
hazeycode, are you using zig 0.6.0 ?
<hazeycode>
built 0.6.0 release commit from source yeh
<hazeycode>
just ran with lldb, no stack trace, exits cleanly
<hazeycode>
counter to what the output suggests
<TheLemonMan>
oh the FileNotFound is my fault, but I blame inferred error sets for that
<companion_cube>
there isn't much of a justification in it, too
<andrewrk>
you can comment on a closed issue to ask for justification
<r4pr0n>
well i guess being able to do 4294 would be another argument for 732 if 4294 would be accepted when 732 is
waleee-cl has joined #zig
<andrewrk>
I think one of thejoshwolfe's goals is to have justifications for all the rejected proposals
<andrewrk>
not mine though
<mikdusan>
hazeycode: that error is likely from codegen.cpp
<companion_cube>
heh, sure thing
<hazeycode>
thanks mikdusan
<companion_cube>
andrewrk: thanks, I'll bother him. I know I'm a pain in the butt wrt syntax.
Ichorio has joined #zig
ninjacato has joined #zig
<fengb>
Is he still around? >_>
<andrewrk>
he said he would help write the lang spec during this release cycle
<shakesoda>
i feel like justifications everywhere is nice but it's a lot more important for accepted than rejected
<foobles>
like a formal spec?
<foobles>
that would be cool
<foobles>
still waiting on one for rust :v
pingiun has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<fengb>
The impl is the spec 🙃
<companion_cube>
shakesoda: "why not use this simpler syntax" kind of deserves an explanation imho :)
<companion_cube>
c'mon, there are literally reference books for rust
<fengb>
That's not the same thing though
<r4pr0n>
companion_cube: do you mean for 629 or for 732?
<shakesoda>
companion_cube: it's not like i think a justification in those cases is bad, just that it's more useful to explain why something *did* happen than why it *didn't*
<mikdusan>
andrewrk: maybe we add a label "release notes" so we can tag PRs we _know_ will need to be included in notes. makes for easier collection
<companion_cube>
r4pr0n: for the thing 629 removed
<r4pr0n>
i think the reasoning is in the proposal
Snetry has quit [Quit: left Freenode]
<companion_cube>
the "two ways to return a value from a function"? …
<companion_cube>
the other one I just don't understand
Snetry has joined #zig
<companion_cube>
(the code snippet is perfectly clear)
<r4pr0n>
it actually is yeah, the if statement should return the return values of the inner branches, if they are different types, compile error, right?
<companion_cube>
expressions return values, transitively. end of stor
<companion_cube>
y
<r4pr0n>
well you could argue that it is not clear if it is actually meant to be an statement or an expression here
<r4pr0n>
because normally if statements without an semicolon are a statement
zfoo has quit [Remote host closed the connection]
<r4pr0n>
but i don't think that is a real problem because it is obvious that the if statement does return something here, due to the var x = and due to the bar() and baz() in the branches
Xavi92 has joined #zig
PC9801 has joined #zig
<Xavi92>
Are there any reasons to prefer 'fn function(self: *Self)...' over 'fn function(self: Self)...'?
<companion_cube>
r4pr0n: my point is, statements are just expressions returning void
<r4pr0n>
you can't modify self in the latter, can you?
<companion_cube>
or they should
<r4pr0n>
good point
<r4pr0n>
i actually think that the best approach is to revert 629 and keep 732
marijnfs has quit [Quit: leaving]
<companion_cube>
I don't think that's going to happen…
<r4pr0n>
why not? i don't think two solutions to one problem is a good enough reason for a change that prevents #4294
<r4pr0n>
and I also don't think that the "another problem" of 629 is a problem; it should be allowed imo
<ifreund>
ok, i've thought about it for a while now and i think the status quo is the right way to go andrewrk knows what he's doing
<fengb>
Nah, let's assume he doesn't know what he's doing
<r4pr0n>
ifreund: i don't think that's a strong argument, maybe he didn't think about something like 4294 when accepting 629
<ifreund>
i think the current syntax is more readable, plain and simple
<ifreund>
an explict return or break keyword beats implict return by dropping a `;` by a mile
<companion_cube>
r4pr0n: that's why I'm asking a justification, tbh
<companion_cube>
I think getting closer to rust (I know…) would simplify the syntax
<companion_cube>
(blocks return last expression's value, if/while/for have mandatory {}, no corner cases needed)
<r4pr0n>
exactly
lanodan has joined #zig
<r4pr0n>
ifreund: i also don't think that dropping ";" or breakloop/breakblock is worth it on itself, but i think #4294 is worth it, because those proposals would (probably) enable that
<ifreund>
i'm saying that implict return by droppint the `;` is a negative for readability
<ifreund>
i'm not convinced that required curlies for if/while are worth the tradeoff, especially since indentation will be enforced in the future
<companion_cube>
it's not implicit, just uniform
<companion_cube>
and more readable than `x: { …; break :x 42; }`
<companion_cube>
(but again readability is relative I guess)
<r4pr0n>
you would have the following advantages: - you can remove the () of the if/while/for statements; - { a } is equal to a (which would simplify the language a lot imo)
<r4pr0n>
and i think the unreadability of omitting ";" is overestimated since it is only allowed at the end of a block
<ifreund>
i'd say it is implicit if the `return` keyword is still in the language
<ifreund>
and `break`
<companion_cube>
r4pr0n: and it's typesafe
<companion_cube>
ifreund: return/break would be there for early return
jjido has joined #zig
<companion_cube>
(rust does it, and it's quite neat)
<ifreund>
yes, so then they function just as well when used on the last line of a block. Therefore dropping the `;` is an implict as opposed to explicit return
<r4pr0n>
ifreund: and i can speak of my experience with rust, where i had absolutely no problem with confusing { a; b; } with { a; b }
<ifreund>
i've written my fair share of rust,
<companion_cube>
ifreund: well that's nice for one line function, yes
<companion_cube>
`fn foo(x: int) int { x+1 }
<companion_cube>
`
zfoo has joined #zig
<companion_cube>
it's in line with #1717 too, since everything goes towards being an expression
<afontain_>
ruby also does that IIRC
<companion_cube>
languages lacking that tend to do `function() { … return x; }()` :p
ur5us has joined #zig
FireFox317 has quit [Ping timeout: 256 seconds]
omglasers2 has quit [Quit: Leaving]
tane has joined #zig
<Xavi92>
Sorry, was afk
<Xavi92>
r4pr0n: so that means (self: Self) and (self: *const Self) are equivalent?
<foobles>
Xavi92 I dont believe so
<r4pr0n>
i'm not actually sure what Self does exactly
<ifreund>
Self isn't special, just a type
<foobles>
usually defined as `const Self = @This()`
<r4pr0n>
yeah, i mean what that in a function call does
<foobles>
its just the type of the type its being implemented for
<r4pr0n>
i'm not sure if it is pass-by-value, pass-by-copy or something like that
<ifreund>
Xavi92: those aren't equvivalent. the first is semantically a copy but allows the compiler to transparently optimize to a const* if it is faster
<Xavi92>
Isn't the zig compiler free to determine which pass-by method to use?
<ifreund>
the second is explictly a const* so you can do, for example, pointer comparisons
<ifreund>
is that clear?
<Xavi92>
So they *might* compile to the same thing
<r4pr0n>
companion_cube: could you elaborate on "r4pr0n: and it's typesafe", i'm trying to write a comment with the pros and cons to 629
<ifreund>
as far as i understand it yes
<Xavi92>
Alright
<companion_cube>
r4pr0n: well, adding a spurious `;` is safe because it will be a type error
<companion_cube>
(expected int, got void)
<companion_cube>
same way that `const x = if (a) 1 else {}` fails because the else is not an int
<companion_cube>
(imagine `else { foo; 2; }`, that doesn't typecheck)
<Xavi92>
ifreund: then if two possible ways exist, is (self: Self) preferred over (self: *const Self)? Except from the pointer comparison use case, of course
<ifreund>
Xavi92: yes (self: Self) is preferred everywhere that you can use it
<Xavi92>
r4pr0n: totally agree with the first point. Not so much with the second point (probably since I'm more used to C than Rust, but I'm fine with both approaches)
<Xavi92>
r4pr0n: what's the meaning of the third point? Allowing e.g.: 'if (a) b' instead of 'if (a) {b}'?
<Xavi92>
ifreund: thank you very much
<ifreund>
no problem
<r4pr0n>
no that wouldn't be allowed by #4294 if it would be implemented
<companion_cube>
r4pr0n: easier to switch between an expression and a block when adding, say, a debug message
<r4pr0n>
i meant more of a: "the language would be easier to understand since those are semantically identical"
<Xavi92>
r4pr0n: then it's a pro IMHO. Avoiding the curly brackets has introduced bugs in C and C++ over the years
<r4pr0n>
yeah
<r4pr0n>
that's the fourth pro, but i'm gonna rephrase that to make it more clear
<Xavi92>
In the end, AFAIK encourages K&R curly brace style, so vertical space isn't that much wasted
ifreund has quit [Read error: Connection reset by peer]
<Xavi92>
I have a proposal too, although it'd break existing code. Don't know if that's a serious issue given current status of the language
<r4pr0n>
syntax change?
<Xavi92>
Yeah
<Xavi92>
Variables/instances/objects/younameit are always created by using either 'const' or 'var'. However, arrays passed to functions may be either '[] type' or '[]const type'
<r4pr0n>
now would be the time to do that, after 0.7.0 the syntax is very unlikely to change again
<r4pr0n>
s/do/propose
ifreund has joined #zig
<Xavi92>
Why not use '[]var type' to make mutability explicit?
<Xavi92>
AFAIK this is the one of the cases in zig where mutability is assumed by default (as in C and C++), instead of making the user choose one
<Xavi92>
This leads to const-correctness issues and potential bugs if the user forgets the 'const' qualifier
<Xavi92>
Which, from my own experience with many third-party C libraries, is much more common than it should
<Xavi92>
Rust forces default immutability and must be explicitly changed by the user by adding the 'mut' qualifier
<Xavi92>
I don't think we should do like Rust either, but make the user choose between 'var' or 'const', as with variable definition
<ifreund>
Xavi92: pointers are the same: `*Server` vs `*const Server`, tbh it's a valid question and I wonder if there's an open proposal
<Xavi92>
ifreund: sure, didn't want to mention pointers as I was not 100% sure, but same applies here
<Xavi92>
After all, zig uses 'const' for pretty much "everything"
<r4pr0n>
"Also, mutable pointers by default. &const u8 or & u8 to declare a pointer type to u8."
<r4pr0n>
seems that this was intended after all, but I don't know why
<Xavi92>
r4pr0n: that looks like an arbitrary decision though. I don't know if andrewrk considered using '&var u8'
<andrewrk>
I did
<Xavi92>
andrewrk: why wasn't it considered?
<andrewrk>
it was considered
<Xavi92>
I mean, why was '&u8? chosen over '&var u8'?
<Xavi92>
andrewrk: IMHO default mutability has surely caused many issues on C and C++ over the years. I'm not saying zig should go for default mutability for pointers and arrays, but making mutability explicit surely would help avoiding them in zig
<Xavi92>
...go for default immutability*
<TheLemonMan>
hazeycode, that's not a backtrace, you need the `bt` command in lldb to get one
tschaei has joined #zig
<gonz_>
The release notes for 0.6.0 reads super well. I'm impressed with the breadth of the changes as well as the write-up itself.
<gonz_>
Well done, everyone. :)
<foobles>
i have to agree with Xavi92, but i doubt that will make it into the language
<foobles>
you could write a proposal, assuming it hasn't been done already
<Xavi92>
andrewrk: surely forcing the user to add 'var' on pointers and array parameters would break existing code, so for the next versions a warning could be emitted instead of an error
Ichorio has quit [Read error: Connection reset by peer]
<Xavi92>
Until a given version of the compiler stops supporting then-legacy '[]type' and '*type', emitting an error
<Xavi92>
foobles: thanks. Now that it sounds like a reasonable proposal for other people as well, I'll post it on github
Akuli has quit [Quit: Leaving]
<shakesoda>
i kinda feel like the comfort of it as is is preferable
<shakesoda>
i don't really take any ideological issue against it though
<shakesoda>
s/take/have/
<foobles>
coming from rust, I realized that in C i want const 90% of the time
<Xavi92>
shakesoda: sure, []type and *type are more comfortable to write. And that's usually a problem
<foobles>
^^^^ exactly
<shakesoda>
i dunno if i'd say it's usually a problem
<shakesoda>
it is occasionally one
<Xavi92>
shakesoda: I mean it's a problem because we programmers are lazy, and we prefer omitting a keyword than adding zero-cost safety
<foobles>
I would much rather forget to make something mutable, and then change the interface to be more inclusive, than to erroneously accept mutability and have to restrict the interface
<shakesoda>
and absolute refusal to allow some laziness is why i can't tolerate rust :)
<shakesoda>
i'm just not especially sold on it being worthwhile
<Xavi92>
foobles: that's the ideal approach if I were to write a new language. But given how zig operates, a balanced approach can be taken
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<Xavi92>
shakesoda: then don't take default immutability, but make the user choose between 'var' and 'const'
<r4pr0n>
shakesoda: the problem is that the lazy way (omitting the mutability specifier) is the less restrictive way
tane has quit [Quit: Leaving]
<Xavi92>
shakesoda: that's pretty much the same effort as writing 'var' or 'const' when defining a variable
<Xavi92>
shakesoda: and honestly I hope people in zig don't type 'var' over 'const' just because it's two characters shorter
<foobles>
what would you think of getting rid of const-specifiers on pointers altogether?
<shakesoda>
i don't specifically have a desire for adding yet more specifiers all over the place
<foobles>
replace const with var in pointers
<foobles>
so its const-by-default
<foobles>
i would not mind that at all
<Xavi92>
shakesoda: ^^^^ it's just making the user choose between one or other
<shakesoda>
that would help a lot to offset visual noise of it
<shakesoda>
things are already const by default in a lot of situations though
<foobles>
when?
<shakesoda>
parameters
<foobles>
ah thats true
<Xavi92>
Sure, and I love that approach
<foobles>
me too
<shakesoda>
most of the mutability concerns are related to parameters to begin with
<Xavi92>
Not really, or probably not a concern in C-like languages
<Xavi92>
Pretty much the opposite
<Xavi92>
Mutability is a concern with pointers, essentially
<ifreund>
i think const by default for pointers would be inconsistent with having const/var instead of e.g. let/let mut
<Xavi92>
ifreund: that's why I prefer '[]var type'/'[]const type' for zig
<ifreund>
my vote would be fore `*var` and `*const`
<Xavi92>
Makes it much more consistent
<Xavi92>
ifreund: exactly
<foobles>
i would be fine with that
<Xavi92>
So, winning 3vs2 so far :)
<r4pr0n>
im torn, on one hand immutability by default would be much easier to use
<foobles>
although i would prefer `*T` and `*var T`
<shakesoda>
given what i would describe as "a crapton" of * things all over the place i don't really want to force writing the specifier everywhere
<foobles>
yeah
<r4pr0n>
Xavi92: did you make a proposal
<ifreund>
default immutability is easier but less explicit, it goes against zig zen imo
<r4pr0n>
/s/proposal/proposal?/
marijnfs has joined #zig
<Xavi92>
r4pr0n: no, I'm on it. I'm glad to know some of you agree
<shakesoda>
Xavi92: andrewrk has veto power over anything lol
kk- has quit [Quit: Leaving.]
<Xavi92>
That makes 3vs10000000000000000000001 then :)
FireFox317 has joined #zig
<companion_cube>
ifreund: how is it less explicit, again? :D
<companion_cube>
it's mutability that should be explicit
<hazeycode>
I vote for pointers immutable by default :D make mutable explicitly
<ifreund>
companion_cube: for someone that is not familiar with zig, `*const` and `*var` are instantly understandable
<hazeycode>
(not sure I have a vote) :D
<r4pr0n>
^
<foobles>
i would vibe with that 8)
<shakesoda>
generally speaking one should probably make language decisions for the users of that language
<ifreund>
more importantly, it's consistent with const/var for variable declarations
<shakesoda>
not with utter disregard for everyone else, but a fairly strong bias
<foobles>
thats true too ifreund
<foobles>
i like that perspective
<Xavi92>
shakesoda: my proposal is specifically meant for zig
<shakesoda>
that was directed at the "for someone that is not familiar" comment
<shakesoda>
which probably shouldn't be a driving force here
<Xavi92>
shakesoda: I don't want it to have (at least one) of the issues C already suffers from. I'm tired of reading third-party C libraries from well-know manufacturers that know nothing about const-correctness
<shakesoda>
in the scope of real software bugs, const correctness is so low it barely even registers
<shakesoda>
not that i think it doesn't matter
<Xavi92>
shakesoda: that's like saying malloc() should never be checked against NULL since it's a very rare condition
<companion_cube>
ifreund: well why would they know `var`?
<Xavi92>
And then you have undefined behaviour unexpectedly
<shakesoda>
it is most certainly not like that
<companion_cube>
the principle of least surprise matters a lot more to beginners, than keywords vaguely resembling other languages
<ifreund>
companion_cube: imo it's pretty clear that var is short for variable/variablity and the opposite of const short for constant
<companion_cube>
if you see `*const T` first
<companion_cube>
otherwise it's just weird
<Xavi92>
companion_cube: does that mean *var T would sound weird to beginners?
<companion_cube>
well, beginners will find things weird anyway
<shakesoda>
fwiw i don't think var is good to put in a type specifier anyways, it's too overloaded there
<hazeycode>
with immutable by default, a new user not thinking about pointer immutability with just use *T types happily, until they try to a) mutate a pointer they shouldn't have and get told off by the compiler and correct their mistake or b) try to write some pointer mutating code and get told by the compiler to use *var T. That's a nice onboarding
<hazeycode>
experience, and I don't have to write const everywhere :)
<companion_cube>
(*mut T? :D)
<hazeycode>
:D :D I refrained from that
<afontain_>
^ this
<Xavi92>
Not that I'm against 'mut', but I don't see the need when we already have 'var'
<shakesoda>
var already does other things.
<shakesoda>
including things when used in types
<afontain_>
`f(*var int)` ?
<shakesoda>
e.g. parameter type var is totally legal and commonly used, and that then leaves you with things possibly like *var var
<hazeycode>
ok *mut T is sounding reasonable
<Xavi92>
I'm about to submit the proposal. Would you all prefer '*mut type' and '[]mut type'?
<shakesoda>
if we're talking about changing the semantics of things like this then rust's mut sounds fine and we can just kill const
<shakesoda>
my support is still kind of low, but it's a lot better than further overloading `var`
<ifreund>
imo that's not the right way to go, this proposal needs to be in the context of and consistent with the current language
<ifreund>
that means `*const foo` and `*var foo` imo
<shakesoda>
well yeah, and using var here doesn't fit the current language
<shakesoda>
because var does very much different things in some of the same places
<ifreund>
`*var` isn't valid now, why would `*var var` be valid?
<Xavi92>
Alright, I'll submit the proposal with 'var' (which is what I came up with initially) and add a foot line where 'mut' could be also considered
<ifreund>
sounds good to me
<ifreund>
shakesoda: and please do add a comment mentioning the confusing with var as a type so that sees formal discussion
<ifreund>
*confusion
<Xavi92>
ifreund: oh, you're right
<ifreund>
Xavi92: about what?
<Xavi92>
Hadn't thought of 'var' as a type
<Xavi92>
Which I still don't fully understand what 'var' is when used as a type
<nycex>
to the second one, i guess "variable type"
<Xavi92>
Please feel free to comment and provide suggestions / improvements
jjido has quit [Ping timeout: 246 seconds]
<shakesoda>
threw mine in, minus the resolved var ambiguity
<shakesoda>
i don't know how it sounds but my actual attitude is mostly indifferent, i just really don't want this to cause more visual noise than zig already has
tschaei has quit [Remote host closed the connection]
xackus has quit [Ping timeout: 256 seconds]
kenaryn has joined #zig
<kenaryn>
Hello, please how can I activate `-fmem-report`? I do not know where and how to put 'ON' on `-DZIG_ENABLE_MEM_PROFILE`.
<foobles>
can I get some help implementing my compiler feature? I am trying to implement runtime comparison of optionals (non-pointer), by expanding `x == y` into `((x==null) == (y==null)) and ((x==null) or (x.? == y.?))`
<foobles>
`((x==null) == (y==null)) and ((x==null) or (x.? == y.?))`
puzzleddev has quit [Quit: Leaving]
puzzleddev has joined #zig
<foobles>
and `x != y` will become `((x==null) != (y==null)) or ((y!=null) and (x.? != y.?))`
foobles has quit [Remote host closed the connection]
<fengb>
I believe just libc
xackus has quit [Ping timeout: 265 seconds]
<fengb>
Oh wait maybe. Mac’s libc is also the syscall layer
<r4pr0n>
i don't know if the compiled binary works, but zig build-exe -target x86_64-macosx hello_world.zig works without erroring and produces a binary
<copy>
Indeed my observation so far is that it compiles but fails to run
<r4pr0n>
may be, i have no machine to test on
r4pr0n has quit [Quit: r4pr0n]
grant_ has joined #zig
<grant_>
I am trying to build stage 1 on fedora 31, I get this error right away `CMake Error: CMake was unable to find a build program corresponding to "Unix Makefiles".`
<grant_>
I'm not familiar with cmake, is this not set in this release, should I change the cmake files myslef
<waleee-cl>
grant_: do you have make installed?
<grant_>
ah no, my bad
<grant_>
I'm rather suprised it was not installed...
<grant_>
sorry about that
<waleee-cl>
redhat-based distros are often surprisingly sparse with buildtools as the default