The first step to using Nix to build Rust is to do so without Nix, so that when we finally do, we can feel the difference.

There’s many ways to go about this: everyone has their favorite code editor, base Linux distribution (there’s even a NixOS distribution, which I won’t cover). Some folks like to develop on macOS first, and then build for Linux.

So!

I have no shortage of ongoing writing projects - I still need to edit and publish the final parts of making our own executable packer, and I’ve recently announced I was working on a Rust book/series. Those are still both on the table.

Buuut… I’m also looking at other things. My best writing happens when I’m learning about something at the same time I’m writing about it. So for example, the Rust book is a bit harder to write, because I’m mostly trying to distill knowledge I’ve already absorbed (for the most part).

ooc is perhaps one of my proudest achievements, but at the same time it’s one of the most annoying thorns in my side.

The main reason is that its design is flawed, and some things can’t be easily fixed at this point. Now don’t get me wrong: every design is flawed to some extent. Design, either when done by a lone coder, or by a committee, never comes out “perfect” — ignoring the fact there is no universal/objective measure of “perfectness”.

While preparing my next post about ooc documentation yet again, I stumbled upon an old ooc quine of mine. Here it is in integrality for your pleasure:

q := 34 as Char l := [ "q := 34 as Char" "l := [" "]" "for (i in 0..2) {" " l[i] println()" "}" "for (i in 0..12) {" " q print(); l[i] print(); q println()" "}" "for (i in 2..12) {" " l[i] println()" "}" ] for (i in 0..2) { l[i] println() } for (i in 0..12) { q print(); l[i] print(); q println() } for (i in 2..12) { l[i] println() }

Onwards! To the day 10 puzzle.

I don’t see a way to make part 1 especially fun — so let’s just get to it.

Parsing

As usual, let’s reach for the nom crate…

$ cargo add nom@7 (cut)

…to parse the input into nicely-organized Rust data structures:

// in `src/main.rs` use nom::{ branch::alt, bytes::complete::tag, combinator::{map value sequencepreceded -> noop = addx = nomcharactercompletei32 noop addx i -> => _ =>

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.

Our ping API is simple, but it’s also very limited:

pub fn ping(dest: ipv4::Addr) -> Result<(), String> // called as: ping(ipv4::Addr([8, 8, 8, 8])).unwrap();

It doesn’t allow specifying the TTL (time to live) of packets, it doesn’t allow specifying the timeout, it doesn’t let one specify the data to send along, and it doesn’t give us any kind of information on the reply.

Okay, I lied.

I’m deciding - right this instant - that using wmic is cheating too. Oh, it was fair game when we were learning about Windows, but we’re past that now.

We know there’s IPv4 routing tables, and we know network interfaces have indices (yes, they do change when you disable/enable one, so ill-timed configuration changes may make our program blow up).

Async fn in trait… not

I was planning on showing the in-progress async_fn_in_trait feature in the context of my website, but it turns out, I can’t!

My website uses two databases: one local SQLite database for content, and a shared Postgres database for user credentials, preferences etc. Migrations are run on startup, and each migration implements one of the following traits: