Actually the reason I wanted to come is to attend the GObject introspection hackfest starting on Tuesday. But the GNOME Foundation decided if we were coming to Berlin anyway, the hackfest participants should come a few days earlier and attend the talk on the weekend.

It’s great to be in Berlin for a few more days, and during the talks I’ve already started hacking on PyGObject in preparation for next week.

I also love that my employer, Prezi, has given me the whole week to attend the summit and hackfest. Visiting conferences is one of the perks of working at Prezi. Even though the Desktop Summit has little direct connection to my work there, they are paying me to go anyway.

Prezi is almost certainly the best place to work at in all of Hungary, and probably most of eastern Europe too. If you’re interested in working in Budapest, we are hiring.

There are plenty of clipboard managers for Gnome, but this is the one I started using. And I like it enough that I don’t care to switch. But as a Gnome panel applet, Glipper does not work with Ubuntu’s Unity or Gnome Shell. Since it is written in Python, I figured it wouldn’t be too difficult to fix this.

Glipper 1.0 is a Gnome panel applet and has not been updated since 2007. After asking on the mailing list, I was able to get permission to take over maintenance. The sourceforge page was closed down, and I put everything on Launchpad. I moved the code to Bazaar and started cleaning up the code.

After removing the custom C code to bind global key presses (using python-keybinder instead), I was able to remove autotools and replace it with distutils. I then removed the deprecated Gnome libraries and Gnome applet code, and used Ubuntu’s appindicator library instead. This was really straight forward because appindicator accepts a Gtk.Menu, which Glipper was already using for the applet menu.

Last week I made a release on Launchpad, and figured out how to build a deb package. It was my first, and using distutils made it really simple. I made a PPA, and yesterday I requested that it be put in Natty.

Interestingly, when I asked for help to get it pushed into Natty, it was Martin Pitt (who I met at the PyGObject hackfest) who approved the feature freeze exception. And it was my old friend Daniel Holbach who did the actual packaging and upload. That dholbach; how is he everywhere all at once?

Unfortunately the new Glipper only works on Ubuntu or distributions with appindicator support (are there any but Ubuntu?). The Gnome Shell developers have not yet provided a way to make little menus in the panel of the shell. When they do I will try to have Glipper support it right away.

So there you go folks. You can find Glipper 2.0 in Natty universe. Maverick users can use the PPA. The source release is also available.

All of us who attended are really thankful for Collabora paying for the usual bits, as well as our beers for the week and a traditional Czech duck dinner on the Thursday evening. I don’t think the beer expenses came out to too much because beer is really cheap in Prague and we spent most of the time working and not drinking. Nonetheless Collabora was willing to pay for whatever we drank, and the dinner too, which was absolutely delicious.

The hackfest was at BRMLab, a local hardware hacking club, and although hard to find, was a comfortable space with good internet and a great place to get work done. It was really nice meeting so many cool hackers and talk about all sorts of interesting things over dinner every night.

How I spent my time at the hackfest

I asked to attend the hackfest when J5 asked on his blog for application developers to attend. The week before the hackfest I started porting Jokosher and asking about issues on IRC. By the time the hackfest started I had met a couple of the hackers on IRC, and was getting familiar with the how the introspection bindings worked.

The first three days of the hackfest I worked on Jokosher. It was really useful having Tomeu and J5 in the same room. When I came across issues, I could ask them right there. I quickly figured out that Cairo isn’t going to be wrapped, and so static bindings for cairo should be used. In addition, GStreamer support is lacking, but it isn’t so crucial at the moment because they develop their static bindings separately. The GStreamer Python bindings will still be available for the next major release, unlike with PyGTK, where there will be no static Python bindings for Gtk 3.0.

So for those three days I concentrated only on porting Gtk, and making sure it worked with Jokosher. After getting my patches reviewed and committing them all on Wednesday I was looking for something to do for the last two days. I had run into a few problems with drawing callbacks using Gtk 3 and introspection, and I wanted to work on something less specific to Jokosher and more generally useful.

