Year: 2006

I started to debug korganizer this evening, because the exchange plugin added appointments downloaded from an Exchange server one hour too early. After building kdepim from the debian source package, the first thing I learned is how to debug plugins (see KDE developers FAQ) (thanks, Mirko):

KDE searches its libraries in $KDEDIR/lib and in the lib directory of all the components of $KDEDIRS. So, while you are still developing your library and don’t want to install it, you can use this trick:

• cd to your development directory, the one where your library is built.
• Set up KDEDIRS so that it include your development directory: export KDEDIRS=`pwd`:$KDEDIR
• Create a pseudo lib directory where KDE should find your component: ln -s .libs lib
• Run kbuildsycoca to inform KDE that it KDEDIRS has changed.

Now, KDE should find your library when using KTrader or KLibLoader.

This worked perfectly, and after some time of debugging I found the reason for the problem: libkpimexchange/core/utils.cpp contains the functin utcAsZone() which returns the local time for a given UTC time and time zone. The time zone is passed as id in the form “Country/City”, like “Europe/Berlin”. Inside this function, the function icaltimezone_get_builtin_timezone_from_tzid() from the ical library is called which shall return a time zone structure by its id. However, this function does something different: it expects the passed string to be in a specific format (it has to start with the prefix “/softwarestudio.org/”, for example) and extracts the time zone id from this string. So, of course, it could never find a matching time zone… The fix seems to be quite simple: just use icaltimezone_get_builtin_timezone() instead, which directly works on the “Country/City” format. Then, downloading appointments from the exchange server works well again. [UPDATE] I checked in the KDE svn repository: The very same fix has already been committed about two weeks ago 🙂

After I came across the Haskell programming language three times today (twice while scanning the latest debian-devel postings, and later again while searching for some documentation about the python distutils package) I had a closer look at it. Other than wide spread languages like C++, Java or Python, which are imperative languages, Haskell is a functional language (until know, I thought that these are those languages which are rarely used in practical programming because they are too complicated… I am curious if Haskell can argue the converse 😉 ) The introduction at the start page looks quite interesting, at least the implementation of the quicksort algorithm is much shorter in Haskell than in C.

For the new year, I had the intention to write blog entries more regularly, but currently I don’t see any improvement yet 😉 Well, the new AMD64 system is running quite good, it sometimes looses the mouse after booting (i.e. the pointer simply is simply frozen), but this could be a problem with a conflict of the ehci_hcd USB kernel module. Some hints suggest to load it directly at boot time instead of automatically when it is needed during the boot process. Apart of that, I continue to collect a list of applications which are not yet available as 64 bit version, among them are the RealPlayer (the helix-player is available but crashes) and the Adobe Acrobat Reader. Hopefully this situation will get better soon…