kllr_sbstn has quit [Remote host closed the connection]
bjorob has quit [Ping timeout: 265 seconds]
ltriant has joined #zig
ltriant has quit [Ping timeout: 240 seconds]
ntgg has joined #zig
<andrewrk>
I'm planning to do a stream tomorrow, live coding a basic TCP chat server using evented I/O in zig. I think it will be fun, because i'll forward a port on my router and let people join
<pixelherodev>
Sounds exciting!
<scientes>
so the original proposal on array access on vectors is what is implemented, and pointers can also be supported the way that gcc-9 does it, and I really think that is the ideal way to do it, as those are common operations on vectors, and manually loading and storing is awkwards (there is a reason we never do that in C on ints, despite assembly working that way), unnecessarily
<scientes>
I really feel you are overthinking things with this new proposal
<andrewrk>
scientes, vector of integers should support all operations that integers support, yes?
<scientes>
generally yes, can't think of any exceptions ATM
<andrewrk>
vector of pointers, why not the same thing?
<scientes>
except that that isn't the common case, memory is a flat address space, and usually when dealing with @scatter and @gather you are dealing with a single base, and a vector of indexes
<scientes>
which my series supports
<scientes>
in addition to the vector-specific @scatter and @gather
<andrewrk>
I agree it is not a common case
<scientes>
basically the problem is that if you use vectors you have to do vector operations----the same math on every element
<scientes>
so generally you only do that with a single base array address
<andrewrk>
but you cannot have one without the other
<scientes>
v.* could return a vector
<andrewrk>
then v[i] must return a vector also
<scientes>
andrewrk, actually that can work with my patch set
<scientes>
i just didn't think of that
<scientes>
*that case
<andrewrk>
@Vector(N, *i32) vs @Vector(N, [*]i32)
<scientes>
but only if i is a vector
doublex has quit [Ping timeout: 246 seconds]
<scientes>
which actually makes way more sense than the vector version
<scientes>
but does mean we are overloading two operations with [i] which is a bit confusing, and I like that you point that out
<andrewrk>
oh!! good point. we can check the type of the index
<andrewrk>
maybe my branch is not wasted after all
<scientes>
so we are already supporting i as a vector
<scientes>
well, I am
<scientes>
when accessing both array (@gather/@scatter) and vector (@shuffle)
<scientes>
but if it is a vector of *pointer* than it can do this third thing
<scientes>
there is also the nasty that the index type is differ in the array and vector case
<scientes>
u32 and usize
<scientes>
also, if the sizeof() of the differn't pointer's types is differn't, we will have to do a vector multiplication by the sizeof (which may be optimized to a right shift)
<andrewrk>
I agree it is nasty
<andrewrk>
I think there is a way to make it work without being nasty
<scientes>
it made me realize that @gather and @scatter with 32-bit pointers should be supported on 64-bit architectures (with a passed base address somehow)
<scientes>
as you get twice the number of load/stores that way, and don't have to use unpack operations
<andrewrk>
I think it is quite clean, and it is different than your implementation
Ichorio_ has quit [Ping timeout: 264 seconds]
<scientes>
going through it now
a_chou has quit [Remote host closed the connection]
<andrewrk>
scientes, that test case passes in your branch?
a_chou has joined #zig
<scientes>
no. I do not have pointers working because I ran into issues with understanding how ResultLoc works
<andrewrk>
in mine this compile error is intentional
<scientes>
but gcc-9 supports that sort of thing
<andrewrk>
I would like to see such code
<scientes>
it just stack allocates
<scientes>
and than passes a pointer to the stack allocation
<scientes>
to the *element*
<andrewrk>
I don't understand
<scientes>
vectors have a in-memory representation
<scientes>
so you always write vector operations back to the stack
<andrewrk>
I see
<scientes>
and then rely on the optimizer to fix it up
<andrewrk>
but if you address an element, this will prevent the optimizer from doing such fix ups
<scientes>
that way atomics will work too
<scientes>
but in that case you want that
<scientes>
andrewrk, only if it can't optimize out the pointer to a direct element access
<andrewrk>
hm. we can make this work
<scientes>
also, it depends on GEP working on vectors
<scientes>
which is officialy not supported, but this is a valid use case
<andrewrk>
you mean it depends on GEP working on a vector element
<scientes>
so once it is working, we have to ask for that "not supported" to change
<scientes>
as GEP is the best way to do it
<andrewrk>
this would be done by pointer casting a vector to an array and using GEP on the array pointer
<scientes>
soooo
<scientes>
GEP works on vectors
<scientes>
there just wasnt a use case (and clang isn't doing what gcc-9 can do yet)
<scientes>
*noooo
<andrewrk>
if GEP worked on vectors this patch would be incredibly easy, and the type of &v[0] would be simply *i32
<scientes>
yes
<scientes>
i just ran into ResultLoc issues
<scientes>
unless I am missing something else
muffindrake has quit [Ping timeout: 246 seconds]
<scientes>
I don't know where we store *where* the vector stack allocation is
<andrewrk>
ok we can't rely on undocumented unsupported GEP behavior though
<scientes>
well we get it working, and point out that clang will also need it
<andrewrk>
the part you're missing is that it only works on a pointer to a vector. the pointer tells where the allocation is
<scientes>
and we *do* rely on it, because the optimizer needs it to work that way
<andrewrk>
this is exactly the same code path as arrays
<scientes>
yes it is
<scientes>
except we have to check the type, because vectors are not packed, and a u7 vector cannot be supported
muffindrake has joined #zig
<scientes>
(gcc doesn't support those, so doesn't have this issue)
<andrewrk>
I think we can support u7 just fine, we tell llvm it's u8
<andrewrk>
let's think for a moment if there was no llvm, how this would work
<scientes>
then we would have to copy it when it gets written somewhere else
<scientes>
with a cast
<scientes>
cause I actually *like* llvm's lack of vector packing
<scientes>
you just need bit-granularity pointers to work with it fully
<scientes>
which are not in scope
<andrewrk>
ok so your objection to this PR is that @typeOf(&v[0]) can actually be simply *i32
<scientes>
exactly
<scientes>
i played with gcc-9 and realized the code could be that simple
<andrewrk>
this is a difficult decision you've created for us to make. I certainly would want some reason to believe that LLVM core devs plan to make this change before relying on it
<scientes>
we can do it other ways
<scientes>
it just won't optimize correctly in llvm
<scientes>
(either now or in the future)
<andrewrk>
right, ok, so then the question of what if there is no LLVM, does this make sense in general
<scientes>
a big part of compiler development is making things optimizable
<scientes>
I think clang will want to do it this way
<scientes>
its just that we are ahead of clang
m4ge123 has joined #zig
<andrewrk>
it's annoying being ahead
<andrewrk>
ok I think this makes general sense. compiler chooses an in-memory layout for vectors. element access of a pointer means it's in memory, so element pointer is possible
<andrewrk>
if there were vector packing, then our bitfield pointer annotations will be sufficient to address sub-bytes
<scientes>
well, I don't like the limitation of those types anywhere
<scientes>
the general solution is bit-granularity pointers
<scientes>
but that is a different problem
<andrewrk>
agreed
<andrewrk>
ok, well having vector element access be simpler is certainly desirable, so you've convinced me this is the direction to go. I'll amend my branch to do this
<scientes>
well, let my finish this PR request
<andrewrk>
I think the rest of your SIMD series will be easier to merge. element access was a tricky subject
<scientes>
and you brought up a case I missed
<scientes>
vector of pointers, with vector index
<andrewrk>
let's just make progress in master branch, a little bit at a time. eventually we'll get this thing finished
<andrewrk>
urgh I gotta improve the CI to not fail so often
<scientes>
I have a bug on my CI failure
<scientes>
its a qemu bug
<andrewrk>
I knew this day was coming. each different service must start a "try to update download page if all other services are done" job after completing successfully
<andrewrk>
ah yes the qemu bug
<andrewrk>
zig is starting to generate a lot of bug reports for other projects
<scientes>
well, i did warn that qemu doesn't work with SIMD
<andrewrk>
I have an idea
<scientes>
although it would be nice if qemu could actually KNOW when it doesn't work correctly
<scientes>
which it totally could do
<scientes>
I get that supporting so many instructions, that are rarely used, is not a high priority
<andrewrk>
if there is a "CPU target features" option to disable SIMD, then we can add to zig build, -Ddisable-SIMD-features, (depends on #2883)
<andrewrk>
and the CI script will add this flag
<andrewrk>
because it knows it is using qemu for non-native architectures
<scientes>
I think SIMD on arm64 actually works...
<andrewrk>
then the vector tests will still run - but LLVM will not emit SIMD instructions, it will expand the vector instructions
<andrewrk>
yes ok then we can make flags for specific architectures
<scientes>
ahhhh I see
<andrewrk>
then we can find bugs in LLVM instead of QEMU! /s
a_chou has quit [Quit: a_chou]
<scientes>
lower the SIMD is a good idea
<scientes>
I like that
<andrewrk>
yeah that's the whole point of having language support for vectors
<andrewrk>
is that you're not wasting your time, because they can be lowered
<andrewrk>
your intent is specified precisely enough
<andrewrk>
this was a productive chat, thank you for your patience scientes
<wilsonk>
andrewrk: what time were you planning the stream tomorrow?
<andrewrk>
wilsonk, let me pick a time right now... 15:00 EST
<wilsonk>
sounds good, thanks :)
ltriant has joined #zig
ltriant has quit [Ping timeout: 268 seconds]
Jezza__ has quit [Ping timeout: 264 seconds]
achaninja has quit [Remote host closed the connection]
chemist69 has quit [Ping timeout: 246 seconds]
chemist69 has joined #zig
knebulae has quit [Read error: Connection reset by peer]
traviss has joined #zig
<traviss>
I made a simple command line parser inspired by the Jon Blow stream from a few days ago with similar functionality. Have a look: https://github.com/travisstaloch/cmdlinezig
<bhansconnect>
looks really cool, traviss. I will have to dig into the code when I am less tired.
bhansconnect has quit [Ping timeout: 260 seconds]
ltriant has joined #zig
<traviss>
thanks guys. it helped me to understand comptime a little better. i ended up being a little inefficient, looping over struct fields and then searching through command line args in order to satisfy the compiler. many 'unable to evalute constant expression' type errors were encountered.
ltriant has quit [Ping timeout: 276 seconds]
<traviss>
if anyone can suggest a better approach, i'd like to hear it
<pixelherodev>
Is there a way to have a variable that can hold one of two different struct types?
<pixelherodev>
e.g. with an array_list, can you have a var that's either array_list(u8) or array_list(u16), the type of which is determined at runtime?
<pixelherodev>
I was thinking of using a tagged union containing both types with a `get() var` method, but apparently returning variable types isn't implemented yet :P
dingenskirchen has joined #zig
<lucus16>
andrewrk: where will I be able to find this stream? I'd love to watch it
jokoon has quit [Read error: Connection reset by peer]
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
<dimenus>
:q
<dimenus>
hah
dingenskirchen has quit [Ping timeout: 264 seconds]
ltriant has joined #zig
ltriant has quit [Ping timeout: 245 seconds]
dingenskirchen has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
clktmr has quit [Ping timeout: 265 seconds]
wesada has joined #zig
<pixelherodev>
There a way to force the compiler to allow an import of a file outside the package path?
<pixelherodev>
Eh, for now I can just use an `export`/`extern` function and it should be fine...
<mq32>
what do you want to do?
<pixelherodev>
I'm writing a text-based game using the kernel - except it also builds as native
<pixelherodev>
so I have src/os, src/native, and src/main.zig
<pixelherodev>
Within the src/os and src/native folders, the root source file includes `../main.zig`
<dimenus>
pixelherodev: yes, use 'addPackagePath' in your build.zig
<pixelherodev>
I'm not using build.zig
<pixelherodev>
I have a Makefile
<dimenus>
why?
<mq32>
still, you can add stuff as packages
<mq32>
also: why?
<pixelherodev>
Annoying to set up
<mq32>
everything build.zig can do can be done with a Makefile
<mq32>
it will just be more work
<pixelherodev>
--pkg-begin I assume?
<dimenus>
yes
<dimenus>
what about build.zig is "annoying"?
<pixelherodev>
Figuring out how to target it properly
<dimenus>
what is 'it' in this scenario?
<dimenus>
aarch64?
<pixelherodev>
i386-freestanding
<pixelherodev>
Plus, I have a lot of custom targets
<pixelherodev>
e.g. `make burn DEVICE=/dev/sdb` uses parted to fetch device info, ask for confirmation, then uses `dd` to "burn" the image to the specified drive
<mq32>
i have build.zig for building zig stuff and make files for the rest
<mq32>
btw, what bootloader are you using?
<pixelherodev>
Mostly, none
<pixelherodev>
QEMU with `-kernel` can load multiboot-compatible ELF files
<pixelherodev>
When producing a disk image, GRUB
<mq32>
ah
<mq32>
yeah, but the multiboot loader from qemu cannot do everything a "real" bootloader can do :D
<mq32>
like init VBE
<mq32>
i use syslinux for my image file and modify it with mtools
afon has joined #zig
<pixelherodev>
Sure, but I don't need those
<pixelherodev>
How do you specify to link against libc in the command line? `--library c`?
<mq32>
-lc
<pixelherodev>
That's literally an alias of --library c :)
wesada has quit [Remote host closed the connection]
kenaryn has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
<kenaryn>
Hi guys, I am brought to a standstill by a 'incompatible types' error. Here is the code snippet if someone accepts to look at it: https://bpaste.net/show/BQC3U
ltriant has joined #zig
<mikdusan>
your catch block has a path that can "result" void to `const line =`
<mikdusan>
ie. what is the result type of "try stdout.write..."
<kenaryn>
My apology, you meant at a newline. It works, I thank you :)
wesada has joined #zig
clktmr has joined #zig
wesada has quit [Ping timeout: 276 seconds]
dingenskirchen has quit [Quit: dingenskirchen]
kenaryn has quit [Quit: WeeChat 2.3]
dingenskirchen has joined #zig
traviss has quit [Quit: Leaving]
dingenskirchen has quit [Remote host closed the connection]
wootehfoot has joined #zig
dingenskirchen has joined #zig
dingenskirchen has quit [Client Quit]
dingenskirchen has joined #zig
marijnfs has quit [Quit: WeeChat 2.6]
lf94 has joined #zig
<lf94>
Question: could zig be re-implemented in a month, given a spec?
<andrewrk>
that's a fun question
<lf94>
I've been using Rust as my systems language for the past 2 years, but now I want to start programming stuff that will last decades.
<lf94>
I don't believe Rust code is suitable for this
<lf94>
Anything C, sure. And since Zig is more or less a derivative...it would fit the bill too, I think.
<lf94>
Then I think: maybe programming languages at all is not a good idea. Maybe I should plan my software via a spec, which will last forever.
<andrewrk>
incoming, a bunch of broken master branch commits while I fiddle with how the download page gets updated
ltriant has joined #zig
<lf94>
andrewrk: /do/ you think zig could be re-impl'd in a month? :)
bhansconnect has joined #zig
ltriant has quit [Ping timeout: 268 seconds]
<andrewrk>
no. I think that while the zig language is simple for programmers to read and write, the compiler is in fact doing quite a bit of complicated work on behalf of the programmer
<lf94>
What do you think is a reasonable time frame?
rjtobin has joined #zig
bjorob has joined #zig
traviss has joined #zig
ky0ko has quit [Ping timeout: 245 seconds]
afon has left #zig [#zig]
<wilsonk>
Is the stream on Twitch? Or has it not started yet?
<mq32>
wilsonk, same question here :D
<andrewrk>
I'm dealing with some audio issues, will start the stream hopefully within the next 30 minutes
<wilsonk>
Ah, cool. No pressure here...just didn't want to miss it because I no Twitch so good :P
<scientes>
or is there a way to detach strace and attach gdb?
<lf94>
it's gonna work
<scientes>
lf94, zig requires an interpreter
<scientes>
this makes it much more complicated than, say, c89
<scientes>
(that said, the current interpreter does not have a full memory model that the language requires)
<lf94>
hm
allan0 has quit [Ping timeout: 240 seconds]
ltriant has joined #zig
FireFox317 has quit [Ping timeout: 268 seconds]
reductum has joined #zig
gsomix has quit [Quit: Leaving]
FireFox317 has joined #zig
tridactyla has quit [*.net *.split]
tracernz has quit [*.net *.split]
FireFox317 has quit [Ping timeout: 265 seconds]
tridactyla has joined #zig
tracernz has joined #zig
ltriant has quit [Ping timeout: 240 seconds]
M-ou-se has joined #zig
doublex has quit [Ping timeout: 245 seconds]
<andrewrk>
that was a fun stream
reductum has quit [Ping timeout: 240 seconds]
<rjtobin>
it was! thanks man
<mq32>
it sure was!
<mq32>
and i'm impressed on how well that all went
wootehfoot has quit [Read error: Connection reset by peer]
<rj00>
Hey there, so i've hit a compile error I can't decipher. Any idea what "error: switch on type 'i9' provides no expression parameter" means? For context, I have a switch prong that looks like this: `'\'', '"' => |c| return self.string(c)`
<lf94>
to be fair hitting compiler bugs was unexpected to a first timer watching
<lf94>
(and unsettling)
<lf94>
with that said, zig looks nice, but still a ways to go.
<andrewrk>
rj00, can I see a link to a paste of the output?
<rj00>
I wasn't able to reproduce the error elsewhere
<andrewrk>
rj00, oh, it means you don't get a capture value, you have to access the same value you used in switch()
<andrewrk>
that potentially could be changed
<rj00>
oh why's that? So I have to create a variable outside the switch, and then switch on that?
<andrewrk>
yeah. it used to be that only tagged unions gave capture values
<andrewrk>
but then it made sense to add support for various other things. and now I think it probably makes sense to make this work as well, to be consistent
<mq32>
would be cool!
<rj00>
oh ok, Sounds good. I was expecting it to be like rusts pattern binding syntax e.g. `c @ 1..=5 => foo(c)`
doublex has joined #zig
<traviss>
how do i run the tests in test/translate_c.zig? i tried: `zig test test/translate_c.zig --test-cmd add_both` but it says "No tests to run".
<pixelherodev>
Yeah, but given how big this is liable to grow, that just means it'd end p being a RAM-murderer
<pixelherodev>
Longest one is 2KB so far, probably going to have even bigger ones
<mikdusan>
i'm curious what is your need for such large comptime strings
<mikdusan>
_format_ strings
<pixelherodev>
Making a text-based adventure game
<pixelherodev>
Using stuff like e.g. `print(@embedFile("data/intro/N.txt"), args);`
<pixelherodev>
Might just switch to using printf
<pixelherodev>
I already have a printf function on all targets anyways (normal printf on native platforms via libc, plus the implementation I whipped up for ACPICA)
<pixelherodev>
Except that doesn't work because I can't use C varargs from Zig
kllr_sbstn has quit [Quit: leaving]
<pixelherodev>
Ah, solution
<pixelherodev>
I'm already tokenizing into lines so I can handle scrolling
<pixelherodev>
I'll just tokenize *before* passing through std.fmt.format
clktmr has quit [Ping timeout: 240 seconds]
<pixelherodev>
Though that means all arguments will have to be positional, not implicit
<andrewrk>
pixelherodev, you can call c var args from zig. can't export a c var args function yet
<andrewrk>
pixelherodev, I don't think you want to use N.txt as your format string, right? it shouldn't be interpreting {} in there
<andrewrk>
i think you want print("{}", @embedFile(...))
<scientes>
^^^
<pixelherodev>
No, it should be interpreting {}
<scientes>
printf(variable) is extremely dangerous
<pixelherodev>
It passes in variables
<pixelherodev>
That's not variable.
<pixelherodev>
It's constant.
<pixelherodev>
It's just a very long constant which happens to be in its own file.
<andrewrk>
oh ok. no problem then. just set a higher branch eval quota
<pixelherodev>
Approximately how big would I need?
<andrewrk>
imo just double it until it's big enough
<pixelherodev>
Huh. 2K is enough for now.
<fengb>
Bump it up to 640k 🙃
rj00 has joined #zig
<pixelherodev>
I might actually bump it up to 64K for now.
<pixelherodev>
2K quickly became too small also
<andrewrk>
you might start to run into inefficiencies in stage1 with regards to slowness or ram usage, and for that I apologize
<andrewrk>
these things can be improved eventually