Welcome back to the “Making our own executable packer” series, where digressions are our bread and butter.

Last time, we implemented indirect functions in a no-libc C program. Of course, we got lost on the way and accidentally implemented a couple of useful elk-powered GDB functions - with only the minimal required amount of Python code.

The article got pretty long, and we could use a nice distraction. And I have just the thing! A little while ago, a member of the Rust compiler team stumbled upon this series and gave me some feedback.

I try to avoid doing “meta” / “behind the scenes” stuff, because I usually feel like it has to be “earned”. How many YouTube channels are channels about making YouTube videos? Too many.

Regardless, because I’ve had the opportunity to make my own mistakes now for a few years (I started doing the video thing in earnest in 2019), and because I’ve recently made a few leaps in quality-of-life re: shooting and editing video, I thought I’d publish a few notes, if only for reference for my future self.

It’s a new day, it’s a new advent of code puzzle.

In that one, we have to apparently cosplay as an IBM mainframe and just.. crunch them numbers. This doesn’t look fun, and I can’t think of a clever twist to make it fun, so let’s try to make it short and sweet.

Parsing

Our input looks like this:

Monkey 0: Starting items: 79, 98 Operation new = old divisible by true throw to monkey false throw to monkey items new = old + divisible by true throw to monkey false throw to monkey etc

Part 1

In the day 2 challenge, we’re playing Rock Papers Scissors.

We’re given a strategy guide like so:

A Y B X C Z

Left column is “their move”: A means Rock, B means Paper, C means Scissors. Right column is “our move”: X means Rock, Y means Paper, Z means Scissors.

Each line corresponds to a turn, and we must calculate the total score we get. Picking “Rock” gives 1 point, “Paper” gives 2 points, and “Scissors” gives 3. Losing the round gives 0 points, drawing gives 3, winning it gives 6.

I do not come to you with answers today, but rather some observations and a lot of questions.

The weird glitch

Recently I was editing some video and I noticed this:

Not what the finger is pointing at — the dots.

Here are the separate layers this image is made up of: the background is a stock image I’ve licensed from Envato Elements:

Because I use it as a background image, I’ve cranked down the exposition in the Color tab:

Hello and welcome to Part 11 of this series, wherein we finally use some of the code I prototyped way back when I was planning this series.

Where are we standing?

Let’s review the progress we’ve made in the first 10 parts: first, we’ve started thinking about what it takes for computers to communicate. Then, we’ve followed a rough outline of the various standards and protocols that have emerged since the 1970s.

In the previous chapter, we’ve made a nix “dev shell” that contained the fly.io command-line utility, “flyctl”.

That said, that’s not how I want us to define a dev shell.

Our current solution has issues. I don’t like that it has import <nixpkgs>. Which version of nixpkgs is that? The one you’re on? Who knows what that is.

Also, we haven’t really seen a mechanism to use .nix files from elsewhere.

A couple months ago I made a loudness meter and went way too in-depth into how humans have measured loudness over time.

Today we’re looking at a spectrogram visualization I made, which is a lot more entertaining!

We’re going to talk about how to extract frequencies from sound waves, but also how my spectrogram app is assembled from different Rust crates, how it handles audio and graphics threads, how it draws the spectrogram etc.

Now that our development environment is all set up, let’s make something useful!

Creating the catscii crate

From a VS Code window connected to our VM (as we just set up), let’s make a new Rust project:

amos@miles:~$ cargo new catscii Created binary (application) `catscii` package

And open it in a new VSCode window:

amos@miles:~$ code catscii

Now that our service is production-ready, it’s time to deploy it somewhere.

There’s a lot of ways to approach this: what we are going to do, though, is build a docker image. Or, I should say, an OCI image.

This is still a series about Nix, but again: because the best way to see the benefits of Nix is to do it without Nix first, we’ll use only Docker’s tooling to build the image.