Fantastic idea. This is the sort of thinking that we like in the embedded industry.
How does your DST take shape?
One of my friends needs to parse multiple TiB of data using C.
In order to help him, I needed to implement a Buffered IO Stream library.
Not surprisingly, after looking at C3, Hare, Odin and Rust implementation of this idea, the one that stood out to me was Zig io.Reader and io.Writer. 
Zig’s file reader is unique because you don’t need to copy the data to read it:
It simply returns a slice, re-basing the buffer if needed.
My C API looks like this:
typedef struct {
Str buffer; //< `Str` is a slice of u8
isize end;
isize seek;
void *ctx;
isize (*source)(void *ctx, Str buffer);
} Reader;
typedef struct {
Str buffer;
isize end;
void *ctx;
isize (*sink)(void *ctx, Str buffer);
} Writer;
Notice, that I didn’t need “vectored” IO and also I didn’t implement the splat parameter, because I still don’t understand it’s use case.
Re-implementing a simpler version of io.Reader and io.Writer helped me better appreciate Zig’s design. I’m still digesting the power of the stream API, which allows chaining/pipelining writers together.
4 Likes
Had a good time learning and helping with some basic audio interfacing and DSP modules with @glfmn, and I hope to continue some of that and improve the error handling especially.
I’m also trying to get a project of my own off the ground - I want to prototype a small digital audio mixer, like might be used to run sound for live events, but teeny tiny and running fully open source Zig firmware. I have a lot of experience using the full size, proprietary versions, and I think there’s potential in making a truly open source version, even if only the potential for me to learn a lot. I’ve got only a little prior experience with hardware prototypes, so there’s a lot I need to learn! I am currently looking into microzig and trying to build a basic Zig LED-blinker for ESP32.
8 Likes
I took a break from my main side project during the summer and focused on learning some new things instead. I started a new project using Flint and built a 3D renderer using SDL GPU, a 3D model importer for .glb files, and got Box3D building using the Zig build system. All this to give me a testbed for learning how games do vehicle physics which I’ve been curious about for a long time. I also learned the basics of 3D modelling and texture wrapping using Blockbench. The result is Wildcar! It’s based on pre-release versions of Zig and Flint, but I’ll update the project once those versions have landed.
Here’s a clip of what it looks like now:
For the car physics, parts of the renderer, and matrix math, I experimented with a more human centric approach to using LLMs for coding: I asked it to teach me how to do something rather than doing it for me. It was a much more enjoyable experience than using it as a coding agent, and it meant that I wrote every single line of code so I both understand it and still care about it. I wrote more about Wildcar, my experience with using an AI tutor, and my general worries about working with AI over on my homepage: Knowledge and learning with AI
I had a lot of fun and fulfilled my ulterior motive of getting a better feel for how Flint is to use and where the rough edges are, so far I’m very happy with the results. I’m enjoying this project so much that I will continue to focus on it for a bit longer. I’m also looking forward to experimenting with Zig as the main shader language in this project later.
12 Likes
Still working on my text editor, very much a work in progress so there’s no public repo yet.
16 Likes
Oh cool. Would like to see more or try it out. I’m looking for a potential editor replacement since many existing projects seem to focus too heavily on AI/LLM (IMHO)
2 Likes
I’ve long been interested in 「Writing An Interpreter In Go」 and 「Writing A Compiler In Go」, and I’d like to try implementing them in Zig.
However, since the original implementations rely on Go for garbage collection, I plan to skip that part this time… (Please forgive me—I just want to learn about the language implementation itself, not garbage collection!)
8 Likes
Zig Day related:
We’ve just gone live on zig.day. Here is the announcement.
Anyzig related:
Oh, nice find. Maybe I would not have started working on anyzig if I had known this sooner… I’m in the final stretch of making a PR that updates anyzig to 0.16 though. I think it’s still worth investing the time as it’s a very popular tool.
My DST is heavily inspired from the one Will Wilson used in this talk at Systems Distributed.
I started by writting close-enough simulation of the other components of the motorcycle. For example, I have a mock battery that heats up and loses energy when current comes out of it.
Then, I define conditions of failure. For example if the battery drops below it’s minimum voltage, goes above max temperature or acceleration or decceleration is too abrupt, then it means there exists a sequence of inputs to the ECU that makes it do bad stuff.
The sequence of inputs is simply what buttons the controllers toggled in this timeframe and the value of the throttle.
I’m still not sure on how to define the state-space to explore it effectively instead of doing random inputs, I still have to think about that.
Of course we will also test it for real on a dyno to make sure the real thing integrates and functions perfectly.
1 Like
I’m still working on Nano Dash and almost done. Nano Dash is a Boulder Dash tribute to the original Boulder Dash game on C64 from the 80ies.
The adventurer story is now complete with six different worlds and all power-ups and secrets are hid. Only some polishing left, and testing testing testing.
Graphics, most of the sounds and the game content as well are all handcrafted. The game itself is written fully in zig using only raylib as dependency. No AI involved at all, because, it should be fun, shouldn’t it?
Also made an update for the demo on steam and added a demo for linux now. You can play it for free: Nano Dash Steam Page
14 Likes
These projects are done with a lot of work by various Claude models.
a) A port of 0.17 zig (a few weeks behind I think at this point) to Haiku OS. Primary reason is running Zebra on Haiku. The port doesn’t use the LLVM backend, just the self-host since I didn’t want to figure out the LLVM latest greatest packaging.
b) A programming language called Zebra that compiles down to Zig. It was greatly inspired by a programming language Chuck Esterbrook did called Cobra which was my favorite language – it was python-like and compiled to C# and could use the .Net ecosystem. There were a lot of quality focused aspects of his language that made Zig feel like a spiritual uncle to it so it felt like it was a good base language to build on. [Zig + Cobra ~> Zebra]
A demo using Scintilla component within libui-ng library. Shows for example the contracts support, and the branching mechanism. The language now self-hosts and is in the bug fixing state (have been doing that for multiple months now).
One thing that is pure zig (also Claude created) is an Early parser that Zebra consumes. That’s been reliable from the get go.
1 Like
All around tool for helping with Monster Hunter Freedom Unite. Ported some code from an old armor search tool, and extracted all useful data from the game and savestate to help with the eternal grind.
Custom layout system, based on clay, with a vulkan renderer backend. Ubershader on instanced AA tiles for MSDF text, boxes and spritemaps to get it down to one draw call.
9 Likes
Yoo, join the interpreter club! Feel free to ping me here or on the discord (same handle there as here) if you run into any problems/roadblocks, since I’ve been working on an interpreter for the past couple months as well.
I’ve been working on an interpreter, Zicl, some more over the past couple months. Zicl is a multithreaded Tcl-inspired interpreter, that takes Tcl’s vision of everything being a string and goes much further. I was able to do this mainly through the use of linked dictionaries (think Self), except that a parent “pointer” is actually a hash of its parent. That way parent “pointers” are content addressed, which makes them stable across computers. This lets me do cool things like
> set parent [dict create foo bar]
foo bar
> set child [dict link $parent [dict create baz qux]]
baz qux ~parent blake3~maj5kimcmt5j5ChegZP1oLmy7CwzJ2reKIlKSWLOnAE
> dict get $child foo
bar
I call the blake3~... a “hash reference”, and the interpreter will track liveness of hash references by scanning created strings for blake3~ entries, and keeping the hash value alive until no strings reference it anymore.
I can implement scope capture this way:
> fn foo {x y} { return [+ $x $y] }
fn name foo impl {{x y} { return [+ $x $y] }} scope blake3~m-zuefhmPJR8Mn54N5FJF5wBj5AmskieP3InY-zIvdY
I can also implement Haskell-like objects:
> method proto::incr {self amount} { incr self::counter $amount }
method name proto::incr impl {{self amount} { incr self::counter $amount }} scope blake3~4Q6zMQy3WwE_3xIuEEAzvceJ8rvYY5NKoTgwxOJt3aw
> set proto
incr {method name proto::incr impl {{self amount} { incr self::counter $amount }} scope blake3~4Q6zMQy3WwE_3xIuEEAzvceJ8rvYY5NKoTgwxOJt3aw}
> set instance [dict link $proto { counter 5 }]
counter 5 ~parent blake3~pXWAvQDXM-oENcsczfREDowKUADfueE8IyZzFi4NNQ8
> instance::incr 10
15
> set instance
counter 15 ~parent blake3~pXWAvQDXM-oENcsczfREDowKUADfueE8IyZzFi4NNQ8
My next plans are to get the C API cleaned up, since this interpreter is designed to be embedded in existing projects, and I also want to set up some fuzzing.
2 Likes
I’m currently working on a fork of an S3 client written in Zig. I’ve already migrated it to version 0.16 and fixed all the tests. Right now, I’m working on adding multipart upload support (and struggling a bit with it!).
3 Likes
I’m currently working on a simple Uxn VM in Zig. I don’t know yet what I’ll do with it when I finished the core emulator part…
Maybe I’ll try supporting enough of the other devices so that programs from the 100r guys work; that would be cool. Or I’ll take this as first step (and design sketch) before writing an Uxn emulator in the ICE programming language for the TI-84 Plus CE-T graphing calculator…
Anyways, regardless of what I’ll do with it: I’ll write everything by myself (NO AI).
3 Likes
I got really interested in binary protocols and efficient parsing in zig, trying to keep copies and syscalls to a minimum.
I decided to start writing a pcapng parser tool just a couple hours ago to process large pcapng files and print a short report:
./pangz testfiles/large.pcapng
==================================================
PCAPNG FILE STATISTICS
==================================================
File Size: 1648156248 bytes
Total Blocks: 1672002 (Sections: 1, Interfaces: 1)
Capture Metrics:
Total Packets: 1670000
Captured Bytes: 0 bytes
Original Bytes: 0 bytes
Duration: 0 ms
Performance & Throughput:
Packets / Sec: 0 pps
Avg Packet Size: 985 bytes
Throughput: 0 bps (0.00 Mbps)
Block Breakdown:
Enhanced Packets (EPB): 1670000
Simple Packets (SPB): 0
Interface Desc (IDB): 1
Name Resolution (NRB): 1000
Interface Stats (ISB): 0
Other Blocks: 1000
==================================================
I benched it against capinfos:
$ capinfos -c testfiles/large.pcapng
File name: testfiles/large.pcapng
Number of packets: 1.670 k
I got reasonable results: pangz is roughly 3 times faster but pangz is probably still missing a lot of functionality and also needs a proper test suit, which will hopefully be added in the future.
$ hyperfine --warmup 10 './pangz testfiles/large.pcapng > /dev/null' 'capinfos -c testfiles/large.pcapng'
Benchmark 1: ./pangz testfiles/large.pcapng > /dev/null
Time (mean ± σ): 222.7 ms ± 1.3 ms [User: 78.0 ms, System: 144.1 ms]
Range (min … max): 219.6 ms … 224.5 ms 13 runs
Benchmark 2: capinfos -c testfiles/large.pcapng
Time (mean ± σ): 734.9 ms ± 6.1 ms [User: 553.2 ms, System: 180.0 ms]
Range (min … max): 723.2 ms … 742.6 ms 10 runs
Summary
./pangz testfiles/large.pcapng > /dev/null ran
3.30 ± 0.03 times faster than capinfos -c testfiles/large.pcapng
Sources: https://github.com/giaco743/pangz
1 Like
This is the best thread ever ….
Spend most of Aug working on getting a Zig build toolchain + basic dev library (mostly) working for Atari ST.
Great learning experience! The m68k backend for llvm is still “experimental” apparently, so had to work around some nasty things to get anything working at all .. but it definitely works.
Managed to get a very poor space invaders clone playable, some GEM apps, and a cool little app that plays selected EBM bass lines through the Yamaha chip using a sequencer API. All written in idiomatic zig, with a clean enough dev api that’s not hard to learn.
Delightful !
EBM bassline player
code for 1 song
// Full "Der Mussolini" arrangement: bassline (tone, A) from rep 1; kick (noise,
// B) and snare + hi-hat (noise, C) enter at rep 3; all stop after rep 12.
// TODO tech debt - sounds ok at 100bpm, terrible below that, with notes running into each other
const mussolini_notes = "e1 b0 d2 b0, b1 b0 b0 b1, b0 b1 b0 b1, a1 b0 b1 b0";
const mussoliniSong = [_]gemz.Part{
// Das bassline, with a pitch shift in the middle (down a major third).
.{ .channel = .A, .notes = mussolini_notes, .volume = 15, .from_rep = 1, .to_rep = 4, .instrument = 1 },
.{ .channel = .B, .notes = "k . . . k . . . k . . . k . . k", .volume = 12, .from_rep = 3, .to_rep = 8 },
.{ .channel = .A, .notes = gemz.transpose(mussolini_notes, -4), .volume = 15, .from_rep = 5, .to_rep = 6, .instrument = 1 },
.{ .channel = .A, .notes = mussolini_notes, .volume = 15, .from_rep = 7, .to_rep = 8, .instrument = 1 },
.{ .channel = .A, .notes = gemz.transpose(mussolini_notes, 2), .volume = 15, .from_rep = 9, .to_rep = 9, .instrument = 1 },
.{ .channel = .A, .notes = mussolini_notes, .volume = 15, .from_rep = 10, .to_rep = 12, .instrument = 1 },
// Den Drum Kick starts on the 3rd rep (instrument 0 = no envelope).
// Und denn das Hat und Snare drum muss gepoken its fingerpicken in den song spielen !
// turn this off for now - its barely audible, and it adds too much work to the loop
// .{ .channel = .C, .notes = "h h h h s h h h h h h h s h h h", .volume = 8, .from_rep = 5, .to_rep = 12 },
};
fn mussolini(app: *MyApp) bool {
switch (app.form_choice(.default_button, "Der Mussolini|DAF - Alles ist gut (1981)", " Play | Close ")) {
1 => app.playSong(mussoliniSong, 92), // 80 bpm = 750 ms/step (calibrated: 4000/bpm in armCore)
else => {},
}
return true;
}
Next up, I want to write a new Atari linker from scratch and have a go at fixing some miscompilation issues with llvm before I call it done.
For September - I’m booked in for some surgery later this month, so deliberately getting off the keyboard for a few weeks and putting in more time on the bike. Time afk is an important and productive part of the dev journey that’s too easy to skip.
20 Likes
Hello, this is my first time posting on this forum and wanted to share this project. I am currently working on shinobi, a library/program to convert ‘build.ninja’ files into ‘build.zig’ files. The goal is to make it easier to add C/C++ projects to a Zig project without having to manually create and maintain a ‘build.zig’ file for the C/C++ project.
10 Likes
I continue to develop my CLI utility CheckLinks ( GitHub - ktarasov/check_links: CheckLinks is a command-line utility (CLI) written in Zig for checking links on a web page. · GitHub ).
You can find the answer to the question of why this is needed by following this link: check_links/README.en.md at master · ktarasov/check_links · GitHub
Since last month, the ability to localize the interface has been added. Currently, Russian, English, Spanish, and French are available.
Script generation for autocompletion in your shell has been added. bash, zsh, fish, and nushell are supported.