Improving startup time

At dinner someone mentioned that right now startup time with introspection is way slower than with the static bindings, even though in theory it should be quicker, because most classes are only loaded when they are accessed, and not at startup. I said I’d look into it.

On Thursday hooked up Python’s hotshot profiler and figured out where the slowest parts of the code were. It turned out that most of the time during import was spent in only two functions, both of which were responsible for setting up virtual methods. Both were also recursive, which explained why they took so much time.

In the end, I removed most of the recursion in both functions (one of them will still recurse in the case of an interface virtual method), and managed to reduce the import time with Gtk 3 from 2.5 seconds to 0.4 seconds. That is timed on my computer, with a warm startup (everything still in kernel cache). But regarless, the startup time is now slightly faster than the static bindings for either cold or warm starts.

I managed to grab a power socket on my train back to Budapest to Prague on Saturday, and cleaned up my changes a bit. Then when everyone was back on Monday and Tuesday, I got both my patches committed. If J5 also finishes up his invoke rewrite branch soon, the next release of PyGObject introspection should be much faster.

I’ve already started porting Jokosher, but there is still a lot do to. I’m working on the easy stuff so far, and probably won’t get to the difficult bits until next week in Prague. But I’ve already found, and created patches for two simple bugs: one to identify the file that a dynamic module is loaded from, and another to list all the available attributes of the module. Both of these make it easier for me to use PyGObject in an interactive terminal; something I am doing a lot of while I am porting Jokosher and need to check the new method names.

I would like to thank the GNOME Foundation and the sponsors of this hackfest (especially Collabora) for funding the hackfest, and my attendance. I get a great opportunity to visit Prague and meet many really cool Python hackers. Thanks!

My GStreamer session went well. The IRC log is available online. I went through my slides which explained how to do a few simple things in Python. I used playbin2 to implement audio/video playback with pausing, seeking and position queries to update the slider. I was impressed how simple the code is; only 120 lines of Python.

I was less impressed with my Cairo session. Unlike with GStreamer, I couldn’t think up a clear use case that I could explain the solution to in under one hour. Instead I went through the very simple cairo API and showed how to use it with GTK or with PDF, PNG and SVG file formats. The IRC log and the code as online for this session as well. I did not make any slides.

Jokosher

This week Michael and I also released a new version of Jokosher. It is available on the download page on Launchpad even though the Jokosher website has not been updated yet.

Little has changed in this release so when we get around to changing the website there won’t be an announcement or anything. The reason for making this release was to get a bug fix out for a blocker which prevented Jokosher from running at all with newer versions of GTK. We wanted to get this done soon so it could be in the Ubuntu Lucid release, and the packaged version wouldn’t be broken. We also threw in a few other bug fixes while we were at it.

I’m down for some ice cream.

I’m up for some ice cream.

I could care less.

I couldn’t care less.

I filled in the form.

I filled out the form.

I finally got the time to get something I’ve been thinking about for a while down on paper (but not real paper of course), and my article discussing using undo on the desktop to reduce the annoyance of modal dialogs has been published in GeekDeck Issue 3, which was released today. Hope you enjoy it! Here’s a list of all the articles in this issue:

• Editor’s Letter
• Og looks at Foresight Linux
• Damien interviews OpenCandy CEO
• Why does society hate geeks?
• Are modal dialogs a thing of the past?
• Our feature on creating a Live CD
• Mark gets angry…Very angry
• Pete get’s something off his chest
• Is the Internet really so virtual anymore?
• The best bag in the business?
• Pete gets a break as Mark talks E3

laszlo@sescento:~$ sudo mount /dev/dvd1 /media/cdrom
mount: block device /dev/sr1 is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/sr1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Looking at the system log, shows the following message:

laszlo@sescento:~$ dmesg | tail
...
[588493.006569] UDF-fs: Filesystem marked read-only because writing to pseudooverwrite partition is not implemented.
[588493.214121] UDF-fs: No fileset found

