2024

Go request handlers typically include a “context” value as their first argument:

func handler( ctx context.Context, ... ) { 
    ...
}

In my experience, this convention is typically fastidiously followed, but then nothing is ever done with that ctx argument. What is it really for? Unfortunately, the description in the official Go package documentation is a bit cryptic, and the type implementation itself does not reveal anything either (the default context is just an empty struct).

Properly understood, it’s actually a really convenient idiom; however, its value is not so much in the context package itself, but in some idioms in the code that use the package.

Every once in a while, I need to evaluate the normal distribution function $\Phi(x)$:

$$ \Phi(x) = \frac{1}{\sqrt{2 \pi}} \int_{-\infty}^x \! e^{-\frac{1}{2}t^2} \, dt $$

Unfortunately, it is not always available in the standard math libraries, and hence I have to implement a “good-enough” version myself. Here are some options.

I have never seen a software project in which the limiting factor was the speed with which programmers could type.

The default highlighting of the Emacs “region” (the part of a buffer between “point” and “mark” — selected text, if any, in other words) is, out of the box, barely visible, at least against a light background. An attempt to customize it runs into an interesting problem when used in a text- or terminal-based environment, rather than a GUI.

I wanted to explore some of the new features in Emacs 29 (in particular Eglot). The version of Emacs that ships with my version of Linux Mint is Emacs 27, so I decided to build Emacs 29 from scratch.

This turned out to be absolutely painless; but installing the new version seamlessly into the existing environment did cause some hang-ups.

As it turns out, Emacs actually allows for different cursor shapes. We can use this feature to change the cursor based on the current minor mode.

Imagine a parking lot, consisting of a long, linear strip of slots. Cars enter at one end and leave by the other. Let’s also stipulate that each arriving car takes the first available slot that it encounters, that is, it will park in the first empty slot that is nearest to the parking lot entrance. Cars arrive randomly, with a given, average interarrival time $\tau_A$. Furthermore, cars occupy each slot for a random amount of time, but all with a common average dwell time $\tau_D$.

If we number the slots, starting at the entrance, we may now ask the question: what is the probability that the slot with index $n$ is occupied?

A little while ago, I read (and quite enjoyed) “Learning eBPF” by Liz Rice. “Linux Observability with BPF” David Calavera and Lorenzo Fontana is another, slightly earlier, book on the BPF framework, also published by O’Reilly.

A while back, I looked at the Diamond-Square Algorithm for terrain generation. That is a purely procedural algorithm that only attempts to generate realistic looking landscapes, without trying to model any physical or geological processes. By contrast, we will now look at an algorithm to generate realistic river networks, which is based on a (simplified) model of geological erosion.

The extended Berkeley Packet Filter, or eBPF for short, is a plugin architecture for the Linux kernel. Using eBPF, it is possible to load (short) programs into the kernel at runtime, and have them be executed by the kernel. As the name suggests, the technology started out as a method to build custom filters for network packets, but it has since been extended and become much more general.