gareth_rees

The story so far: I wrote a solver for a generic exact cover problem in Python, and used it to find polyomino tilings. The reason for using Python was because Python’s simplicity, terseness, and flexibility makes it easy to write solvers for other combinatorial problems. ( So let’s have a look at a second problem … )

So, another day at the customer site, another issue to fix:

Issue 234. Over the past three months, the performance of [PRODUCT] has regressed. In December, at commit 919074d, [TESTCASE] ran in 21 seconds, but now it takes 44 seconds.

The first step is to check that the problem is reproducible (it is), ( and the next is to run a git bisect to see if there was a bad commit … )

It was Friday afternoon at the customer site and I had completed my tasks for the week. I had implemented the new feature and its test cases, written a design justifying the implementation, and drafted a section of the user manual explaining how to use it, so now I was looking for something else to do. In any large program, there are always things that need fixing, so I poked about in the depths of the issue tracker to see if there were any interesting problems that could be appropriated from the other developers. ( The unluckily numbered and long unsolved issue 13 caught my eye… )

Jean le Flambeur, gentleman thief, is sprung from prison by the beautiful Mieli, who persuades him to undertake one last job. Author Hannu Rajaniemi works hard to obscure the familiar outline of this hoariest of heist plots, by layering on the worldbling with a trowel:

The hidden Sobornost tech beneath the Oortian sapphire coral wakes up. The spidership reconfigures itself. The scattered modules pull themselves together along their tethers and fuse together into a tight, hard cone. The q-dot winglets transform from a perfectly reflective material into a diamond-hard firewall. Just in time, before the Archon’s nanomissiles hit.

I do like the experience of being confronted by a complex fictional world and having to make sense of it. ( But I also like to feel that there is in fact some sense to be made, and in this novel I frequently failed to make it. )

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. )

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. )

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 )

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 )

The “Emitremmus” is a 100 km audax, run by Stevenage CTC each autumn for the last 19 years, on the Sunday that the clocks go back. The route starts at Fairlands Valley Park in Stevenage and heads east via Great Munden and Hare Street to Saffron Walden, returning via Great Chishill and Therfield. ( The start of the ride is almost exactly 50 km from my house )

In “Scalable vector triangulations” I used the svgwrite package to draw the 429 triangulations of an oriented convex nonagon. But there was something unsatisfactory about the size of the resulting image: 1.2 MiB seems rather large for an image which has 3003 triangles and 6435 lines. ( A look at the source reveals three sources of wasted space )