After googling this problem for a while I found many Hardy users having this problem, and links to solutions which involve patching the filesystem driver and recompiling the kernel module. However I am running Jaunty, which was released just last month. It should have the latest driver necessary to read the new UDF format produced by Roxio.

After finding many Ubuntu Forums threads which were no help, I found a comment on this UDF format bug which apparently has been fixed in Intrepid. The comment mentions to make use of the “session” and “lastblock” mount options.

As the comment suggested, I tried running dvd+rw-mediainfo and getting the lastblock value of 1678800. The following command gave the same error message.

sudo mount /dev/scd1 /media/cdrom1 -t udf -o ro,user,noauto,exec,umask=0,session=0,lastblock=1678800

After playing around with this command for a while I figured out that 1678800 is one of the only values that doesn’t work. Specifying 0 or 1678800 or 1678801 causes the mount to fail. Specifying almost any other number allow the disc to be mounted and read. I can speculate that if the lastblock value seems valid, for example it is close to the end of the track it tries to use it. However with a value that is almost certainly wrong, it tries to search for the proper value. To me it still does not make sense why if the lastblock option is not specified, the disc cannot be mounted.

So for simplicity I will just use the value 1. Here is the command which allowed me to mount the disc successfully:

sudo mount /dev/scd1 /media/cdrom1 -t udf -o ro,user,noauto,exec,umask=0,session=0,lastblock=1

Now its time to listen to the music and watch the movies contained inside.

Carleton University’s Health Services and the university’s Administration continue to monitor the situation regarding Human Swine Influenza.

I did not realize we had human swine at our univeristy. Did a DNA splicing experiment in the biology department get out of hand? It’s good that health services is concerned for the well being of everyone including hybrid beings.

But as Håkon Wium Lie, the CTO of Opera once said:

…I’m no fan of either specification. Both are basically memory dumps with angle brackets around them.

He was talking specifically about the document formats competing for standarization at the time. More generally, he was talking about the whole idea of XML file formats. I remember thinking about Jokosher’s own file format after hearing this quote. It is an XML based format that I largely designed myself.

I will admit that our format is in a lot of ways a memory dump with angle brackes. The main nodes <Project>,<Instrument> and <Event> have the same name and structure as the classes that implement them. Each of these nodes also has a subnode called <Parameters> which is simply a list of the variable name, type and value of all the class variables. This only works well for simple data types; for list and dictionaries we have more complex structures.

In previous versions of Jokosher, I needed a easy way to store the very large list of volume levels used to draw the waveform. I figured that putting each number in its own XML node would take a lot longer to parse and consume much more memory than necessary so I created one simple node that looked like this:

<Levels value="0.911560058594,0.913299560547"/>


Imagine the above except with three thousand floating point levels, as is required for a typical five minute song. At this point it starts to get messy and stops looking like proper XML. It is also harder to decipher, and much more like a memory dump. Luckily the current version of Jokosher does not use this anymore. I stores the level data in a separate file that is just a raw dump of the bytes from the array.

Even though I have just shown Jokosher’s file format to be essentially a memory dump with angle brackets, I don’t feel bad about it. It makes our job as programmers easier, and the whole program is still simple enough that you can figure out most parts of the file format without documentation.

Today I had the chance to look at the file format used by Apple’s GarageBand, a program with a very similar purpose to Jokosher. It was interesting to find that like Jokosher, GarageBand has a folder for the project which contains the project file as well as a separate folder for all the audio files. Also just like Jokosher the project file is XML based.

After a few <dict> nodes obviously representing a dictionary data structure, there is a <data> node containing (wait for it…) 2584 lines of base-64 encoded data, and the entire XML file is only 2794 lines! Talk about a memoy dump with angle brackets. And you though your file format was difficult to interoperate with! If you really want to peer at the impurity, you can download the entire file.