City pigeons

The London PigeonA pigeon is sitting in the yard of our London flat. I don’t think it can fly very well: it’s been mostly walking for the past few days, though it will flap away if alarmed. It has two mangled feet and doesn’t walk all that tidily either.

We took pity on it and gave it some mixed seeds and peanuts, which it seemed to like, except the pumpkin seeds, which it’s scrupulous about leaving. Then it started coming up to the door, including appearing in the morning waiting hopefully for breakfast.

As it was our guest I decided I should learn something of its ways, so I went on an internet hunt for city pigeon facts. I found myself pretty impressed.

  • Feral pigeons are found in cities across the world, and they’re the same kind everywhere (Columba livia). They’re apparently all descended from domesticated rock pigeons that got away. Presumably they do well in cities because the building habitat resembles the rocky cliffs they originally grew up around, back in the day.
  • They mate for life. Our pigeon (I don’t know its sex, apparently it’s hard to tell) has a much fitter-looking mate, which will come down and join it in the yard but then hangs back to let the weaker bird have the food.
  • They can in theory live for 15 years, though in the wild they usually expire before their time. Their predators include other birds like hawks (which are sometimes brought in to our local train station to frighten the pigeons away) or even seagulls, as well as larger mammals like cats and people.
  • Pigeons are pretty clever, being good at classification tasks as well as famously good navigators.
  • The reason why pigeons (and some other birds) bob their heads when walking has to do with their sight, and specifically the way their eyes point in different directions so they lack stereoscopic vision. Either the head-bob stabilises eye motion to reduce parallax effects while walking, or else it intentionally introduces parallax in order to provide depth cues.
  • Pigeons are resistant to bird flu and you’re unlikely to catch anything nasty from one. Less likely than from a cat or dog anyway.
  • Although the rock pigeon seems successful in cities, across the UK it’s vastly outnumbered by the wood pigeon, which has apparently around 5 million pairs, compared to just over half a million rock pigeon pairs (including feral ones).
  • Rock pigeons are also outnumbered by many far less visible birds, even in cities. This study in 2008 reckoned there were about 12,000 feral pigeons in Sheffield, a city of half a million people: fewer than there were of wood pigeons, swifts, house martins, wrens, dunnocks, robins, blackbirds, blue tits, great tits, magpies, starlings, greenfinches, or (most numerous by far) sparrows. This seems hard to believe to me, but there it is.
  • The dodo may have been a kind of pigeon.Mean bird sorting out a pigeon

Although I’d like to think this pigeon is safe in our yard, I doubt if it is. I’ve seen bigger birds munching on pigeon out there before (see photo—this is from several years ago, and is not yet the fate of our friend). I do worry that a lone pigeon motionless in the middle of the yard might almost as well be sitting on a serving dish.


Single-key menu shortcuts with Qt 5 on OS/X

Several of my Qt-based applications, including Sonic Visualiser and Tony, have some menu actions attached to single-key shortcuts without a modifier key. Examples include the Space bar to start and stop playback, or the “f” key (without Ctrl, Alt or any other modifier) for zoom-to-fit.

While testing the update from Qt 4 to Qt 5.1 we found that some of these shortcuts were no longer working on the Mac, though they still worked on other platforms. Hoping this would be fixed in a Qt update, I decided to stick with Qt 4 for the official Mac builds of Sonic Visualiser for the time being. As of Qt 5.3.0, though, the problem still wasn’t fixed and I decided I couldn’t avoid it any longer.

After some digging (documented in this issue tracker) I think I understand the cause and have a workaround, although I don’t know how to fix it properly in Qt. Here’s the summary as I understand it:

  • Qt on OS/X does not (in general) handle menu shortcuts itself. It creates a native Cocoa menu and lets Cocoa’s Key Equivalents mechanism handle them.
  • Key Equivalents apparently do not work reliably for shortcuts without modifiers.
  • Before Qt 5.1, any menu shortcuts that Cocoa did not handle would drop through to Qt’s cross-platform layer and be handled as window-level shortcuts bound to a QAction instead. So the single-key shortcuts continued to work even though Cocoa didn’t handle them itself.
  • This broke in Qt 5.1 because of this commit which was applied to fix this crashing bug. The problem was that some menus that should have been inactive (because a modal dialog was overriding them) could still be activated erroneously from the keyboard through this fallback shortcut mechanism.
  • There is an open Qt bug about the single-key shortcut problem and it contains a partial workaround.

So there’s a workaround in that last bug tracker, which binds each of the menu actions to a separate, global, application-level shortcut instead:

foreach (QAction *a, menu->actions()) {
    QObject::connect(new QShortcut(a->shortcut(), a->parentWidget()),
                     SIGNAL(activated()), a, SLOT(trigger()));

This works as far as it goes, but it doesn’t check the action’s enabled status (and nor does the action’s trigger slot) so it’s possible to use this to invoke an action that is supposed to be disabled.

I ended up using a more complicated workaround, which you can find here. The code is basically as follows:

void MainWindow::finaliseMenu(QMenu *menu)
    QSignalMapper *mapper = new QSignalMapper(this);

    connect(mapper, SIGNAL(mapped(QObject *)),
            this, SLOT(menuActionMapperInvoked(QObject *)));

    foreach (QAction *a, menu->actions()) {
        QKeySequence sc = a->shortcut();
        if (sc.count() == 1 && !(sc[0] & Qt::KeyboardModifierMask)) {
            QShortcut *newSc = new QShortcut(sc, a->parentWidget());
            QObject::connect(newSc, SIGNAL(activated()), mapper, SLOT(map()));
            mapper->setMapping(newSc, a);

void MainWindow::menuActionMapperInvoked(QObject *o)
    QAction *a = qobject_cast<QAction *>(o);
    if (a && a->isEnabled()) {

I then call finaliseMenu on each of the menus returned by findChildren<QMenu *> from the main window’s menuBar() object.

There may be a simpler way: let me know if you can see one.


Undergraduate programming languages

I read two quite different articles about programming in academia today.

I don’t know Yossi Kreinin, and when his piece Why bad scientific code beats code following “best practices” appeared on the Hacker News front page, I guessed that I probably wouldn’t agree with it. I’m a programmer working in academia who has spent some time trying to find ways to improve the code that researchers write, and I don’t want to be told I’m wasting my time.

But on the whole I agreed with him. A totally naive programmer is going to produce messy, organic, but basically linear code that will usually be easier to understand and work with than the code of someone who has learned a bit of Java and wants to put everything in a factory class. The part I don’t agree with of course, and that I suspect he put in just for the sake of the headline, is that these really are best practices.

I think that one of the hidden goals of a project like Software Carpentry is to teach that the reason software developers appear to be “too clever”, and somehow unreachable for the scientist outside the software field, is that they are being too clever. Programming gets over-complicated; you can learn to write good code (that is, readable code) more easily than you can learn to write bad code the professional programmers’ way.

I also identified with Yossi’s line that “I claim to have repented, mostly”. Most of the code I’ve written in my career is not very good, by this standard. It’s a long path to enlightenment.

The other article was by my friend Christophe Rhodes: What is a good language to teach at undergraduate level for Computing degrees?

A computing degree is an odd thing. Computer science is the theory of how computers and programs work. Computing, as a subject, is computer science plus some stuff about how we should actually program them in order to get a job done. The two are very different.

Christophe breaks down objectives of a computing degree: Think, experiment, job, career, study, society. I’m not very familiar with the study objective, which refers to postgraduate study in a computing department (something I never did). Think refers to teaching students how to think and solve problems computationally. I think he may be missing a step, and it may be useful to separate thinking about how the computer works (“understand”?) from thinking about how the programmer can work.

There is also, of course, the question of how to avoid making your programmer feel too clever.

As an undergraduate in 1990-94, I was taught, in this order, Prolog, C, ML, 68k assembly language, and C++. I also learned some Lisp, though I can’t remember being formally taught it. Prolog, C, and the assembly language were all good bases for what I referred to as the understand objective, getting something out of the history of computing and learning about how computers work. ML was a wonderful introduction to thinking, and it’s no coincidence that I’ve recently been programming in an ML variant as an engaging alternative to work.

The hard one to evaluate is C++. It was a very poor teaching language for object-oriented programming, which is a pity because at the time we learned it, I didn’t get object-oriented programming at all. And we learned nothing about any other kind of programming from it, having already been taught three different high-level languages. So it contributed very poorly to the think objective and not at all to the understand one. It’s an awful language to learn to write clear, reliable code in, therefore bad from the society perspective, and you can (as I have) spend 20 years learning to write it, which is obviously ridiculous, hence you would think also bad from the job perspective.

But it turns out that C++ has been the most valuable job language there could be, because (a) it is resiliently portable: it turns out that write-once-run-anywhere with a virtual machine comes and goes in waves, depending on the whim of the top operating system provider of the time, but compiling to machine code seems to be eternal; (b) it is just about able to ape a number of programming paradigms, so you can get away with adopting a style without adopting another language; and (c) its complexity means that it looks good on your CV. I honestly wish, as a 20+-year C++ programmer, that we could make it so that nobody ever had to learn C++ again, but even now I don’t think that is the case.

The one goal completely unaddressed by my own degree, and almost every language I’ve learned since, is experiment. I think there are two essentials for this: a responsive interactive interpreter, and visual responsiveness, like a graphical scene environment or plotting tools. Most of the things you want to do here are probably growing up in Javascript and HTML5.

I don’t really know anything about teaching, about the actual on-the-ground business of making people learn stuff. So you shouldn’t listen to me on this next bit, I’m just daydreaming. But if I were planning a 3-year computing degree course in my head now, I think I would aim to teach, in this order:

  • Python, for the basics of procedural computing. It’s the cleanest language for doing satisfying simple loops and input/output transformations, and is a sound general-purpose language.
  • Clojure. I’ve decided now that I don’t so much care for Lisp syntax day-to-day, but a Lisp gives you so much to talk about and investigate without getting lost in the specific requirements of the language. And a Lisp on the JVM gives you more depth: advanced students could learn quite a lot about Java without ever actually being taught Java.
  • Some assembly language, probably ARM and preferably with a nice visible bit of circuit board on hand.
  • Javascript, but not aiming to teach the language so much as using a specific interactive framework and with a specific small game-development project to complete. I would probably also use Typescript rather than untyped Javascript.
  • Haskell. As an ML guy it was always my enemy, but Haskell is the functional language that has endured. It’s a follow-on course from Lisp.
  • C++. Because, as far as I can see at the moment, you pretty much have to. But please, give them modern-style pointer ownership and RAII (i.e. avoiding explicit heap allocation).
  • Python again, in a closing course that taught people how best to do things in an actual working environment. Testing, not being too much of a smartarse, etc.

But the odd thing about that set of languages is that, just as with my own degree, you never get a very good dedicated object-oriented language. Maybe Objective-C could replace C++; it’s probably a clearer pedagogical object language, but C++ is everywhere while Objective-C is effectively platform-specific, even if it is a very popular platform.

And be sure to teach them version control.

Oh, and don’t forget to add a double-entry book-keeping course. It’s probably more useful than the programming stuff.


T40p, T60p, T540p, go!

I recently replaced my desktop machine at work with a Thinkpad T540p.

T540pThis laptop has had some bad reviews online: terrible trackpad, keyboard a great disappointment, Windows drivers problems, not the proper colour for a Thinkpad (it’s dark grey instead of black), installing Linux will brick it.

I read a few of these and did hesitate. On the one hand, bad reviews and all that. On the other, a matt-finish retina-resolution 15″ screen.

The screen and keyboard are the most important things about a computer. Some people clearly disliked this keyboard, but it’s still a Thinkpad and their reputation is still pretty good. Worth taking the risk, I thought.

So we ordered one with the 3K (i.e. high-resolution) screen and the upgraded keyboard option. I deleted Windows and installed Arch Linux, and didn’t brick it in the process. And it’s a terrific computer. The screen really is splendid. The keyboard is quite heavy, which I like, and is asymmetrically placed, which others seem to have a problem with but hasn’t bothered me. And it’s fast and quiet, tough, and relatively cheap by the standards of new T-series laptops.

This is the first new computer for years I really look forward to using: finally a good successor to the older T40p and T60p series.

There’s one caveat, where I agree with all the reviews: the trackpad is indeed awful. It looks good, it’s got a nice soft smooth finish and it’s fine for moving the pointer, but it has a whole-button design with a nasty twist: you have to push the whole pad about a millimetre before it registers. It’s impossible to do it without moving the cursor, and click-drag is out of the question. If you prefer using the Trackpoint in the middle of the keyboard, well forget that too: the only buttons are built in to the trackpad and consequently useless.

But this is a big laptop, and you’re probably using it in a space where a mouse is OK anyway. Get one of the Microsoft Arc Touch mice that fold flat, and forget the trackpad ever happened.

Proprietary Unix

From 1992 to 1998, every paid job I did came with a Unix workstation on my desk. Admittedly that only covers three employers, but it covers a lot of different kinds of workstation.

In those days, selling Unix software (unless you could dictate the hardware as well) involved a lot of porting, and companies would build up a library of different workstations to port and test on. A bit like Android development nowadays, but much more expensive.

At some point I used, or had in the rooms around me, machines running

  • Silicon Graphics IRIX on MIPS processors (the SGI Indigo and Indy—the natty coloured boxes)
  • Sun Solaris on SPARC (with my favourite keyboards, the Sun Type 5)
  • SunOS 4 on Motorola 68K (immense single-bit-depth mono screens)
  • DEC Ultrix on MIPS, and OSF/1 on Alpha (everyone wanted the Alpha)
  • SCO Unix on Intel x86 (nobody wanted that)
  • Hewlett-Packard HP-UX on HP Precision Architecture (nice hardware, didn’t enjoy the OS)
  • Data General DG/UX on AViiON (not a very likeable machine)
  • IBM AIX on POWER architecture (fast, though I was never into the rattly keyboards)
  • and a System V implementation from Godrej & Boyce of India running on Intel i860

That was up to 1998.

From 1999 to 2014, every paid job I’ve done—other than excursions into Windows for specific bits of work—has come with an Intel PC running Linux on my desk.

I suppose proprietary Unix workstations made something of a comeback in the shape of Apple’s Mac Pro line with OS/X. I think of the dustbin-shaped Mac Pro as a successor to SGI workstations like the Indy and O2: the sort of thing you would want to have on your desk, even if it wasn’t strictly what you needed to get the job done.

Small phones will rise again!

In 2007 Apple launched the iPhone. It was a fancy phone, but big and heavy by the standards of the time.

For the first few years after that, it seemed to be generally accepted that the iPhone was big. Even by 2010 commentators were writing things like “Apple has to expand its product range [with] a nano model … give it a modestly smaller screen than the iPhone 4, ie 3.2 inches.”

In time, other companies started making Android phones with even bigger screens. Perhaps they were working on the hi-fi shop principle that if you play it a bit louder, listeners will think it sounds better. Commentators supplied compelling arguments why Apple would never follow suit: you wouldn’t be able to reach the edges of the screen while holding it one-handed.

In 2011, the Google and Samsung flagship Android phone was launched with a surely ludicrous 4.65 inch diagonal, and iPhone users mocked it (“That’s no moon. It’s a phone”).

Time passed. In November 2013, The Verge opened a review of a Nokia Windows Phone with: “Three years ago, Nokia shipped over 110 million smartphones worldwide. None had a display larger than 3.5 inches. Today the company moves far fewer smartphones, every single one of them with a display bigger than its largest option in 2010.”

In January 2014, Sony launched its Xperia Z1 Compact, a new device promoted as being pleasingly small. It had a 4.3-inch-diagonal screen.


The most distinctive feature of a mobile phone is that it’s mobile. You can carry it anywhere.

No matter how engaging the experience or how captivated you are, you’re never going to spend as much time poking at your phone as you do just carrying it around. The main thing a phone has to do is sit in a pocket and shut the hell up without making you constantly aware that it’s there. Small is good.

I recently retired my Nokia 700, a Symbian-powered phone with a 3.2″ screen. With the Swype keyboard it was nicely usable, but Nokia had started shutting down many of the Symbian services. I would love to have been able to keep using that hardware with a different OS, but that’s impossible with these devices.

I’ve been testing a FirefoxOS device and I’d like to be able to switch to that—but the smaller FirefoxOS phones have pretty ropey hardware (nasty screen, awful camera) and the only other one available now is too big. I’d have been happy with a device no bigger than a Keon but with a better screen and camera.

Apple have stayed pretty sensible: the iPhone did go a 3.5 to a 4″ screen, but it got thinner and lighter at the same time. But I don’t want an iPhone.

(I ended up buying a lightly-used Nokia 620, a nice enough phone with Windows Phone 8 and a 3.8″ screen. It’s a year old and I think it’s technically been discontinued in favour of larger models. It’s still a bit too big, but it’s the best I could do.)


SoundSoftware tutorial at AES 53

I’ll be co-presenting the first tutorial session at the Audio Engineering Society 53rd Conference on Semantic Audio, this weekend.

(It’s the society’s 53rd Conference, and it happens to be about semantic audio. It’s not their 53rd conference about semantic audio. In fact it’s their second: that was also the theme of the AES 42nd Conference in 2011.

What is semantic audio? Good question, glad you asked. I believe it refers to extraction or estimation of any semantic material from audio, including speech recognition and music information retrieval.)

My tutorial, for the SoundSoftware project, is about developing better and more reliable software during research work. That’s a very deep subject, so at best we’ll barely hint at a few techniques during one programming exercise:

  • making readable experimental code using the IPython Notebook, and sharing code for review with colleagues and supervisors;
  • using version control software to manage revisions and escape disaster;
  • modularising and testing any code that can be used in more than one experiment;
  • packaging, publishing, and licensing code;
  • and the motivations for doing the above.

We presented a session at the Digital Audio Effects (DAFx) conference in 2012 which covered much of this material in presentation style, and a tutorial at the International Society for Music Information Retrieval (ISMIR) in 2012 which featured a “live” example of test-driven development in research software. You can find videos and slides from those tutorials here. The theme of this one is similar, and I’ll be reusing some code from the ISMIR tutorial, but I hope we can make this one a bit more hands-on.