When I was in grad school and struggling with my Master’s thesis, I started a small side project in order to distract myself and work on something that felt more rewarding. This project was basically a clone of vim – a terminal-based text editor I called badavi. That was around seven years ago. I haven’t worked on it continuously since then, but I would occasionally go back and hack on it in short little bursts. In particular I’ve been doing this the last couple of months, and I thought it might be interesting to write about some of the things I’ve been up to.

For this post, we’ll look at some small performance fixes I made recently, guided by perf and flame graphs.

I like out-of-tree builds. Out-of-tree builds are nice for lots of reasons. You can have multiple builds of the same project coexisting side-by-side – for example a debug build for development, a release build, and an instrumented build for code coverage runs. All the generated build artifacts are together underneath one directory which you can easily delete without having to maintain a make clean target, or place under .gitignore without having to maintain a growing set of patterns for the different kinds of artifacts. I was going to write a post about this, but came across this one by Jussi Pakkanen which covers a lot of the ground I would have, so I’ll just link to it here.

Instead, this post is about an issue that arises when implementing out-of-tree builds in make, and the best approach I’ve found for dealing with it.

Update (2022-09-05): The issue described in this post was addressed by PEP 479, which made it so that StopIteration is automatically changed into a RuntimeError when raised inside a generator. As of python 3.5 (which was already available when this post was written), it was possible to opt into the new behavior with from __future__ import generator_stop, and the default was changed in python 3.7.

Sometimes, if I have a generator that I happen to know is non-empty, and I want to get at the first element, I’ll write code like this:

output = next(f for f in os.listdir(dir) if f.endswith('.o'))

This is a small gotcha about file permissions I ran into recently.

This is a quick post about a bug I ran into at work which turned out to be caused by passing a literal 0 instead of NULL to a function. Here’s a small program reproducing it:

The past few months at work I’ve been working with a large legacy codebase, mostly written in C. In order to debug problems as they come up, I wanted to use gdb – but it seemed like the program was only ever compiled with optimizations turned on (-O2), which can make using gdb a frustrating experience, as every interesting value you might want to examine has been optimized out.

After grappling with the build system to pass -O0 in all the right places (a surprisingly difficult task), I found that the program did not link with optimizations turned off. Once I got around that, I ran into a crash in some basic functionality, easily reproducible at -O0, but not -O2. This post contains two tiny contrived programs reproducing those issues.

It’s common to be asked a question like “what’s the hardest bug you’ve debugged?” at job interviews in tech. This post is about the bug I usually describe. The snag is that it’s quite involved and I don’t actually understand it all the way through – there are one or two aspects to it I often hand-wavingly gloss over. The hope was that by writing it out and fact checking it I’d have a better handle on it; this is what came out.

Disclaimer: I’m not quite sure who the audience is for this. I guess it’s describing a fun little project I put together, but it’s also written kind of like a tutorial, so you can maybe follow along. I don’t think it’s particularly beginner-friendly, though. Some knowledge of Java is assumed, but not much. The code is available on github.

Code coverage is a software metric that measures how much, and which parts, of the source code of a program were exercised in a given execution of that program. There are many different flavors of coverage data, for example tracking which lines or statements were executed, which functions were called, which branches or control flow paths were taken. In this post, we’ll walk through writing a simplistic coverage collection tool for Java.