Daniel’s Blog

And here’s yet another new blogger on Planet GNOME. Many thanks go to Jeff Waugh, who kindly added me to the celebrity pool. I’m Daniel Elstner a.k.a. danielk, co-maintainer of gtkmm and also part-time employee of Openismus GmbH.

I thought it would be nice to celebrate the occasion with a new release of my pet project regexxer. It’s about time, too. Maybe I can get Daniel Holbach to sign off an NMU of the Ubuntu package before Feisty hits the mirrors.

Well, that’s it for now. Hello fellow Gnomers!

I do way too much tinkering around. Scraping a single CPU cycle here, moving a pixel around there, and so on. You get the idea. It’s a habit that has recently become so excessive that I don’t get much else done anymore, because during my tinkering I find all over the place “exciting” new opportunities to tinker around.

So much for the whining part. Now, when it comes to software projects, what’s the best way to stop yourself from tinkering yourself to death? Right. Release it. Early and often, as they say. Release the damn thing and get over it. There’s an exciting possibility that further tinkering will likely involve actual bugs reported by actual users.

So I’m going to do just that right now. There’s a project I’ve been tinkering with for about four years now, and there has never been a public release until now. I guess I lose spectacularly in any time-to-market comparison. And this is a tiny project.

Anyway, back on topic. You probably guessed it already — the project I’m about to announce goes by the name Somato. Years ago, my computer science class at school did a software project term. The task was to write a program that solves the Soma cube puzzle created by Piet Hein. And so I did. But then I got carried away a bit. The result, complete with 20-milliseconds solver, 3-D animation and SSE intrinsics is now available at the Somato project page. I also created binary packages for Ubuntu to raise the chance that someone will actually download my favorite toy, despite the fact that it doesn’t actually do anything productive.

A nice side effect of preparing the release was that it forced me to complete my website. You’ll notice that the “Site Almost Finished” headline is gone now. I put together projects overview and how-to overview pages. So all the basic infrastructure is in place now.

Next week will see a regexxer release. For real.

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!

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!