When working on Telepathy, I've often wanted to be see which D-Bus methods are being called on whom, when signals are emitted, and so on. Timing information is also handy: I'd like to figure out why cold-starting Empathy takes 12 seconds, and it'd be much easier if I could look at a diagram rather than staring at the unreadable output of dbus-monitor.

Previously, Alban wrote a tool that used a patched version of mscgen, and produced appropriate input with a dbus-monitor-like Python script. I wanted some more D-Bus-specific diagrams, and ended up reimplementing both the monitoring component (by forking dbus-monitor, as its --profile output did not contain quite enough information) and the diagram-drawing component (using Cairo). I'm happy to present an initial release of Bustle:

There's a Telepathy-specific hack in the tool to shorten object paths, but it shouldn't make the tool any less useful for looking at other D-Bus traffic.

I haven't made binary packages yet, I'm afraid, so you'll need to grab the source tarball and build it if you want to try it out. In Debian-land, the dependencies are libdbus-1-dev libglib2.0-dev libghc6-mtl-dev libghc6-cairo-dev libghc6-gtk-dev libghc6-parsec-dev; see README in the source tree for how to build and use it.

The astute among you may have noticed from the dependencies that the diagram-building component is implemented in Haskell, using the excellent bindings to Gtk+ and Cairo. I got a prototype going within a few hours, and the strong correctness guarantees that the type system provides meant that I could refactor it mercilessly with confidence. I'm sure that I would have spent many frustrating hours chasing type bugs had I written it in Python, which is a more conventional high-level language for prototyping and writing tools like this. Next time you're frustrated by such bugs, you should give Haskell a try. :-)

Edit: Bustle now lives at willthompson.co.uk/bustle.

My college's computer room has a printer I like to use to turn bits into dead trees. The computer there don't have Postscript viewers, which is a Right Pain in the Arse.

So I just wrote a proxy-type thing that, if fed the URL of a Postscript file, runs it through ps2pdf and gives you the resulting PDF. For extra bonus points, if you feed it a random HTML URL, it rewrites the links within the page to go back through itself, then serves up the page. So I can feed the Comlab internal web page through it and happily print out the exam papers that I want for revision porpoises.

I had to password-protect my live copy, otherwise random people would be able to get to ox.ac.uk-internal pages. But you can grab the code, licensed under the WTFPL, with:

darcs get http://salami.ox.compsoc.net/~resiak/darcs/ps2pdf

If you're an .ox.ac.uk person and want to use it, prod me and I'll see about depasswording the live copy for IPs within the university.

So I have my calculator written in Java, using Swing. There are four logical components there: the stack, the history, the display, and the keypad. So obviously I have created four Swing components, to stop the Window class from being cluttered with where the hell the buttons all are. Cool.

Now we're meant to be adapting an XML UI description language (like Glade) so we can avoid hard-coding the interface. We're meant to make a custom "Display" component, and add an element to the XML dialect for it. Okay, that's easy --- I already have one. But if I now make a <keypad> element, and so on, my XML description of the UI will be about four lines long. This is sub-optimal, because I have not avoided the hard-codage. So I think that I will have to break keypad et al. out of their little abstracted homes so that I can complete the practical.

Oh, yes, I could augment the UI-description-to-actual-real-live-widgets fu so that it can read separate XML files for the custom components, but that's far more work and is overkill. Yay for having to deliberately undo abstractions I have created (in the spirit of the course (OOP)) to make the practical, erm, practical.

So I am creating a snogweb site for imsoc, on which lovely SVG representations of undirected graphs of people who have exchanged oral juices will exist, such as this one, and on which people can add new links to the web. A paper one currently exists, but paper is so last century, etc.

Obviously, this diagram will have to be updated whenever links are added to the graph. However, I'm planning to allow people to see other things, such as a graph of n links away from them, and shortest path graphs to $other_person, so there are going to be lots of graphs. Now, I could just draw these graphs as requested, via my handy Perl script, but it'd be cooler to cache them. My question to the dear lazyweb is as follows:

Is it worth trying to figure out some way of allowing the img tags to point directly at SVGs, rather than at a Perl script that creates it if necessary but then basically act as cat(1)? The latter involves forking a new Perl process every time, unless I invoke the magic of mod_perl, which would solve the problem but is not a great deal of fun. Is there some way I can use mod_rewrite to rewrite a URL to a file if it exists, and to a Perl script if it does not?

Or am I overcomplicating things?