rr

So this is cool. The debugger "rr" approaches things from a different perspective from most debuggers. Instead of instrumenting a live, running program, it makes a thorough recording of a full run, which you can then run back and forth through with a debugger. Sounds resource-intensive, but also pretty fantastic - like the author, I hardly ever use a debugger, but even my few times using one have been characterized by shooting past the point where things actually started to go wrong.

PyScribe

PyScribe is a kind of neat debugging logger for Python. I've always been partial to printf-style debugging myself, so I like the look of this.

Packet sleuthing

A fascinating post-mortem of a really, really strange packet problem (an ASCII 2 or 3 in a particular offset would kill the Ethernet interface until a hard power cycle!)

I love this stuff.

Debugging parsers

This parser subproject is the hardest programming I've done in twenty years. Well, wait - I took Compilers from Kent Dybvig in ... must have been 1995. So fifteen years, anyway, but I don't remember Compilers. That is, I remember Kent, and I remember the class, but I don't really remember the coding. This stuff is stored in a different place in my brain, I think, very intuitive and nonverbal - part of what makes it so exhilarating.

Anyway, debugging recursive descent compilers is hard, because they're declarative in nature. This is actually going to end up being a key insight (no, not hexapodia) - debugging an imperative program is far, far easier than debugging a declarative one, because you can step through what the program is doing. In a declarative program, not only do you not know when or where things are being done, it's exceptionally difficult to interpose a check point.

I wrote a small debug atom for parsers, though - when it's invoked, it always succeeds, consuming nothing, just like \&nothing - but it prints a message.

Using it felt like ... Prolog.