Being creative is hard work, let’s go optimizing instead! My graphics engine dye was pretty naive about displaying text, and it was wasteful. Let’s see how I made it all better with this one weird tip.

Disclaimer: Even after a few years I’m still very much an OpenGL newbie. Please don’t hit me with crowbars.

Once upon a time, OpenGL was easy to use - and also falling out of relevancy as far as high-performance 3D graphics were concerned. But it wasn’t all bad! You could basically pick up any library out there and integrate it with your existing GL project. Not that it’s a good idea, but it usually just worked.

So, how does ping.exe actually send a ping? It seems unrealistic that ping.exe itself implements all the protocols involved in sending a ping. So it must be calling some sort of library. Also, since it ends up talking to the outside world via a NIC (network interface controller), the kernel is probably involved at some point.

In reading files the hard way - part 2, we learned about dynamic libraries (like libc), and the Linux kernel, and how syscalls allowed us to ask the Linux kernel to do our bidding. For this series, we’re going to have to look at the Windows equivalents.

Day 2, Day 2! Woo!

The Advent of Code 2020, Day 2 problem talks about passwords. Sounds familiar.

Basically, our input looks like this:

1-3 a: abcde 1-3 b: cdefg 2-9 c: ccccccccc

Each line contains a “password policy” and a “password”. For the first line, the policy is that the password must contain between 1 and 3 (inclusive) times the letter “a”.

NO! No no no.

What?

WE WERE DONE!

Well… yes! But also no. We still shell out to a bunch of tools:

$ rg 'Command::new' src/commands/mod.rs 126: let variant = if let Ok(output) = run_command(Command::new("wslpath").arg("-m").arg("/")) { src/commands/cavif.rs 29: Command::new("cavif") src/commands/imagemagick.rs 25: Command::new(&self.bin) src/commands/cwebp.rs 25: Command::new("cwebp") src/commands/svgo.rs 25: Command::new("svgo")

In 2020, I switched from a static site generator to something homemade.

And, as tradition commands, I did a whole write-up about it.

Since writing articles and making videos is now my full-time occupation, I took some time to upgrade futile, my server software, to the latest and greatest the Rust ecosystem has to offer.

We’ve achieved our goals already with this series: we have a web service written in Rust, built into a Docker image with nix, with a nice dev shell, that we can deploy to fly.io.

But there’s always room for improvement, and so I wanted to talk about a few things we didn’t bother doing in the previous chapters.

Making clash-geoip available in the dev shell

Day 9’s problem statement is convoluted - the “ah maybe that’s why I don’t usually do Advent of Code” kind of convoluted, but let’s give it a go anyway.

So, we have a series of numbers, like so:

35 20 15 25 47 40 62 55 65 95 102 117 150 182 127 219 299 277 309 576

And uh the first N numbers are a “preamble” and every number that comes after that must be the sum of any two of the numbers that come before it.

A little less than two months after the previous release, I’m happy to announce that the ooc compiler rock 0.9.8, codename columbia is now out.

The impatients can readily skip to the release notes, but for those who prefer a narrative, let me tell you why I’m excited about this release.

String interpolation

We’ve thrown around this idea a lot since the early versions of rock since we have a few rubyists in our ranks, but only recently Alexandros Naskos took matters into his own hands and just implemented the fuck out of it.

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 article, We’ve built a nagaqueen-based tool that can parse one ooc file, detect class declarations and print its doc strings. Today, we’re making a bit of infrastructure for our app to support more sizable projects.

Source path and lib folders

Parsing a single file was a nice milestone, but it’s not nearly enough. We want to generate documentation for a whole project at a time: and since we’ll want to cross-link the various bits of documentation we generate, we’ll also need to parse the various dependencies (such as the ooc sdk, and any used library) so that we can resolve argument types and link them properly.