<telemach>
I like this approach because it's clear and straightforward, and also allows to have the type conforming multiple interfaces, and cast it back from interface when needed.
<telemach>
Is anyone keen to help me to understand if this approach optimization-friendly? Is generated assembly any optimal for the task in my example?
<telemach>
I renamed things a bit (because Interface there is more about Implementation inside actual interface type) and came up with this silly example: https://godbolt.org/z/f2BA0p
<daurnimator>
telemach: why the extra indirection via _compare instead of having the user provide the actual `compare`?
<telemach>
just for the calling magic s1.compare(&s2), otherwise need to s1.compare(s1, s2)
<_Vi>
Is there "safe navigation operator" in for optional field access in Zig?
<telemach>
(with `&` before args ofc)
<telemach>
does this indirection have cost expect boilerplate? i assume that it should be easily optimized out, but i don't know for sure and can't read assembly
<telemach>
s/expect/except/
<daurnimator>
_Vi: what would you want to happen if its null?
<_Vi>
daurnimator, Return null, obviously.
<_Vi>
If type of the field is itself nullable, then the result may be doubly nullable (preserves info) or just nullable (flattens).
<daurnimator>
_Vi: in zig there is no non-safe navigation...
<daurnimator>
_Vi: i.e. `x.foo.bar` isn't allowed if `foo` is nullable
<_Vi>
Unsafe navitaion: `mything.?.myfield`
<_Vi>
It is way shorter and nicer to type than safe analogue `if(mything)|x|x.myfield else null`
<daurnimator>
_Vi: have you considered `orelse` and a slight change in your control flow elsewhere?
<daurnimator>
`(x.foo orelse return null).bar`
<daurnimator>
telemach: oh interesting that the self-passing doesn't work if its a function field
<daurnimator>
mq32: the `_1` in there... shouldn't need to be
waleee-cl has joined #zig
doublex has joined #zig
<mikdusan>
if i read code correctly, the "payload" of decls brought in by usingnamespace are _NOT_ added to ScopeDecls.decl_table and instead added to use_decls,
doublex has quit [Ping timeout: 264 seconds]
<mikdusan>
and later something triggers a load of payload decls from use_decls -> decl_table
<mikdusan>
there are a few places (namely where I recently patched ir_analyze_container_member_access_inner to support VarDecl struct-method calls),
<mikdusan>
ok i think i see the gap now. just thinking outload :)
<Cadey>
even better when you let the rubber duck talk back
<daurnimator>
quack.
<presiden>
\_o< (meow)
<mikdusan>
heh nice
LargeEpsilon has quit [Ping timeout: 264 seconds]
mahmudov has quit [Remote host closed the connection]
LargeEpsilon has joined #zig
<daurnimator>
mikdusan: I just came to a realisation far far too slowly. your nick is based on your name.
<mikdusan>
nobody ever said I was original :)
<fengb>
It's missing a letter
<companion_cube>
wait until you realize that andrewrk's nick is also based on his name
<mikdusan>
i can't even remember why i did that. maybe mikedusan was taken. or i wanted to limit to 8 chars.
<fengb>
... I now read his name as Andrew R Kelley
<fengb>
Unfortunate implications >_>
<jaredmm>
andrewrk, just as confirmation: the epoxy linking issue happens with a normal C program, so it is something about how it is built on Windows that causes the problem. Only difference I noticed between a working and not working Windows .lib was that the code section included the exported symbol a second time.
doublex has joined #zig
<daurnimator>
companion_cube: yeah. but somehow in my head I read it as "andrew work"
<companion_cube>
"andrew worker"
<companion_cube>
it's just one of his worker threads
LargeEpsilon has quit [Remote host closed the connection]
LargeEpsilon has joined #zig
doublex has quit [Ping timeout: 245 seconds]
ntgg has joined #zig
<andrewrk>
jaredmm, thanks for the follow-up
<andrewrk>
scientes, I'm going to play around with the way you implemented vector element access. I might need to make some adjustments
<scientes>
see, this is buggy qemu, not zig or llvm
<andrewrk>
scientes, as an example, this crashes the simd branch, where `v` is a vector: const ptr = &v[1];
<scientes>
SIMD support in qemu is buggy, arm-32 too (arm64 seems to work)
<scientes>
andrewrk, oh yeah, that needs a special exception, which I forgot to put in
<andrewrk>
I'll be happy to rework the Array accesses on vectors commit, but it'll take me some time
<scientes>
yeah I can work on the address not being possible
<andrewrk>
I think this is the same problem as taking the address of a non-byte-aligned packed struct field, which requires additional metadata into the pointer type
<scientes>
except here you just can't take the address
<andrewrk>
and we should just embrace that. a zig pointer type can have metadata that tells you how to access the vector
<scientes>
gcc ang clang will both error
<andrewrk>
that's the same thing with packed structs
<andrewrk>
hmm, you got it working with runtime indexes though, nice. that's a difference
<andrewrk>
scientes, here's a question that I think you are the best poised to answer. would making the vector index required to be comptime be problematic?
<scientes>
andrewrk, not currently, but for RISC-V (which isn't supported by LLVM yet, but they are working on it)
<scientes>
which has variable-length SIMD
<andrewrk>
in what way would that be problematic?
<scientes>
the length is run-time on RISC-V
<andrewrk>
hmm is this what the vscale thing is designed to address?
<scientes>
stage1 will require a overhaul once llvm figures it out, but I have tried to not create problems in the zig code
<andrewrk>
OK, I want to think through this carefully
<scientes>
like maskedLoad and maskedStore are very x86-specific and deprecated
<andrewrk>
it's an important design consideration whether or not the appropriate vector length is comptime-available or not
<scientes>
It is on current architectures
<andrewrk>
I want to learn more about this runtime vector length risc v thing
<scientes>
Mill CPU does the same thing, but that is still vaporware
<daurnimator>
the hardware is vapor...
<scientes>
<andrewrk> and we should just embrace that. a zig pointer type can have metadata that tells you how to access the vector
<scientes>
but you really can't take a pointer
<scientes>
just copy the value
<scientes>
but I guess "pointer" could be reference
<scientes>
and could even support pointer arithmetic
<andrewrk>
scientes, if the index is comptime known, then the index can be part of the pointer metadata. this is how packed structs work
<scientes>
anyways, for now I think it should just be disallowed
<scientes>
ahhhh, I see
<andrewrk>
so that's why it's pivotal whether or not we decide if indexes are allowed to be runtime
<scientes>
oh yes, that's really useful
<scientes>
even if on some architecture it has to be done with bit shifting
<scientes>
no, i think it works on every architecture i've used
<scientes>
I think pointer should be pointers, and they are with packed structs (its just that its a sub-byte pointer)
<scientes>
and in that case it can be runtime too if you just use the high bits
<scientes>
or whatever
lunamn has joined #zig
<andrewrk>
another option is that index syntax has to have comptime indexes but additionally provide @vectorLoad(v, runtime_index) and @vectorStore(v, runtime_index, new_elem_value)
<andrewrk>
so you can have a "pointer" to a vector but the index has to be comptime known
<scientes>
I don't see that pointers of vector elements is useful at all
<scientes>
and its not even a pointer
<scientes>
If archs supported run-time choosing of vector register it would be differnt
<scientes>
but they don't
<scientes>
andrewrk, cause you wouldn't be able to assign the "pointer" to one vector to the "pointer" to another vector
<andrewrk>
why not?
<scientes>
because the vector register an instruction references is fixed
<scientes>
it would have to refer to the *same* register
<andrewrk>
it's the same as integers
<andrewrk>
vectors have a well defined in-memory layout
<scientes>
but we don't have pointers to registers
<andrewrk>
we have pointers to integers
<andrewrk>
zig doesn't have the concept of registers; it only has the concept of memory
<scientes>
ahh yes I see, and then it can be run-time
<andrewrk>
but certainly we are relying on the optimizer to convert memory loads and stores to registers where appropriate
<scientes>
I don't think LLVM knows how to optimize this
<scientes>
you would have to write to memory and then write back to the register
<scientes>
yeah I get your point
<scientes>
the compilers have just been lazy with vectors
<andrewrk>
in zig a vector is very much like an integer
<scientes>
we could just stack allocate all vectors
<scientes>
like we do with integers
<andrewrk>
and we already support sub-byte pointers to integers
<scientes>
and then we could do this
<andrewrk>
I think we already do that...
<scientes>
oh yes we do
<andrewrk>
yeah even in your branch
<andrewrk>
what I'm suggesting is that in the same way zig already supports sub-byte pointers to integers, that might be the best way to do per-element pointers to vectors
<scientes>
yeah, I think you've convinced me
<andrewrk>
and we can still provide runtime element index access builtins for that use case
<scientes>
no, we can do both
<andrewrk>
this will make all zig pointer semantics work correctly
<scientes>
run-time and comptime index
<scientes>
the problem with that is that the pointer is bigger
<scientes>
at least on 32-bit arches
<andrewrk>
the point of comptime index is that the pointer can be not bigger
<andrewrk>
because the index will be part of the type
<scientes>
oh no, it isn't bigger!
<scientes>
its just pointing to the stack, and its aligned!
<scientes>
so you can use the low bits
<andrewrk>
right
<scientes>
except that only works for byte-sized array elements
<scientes>
and llvm bit-packs sub-byte-sized vector elements
<scientes>
sorry, not array there, then the packing is differn't
<andrewrk>
the runtime address will point to the base of the vector. the comptime pointer metadata will inform how to access the element
<scientes>
we still have 4 bits free
<andrewrk>
yes I'm not even suggesting to use these bits
<scientes>
hmmmmm....id rather support run-time indexes, have it point to to the element, and just have addrof not work on weird-sized integers
<scientes>
in vectors
<scientes>
although then its quite a hack with getelementpointer
<scientes>
yeah, i guess comptime index support is better than no index support, ok agreed
<andrewrk>
&v[2] would have type of something like this, assuming v is @Vector(4, i32) type: *align(16:0:4:2) i32
<andrewrk>
here I appended another : field to packed struct syntax, this way we can even refer to sub-bytes of elements of a vector
<scientes>
I don't see this a reason to change the syntax
<andrewrk>
`*align(4:0:4) i32` is status quo syntax; and in fact `*align(4:0:4) i32 == *i32`
<scientes>
hmm, I haven't used that type of syntax. RISV-V also has pretty cool bit-shuffle instructions
<andrewrk>
if pointers gain additional metadata for vectors, then it makes sense to add this other field
<andrewrk>
for: `*align(16:0:4:2) i32` it would mean: "this is a 16-byte aligned address, pointing to index 2 of a vector of i32 elements. Offset starting from bit 0, and the size of the containing integer is 4.
<andrewrk>
this is that bit_offset_in_host, host_int_bytes, thing you were asking about
<scientes>
ahh thanks for the explination of the syntax, i was looking for that
<andrewrk>
let me rephrase the explanation
<scientes>
I think I get it
<scientes>
but vectors don't need the bit_offset and host_int fields
<andrewrk>
for: `*align(16:0:4:2) i32` it would mean: "this is a 16-byte aligned address, pointing to the base of a vector of i32 elements. We refer to a 4-byte integer at index 2 of the vector, offset starting from bit 0
<scientes>
and they should never be packed like that
<andrewrk>
you could put a vector into a packed struct
<scientes>
oh I guess that is OK
<andrewrk>
hmm that's not quite what this situation would cause
<scientes>
all this stuff is comptime
<andrewrk>
yes, usually nobody would even see these types; it would just look like normal indexing worked
<scientes>
and in this case pointer arithmetic can also be supported
<andrewrk>
but if you tried to do foo(&v[1]) then you'd get something like, expected *i32, found *align(x:y:z) i32
<andrewrk>
(unless you used the correct parameter type, in which case it would work fine!)
<scientes>
yes it would!
<scientes>
as we are not bound to C functions
doublex has joined #zig
<andrewrk>
I think I would make the argument that this comptime index restriction is a good place to start
wootehfoot has joined #zig
<scientes>
I want to support runtime indexes too
<scientes>
that can't be remove
<scientes>
yeah I'll have a stab at this
Barabas has quit [Ping timeout: 260 seconds]
<andrewrk>
one way to do that would be to provide @vectorLoad(v, runtime_index) and @vectorStore(v, runtime_index, new_elem_value)
<andrewrk>
this way they avoid going through a pointer type
<andrewrk>
so you cannot have the &v[x] problem
<scientes>
I'm still not convinced these pointers are useful at all
<andrewrk>
this would probably be the most straightforward way to implement, to avoid having to introduce any additional complexity to the compiler
<scientes>
i see a little use though
<andrewrk>
well you already had to add a hack to avoid pointers
<scientes>
i realized that f16->f128 should be implemented with @shuffle
<andrewrk>
ceymard, I think you are going to be happy with the changes I'll be pushing today
<Cadey>
how do i target wasi in zig?
<Cadey>
-target wasm32-wasi-musl isn't working
<andrewrk>
in what way is it not working?
<Cadey>
Zig is unable to provide a libc for the chosen target 'wasm32-wasi-musl'.
<andrewrk>
that message is accurate
<andrewrk>
what do you need libc for?
<andrewrk>
the wasi spec is incompatible with libc in a lot of ways
<Cadey>
i was curious if i could use zig as a c cross-compiler
<andrewrk>
you can do that for all the targets listed under "Available libcs:" in `zig targets`
<andrewrk>
we've got a W.I.P. wasm32-freestanding-musl libc
<andrewrk>
no wasi one yet
<andrewrk>
it's likely whatever c code you wanted to cross compile would be fundamentally incompatible with a wasi libc
<andrewrk>
things like memcpy, strlen, etc can work, but wasi doesn't support e.g. the concept of a current working directory
<andrewrk>
or any networking
<andrewrk>
or lots of stuff. it's not very mature
<andrewrk>
I mean even as a specification
<daurnimator>
libc doesn't have to provide that stuff...
<Cadey>
so how would i get a pure zig program building against wasi?
<daurnimator>
Cadey: use freestanding rather than trying to link libc?
<Cadey>
should i -target wasm32-wasi?
<andrewrk>
Cadey, your -target param is fine (you can drop the musl if you want, it doesn't matter), but you need to omit -lc
<Cadey>
okay
<andrewrk>
it's just bare bones support in std and some stuff may have regressed because we don't have test coverage for it
<andrewrk>
shritesh did a bunch of nice contributions for wasi but lost interest months ago, and nobody else is driving the use case (until you, right now)
<Cadey>
this is weird, the default hello world app from `zig init-exe` works when i build it with `zig build-exe -target wasm32-wasi src/main.zig` but not with this build.zig: https://clbin.com/hrWsj
<Cadey>
andrewrk: yeah, i more mean they compiled nginx to wasm using emscripten, which makes a javascript wrapper around a subset of linux system calls
<andrewrk>
yeah, sorry I was selfishly changing the subject
<Cadey>
:+1:
<andrewrk>
I want them to finish self hosting so I can make a zig "sandbox" that is just client side javascript
<Cadey>
i half wonder if wasi is good enough for compiling zig to it
<Cadey>
er
<Cadey>
like the compiler itself
itsMontoya has quit [Remote host closed the connection]
LargeEpsilon has joined #zig
LargeEpsilon has quit [Ping timeout: 245 seconds]
samtebbs has quit [Remote host closed the connection]
samtebbs has joined #zig
<samtebbs>
I'm getting an error whose @errorName is "Overflow". Is that only caused by addition overflow?
<andrewrk>
samtebbs, if you grep the std lib for `error.Overflow` there are only a few places that comes from
<andrewrk>
mostly std.math functions
<samtebbs>
andrewrk: Thanks, I'm getting it when using std.debug.openElfDebugInfo
<samtebbs>
I'll look into what could be causing it
<samtebbs>
Working on freestanding code does make tracking down things like this difficult
<andrewrk>
yeah
<andrewrk>
you might be able to set up a non-freestanding unit test
doublex has joined #zig
<samtebbs>
Perhaps I could. My setup is quite involved though, I'm loading my kernel's elf file as a grub module then creating a SeekableStream using the start and end of the module, then passing that to openElfDebugInfo
<samtebbs>
There's quite a few places where things could be going wrong xD
halosghost has quit [Read error: Connection reset by peer]
halosghost has joined #zig
halosghost has quit [Read error: Connection reset by peer]
halosghost has joined #zig
<samtebbs>
I see that the error is returned in leb128.zig as I've seen that leb128 is used to decompress some parts of elf files
<samtebbs>
and I've seen*
FireFox317 has joined #zig
<FireFox317>
Is zig target armv7 to be used for an armv7-A core? I can't find a target arm-v7a
doublex has quit [Ping timeout: 240 seconds]
<andrewrk>
FireFox317, I believe the "a" is a target feature, which would be handled by https://github.com/ziglang/zig/issues/2883. I consider this issue to be high priority
<FireFox317>
Uhm well, Clang has the triple armv7a-none-eabi. Are you sure it is a target feature?
<andrewrk>
I think they parse that as: arch: arm, sub-arch: v7, features: +a
halosghost has quit [Quit: WeeChat 2.6]
doublex has joined #zig
<FireFox317>
Ah yeah that makes sense
<andrewrk>
(I didn't understand this until a few months ago)
dimenus has quit [Quit: Leaving]
return0e has joined #zig
return0e_ has quit [Ping timeout: 276 seconds]
doublex_ has joined #zig
doublex has quit [Ping timeout: 276 seconds]
FireFox317 has quit [Ping timeout: 240 seconds]
kllr_sbstn has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]