Category Archives: General

Paraphernalia and chaos.

Marin Bobcat Trail bike maintenance

I just spent a few days overhauling my aging mountain bike. It was an interesting (and at times frustrating) process, partly due to this being the first time I’ve done anything like it, and partly due to the apparent lack of maintenance manuals for the bike or many of its components. I thought it might be useful to put together a brief Marin Bobcat Trail maintenance manual, in the hope it’s useful to someone else who owns the 2008 or 2009 edition of the bike. I’m new to this, so it’s probably a laughable effort in cycling circles, but it’ll be useful to me next time I overhaul the bike anyway. Feedback welcome at the address given in the document!

Weston frame buffer backend

Just over a week ago everyone’s favourite Xorg replacement, Weston, gained a frame buffer backend I put together as part of some university work. It was remarkably easy to write, since almost all of the code already existed in the DRM and RPI backends; I just needed to hook pixman up to /dev/fb0 and everything worked!

Weston’s code base was a pleasure to work on. Hopefully someone stuck on a frame buffer somewhere finds this work useful. Since I did this work, I also got the frame buffer backend working on FreeBSD (as part of the same university project), but haven’t had time to update, tidy up and submit my patches yet. They’re pretty hacky in (many) places.

Without further ado, a gratuitous flowery screenshot (taken using fbcat):

Weston running on a Linux frame buffer, taken on 2013-01-15.

Weston running on a Linux frame buffer, taken on 2013-01-15.

Adventures with an ATmega

As part of some university coursework, I’ve recently been playing around with an Atmel 8-bit microcontroller in a quest to build a data logger for home brewing. The aim is to log various sensor readings over the course of primary fermentation of a batch of beer to see how it’s progressing without having to disturb the brew.

While working with hardware is fun, it has the downside that you’re working with hardware. Things break as much as they do in software, but are harder to debug. A nice solution to this is to use a simulator to test the software, rather than using the hardware itself. I’ve been using the simavr simulator. It’s got all the right features, but more importantly its code is easy to understand and extend. In fact, most of the simulator is written as a library which one can build a simulated circuit board around.

I’ve built simulations of several of the components used in the brewing logger now, including an SD card and a flash memory. The code isn’t brilliant, but they’re working well enough to get my firmware booting. Hopefully they might be useful to other people too — hence the code is on gitorious. The SD card simulator is for a generic SDv2 card. The flash memory is for an ST M25P16 (but should support any of the M25P family, with a little work). The serial LCD is for a custom LCD daughter board provided by my university, so that’s probably not so useful. The RHT03 temperature/humidity sensor is general purpose; as is the DS3231 real-time clock.

Put together, and with a little extra work, these will allow closed loop testing of the microcontroller firmware — without ever having to go near the hardware itself. Bliss. (This is all under the misguided assumption that the simulations are sound and complete, but they’ll get there eventually.)

As an example of how easy simavr makes this, take a look at the code needed to instantiate and hook up the humidity sensor simulation:

/* Create the sensor. */
rht03_t rht03;
rht03_init (avr, &rht03);

/* Connect its bidirectional data pin to pin D3 on the microcontroller. */
avr_connect_irq (avr_io_getirq (avr, AVR_IOCTL_IOPORT_GETIRQ ('D'), 3), rht03.irq + IRQ_RHT03_DATA);
avr_connect_irq (rht03.irq + IRQ_RHT03_DATA, avr_io_getirq (avr, AVR_IOCTL_IOPORT_GETIRQ ('D'), 3));

Interaction in team projects

I had an interesting experience over the summer, working in a small but diverse team on a single project for several months. I was contracted to design and maintain the build system, and so ended up getting involved in all areas of the project. As a result, I came across many of the problems which my team mates were having. A lot of these problems were my fault, some were my team mates’ faults; but a lot of the problems were a result of bad communication.

While this all occurred in a (unfortunately) closed source project, I’ve seen similar things happen in open source. I thought I’d come up with a list of suggestions for people starting out in the open source world, to try and help them understand the best way to interact with other people on the same project, or with their mentors in GSoC (for example). None of this is targeted at anyone in particular (especially not the GSoC students I had the pleasure of interacting with this summer)!

