Our January project was ambitious: a 2D puzzle game, a-la lemmings with a twist, with big and numerous levels. And of course, all using our homegrown tools, from the compiler to the level editor to the UI system and game framework.

However, January ended too soon, and, sleepless nights notwithstanding, I had to resolve to publish something completely different. It was a good occasion to get to know Twine.

Learning Rust is… an experience. An emotional journey. I’ve rarely been more frustrated than in my first few months of trying to learn Rust.

What makes it worse is that it doesn’t matter how much prior experience you have, in Java, C#, C or C++ or otherwise - it’ll still be unnerving.

In fact, more experience probably makes it worse! The habits have settled in deeper, and there’s a certain expectation that, by now, you should be able to get that done in a shorter amount of time.

Hello all, and welcome back to Advent of Code 2020, featuring Cool Bear.

Hey y’all!

Let’s get right to it.

The problem statement for Day 3 is as follows: we’re given a map, that looks like this:

..##....... #...#...#.. .#....#..#. ..#.#...#.# .#...##..#. ..#.##..... .#.#.#....# .#........# #.##...#... #...##....# .#..#...#.#

And we imagine that it repeats infinitely to the right, like so:

In the previous article, we saw how to use NaturalDocs, a language-agnostic documentation generator. Today we’ll see how to use brummi, a tool specific to ooc, written by Friedrich Weber.

Generating .json files

The first step to generate docs using brummi is to use rock, to generate a set of .json files describing the code. The --backend command-line option allows to select which backend you want rock to use (the C backend is the default).

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?

Part 1

The day 5 challenge actually looks fun!

Our input looks like this:

[D] [N] [C] [Z] [M] [P] 1 2 3 move 1 from 2 to 1 move 3 from 1 to 3 move 2 from 2 to 1 move 1 from 1 to 2

Which is a visual representation of stacks, and so, for once, we have some serious parsing to do, and that means I finally have a good reason to bust out the nom crate.

Welcome back to the eighteenth and final part of “Making our own executable packer”.

In the last article, we had a lot of fun. We already had a “packer” executable, minipak, which joined together stage1 (a launcher), and a compressed version of whichever executable we wanted to pack.

What we added, was a whole bunch of abstractions to parse ELF headers using deku, which we used from stage1 to be able to launch the guest executable from memory, instead of writing it to a file and using execve on it.

Falling out of love with warp

Back when I wrote this codebase, warp was the best / only alternative for something relatively high-level on top of hyper.

I was never super fond of warp’s model — it’s a fine crate, just not for me.

The way routing works is essentially building a type that gets larger and larger. One route might look like:

 bye = warp warppath | | name

The front end of the pool

I’ve been interested in reactive JavaScript for a while. At memoways, we strive to build snappy user interfaces for clients who like to interact with their data with as little latency as possible.

In the past two years, I learned front-end development on-the-fly, as the needs of the clients required it. Two years ago, I was still using jQuery. Then, I discovered space-pen thanks to my colleague Nicolas. It was nice to have proper ‘view’ objects, and use jQuery’s event system to have messages propagate throughout a hierarchy.