Royston

Completion annotations

One of the most useful features of Emacs is its interactive completion. Whenever you need to input the name of some item, Emacs allows you to type some parts of the name and then type TAB to see a list of items that match what you have typed so far. But completion is more sophisticated than just prefix-matching. You can use wildcards (for example *green TAB will show colour names containing the substring ‘green’) and when the completion items have multiple words (separated by hyphens or spaces), completion works on each word individually, so that you can type M-x t-d-o-e RET to run the command toggle-debug-on-error. Naturally you can customize the set of completion mechanisms using the completion-styles setting.

The Emacs/Perforce integration that I maintain, p4.el, implements completion for each kind of Perforce item that you might need to name: branches, numbered pending changelists, clients, filespecs, groups, help topics, jobs, labels, and users. However, this works poorly in the case of changelists and jobs, because all you get when you type TAB is a list of opaque identifiers that give you no help in choosing the item you want. )

Royston

The Bug

I have been working on a project recently where there has been a lot of tricky debugging to do. The code I’m working on has to live in the same process as third-party code that is not under my control, and which calls into my code unpredictably, often from multiple threads or signal handlers. This is an application environment that’s particularly prone to rare crashes and deadlocks that somehow elude my own thorough test procedures but crop up nonetheless on the machines of potential customers during product evaluations. I used to find these kind of bugs intimidating and nerve-wracking, but (at least on this project and for the moment) I seem to be a match for them.

The process of debugging is (or ought to be) one of calmly, methodically and steadily gathering data that narrows the location of the problem until it can no longer hide and is forced to reveal itself. In my current project the first step is to acquire the log and (in the case of a crash) the backtrace from the customer and analyze it for the sequence of events leading up to the crash or deadlock. This identifies important features of the environment (which programs were running? are they multi-threaded? do they handle signals?) and usually pinpoints a suspect area of code which can be inspected for race conditions and deadlocks. Inspecting the code usually leads to a hypothesis or two about the cause; but even if it doesn’t I develop a test case that thoroughly exercises the problem area. With some experimentation and a lot of thought I’ve so far always found it possible to reproduce the problem under controlled conditions, whereupon it can be analyzed in the debugger.

Writing this is of course a form of hubris: no doubt I will return to work on Monday to find in my inbox a customer report describing a bug that I lack the skill to track down and fix. This hasn’t yet happened in my career, though there have been a few occasions where I have been in doubt as to the outcome, one of which I described in my post ‘The last lousy bug’. Programmers like to call these accounts “war stories”—joking, of course, but joking seriously. It is stressful to know that something is wrong in your code, but not to know what it is or how to find it, and to have it hanging over your head day after day as you fail to make progress towards solving it.

( This nightmare scenario is the driver behind Ellen Ullman’s 2003 novel The Bug. )

Royston

Software inspection and the Heartbleed bug

Since 2005, when a train crashes in the UK, a professional body of investigators—the Rail Accident Investigation Branch—is tasked with determining the cause of the incident and making recommendations to reduce the likelihood, or mitigate the severity, of similar events occurring in the future. There are similar branches tasked with investigating Air and Marine accidents.

There is nothing like this for computer security incidents. )

Royston

“Double Dutch” audax

Martin Malins has been organizing the “Double Dutch” 200 km audax for four years now. I rode the first edition back in 2011, when we had the most amazing luck with the weather, and I was looking forward to riding it again. The route is a tour of the Fens: starting at Huntingdon, you head north-east via Ramsey, March, and Nordelph, then north up the River Great Ouse to Kings Lynn for the fourth control and lunch. Then you cross the Ouse and head northwest to an info at Holbeach St Matthew close to The Wash, southwest to the sixth control at the Springfields shopping centre in Spalding, Lincolnshire, and back to Huntingdon for the finish.

I set my alarm for 06:00 )

Royston

DIY 200 audax to Wendover

It’s not easy designing a “DIY” audax route. The way these rides work is that you nominate a series of controls, then you ride around and visit each one in turn, collecting “proof of presence” in the form of receipts or cashpoint slips. The tricky bit is that you only get credit for the shortest distance between each pair of controls. So you pick two nice cafés about 50 km apart, but then it turns out that they are only 40 km apart via the A1, so that’s all you get credit for. Add up all those little diversions, and soon your DIY 200 is actually 240 km.

On a calendar ride, the organizer can put in “information” controls anywhere on the route (or at least, anywhere that it’s possible to ask a question), and so bring the distance ridden closer to the nominal distance. When I ran a calendar event a couple of years ago, with judicious placement of controls I managed to get the distance ridden down to 200 km exactly, and so reasonably friendly for beginners. But that’s not possible on a DIY.

So it was only after many experiments with Google Maps that I settled on a route with five controls )

Royston

Drawing square triangulations

The story so far:

  1. I introduced the tabular method by showing how to count the triangulations of a convex polygon;

  2. I used the tabular method to count the number of ways to triangulate an oriented n×n square using only lines joining the 4n integer points around the edge of the square and so solve Project Euler problem 270;

  3. I used the svgwrite Python package to draw the triangulations of a convex polygon using Scalable Vector Graphics; and

  4. I read Appendix J of the SVG specification and used the advice therein to shrink the size of the generated SVG.

( So now I’ve got all the pieces in place for the last step. )