Thinking about this has been useful to me; hopefully I won’t do any of these things in future (because I certainly have in the past). I just hope it’s useful to someone, somewhere.

  • Don’t spam chats with half-written messages. Take your time and formulate your thoughts properly in a full sentence. Spamming messages just means the other conversant has to sit there and wait for the rest of the sentence, rather than getting on with something else.
  • Don’t join a chat, say “hi” or “someone please help” or “ping” and then sit there without giving more information. This just introduces an extraneous round trip in communication, since someone has to then ask what the problem is before they can start to help. Conversely, if someone joins a chat and says “someone please help”, don’t lecture them about it. Be patient, and help them as much as you can.
  • After asking a question in a chat, wait patiently for the answer to the question. Although they’d love to help, developers are not constantly looking at their chat client. If you leave a fully-formed question in the chat and then wait, a developer should answer in their own time.
  • If you encounter an error or warning (e.g. from a compiler or program) and want help with it, always provide the full error message and some context. The person who’s helping you isn’t psychic.
  • Always give context and be careful of over-using pronouns. “It’s running awfully slow” is not specific enough. What is ‘it’? What were you doing with ‘it’ when things slowed down?
  • Look at man pages and --help output before asking people. Documentation for established software (e.g. SVN) is generally quite good. The person who’s helping you will probably just look at the man page anyway.
  • Read VCS commit logs. Ideally, people will explain and justify all of their work in their commit messages, and mention things which you should be aware of. Reading the logs may well save you debugging later.
  • Use the correct terminology as much as possible, and don’t use that terminology in other contexts where it could confuse matters. Communication is a lot faster if a common vocabulary is used.
  • Learn your version control system and learn it well. It’s a tool you’ll be using every day, and making mistakes with it can be costly for your (uncommitted) work and/or for other people’s productivity. Always check the changes you’re about to commit, especially if conflicts have occurred. People will not take kindly to their work being overwritten because you’ve made a mistake, especially if it happens regularly.
  • If you’re making use of someone else’s code/APIs and you have a problem or can’t get it working, double check (against the documentation which they have written) that you’re using the code correctly. In many cases, the problem might be the way you’re invoking/using that code, not the work itself (thought such problems do suggest a lack of user friendliness in the work which could be fixed).
  • Always check to see if the code at least compiles before committing it to VCS. Committing something which doesn’t compile due to a trivial error shows a complete lack of testing or care. Compile it using the build system which everyone else uses, too. Manually invoking the compiler doesn’t count.

More festive drinks

It turns out that stuffing my failure of an apricot liqueur full of spices has worked, and I now have a bottle of tasty festive spicy apricot vodka. Here's the recipe in full:

Ingredients

  • 300g dried apricots
  • 700ml vodka
  • 1 large cinnamon stick
  • Rind of 1 orange
  • 2 blades mace
  • 4 cloves
  • 8 juniper berries
  • ~200g granulated sugar

Method

  1. Submerge the dried apricots in boiling water and leave them overnight to re-inflate. I had to do this because I could only buy dried apricots, but I guess an equivalent mass of fresh apricots would work.
  2. Split the apricots into halves and put them into a 1.5l plastic bottle (an empty water bottle is perfect) with a cinnamon stick and the vodka. It's better to put the apricots in first so that they don't splash.
  3. Seal the bottle well and shake it.
  4. Leave the bottle in a cool, dark place for around four weeks, shaking it every day. The precise amount of time you leave the mixture to infuse doesn’t really matter, as long as it’s more than about three weeks. Try to avoid opening the bottle during this time, as that’ll introduce contaminants.
  5. After the mixture has infused for a suitable amount of time, filter it out into another bottle. This might take a day or longer, depending on your filter paper. Use fine filter paper (coffee filter papers worked well for me), and be prepared to use several filter papers, as they will get clogged up. Keep the apricots!
  6. Once filtering is complete, add sugar to the filtered liquid to taste. 200g should be about right (I used 225g this time, and it was a little too sweet). Add the cinnamon stick again (or use a fresh one), and the orange rind, mace blades, cloves and juniper berries. Seal the bottle up again and leave it for at least another two weeks, shaking it daily.
  7. After at least two weeks, filter it again. This should take a lot less time, as most of the fine sediment will have been removed during the first filtration.
  8. Drink and enjoy! The recipe produces about 700ml of spiced apricot vodka. The apricots left over from filtration are nice in a pie, though they will have lost a lot of their flavour (more so than the raspberries).

