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

This time around, we’re porting a solution from C++ to Rust and seeing how it feels, how it performs, and what we can learn about both languages by doing that.

See Day 17 for the rationale re: porting solutions rather than writing my own from scratch. TL;DR is: it’s better than nothing, and we can still focus about learning Rust rather than spending entire days fighting off-by-one errors.

The ooc language is known to be friendly to C libraries, and we have a slew of them covered on GitHub, but one common hurdle is how to correctly declare extern functions.

Argument types

For an ooc function prototype, there are many types of arguments. You can go with regular variable declarations, like so:

something: func (a: Int, b: Int, c: String)

But in this case, a and b have the same type, so you can also use multi-declarations to shorten it a bit:

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?

async_trait’s one weird type ascription trick

Now that I got the Log in with GitHub feature working, let’s explore what this would’ve looked like with the async_trait crate.

First up, the trait definition:

/// Something that can refresh credentials #[async_trait::async_trait] pub trait CredentialsRefresher { async fn refresh(&self, creds -> eyre

Note: this article is adapted from a presentation I gave at a Rust Paris Meetup — that’s why it sounds a little different than usual. Enjoy!

Good evening! Tonight, I will attempt to answer the question: Does Dioxus spark joy? Or at the very least, whimsy.

What’s Dioxus, you ask? It is first and foremost a name that is quote: “legally not inspired by any Pokémon”.

Two years ago, I did part of Advent of Code 2020 using the Rust language. It was a lot of fun, so let’s try it again!

The problem statement

Our input looks something like this:

1000 2000 3000 4000 5000 6000 7000 8000 9000 10000

Each group of lines separated by an empty line is a list of food items an elf is carrying: each line corresponds to the number of calories in that food.

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.

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 was a bit anxious about running our poppler meson build in CI, because it’s the real test, you know? “Works on my machine” only goes so far, things have a tendency to break once you try to make them reproducible.

And I was right to worry… but not for the reasons I thought. As I tried to get everything to build in CI, there was a Pypi maintenance that prevented me from installing meson, and then Sourceforge was acting up.