Daniel’s Blog

The project I’m currently working on required me to make some improvements to gmmproc, the code generator used by the gtkmm project. In my current work it’s occassionally necessary to wrap enumerations that don’t follow the consistent naming scheme of GTK+ we take for granted nowadays. This is how the enumerations look like:

• FOO_THIS,
• BAR_THAT,
• FUZZ_THERE

That should of course be:

• MODULENAME_FOO_THIS,
• MODULENAME_BAR_THAT,
• MODULENAME_FUZZ_THERE

Ideally, this would prompt a patch to the upstream code. But it’s not always possible to change upstream API, and even if it is you sometimes just don’t have the time for the bureaucracy involved and only want to get your code to compile for now.

But the code generator didn’t like the idea at all. The Perl script that gathers the enumeration definitions from the C header files even went into an infinite loop. I fixed that, but then it turned out that the enumeration parsing module of gmmproc unconditionally stripped everything up to and including the first underscore in every enumeration constant. The result looked like this:

• THIS,
• THAT,
• THERE

Ugh. Well, this prompted me to change the behavior of the enumeration parser to only strip the prefix if it’s actually common to all constants defined in an enumeration. It’s been a long time since I last dipped my feet into Perl, but it seems to work now. The new code is available from glibmm CVS, including the earlier branches from glibmm-2-8 onwards. I do hope it doesn’t break anything.

In order to actually prefix the enumeration constants in the C++ code, you can use something like this:

• _WRAP_ENUM(SomeType, ModuleSomeType, , s#^\b#MODULE_#)

You could even give the C++ constants the same names as in C, which would in many situations be the most appropriate scheme since we use namespaces instead of module prefixes in C++. The resulting shadowing could lead to problems though if C and C++ code is mixed. Your mileage may vary.

Tonight I had to move two project directories from a public Subversion repository over to a private server. Usually, to do this you’d dump the whole thing with svnadmin into one flat file and load it again at the new location. But to run svnadmin you need shell access to the Subversion server.

However, given that there are lots of tools around with names like cvs2svn I figured that something similar might exist for plain svn to svn migration. So I tried my luck and googled for “svn2svn”, and behold — I struck gold. It’s a hack and puts a quite heavy load on the server in order to retrieve the difference of every single revision to the next. But it worked like a charm:

• mkdir tmp; cd tmp
• svn mkdir http://destination/directory
• ruby svn2svn.rb http://source/directory http://destination/directory

That’s really all there is to it. The project directory is now at its new location, and has its history preserved. Many thanks to choonkeat for sharing his work!

After a somewhat difficult start into my new working life, including illness and missing school, tonight I’ve got some small but real work done. And what’s more I felt like my old hacker-self again. I think the last time I had this feeling of accomplishing something worthwhile in code was back in my huge gtkmm and gvim hacking days. It’s really not a good idea to only do stuff that nobody else will ever see, even if it is interesting and mind-bending. I used to do that way too much.

It feels good being back. And I’m going to blog more regularly too. Promise.

Maemo 2.0 requires the legacy Scratchbox 0.9.8 which does not support the amd64 architecture natively. However, I’m running Ubuntu on amd64 and managed to get Scratchbox working inside a 32-bit chroot environment. Scratchbox itself is built around chroot, so this approach has the weird consequence that I’m now running two nested chroot environments — like matryoshki.

In order to save others the hassle of figuring out how to set this up (read: Murray extorted it from me), I put together a little howto on the subject. Enjoy!