I'm sure it would be quite possible to infuse the vodka with the apricots and spices at the same time, but I didn't try this, so I can't be sure. Another thing I probably should've done is added the sugar after infusing the vodka with the spices, as that would've allowed it to be added to taste. As it was, I added what I guessed was the right amount and fortunately it turned out well.

While not busy playing around with drinks, I've got around to finishing off and releasing libgdata 0.8.0. This vastly improves upload and downloads via streaming I/O, as well as fixing a lot of race conditions, leaks and cancellation problems. This release doesn't introduce much new functionality, but breaks a lot of API, hopefully for the better.

Festive drinks

Earlier in the year, I experimented with making fruit liqueur at home; I made a bottle of raspberry vodka with great success. Seeking to repeat the success and add some variety, I recently tried making apricot vodka (with the intent to have it ready for Christmas and the New Year). Unfortunately, I failed. It turns out that apricots don't have enough flavour in them to overcome the taste of vodka, and so I've ended up with pale yellow coloured bleach. I'm now attempting to rescue it by ramming it full of spices.

I realise it's a little late now for anybody who's interested in making this for Christmas, but if anyone fancies making it some other time, here's the (successful, at least in my opinion) recipe for raspberry vodka. It takes three weeks or more to do. A good recipe for apricot vodka is left as an exercise for the reader.

Ingredients

  • 675g fresh raspberries
  • ~1tbsp lemon juice
  • 700ml vodka
  • ~250g granulated sugar

Method

  1. Slightly crush the raspberries and put them into a 1.5l plastic bottle (an empty water bottle is perfect) with the lemon juice and vodka. It's better to put the raspberries in first so that they don't splash.
  2. Seal the bottle well and shake it.
  3. Leave the bottle in a cool, dark place for around four weeks, shaking it every day. The precise amount of time you leave the mixture to infuse doesn't really matter, as long as it's more than about three weeks. Try to avoid opening the bottle during this time, as that'll introduce contaminants.
  4. After the mixture has infused for a suitable amount of time, filter it out into another bottle. This might take a day or longer, depending on your filter paper. Use fine filter paper (coffee filter papers worked well for me), and be prepared to use several filter papers, as they will get clogged up. Keep the raspberries!
  5. Once filtering is complete, add sugar to the filtered liquid to taste. 250g makes it fairly sweet, so you could quite easily use less. If you're not sure, add it gradually, since it only takes a few tens of minutes (and some shaking) to dissolve.
  6. Drink and enjoy! The recipe produces just under 1l of raspberry vodka. The raspberries left over from filtration are excellent when eaten with cream or ice cream.

I can't take much credit for this, as it's based on a recipe I found here: http://www.guntheranderson.com/liqueurs/raspberr.htm. I made some alterations, though, such as doubling the ratio of raspberries to vodka. Fortunately, they seem to have worked out well.

In other news, libgdata's API documentation is now available on library.gnome.org! Thanks to Frédéric Péters for getting this sorted out.

End of the summer

It's come to the end of the summer, and the end of my internship with Collabora. They've enabled me to spend three months helping work on adding meta-contacts support to Empathy in the form of libfolks; something which I've thoroughly enjoyed. Thank you to all my friends and colleagues at Collabora for letting me do this!

Term starts at university for me again in the next few weeks, so I expect to disappear back into the world of degree-enabling work, but I hope to be able to poke my head up from my little hole every so often, and possibly even submit a patch or two.

Git commit hooks

I recently wrote/extended a couple of git commit hooks which have turned out to be rather useful. Once is a fairly standard commit-msg hook to check the format of the first line of a commit message is either "Release version x.y.z", "[tag] Message" or "Bug 123456 — Title":

tags="core|atom|gd|media|build|docs|tests|calendar|contacts|documents|picasaweb|youtube"
test "" != "$(grep -P '^(Release version [0-9]+.[0-9]+.[0-9]+|

