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’ve recently come back to an older project of mine (that powers this website), and as I did some maintenance work: upgrade to newer crates, upgrade to a newer rustc, I noticed that my build was taking too damn long!

For me, this is a big issue. Because I juggle a lot of things at any given time, and I have less and less time to just hyperfocus on an issue, I try to make my setup as productive as possible.

I love diagrams. I love them so much!

In fact, I have fairly poor visualization skills, so making a diagram is extremely helpful to me: I’ll have some vague idea of how different things are connected, and then I’ll make a diagram, and suddenly there’s a tangible thing I can look at and talk about.

Of course the diagram only represents a fraction of what I had in mind in the first place, but that’s okay: the point is to be able to talk about some aspect of a concept, and so I have to make choices about what to include in the diagram. And maybe make several diagrams.

Enhance! In this series, we’re looking at TV depictions of technology, and reviewing how realistic they are. Of course, they’re very rarely accurate, but it’s still interesting to take a look and try to figure out what they could’ve been thinking of, and just reminisce in general.

What?

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")

ooc makes it easy to compile your application on all major platforms (Windows, OSX, Linux) - the compiler itself runs there, and the SDK supports all these platforms with basic functionality: data structures, file handling, time handling, networking, etc.

But between getting your application running on your dev environment with all the libraries installed, and getting it into a neat package for your users to run without having to install any dependencies by hand, there’s a bag of tricks. Fortunately, I have found the time to figure most of them out. I’ll try to explain these in detail here as clearly as possible, here in this article.

As I’ve said before, I’m working on a book about lifetimes. Or maybe it’s just a long series - I haven’t decided the specifics yet. Like every one of my series/book things, it’s long, and it starts you off way in the periphery of the subject, and takes a lot of detours to get there.

In other words - it’s great if you want an adventure (which truly understanding Rust definitely is), but it’s not the best if you are currently on the puzzled end of a conversation with your neighborhood lifetime enforcer, the Rust compiler.

Writing Rust is pretty neat. But you know what’s even neater? Continuously testing Rust, releasing Rust, and eventually, shipping Rust to production. And for that, we want more than plug-in for a code editor.

We want… a workflow.

Why I specifically care about this

While looking to write a pure ooc version of ftgl, I was reading the source of ftgl-gl3 and I stumbled upon this piece of code:

static inline GLuint NextPowerOf2(GLuint in) { in -= 1; in |= in >> 16; in |= in >> 8; in |= in >> 4; in |= in >> 2; in |= in >> 1; return in + 1; }

This is needed because dealing with power-of-two textures (32x32, 64x64, 128x128, etc.) is more efficient with OpenGL (some implementations don’t even support non-power-of-two textures!).

Just 8 days after the last release, rock 0.9.6 is out.

To update, run git pull && make rescue as usual. To install from scratch, clone the repo, cd into it, and run make rescue from there - it’ll download the latest bootstrap, compile itself from C, then recompile itself from ooc.

Running rock -V should give you something like this:

rock 0.9.6 codename loki, built on Wed Feb 20 15:09:08 2013