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 often write pieces that showcase how well Rust can work for you, and how it can let you build powerful abstractions, and prevents you from making a bunch of mistakes.

If you read something like Some mistakes Rust doesn’t catch in isolation, it could seem as if I had only nice things to say about Rust, and it’s a perfect little fantasy land where nothing ever goes wrong.

Haven’t blogged in a while. Life’s fine, project are a-plenty, but I just wanted to make a more lasting post about one particular issue that struck me as funny when programming Paper Isaac.

Bugs, bugs, bugs

What’s infuriating when letting others play an early prototype is that you hear constantly the same things. Some bugs are non-trivial to fix, some you’re just not motivated to fix now… sometimes you just have your head elsewhere, gotta focus, or are elbow-deep in some other piece of code and the damn walls can wait.

Damian Sommer did a casual AMA on Reddit recently, about his upcoming game, The Yawhg. I got to ask him a few questions. Here’s what he had to say.

What brought you out of your usual “let’s make fucked up platformers” style?

“I was just kind of tired of them. There’s still one more platformer I really want to finish, (The Clown Who Wanted Everything), but besides that, I’m just extremely bored of them now.”

The day 7 challenge talks about trees! File trees that is.

The temptation to solve it before starting to write this article so I don’t look silly is high, but I’m explicitly not doing so, so that we can bang our collective heads against any walls at the same time, and see how we can get out of it! Trees are serious business!

Part 1

The sample input looks like this:

In the last article, we found where code was hiding in our samples/hello executable, by disassembling the whole file and then looking for syscalls.

Later on, we learned how to inspect which memory ranges are mapped for a given PID (process identifier). We saw that memory areas weren’t all equal: they can be readable, writable, and/or executable.

Documentation in ooc land has sucked for quite some time. The standard response is pretty much: “use the code, Luke!” — which is fine when doing small projects that don’t matter much, but not so when you want to get serious.

So when a newcomer, beoran, asked how to generate documentation, and later told us he got NaturalDocs to work, naturally, I had to see for myself how well it worked.

In the Day 13 problem, we’re trying to take the bus.

Our input looks like this:

939 7,13,x,x,59,x,31,19

The first line indicates the earliest minute we can leave from the bus terminal, and the second line indicates the “identifier” of the buses that are active.

Each bus departs every “bus ID” minutes - bus 7 leaves at minute 0, minute 7, minute 14, minute 21, etc. The question is: which bus can we take first (apparently they either all go to the same destination, or we don’t really care where we’re going), and how long do we have to wait for it?

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.