\[\]

[\S].+[\S]|Bug [0-9]+ — [\S].+[\S])$' "$1")" || { echo -e >&2 "First line of commit message should be in one of the following formats:\n * 'Bug 123456 — Title'\n * '[tag] Message'\ \n * 'Release version x.y.z'\nValid tags are:\n * ${tags//|/\n * }" exit 1 }

Just define the tags your project allows in the tags variable, separated only by pipes.

The other hook is a pre-commit hook to ensure any new API has a Since: tag if it's got a gtk-doc comment. It's implemented as a modification of the sample pre-commit hook, so here's the diff:

--- /home/philip/Downloads/4m8QcjYs.txt    2010-03-28 19:14:50.432440248 +0100
+++ pre-commit    2010-03-22 20:37:47.612794352 +0000
 my $filename;
 my $reported_filename = "";
 my $lineno;
+    my $in_gtk_doc_comment = 0;
+    my $used_since_tag = 0;
 sub bad_line {
 my ($why, $line) = @_;
 if (!$found_bad) {
@@ -64,6 +68,19 @@
 if (/^([<>])\1{6} |^={7}$/) {
 bad_line("unresolved merge conflict", $_);
 }
+        if (/^\s*\/\*\*$/) {
+        $in_gtk_doc_comment = 1;
+        $used_since_tag = 0;
+        }
+        if ($in_gtk_doc_comment && /^\s*\*\*\/$/) {
+        $in_gtk_doc_comment = 0;
+        if (!$used_since_tag) {
+            bad_line("new gtk-doc commented API without a Since: tag", $_);
+        }
+        }
+        if ($in_gtk_doc_comment && /\*\s+Since:\s+[0-9]+.[0-9]+.[0-9]+$/) {
+        $used_since_tag = 1;
+        }
 }
 }
 exit($found_bad);

It looks for the start of a gtk-doc comment block in any added code, and errors if it doesn't find a Since: tag before the end.

Hopefully these'll be useful to somebody. They've both turned out to be more useful to me than I'd hoped, so hopefully my commit messages make a little more sense now. The code for both of them is in the public domain.

Introspectable libgdata

Now that full term at university has finished, I have a little free time (inbetween sleeping, doing all the holiday work, and that celebration thing that people seem to do) to spend on projects. Today, I got round to adding GObject introspection support to libgdata. I think some of the Makefile changes I made were a little hacky, but they seem to work. If anyone wants to use libgdata from an interpreted language which has GIR support, it should now be possible.

In university news, things have gone well this term, and I managed to (precariously) stay on top of the rolling mountain of work. I've now got two weeks' stay in Cambridge to help shepherd interviewees around for their application interviews before I go home and do Christmassy things.

It took me until about half way through the term to notice that I was actually walking past Collabora's UK office every morning (opposite King's College). It was quite a shock when I noticed. It was also a shock to see they weren't at the computer lab's recent careers fair. Perhaps missing a trick there?

University happenings

One of the lovely Austrian trains.

One of the lovely Austrian trains.

It's the end of a busy summer and I've just stumbled over the finishing line with some (very) late patches to Totem for the 2.28 release. Let's hope it's a good one.

This horrendous timing on my behalf for getting around to doing these patches is mainly due to tacking an InterRail trip onto the end of my busiest summer ever. Ten days travelling around sunny Europe with friends went surprisingly well, with only one person attempting to rob us. The highlight of the trip had to be the Austrian train system: easily the best out of the ones we used (French, German, Austrian, Dutch and Belgian). Photos of the trip are up on my PicasaWeb account.

And now for something completely different: university! I've got just under two weeks left before I leave to start my BA in computer science at Gonville and Caius college, Cambridge. The pile of stuff to take with me is starting to grow, all my computers are reinstalled with Fedora (which should hopefully last for three years without needing too much time spent on keeping it going), and most of my former schoolmates have already left for their respective universities.

I don't know how much time I'll have for GNOME stuff — I'll have to see how the workload is when I get there. It is, however, at the top of my free time priority list, along with learning all the funny language Cambridge has for things, punting, debating and drinking Pimm's. OK, I was kidding about the last three.