Welcome back!

In the last article, we did foundational work on minipak, our ELF packer.

It is now able to receive command-line arguments, environment variables, and auxiliary vectors. It can parse those command-line arguments into a set of options. It can make an ELF file smaller using the LZ4 compression algorithm, and pack it together with stage1, our launcher.

I use the draw.io desktop app to make diagrams for my website. I run it on an actual desktop, like Windows or macOS, but the asset pipeline that converts .drawio files, to .pdf, to .svg, and then to .svg again (but smaller) runs on Linux.

So I have a Rust program somewhere that opens headless chromium, and loads just the HTML/JS/CSS part of draw.io I need to render my diagrams, and then use Chromium’s “print to PDF” functionality to save a PDF.

Now that my website is deployed as a container image, I wanted to give nix a try. I’m still doing it the old-fashioned way right now: with a Dockerfile, running cargo in a “builder” image, copying stuff out of there into a slimmer image (that still has an Ubuntu base, even though distroless images are a thing now).

But why?

I was mostly interested in nix because some parts of my website have pretty big native dependencies. futile itself mostly relies on sqlite3 and some JS engine (used to be quickjs, currently duktape because MSVC Windows builds). But the asset processing pipeline, salvage (which I’d like to integrate with futile at some point) has a bunch more!

In December 2023, a minor miracle happened: async fn in traits shipped.

As of Rust 1.39, we already had free-standing async functions:

pub async fn read_hosts() -> eyre::Result<Vec<u8>> { // etc. }

…and async functions in impl blocks:

impl HostReader { pub async fn read_hosts(&self) -> eyre::Result<Vec<u8>>

Hey internet! So, someone broke into some of my accounts.

I’m taking entire responsibility for this - there’s the part where I fucked up, and if I didn’t fuck up, then none of this would’ve happened.

But there’s also the part where a series of design decisions from various vendors combined into the perfect storm for me.

And we’re going to talk about both! Separately! And calmly.

It took a hot minute.

Try several weeks.

Well, yeah. I got to contribute to a bunch of open-source projects in the meantime though, so I’m fairly pleased with it!

• libffi (for static linking)
• cairo (more static linking!)
• proxy-libintl (more static linking!)
• expat (static linking strikes again)
• poppler (for file descriptor stuff not properly gated on Windows, closed in favor of a similar MR)

In the previous article, I gave brummi a go. However, we’ve seen that it still doesn’t fit our requirements: we need a tool that’s fast, easy to install and configure, produces beautiful and usable docs.

Yesterday I started building my own documentation generator, and in this series I’ll present the challenges I face and how I solved them. This might show a few ooc tricks, perhaps some software design, some good, some bad, but overall I hope it’ll be a good read!

I like how the day 14 puzzle sounds, because I think it’ll give me an opportunity to show off yet another way to have Rust embedded in a web page.

But first…

You bet your furry ass, parsing.

Parsing

The input looks something like this:

498,4 -> 498,6 -> 496,6 503,4 -> 502,4 -> 502,9 -> 494,9

And each line is essentially… a polyline: we’re supposed to draw lines between every point on the path, and that determines rocks on the map.

Disclaimer:

At the time of this writing, I benefit from the fly.io “Employee Free Tier”. I don’t pay for side projects hosted there “within reasonable limits”. The project discussed here qualifies for that.

Why you might want a remote dev environment

Fearmongering aside — and Cthulhu knows there’s been a bunch, since this unfortunate tweet — there’s a bunch of reasons to want a remote dev environment.