<IntoxicatedHippo>
I worked out why, my memset function was nakedcc
<IntoxicatedHippo>
Actually that wasn't it, I ran the wrong build. Debug builds are still not working
fu5ha has joined #zig
<andrewrk>
IntoxicatedHippo, do you know what instruction it's tripping on?
<IntoxicatedHippo>
OK, it was to do with my memset function. When I was invoking lld manually it was trying to link to memset which wasn't defined so I wrote my own memset. Now that I'm using build-exe memset is defined by one of Zig's libraries. Now that I've removed my memset function debug builds work fine.
<IntoxicatedHippo>
It wasn't a GP fault or anything, it just wouldn't execute the efi application at all.
<andrewrk>
note that the default panic handler is pretty bad for the efi target. if you wanted to send some improvements it would be very welcome
<IntoxicatedHippo>
There isn't much that can be done unless zig sets up some runtime stuff for efi. The entry point for efi applications is a function which a pointer to a struct is passed to. All IO (and everything else) is done using function pointers inside that struct.
<andrewrk>
I see. well maybe for efi it's reasonable to expect the programmer to provide their own panic function then
<emekankurumeh[m]>
IntoxicatedHippo: is that struct the same for all efi applications?
<andrewrk>
I'm down to 10 failing std lib tests in result location branch
<andrewrk>
zig fmt turned out to actually provide pretty good test coverage for result location stuff
<emekankurumeh[m]>
andrewrk i know you said that zig fmt is checked on every build, but as of 2d6520d zig fmt fails with a stack overflow for me.
<IntoxicatedHippo>
emekankurumeh[m], I believe so
<hryx>
(wave) I'm back from a bunch of travelling and stuff and trying to wrap up this translate-c PR finally
<andrewrk>
emekankurumeh[m], the command the test suite runs is `zig fmt build.zig` (where build.zig is the zig build script itself)
<andrewrk>
does that work for you?
<andrewrk>
welcome back hryx!
<andrewrk>
result location branch is so, so close
<hryx>
sooooo exciting
<emekankurumeh[m]>
no it fails with error code 127
<emekankurumeh[m]>
from a segfault in ___chkstk_ms
<andrewrk>
emekankurumeh[m], that's strange, it looks like the test suite is running it on windows to me
<andrewrk>
there's even a `test-fmt` step
<emekankurumeh[m]>
well i'm on msys64 so maybe there's an issue there?
<andrewrk>
hmm that's possible
<andrewrk>
I think the mingw checkstk function is different
<hryx>
andrewrk: on the off chance you feel like taking a short break from your branch, I'm kind of stuck on a bug in my branch. Unfortunately I let the branch get kind of big before trying to fix it
<emekankurumeh[m]>
i managed to fix the problem a while ago, but the fix wasn't to change any files, but rather recompiling a couple times
<andrewrk>
hryx, I'm sort of in tunnel vision mode at this point but I definitely want to help as soon as I get this thing merged
<hryx>
no worries, charge towards dat finish line!
<andrewrk>
I believe these functions get invoked when there is a large stack frame. that is when the local variables are enough to push it over the size of 1 page
<emekankurumeh[m]>
that's what i thought too so i inspected the functions that zig fmt called and found it was returning large arrays
<emekankurumeh[m]>
i tried making the arrays smaller but i still get the same stackoverflow
<andrewrk>
it's an important clue that it only happens on msys64, maybe we need to detect that target and have different chkstk semantics
<andrewrk>
it could be useful to see if the msys64 libc has a __chkstk_ms implementation
<andrewrk>
I mean it must, and it might have the answer to the problem in t
<emekankurumeh[m]>
i'm not so sure because format worked fine when launched as a subprocess
<andrewrk>
we could simply disable stack checking for msys targets for now
<andrewrk>
this is a good find because it will be useful to bootstrap the self hosted compiler with mingw someday
<emekankurumeh[m]>
i'll test that and submit a PR if it works
<andrewrk>
thanks!
reductum has joined #zig
<emekankurumeh[m]>
i sent the PR
<andrewrk>
great, so that fixed it then?
<emekankurumeh[m]>
yup
<emekankurumeh[m]>
i just wonder if there is a way to refactor std.os.windows to not need such a large stack
<andrewrk>
I would just merge this but i'm worried about the logic not being exactly identical in CMakeLists.txt
<andrewrk>
I remember that " " was needed for some stupid thing
<andrewrk>
regarding the stack, the plan is to have zig actually calculate the necessary stack size and then just provide it
<andrewrk>
and recursive functions will use allocators so they won't take up stack space
<emekankurumeh[m]>
it's seems to compile fine on macos, linux, and freebsd so far
<emekankurumeh[m]>
but it might be best to wait until all ci passes
<andrewrk>
good night
<emekankurumeh[m]>
gn
reductum has quit [Quit: WeeChat 2.5]
wootehfoot has joined #zig
<marijnfs>
what timezone are you guys in
Ichorio has joined #zig
IntoxicatedHippo has quit [Ping timeout: 258 seconds]
samtebbs has joined #zig
<samtebbs>
Does anyone know if it's possible to pass values to the zig source similiar to how you would do -DFOO=something with GCC
<samtebbs>
I'd like to do this so that I can change the code path based on some parameter
st4ll1 has joined #zig
<mikdusan1>
samtebbs: i suppose you could create a config.zig file and define some constants there; then use command line --pkg-begin/--pkg-end to select which config (namespace) to provide
<emekankurumeh[m]>
samtebbs if you have a build.zig you can put them in there and refer to the file through @build
Ichorio has quit [Ping timeout: 252 seconds]
<samtebbs>
emekankurumeh[m]: Has that been added since 0.4?
<emekankurumeh[m]>
no it's in 0.4.0 but it's not documented
<samtebbs>
Ah ok. I don't seem to be able to import it with @import("@build") or use it directly with @build
<samtebbs>
error: unable to find '@build'
mikdusan1 has quit [Ping timeout: 245 seconds]
<tralamazza>
maybe without the @
<mq32>
hey
<mq32>
i'm just reading some issues on github and wondered: is there already a proposal/project for project dependencies/libraries/...?
<mq32>
(like "cargo" for Rust or "nuget" for dotnet)
<emekankurumeh[m]>
a package manager?
marijnfs has quit [Quit: WeeChat 2.4]
<mq32>
ah yes, that's the word :D
<tralamazza>
#943
<mq32>
thanks :)
<emekankurumeh[m]>
samtebbs that's strange std/special/build_runner uses @build and src/main.cpp has logic for adding that to the package table
Akuli has joined #zig
<tralamazza>
something like #2595 would be helpful for embedded, especially if I could query it from builtin.
Tetralux has joined #zig
<samtebbs>
tralamazza: It would! Hopefully a review can take a look at it soon
<samtebbs>
emekankurumeh[m]: It is weird. I'm gonna see if I can reproduce it with a more minimal setup
<emekankurumeh[m]>
perhaps it's not documented because it relies on special magic for just build_runner file?
<emekankurumeh[m]>
in any case just going with a config file should work
<samtebbs>
emekankurumeh[m]: Yes, perhaps. I'll go with a config file for now. Thanks emekankurumeh[m] and mikdusan1
samtebbs has quit [Quit: Lost terminal]
mikdusan has joined #zig
mikdusan has quit [Ping timeout: 246 seconds]
IntoxicatedHippo has joined #zig
Tetralux has quit [Ping timeout: 248 seconds]
mikdusan has joined #zig
mikdusan has quit [Ping timeout: 272 seconds]
mikdusan has joined #zig
<mikdusan>
andrewrk: copy-elision-3: when init() returns a struct that sets a union(enum) of type void; llvm-ir compare to master. looks like a store is missing on copy-elision-3
IntoxicatedHippo has quit [Ping timeout: 245 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
marler8997 has quit [Ping timeout: 256 seconds]
curtisf has joined #zig
curtisf has quit [Ping timeout: 256 seconds]
curtisf has joined #zig
jjido has joined #zig
Akuli has quit [Quit: Leaving]
<andrewrk>
mikdusan, nice find
curtisf has quit [Ping timeout: 260 seconds]
curtisf has joined #zig
<mikdusan>
the .d parser exposed it on linux so if you see any garbage .d errors it's likely that
SimonNa has quit [Remote host closed the connection]
<hryx>
stage1 renders a nameless fn proto as `fn() ...` while stage2 keeps the space: `fn () ...`. This means that I can't convert some translate-c tests to work for *both* stage1/stage2
<hryx>
I'm thinking about just making stage1 include the space like stage2. how does that sound?
<hryx>
since all the tests for e.g. zig fmt obey stage2 rules
<Tetralux>
Does zig fmt put a space when you declare an anonymous fn?
<marijnfs>
i'm trying to play with libsoundio in zig, but i need access to a member of the libsoundio struct
<marijnfs>
but i get type '[*c].cimport:4:11.struct_SoundIo' does not support field access
Ichorio has joined #zig
<hryx>
marijnfs: it's not an OpaqueType, is it?
<andrewrk>
marijnfs, hmm did I forget to implement field access with C pointers?
<emekankurumeh[m]>
andrewrk: whats your position on exposing the build file to userland code, i.e. through `@import("@build")`?
<andrewrk>
hmm when would this be used?
<emekankurumeh[m]>
as passing flags like -DSOME_VALUE 3 aren't supported in zig, the build file could be used to define these flags for configuring a library
<andrewrk>
the -D thing is supported with b.option()
<andrewrk>
and you can expose options to code too, I just need to document that API
<emekankurumeh[m]>
really?
<andrewrk>
it makes available @import("build_options"). it's a bit of a hack right now, but it'll evolve into something more stable and make sense with the package manager
<hryx>
andrewrk: I can finally convert translate-c tests to work with both stage1 and stage2, but it seems the behavior still differs regarding making a fn `export`ed. Both versions should have the same behavior, right?
<andrewrk>
hryx, there are also those comments at the top of test/translate_c.zig
<hryx>
Oh! I see, about #include mode
<hryx>
what's the TLDR difference between include mode and -c mode?
<andrewrk>
the idea was that in -c mode, you're translating a C project, so non-static functions should be `export` because that's what -c would do
<andrewrk>
but in #include mode, it's like you just want to call the functions
<andrewrk>
now that I'm thinking about it again though, I don't think there should be a difference
<andrewrk>
because if you were to #include a non-static function in C, it would get exported. so the @cImport equivalent of that would be indeed, creating an export function and translating its definition
<andrewrk>
so thinking about it again, I don't see why there needs to be 2 modes
<hryx>
shortest path might be, I'll make stage2 use this "mode" for now, then I can make an issue to change this
<hryx>
how does dat sound
<andrewrk>
hryx, but also, please note that that test/translate_c.zig file has the ability to have separate tests for stage1/2 impls. please feel free to regress stage2 a little bit to make progress on your branch
<andrewrk>
try not to regress on stage1 though
<andrewrk>
yeah sounds good
<hryx>
ok great
<andrewrk>
I mean it will be hard to regress on stage1 without changing the cpp code
<Sahnvour>
their concerns are really specific, but I don't see a usecase where having a "rvalue" on both the left side of an assignment would make sense in zig
<Sahnvour>
-both
<andrewrk>
oh I see
<andrewrk>
yeah this looks like a missing compile error
<emekankurumeh[m]>
about how long does it take for the website to be updated?
<andrewrk>
emekankurumeh[m], are you talking about the CI builds?
<andrewrk>
click on the Details of the rocket ship one
<andrewrk>
you can see the windows build is still going
<andrewrk>
if that succeeds it'll do the UpdateDownloadPage job
<andrewrk>
you can look at previous builds to see how long those took
<andrewrk>
probably another 2 hours
<Tetralux>
Wait - so slicing an array gives a slice where, if it's []T you can modify the elements, and if it's []const T you cannot, but you cannot assign another slice to it to modify the elements underneath either way?
<Sahnvour>
hey, zig just hit 100 contributors :)
<andrewrk>
Tetralux, are you looking at the example in the issue?
<andrewrk>
Sahnvour, yeah! :)
<Tetralux>
I did.
<Tetralux>
I mean both generally, and in that example.
<andrewrk>
you can always reassign a variable
<andrewrk>
Sahnvour is pointing out, if I understand correctly, that reassigning a temporary value is useless and therefore very likely a bug
<Tetralux>
i guess the reason for why it's temporary is escaping me
<Tetralux>
because its a slice
<curtisf>
`[]T` is really something like `struct{ptr: *T, len: usize}`
<Tetralux>
and surely just points to data underneath.
<Sahnvour>
the instance of the slice itself, which is a disguised struct, ist temporary since it's not stored anywhere, juste created via the slicing expression
<Tetralux>
i would not immediately assume that x[0..n] = y[0..n] does anything other than copies y's elements to x's.
SimonNa has quit [Remote host closed the connection]
<Tetralux>
i would be a little surprised if it did nothing.
<Sahnvour>
yeah that's confusing especially for people used to a more semantic way of dealing with collections of data
<Tetralux>
It's a little weird to me that you can assign a single element, but cannot assign a sub-slice of them at once.
<Tetralux>
esp since you can with the ptr+len.
<Tetralux>
And a slice is generally always just a ptr and a len.
<Tetralux>
Like
<Sahnvour>
well, slices are some kind of abstraction over pointers, you don't expect the pointed data to be copied when just copying the pointer itself
<Tetralux>
It's as if the slice is read-only, but one-element-at-a-time is mutable.
<Tetralux>
Like - what else would you mean by x[0..n] = y[0..n] than "please copy the elements from the r-slice to the l-slice.
<Tetralux>
Well that's not it
<Sahnvour>
my point is that it shouldn't compile
<Tetralux>
It's more what I said before
<Tetralux>
If each element of a slice is mutable
<Tetralux>
(eqiv to (ptr+len).* = ...
<Tetralux>
Then why is a range of elements immutable?
<Tetralux>
That seems a little weird to me.
<mikdusan>
except it's not a "range" it's a slice.
<curtisf>
Writing from one slice to another would require a loop. To me, it seems like that doesn't fit well with Zig's no-hidden-control-flow maxim to allow an `=` to spend an unbounded amount of time doing work
<curtisf>
maybe the compiler can detect this and just suggest using `std.mem.copy`
<emekankurumeh[m]>
well zig does hidden mencpy's so there is precedent
<curtisf>
where does it do hidden memcpys? surely just on constant sized objects?
<Tetralux>
Certainly, if you could not do it, I'd expect it to tell you what you _were_ expected to do.
<Tetralux>
But like I said
<Tetralux>
If the slice's elems are mutable
<Tetralux>
But multiple at once are not
<Tetralux>
That's not intuitive to me.
<Tetralux>
But maybe that's just me.
<Tetralux>
I'd expect the error to explain it. Or at the VERY least tell me to use @memcpy instead for clarity.
<Tetralux>
Or mem.copy.
<emekankurumeh[m]>
the slice being mutable is true in rust and nim iirc
<Tetralux>
Or w/e
<Tetralux>
I mean
<Tetralux>
"The slice" is not mutable
<Tetralux>
But the contents it points to is
<Tetralux>
And that's what I'd expect you're addressing when you x[0..n]
<Tetralux>
Which you are
<Tetralux>
But you're not doing that, as above, when used as an l-value.
<Sahnvour>
they are, but the slice itself (as a whole, not for accessing a single element) is a struct, and there's no magic to make it semantically represent the elements it points to, and in this case it does not make sense to expect it to modify multiple elements at the same time (although I agree it's confusing and should be adressed)
<Tetralux>
So
<Tetralux>
Here's the thing
<Tetralux>
x[0..n] is basically just ranged-checked ptr+len.
<Tetralux>
..which means that if it's []T instead of []const T... the elements are mutable.
<Tetralux>
So therefore all of elements are.
SimonNa has joined #zig
<Tetralux>
Therefore a range -- a slice of them, if you will -- are .
<Tetralux>
And they are not.
<Tetralux>
Which is my point.
<Tetralux>
It isn't consistent.
<Tetralux>
And that's fine
<Tetralux>
If you want to make copying clear
<Tetralux>
By making programmers do a mem.copy etc.
<Tetralux>
But it _is_ inconsistent with what you'd expect, I'd argue.
<Sahnvour>
I think it depends on where you come from and your past experience/languages, but I get your point
<Tetralux>
Maybe the whole idea is, "If you want to set one item, asisgn it - if you want to set multiple at once, loop over them or mem.copy.
<Tetralux>
To me
<Tetralux>
A slice is nothing more than a view into an array.
<Tetralux>
Except in this case
<Tetralux>
The elems can be const or non-const.
<Tetralux>
Which is fine.
avoidr has quit [Ping timeout: 272 seconds]
<Tetralux>
But in this case, they are essentially const if you are talking about more than one at once, even if it's []T.
<Tetralux>
Yet not when you address one at a time.
<Tetralux>
Like - I know it's a ptr and a len, so x[0..n] = y[0..n] should just be a memcpy, right.
<Tetralux>
And unless it's []const T, I don't really understand why it wouldn't be.
<Sahnvour>
the thing is, as slices really are structs, having special behaviour for their assignation is akin to operator overloading/hidden control flow, which zig does not want
<Tetralux>
You already have special operator overloading.
<Tetralux>
[0..n]
<mikdusan>
what would be the rules for `x[begin..end] = y[begin2..end2]` . must end-begin always equal end2-begin ?
<mikdusan>
correction: `end2-begin2`
<Sahnvour>
also, consider the case where the slices are computed with runtime length, unknown beforehand, how would you handle putting a larger one into a smaller one, etc. that's hidden control flow again
<Tetralux>
You could have the requirement that both slices are the same length and are of the same eltype, yeah.
<emekankurumeh[m]>
runtime safety would catch that
<Tetralux>
Indeed. Exactly.
<Tetralux>
Same as when you do x[n] now
<Tetralux>
Except once for the whole thing and not once per index.
<Tetralux>
x[0..n] = y[0..n] could check the whole range before doing anything.
<Tetralux>
Unless I'm missing sometihng.
<Sahnvour>
sure
<Tetralux>
And to avoid buffer overflow
<Tetralux>
You could ensure they are the same length
<Tetralux>
Which
<Tetralux>
Correct me if I'm wrong
<Tetralux>
Is the same as what happens for single-index now
<Tetralux>
So it would have the same property of undefined behavior in release-fast.
<Sahnvour>
I have the impression this is higher-level than usual zig constructs, but that could probably be a proposal, and maybe it's already been considered
<emekankurumeh[m]>
it's not much more complex than the compiler inserting a memcpy
<Tetralux>
Precisely.
<Tetralux>
Which - is what you'd expect it to do.
<Tetralux>
Like - if you could slice linkedlists, then obviously you prob wouldn't want this.
<Sahnvour>
well as I said what you'd expect depends on the person and its background
<Tetralux>
But you can only use this syntax on arrays.
<Tetralux>
(and ptrs)
<hryx>
FWIW I would not expect the same thing you do Tetralux, but that's only based on my experiences
<Tetralux>
hryx, what would you expect x[0..n] = y[0..n] to do?
<hryx>
I'd expect a slice expression can't be used as an lvalue... maybe. I'd have to think about it for a sec
<mikdusan>
i have to be honest, supporting `x[0..n] = y[0..n]` is almost misleading - one might wish to `x[2..3] = y[0..10]` which doesn't fly
avoidr has joined #zig
<Sahnvour>
coming from python I would expect the same thing you do, but as a C++ programmer I'm more inclined to think in the actual zig way (not to say one is better than the other)
<Tetralux>
mikdusan, you mean if y is []u8 and x is []u64 or something?
<mikdusan>
same types
<Tetralux>
mikdusan, I don't really see what a programmer could possibly mean by x[2..3] = y[0..10] then.
<mikdusan>
replace 2..3 with 0..10
<Tetralux>
If you replace that then it's fine though xD
<Tetralux>
Maybe I'm not understanding your point.
<mikdusan>
x.len != y.len
<Sahnvour>
you're arguing over slices with constants indices though, in real code it can happen pretty easily to have a variable which is a slice and that gets changed multiple times to point to different slices of element, without intending a copy of them
<Tetralux>
Sahnvour, I've been arguing over x[0..n] - note the 'n'.
<Tetralux>
If you had a slice var and changed it to point at different things
<Tetralux>
That would work as you expect.
<Tetralux>
Only if you used slicing syntax on the lhs would it assign multiple elems.
<Sahnvour>
ok
<Tetralux>
hryx, I'm not too clear as to _why_ exactly you'd expect that you could not assign it.
<Tetralux>
If there's an interesting reason for why you'd expect to not be able to, I'm interested.
<Tetralux>
But, devils advocate, why wouldn't you expect it to just do the obvious thing and memcpy
<hryx>
the reason it makes no sense is because a slice expression is the same as a struct initialization expression, which also can't be used as an lvalue
<Tetralux>
hryx, I'm not sure that's an argument. Slicing syntax is specifically meant to address multiple elems of multi-elem sequence of contiguous things.
<Tetralux>
Whether it's a struct initialisation is an implementation detail, no?
<hryx>
from what I understand the expression `s[0..1]` is like the expression `Slice{.ptr = s, .len = 1}`
<hryx>
maybe
<Tetralux>
Yeah
<Tetralux>
Sure
<Tetralux>
But that's the same as (ptr+len).* = ...
<Tetralux>
(I've never needed to do that in Zig yet, so forgive me if you need some casts with that.)
<Tetralux>
But the fact that it is the same is just syntax sugar.
<hryx>
I encourage you to create a github issue if you're interested in proposing these semantics - it's good to have such discussions in the open where people can search for them
<mikdusan>
these discussions are awesome btw
<Tetralux>
o7
<hryx>
:D
<Tetralux>
Honestly, I'm not sure where you'd use multi-assign like this. Like - using it in a loop would probably be bad right.
<Tetralux>
In which case forcing an explicit memcpy is better.
<Tetralux>
I could be remembering wrong but I think Odin does this.
<Tetralux>
..has the feature I'm suggesting, that is.
ltriant has joined #zig
<emekankurumeh[m]>
is there a proposal for allowing something like `pub fn foo(a, b, c: i32) void {...`?
<Tetralux>
I've actually found myself wondering about that feature a couple of times too.