In December 2023, a minor miracle happened: async fn in traits shipped.

As of Rust 1.39, we already had free-standing async functions:

pub async fn read_hosts() -> eyre::Result<Vec<u8>> { // etc. }

…and async functions in impl blocks:

impl HostReader { pub async fn read_hosts(&self) -> eyre::Result<Vec<u8>>

Unfortunately, the ooc language could have better documentation. In the meantime, I’d like to blog about about some features that might not be very well-known.

Nested functions

Here’s a program that prints 1, 3, 5, 7, 9:

import structs/ArrayList main: func { list := ArrayList<Int> new() addIfOdd := func (i: Int) { if (i % 2 != 0) list add(i) } for (i in 0..10) { addIfOdd(i) } list map(|i| i toString()) join(", ") println() }

A few days ago I posted an ooc quine. But while browing HackerNews, I found an even shorter one. The shortest!

Here it is, in its full glory

Can’t see anything? That’s an empty file. It will compile and run just fine. ooc doesn’t require a main function - you can just shove code in there that will run at the program’s initialization. If there’s none, no big deal! It’ll just not run anything.

Welp, I did it again - I released an album: it’s named *andfall, a play on the word “landfall”, and I wrote it in one week-end, for @McFunkyPants’ entry in the Ludum Dare 33 game jam.

It’s my first solo album, the previous ones were collaborations with @bigsylvain and @geckojsc. It feels a bit weird to release an album alone - there’s nobody to blame for the flaws, and nobody to praise for the good parts!

In part 1, we’ve looked at three executables:

• sample, an assembly program that prints “hi there” using the write system call.
• entry_point, a C program that prints the address of main using printf
• The /bin/true executable, probably also a C program (because it’s part of GNU coreutils), and which just exits with code 0.

We noticed that when running entry_point through GDB, it always printed the same address. But when we ran it directly, it printed a different address on every run.

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.

A couple months ago I made a loudness meter and went way too in-depth into how humans have measured loudness over time.

Today we’re looking at a spectrogram visualization I made, which is a lot more entertaining!

We’re going to talk about how to extract frequencies from sound waves, but also how my spectrogram app is assembled from different Rust crates, how it handles audio and graphics threads, how it draws the spectrogram etc.

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.

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: