Up until now, we’ve been loading a single ELF file, and there wasn’t much structure to how we did it: everyhing just kinda happened in main, in no particular order.

But now that shared libraries are in the picture, we have to load multiple ELF files, with search paths, and keep them around so we can resolve symbols, and apply relocations across different objects.

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”.

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.

Update: Lestac is now available in Early Access on itch.io! Read more on the official page

So, Lestac is out! Ain’t that something? For those who don’t know, it’s Sylvain and I’s entry for Ludum Dare 28, a video game jam that happens every four months.

Here’s how it looks:

You can play it now if you haven’t yet - it’s available for Linux, OS/X, and Windows. And then you can come back and read this postmortem if you will!

To the programmers

It’s too easy! Where’s the documentation for the API? I found an injection vulnerability! Global functions from ‘window’ leak! I tried to attack your server then realized nginx was ignoring me!

Keep struggling, my pretties. The game is not meant for you, but you are good guinea pigs nonetheless. Just because the game involved programming, you found yourself so, so terribly wrong about one thing: that you understood at all what was happening.

The day 13 puzzle needs a speech therapist.

…because it has an awful lisp!! Ahhhahahahhhh

No but seriously we have what are ostensibly S-expressions, except they use JSON-adjacent notation:

[1,1,3,1,1] [1,1,5,1,1] [[1],[2,3,4]] [[1],4] [9] [[8,7,6]] [[4,4],4,4] [[4,4],4,4,4] [7,7,7,7] [7,7,7] [] [3] [[[]]] [[]] [1,[2,[3,[4,[5,6,7]]]],8,9] [1,[2,[3,[4,[5,6,0]]]],8,9]

It’s time for Day 4 of the Advent of Code 2020!

Now, I’ve already had a look at the problem statement, at least for part 1, and I’m not particularly excited.

But it will allow me to underline some of the points I’ve recently been *trying to make about types and correctness.

The problem is to parse passports, with fields like these:

I write a ton of articles about rust. And in those articles, the main focus is about writing Rust code that compiles. Once it compiles, well, we’re basically in the clear! Especially if it compiles to a single executable, that’s made up entirely of Rust code.

That works great for short tutorials, or one-off explorations.

Unfortunately, “in the real world”, our code often has to share the stage with other code. And Rust is great at that. Compiling Go code to a static library, for example, is relatively finnicky. It insists on being built with GCC (and no other compiler), and linked with GNU ld (and no other linker).

Everybody knows how to use files. You just open up File Explorer, the Finder, or a File Manager, and bam - it’s chock-full of files. There’s folders and files as far as the eye can see. It’s a genuine filapalooza. I have never once heard someone complain there were not enough files on their computer.

But what is a file, really? And what does reading a file entail, exactly?