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!).

In the last article, we managed to load a program (hello-dl) that uses a single dynamic library (libmsg.so) containing a single exported symbol, msg.

Our program, hello-dl.asm, looked like this:

global _start extern msg section .text _start: mov rdi, 1 ; stdout fd mov rsi, msg mov rdx, 38 ; 37 chars + newline mov rax, 1 ; write syscall syscall xor rdi, rdi ; return code 0 mov rax, 60 ; exit syscall syscall

If you’re a regular, you might’ve noticed the place has changed around a little. Thing is, I’ve been spending time playing around with a radical new concept: happiness.

The year and a few months that I’ve spent working for a start-up were actually a pretty gloomy time for me, both for professional and personal reasons. It took me a while to get out of this hole and start thinking positive again.

In the two years since I’ve posted I want off Mr Golang’s Wild Ride, it’s made the rounds time and time again, on Reddit, on Lobste.rs, on HackerNews, and elsewhere.

And every time, it elicits the same responses:

• You talk about Windows: that’s not what Go is good at! (Also, who cares?)
• This is very one-sided: you’re not talking about the good sides of Go!

In my previous article, I said I needed to stop thinking of Rust generics as Java generics, because in Rust, generic types are erased.

Someone gently pointed out that they are also erased in Java, the difference was elsewhere. And so, let’s learn the difference together.

Java generics

I learned Java first (a long, long time ago), and their approach to generics made sense to me at the time.

Now that our service is production-ready, it’s time to deploy it somewhere.

There’s a lot of ways to approach this: what we are going to do, though, is build a docker image. Or, I should say, an OCI image.

This is still a series about Nix, but again: because the best way to see the benefits of Nix is to do it without Nix first, we’ll use only Docker’s tooling to build the image.

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.

Let’s use the Advent of Code 2020, a series of programming challenges of increasing difficulty, to learn more about the Rust programming language.

I was not planning on doing anything specific this December, but a lot of folks around me (on Twitter, at work) have chosen this Advent of Code to pick up Rust, and I’ve got big FOMO energy, so, let’s see where this goes.

I’ll be doing all of these on Linux, so there may be some command-line tools involved, but don’t worry about them - the code itself should run on all platforms no problem.

It’s a new day, it’s a new advent of code puzzle.

In that one, we have to apparently cosplay as an IBM mainframe and just.. crunch them numbers. This doesn’t look fun, and I can’t think of a clever twist to make it fun, so let’s try to make it short and sweet.

Parsing

Our input looks like this:

Monkey 0: Starting items: 79, 98 Operation: new = old * 19 Test: divisible by 23 If true: throw to monkey 2 If false: throw to monkey 3 Monkey 1: Starting items: 54, 65, 75, 74 Operation: new = old + 6 Test: divisible by 19 If true: throw to monkey 2 If false: throw to monkey 0 (etc)