<gamester>
tgschultz's solution is pretty clean, maybe that's something that translate c could do in the future
<daurnimator>
andrewrk: also catching up on the stream... I notice that self hosted translate-c has the same allocator bug as the parser
<mikdusan>
terminology: does 'freestanding' mean 'non-libc' / 'without-libc' ?
<daurnimator>
mikdusan: no. it means no operating system
<mikdusan>
are there targets or will there be targets that are freestanding and no-libc?
<daurnimator>
yes
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<tgschultz>
andrewrk: ok, I've spent way too much time trying to work out how to make async<> happy with an allocator that isn't a pointer and I've decided it really really isn't worth it. So I guess round 2 of interface reform is also dead pending coroutine reform.
<tgschultz>
I honestly didn't think it would be this complicated, but everything seems to be written with the implicit assumption that allocators are pointers.
<tgschultz>
or maybe I'll just do it without bothering to switch over allocators
<tgschultz>
since that's the pain point
<tgschultz>
yeah, I think that's what I'll do
dbandstra has joined #zig
karrick has joined #zig
<karrick>
Hello
karrick has left #zig [#zig]
karrick has joined #zig
<gamester>
Hi!
<karrick>
Hello
<karrick>
I’m incredibly new to zig and just learned about it last weekend. Trying to soak up some knowledge. I am primarily a Go programmer now.
<daurnimator>
karrick: welcome!
<karrick>
Thanks
dbandstra has quit [Quit: Leaving]
<karrick>
Did not mean to scare anyone off
<gamester>
huh? You did not :) By the way Zig has improved a lot very quickly and I think you'll enjoy it. Interfacing with C libs via @cImport can be rough but it keeps improving
<hoppetosse>
I've managed to get most of the code shared between the webgl and glfw verisons of tetris. At the moment, it has separate entry points for each platform
<karrick>
I have noticed how much it has changed in the past few years by reading some of the documentation and then just having finished watching the Tetris video.
<hoppetosse>
I tried a couple of ways to share the main, but to no avail. Check it out, let me know if you have any ideas on how to make it one clean codebase
hio has quit [Quit: Connection closed for inactivity]
<daurnimator>
andrewrk: got spare brain space for a design chat? or in the middle of something?
<karrick>
I’m actually watching the compiler internals video from a few years ago.
<karrick>
Kind feel like I need to watch each video in chronological order. But then I know the only way to really learn a new language is to grab a problem and wrestle with it.
<andrewrk>
daurnimator, I'm about to go to bed, got up pretty early this morning. I'd recommend trying to catch me tomorrow
<daurnimator>
karrick: got any areas of personal interest you'd like to work in?
<andrewrk>
karrick, the ziglang.org homepage and then the official documentation is likely the fastest way to catch up
<daurnimator>
andrewrk: k
<karrick>
I spend a lot of time playing with concurrency primitives and standard library stuff in Go
<daurnimator>
karrick: I got started by reading through the 0.3.0 release notes; then the documentation page; then by reading the standard library; then by starting coding. this path isn't suitable for everyone...
<daurnimator>
karrick: ooo, you might be interested in my next project then
<daurnimator>
(which is what I wanted to talk to andrew about)
<karrick>
Shoot
<daurnimator>
karrick: I want to create a "command buffer" abstraction to be used for file and socket IO
<andrewrk>
oh yeah release notes are good too. lots of content there
<daurnimator>
karrick: essentially as a primitive that can be used for not only super high performance IO. but also something that regular file operations can live *on top of*
<karrick>
is `drain` the common idiom in Zig for flushing a buffer of sorts?
<daurnimator>
karrick: no... it's what the linux kernel calls it in an open patch :P
<karrick>
Lol
<karrick>
I have not spent time in Linux kernel source but I do C from time to time...
<daurnimator>
`myfile.write()` => internally, it could: `command_buffer.queueWrite(fd, data); command_buffer.drain()`
<karrick>
Ok
<daurnimator>
karrick: interested? :)
<karrick>
Yes. I have several non blocking queue libs and ADTs in Go on my profile because this is very interesting to me
<daurnimator>
karrick: yep. it finally got merged+released in the 5.1 kernel. which came out this week
<karrick>
I assume you have same name on GitHub?
<daurnimator>
yes.
<karrick>
Congrats for getting it merged into 5.1
<daurnimator>
not my work
<daurnimator>
just have been following closely; and now that its in released kernels, it's time to actually use it!
<karrick>
Ah. My misunderstanding. I was going Jeeping this weekend but that got cancelled. Looks like I have homework.
<daurnimator>
IMO it will be*the* way to perform most file descriptor operations: in a couple of releases all the old syscalls can go and be deprecated ;)
<gamester>
oh cool you're working on abstractions over io_uring? Nice!
<karrick>
Wow. Seriously?
<gamester>
I need that
<gamester>
:)
<daurnimator>
gamester: as soon as I finish this general purpose allocator
<karrick>
And gamester returns
<karrick>
:)
<daurnimator>
karrick: not so serious on the syscall deprecation. nothing is deprecated kernel ABI-wise :P
<daurnimator>
karrick: so what brought you over from Go?
<karrick>
I understood your context that effectively it means that all syscall functionality could be replaced
<daurnimator>
karrick: mostly only syscalls that operate on a file descriptor.
<karrick>
Frustrations with decisions based on Go’s runtime architecture. I taught myself assembly on an 8088 years ago, and then learned C and thought, oh this is so much more easy.
<karrick>
I still work in a high performance mindset
<karrick>
I really liked how Zig embraced C, rather than making working with C a detriment to runtime performance.
<daurnimator>
at the moment only read/write/fsync are supported by uring, 5.2 should bring support for sendmsg/recvmsg/sync_file_range; accept() and connect() might make it in too. ioctls soon after
<karrick>
I have been doing small utilities at work in C when needed to skip the runtime overhead of Go. But it’s been a while since I’ve done anything major in C.
<karrick>
Enough rambling from me. How long have you been working with Zig, daurnimator?
<gamester>
The NVMe spec has the concept of a submission queue and completion queue so without io_uring things were pretty awkwardly mapped to the hardware
<daurnimator>
karrick: since october. I got linked the 0.3.0 release notes and really loved what I saw
<karrick>
Any concurrent Zig code I can take a peek at to prime the pump? I read what you say and think in terms of Go concurrency, which is working against me right now I think.
<tgschultz>
zig's coroutines are due for a major reworking
<gamester>
karrick: you're out of luck I think. As tgschultz says people have been waiting for coroutines
<daurnimator>
karrick: I saw similar things for Go and Rust as they were being developed and thought "this looks cool; will be great to use when mature" -> however Go and Rust grew away from what I wanted, and are now irreconcilably differnet to my aims. I decided to dive into zig early so that I could hopefully keep it on target for what I've wanted for years
<gamester>
karrick: there is of course std.os.spawnThread and atomics
<andrewrk>
it's the beginning of the 0.5.0 release cycle and I've got step 1 underway
<andrewrk>
I took a short break to enhance translate-c to hopefully get people to stop contributing to the C++ code and start contributing to the Zig code
karrick has quit [Remote host closed the connection]
<gamester>
hmm vscode is really helping my flow. It turns out I like having the terminal in the same window. I recommend it.
<mikdusan>
i tried using vscode a while back with older gpu. it was so aggrivatingly slow had to dump it. even had to make workarounds to get it to work minimally.
<daurnimator>
gamester: I generally have my editor (sublime) and a terminal open side by side (using tiling window manager)
<mikdusan>
one of my biggest issues was that when things stopped working with gpu, it didn't tell you. ignored errors. i guess they need zig `try` :)
karrick has joined #zig
<daurnimator>
gamester: should I guess that you're interested in this command buffer work too?
<karrick>
Thanks for the links to the concurrency story for Zig. Also adding to my reading list.
<daurnimator>
goals (of mine): 1. add bindings to io_uring to zig's std/linux 2. create more general abstraction on top of it with handy methods 3. create alternate backing implementation that uses traditional read/write syscalls. 4. rewrite File on top of new abstraction
<karrick>
Or I’ll just read the Coroutines status now
<daurnimator>
karrick: coroutine status right now is "broken; don't bother looking; wait on andrewrk to fix"
<gamester>
daurnimator: I'm definitely curious about what you're working on, and have a use for it, but I feel 0% qualified in helping with design. I'm just not experienced enough.
<andrewrk>
that's a fair characterization. it's a pretty severe project blocker
<karrick>
First of all that does not bother me that it’s broken. I just want to know the vision
<karrick>
I’m very interested in this aspect of programming. Go was not quite doing it right IMO
<karrick>
I think Go has an amazing M:N scheduler. I know Zig does not have the runtime overhead of Go and hence this is not the same thing. I’m just curious how Zig is evolving.
<karrick>
What I mean is that I think co-routines are very useful, but I wished they were lighter weight, and I can only imagjne that the lack of a runtime is a requirement for having light-weight coroutines.
<karrick>
Perfect issue to read. Thanks
<karrick>
andrewrk, any regrets for writing a language?
<andrewrk>
nope
<karrick>
That’s awesome. I assumed they would include folks asking you to make Zig do what they wanted. I’m sure you get that a bunch.
<daurnimator>
karrick: I think you'll find that question has some survivorship bios.
<daurnimator>
*bias
<karrick>
Lol that’s great autocorrect for you
<karrick>
Or just your fingers are primed to say BIOS
<andrewrk>
it's not easy to say "no" to so many ideas but I don't want zig to become c++
<andrewrk>
everybody has that 1 feature from c++ that they actually like, and if everybody got theirs into zig, zig would be C++
<karrick>
Yup
<karrick>
How many active contributors are there mostly?
<karrick>
Not necessarily the one offs but folks who keep working on parts