I really enjoyed the previous “What’s everybody working on?” threads and have been looking forward to the August edition of this thread.
I hope I am not the only one, so I decided to create this thread. 
(I hope it is ok that I created this thread.)
As andrewrk said it:
The previous threads can be found here:
So, what’s everybody working on lately?
No code to share yet, but I’ve been looking into writing audio plugins in the CLAP format with Zig. Seems pretty straightforward so far (quite a bit nicer than VST), got their clap-info to load a dummy one, so that’s a good start. Zig’s translate-c can’t handle their headers yet (at least not the 0.16 version, haven’t tried master), but I think hand-translating the struct definitions in a Zig-idiomatic way will be the better path forward anyway.
Hoping to revive (and rewrite in Zig) an old project of mine with this at some point, if I can keep my focus[1] and pull through. No promises yet, though.
Which is a hard difficulty level for my brain 
↩︎
This month I’ll be working on Beer, a Windows compatibility layer for Linux (inspired by Wine of course) that I started a couple of weeks ago. I’ll be working on this for a long time, it’s really fun and I’m learning a lot of things about both Windows and Linux.
Yesterday I was able to run a simple “Hello World” written in Zig compiled to x86_64-windows with -fsingle-threaded.
Now I need to setup the TEB, PEB data structures and import TLS information from the binary to have a nice execution environment for a multi-threaded program to run. After that I’ll be focusing on implementing the ntdll functions to properly execute native programs as “Windows Internals” call programs that depend only on ntdll.
New month, new side quest, and I’m really excited about this one.
Recently inspired by watching some old videos on low level programming for the Atari ST. So I’m hoping to get to the point where I can have a Zig library that wraps both GEM and various 68k asm snippets … and write me some Atari apps.
This side quest is absolutely about the journey, not the destination.
So I’ve got the hatari emulator installed (that’s the easy part done), and currently working on getting an m68k zig toolchain working. So I’ve got a custom build of llvm working with the (experimental) m68k backend, and can build using C.
Next step is to get a custom build of zig that embeds this llvm build. Then I can start.
I went through Ziglings last month and now I am working on toy projects to learn to use Zig and build a muscle.
For example, one of them was Zight. There are a couple more things that I built but will throw away - a TCP based probe to see if something’s listening on the host / port and a combined log format parser to extract stats from my self hosted services. I’ll like never publish those (and archive zight) as they were all learning tools and perhaps small cogs in my personal workflows (which don’t help anyone else).
I’m working on my first non-toy, but still small, project in zig: a library for broad-phase 2D collision detection. It uses a gridded data structure that borrows some quad-tree + BVH elements (though the tree has a fixed depth), and leans heavily on the comptime + SIMD features of zig. Hopefully the end result will be efficient and easy to use. Excited to share a preview when it’s a more polished state!
Still working on my vulkan renderer.
Since last thread, I’ve added: textures, configurable number of frames in flight, instanced rendering, a compute shader for doing per object math, and a bunch of other refactoring because I’m bad at assuming the correct things.
Right now, I’m working on parsing gltf files to feed my vertex and index buffers because I only have a cube object currently. I’ll hopefully get some of my assumptions checked and corrected around only having one type of object.
Next, I’d like to learn about and implement frustum and occlusion culling.
OpDecorate %img NonUniform in my sampleTexture function is being dropped by the spirv backend for some reason)
I made some progress on my learning project that I started last month.
What I spent my time on:
I did not manage to implement everything I wanted, but I ended up doing some unplanned things like threads / SIMD and the (not-so-useful) sphere shader
Current Stats:
Image of some water and forests:
A snowy mountain surrounded by ice and tundra:
Zoom out to “sphere view” (link to youtube video):
And the current complete map:
I really enjoyed continuing to learn Zig.
Thanks to the explicitness of the language, I was able to optimize (away) some allocations in the hot path. It was so simple to see where the allocations happened (because I explicitly had put them there ).
This was the first time I wrote SIMD code myself and it all seemed very clear, even though it took some time to get used to it.
I also enjoyed the packed structs, which made it easy to interface with C code.
Plans for next month (some carried over from last month):
I don’t know where this test project will go. Right now, my main goal is just to learn Zig.
I really enjoyed reading the July edition of this thread and I’m looking forward to reading this one!
I’ve been learning Kakoune the last couple of weeks. Couldn’t find a plugin to select words inside a camel case identifier, so I wrote one in zig. Learned to write simple parsers, worked out how to spot breaks between words in one pass, and used the new IO and writer systems. Pretty nifty. I might make some of the editor interfacing bits into a reusable library.
I wrote my own snapshot testing micro library based on the tigerbeetle blog post, but it works with non-string types as the snapshot as well, which I find useful for stuff like this.
This is part of an effort to dust-off my static site generator project which uses Janet (a lisp dialect) as the template language, since it more honestly reflects the tree structure of html documents.
Last month I took a break from my debugger, as I had a few trips and vacations. I did spend a little time working on getting a simple server that takes --watch output and feeds it to neovim’s quick fix list. I am eager for the --listen flag to be available in 0.17.0 to get an even better way to get information from the zig compiler. This month I’m planning on working on getting my talk for SYCL to a close to final state.
The friends I used to play with online became parents, and finding a free time slot for us all became tricky. So some game you can play asynchronously was needed – and I had an idea for that in my head for the longest time: a space RTS with light speed constraints: you see your opponent’s actions only after N turns, because they are N light … turns away. This leads to an interesting design, where the game is both real time but also you don’t have to play at the same time.
To get it into little breaks within a day, I target the browser. So the game is in Zig compiled to wasm. Right now it’s still a lot of trying out different game mechanics, balancing, test plays and debugging. The bugs, oof. It’s mostly time logic bugs, with rewinding the simulation when getting actions from the opponent from a previous turn, and then going back to the present. And ofc I suffer strongly from NIH and made very brittle UI system within Zig instead of using HTML.
But so far worth it; the games that didn’t crash were really fun. (: The prototype looks like this right now:
I am porting various libraries to zig. I have raylib, imgui, implot2d/3d, box2d / jolt physics. I target webgpu. Includes a transpiler from spv to wgsl (gpu shaders/compute) and from c to javascript that starts from the c output of the zig compiler). A preliminary result is here: https://codeberg.org/simonclavet/Zimr . Don’t try to use it just yet. It is not ready, it is not good, it really is slop, I am not super proud of that. But I worked 6 months on it. Would have taken 60 years without AI… I guess this can serve as a datapoint in the debate about AI transpiling (but I really don’t feel like arguing. If you hate AI, please look away, this will not change your mind).
I have unblocked myself on playing with pollux (trio-inspired Lua runtime based on std.Io) and std.Io.Dispatch . As a result I have two PRs open to Zig, the second of which is a proper zen koan in terms of “time spent thinking about bug” to “size of diff”
https://codeberg.org/ziglang/zig/pulls/36113
https://codeberg.org/ziglang/zig/pulls/36377
No Lua to show for it yet, but here’s yet another sleep sort in Zig:
/// sleep_sort.zig
/// example usage: sleep_sort 16 4 3 2 6 8
/// times out and exits with an error if any provided value is > 10.
const std = @import("std");
pub fn main(init: std.process.Init.Minimal) !void {
const allocator = std.heap.smp_allocator;
var ev: std.Io.Dispatch = undefined;
try ev.init(allocator, .{});
defer ev.deinit();
const io = ev.io();
var args = init.args.iterate();
var event: std.Io.Event = .unset;
var future = io.async(sleepSort, .{ io, &args, &event });
defer future.cancel(io) catch {};
try event.waitTimeout(io, .{ .duration = .{
.clock = .awake,
.raw = .fromSeconds(10),
} });
}
fn sleepSort(io: std.Io, it: *std.process.Args.Iterator, ev: *std.Io.Event) !void {
var group: std.Io.Group = .init;
errdefer group.cancel(io);
while (it.next()) |arg| {
const seconds = std.fmt.parseInt(u32, arg, 10) catch continue;
group.async(io, sleep, .{ io, seconds });
}
try group.await(io);
ev.set(io);
}
fn sleep(io: std.Io, seconds: u32) error{Canceled}!void {
try io.sleep(.fromSeconds(seconds), .awake);
var buf: [256]u8 = undefined;
var stdout = std.Io.File.stdout().writer(io, &buf);
stdout.interface.print("slept {d}\n", .{seconds}) catch return error.Canceled;
stdout.flush() catch return error.Canceled;
}
I have finished the Forth interpreter I talked about last month. The “collaborative” version of it isn’t accessible yet, as the server side is hosted by my friend and there is some stuff going on there, but a local version is already here: Forth Interpreter
It’s sadly not written in Zig, but that small (vanilla) JS project kept my JS knowledge kind of up-to-date and soon, I’ll start doing some Zig stuff again. For my OS (written in Zig, for RISC-V) though, the thing is that I’m currently thinking about directions my OS should take that haven’t been explored that much by other OSes (=> I’m not writing that much code right now).
I have taken my GameBoy Advance emulator project back up after putting it in my hobby-project-backburner. I had a mostly correct ARM7TDMI emulation going, but any real testing suite needs graphics, so I am starting that now.
No public code yet, since it is pretty ugly, but here’s a RISC-V emulator I built more recently based on what I learned with the ARM core: zrv32
A related backburner project is implementing this RV32I core in Factorio, like that one guy from CCC did, though that is not related to Zig directly.
Hello, I’m new Zig user. I published an experiment (of mine) for
ML-KEM computation on USB device.
The target is CH32V203 (with RISC-V core), which only has 20KiB memory.
About decade ago, I started using Ed25519/Curve25519 on STM32F103 (with ARM core). The implementation was written in C.
Perhaps, I will switch to RISC-V core and Zig, in near future.
I know that the ML-KEM implementation in Zig std library is the one of the best. But I use my own implementation so that I can minimize the memory consumption.
I am making a JavaScript engine. The main purpose is for learning. I try to make the code easy to understand instead of optimizing for performance. Currently, it is developed with Zig master. Hope to use Zig 1.0 soon.
I’m going to be learning about how zig handles subprocesses, trying to pipe a graph into dot and correctly interpret the output.