Matt Williams

Today I got a sudden urge to go for a cycle ride. I don't currently own a bike of my own but luckily my Dad had several old bikes in the garage. Now, most of them didn't work (generally things wrong with the gearing systems) but one of them was in fairly good shape and needed only a little air in the tyres, an oiling and a bike-stand transplant from one of the other bikes. Being an OpenStreetMapper, I only go on trips to places that need mapping (fortunately that is almost everywhere, even if I'm only adding addresses) and so I perused the maps to find a suitable location and I noted that there were substantial bits of countryside that I had traced from aerial imagery but had not yet been in person to check up on. So I decided to take a trip to Havant Thicket which is a nice forest/scrubland area about 6 kilometres from my house with what I remember being very nice cycle paths around it. So I printed off come paper maps of the area for annotation and loaded myself up with my GT-11 GPS, my N96 and N810 and set off. Before I left, the area looked like this:

It wasn't until I got going that I realised two things: how unfit I seemed and how different roads are for a cyclist compared with a car driver. Hills seem to appear that weren't there before and the places you are allowed to cycle are much less obvious. For example unsigned cyclepaths mixed with footpaths really don't help. However, I made to Havant Thicket without too much trouble (although cycling along the single-carriageway 60 mph road was a little scary at times) and started mapping. I found many routes which I hadn't been able to put on the map before simply by randomly cycling around taking whichever path seemed most interesting. In fact there are some paths I didn't venture down in case they kept on going forever and I never got home and some were just too muddy for me to bother with today:

The area just south of Havant Thicket is scheduled to be turned into a water reservoir and nature reserve whilst at the moment it's very nice heath land:

And so with all of that I cycled home, wishing that I'd bought more water with me but thankful for the many benches scattered around the thicket, especially as today was unusually warm for England. Fortunately, it's the time of year for blackberries and so halfway home I stopped and ate about 20 blackberries from the hedge which made be feel very rustic indeed. All in all, I cycled about 14.1 miles which isn't bad considering I've only got on a bike about twice in the last five years. Of course, once I was home I added/re-tagged all the cycle paths in OpenStreetMap and added what cycle lanes I'd noticed on the way. Once the map was re-rendered, it looked something like:

In other news, I've also been doing a lot of mapping around my more immediate area. I'm planning on fleshing out the whole area with building outlines and full addressing but at the rate I'm moving, that'll be several years away. Finally, I'm getting more and more annoyed by my internet connection at home. It seems to flicker on and off which isn't noticeable for web browsing but makes any sort of sustained connection impossible - that includes IRC, IMAP and FTP which are basically unusable with timeouts after a few minutes at the most. Anyone else had similar problems?

Just an update on my PhD application progress. I've now had all three of my planned interviews and have heard back from two of them. Both Warwick and UCL want to offer me a PhD and I'm still waiting to hear from Imperial College. Funnily enough, both the offers I have so far are involved with the RAL. The Warwick one is an LHCb project (I blogged about it before) and the UCL one is an industrial placement where the company involved is the RAL.

My girlfriend, Rachel, also has an offer from Warwick for an Astrophysics PhD so it's likely that I'll be staying here but there's still some other things to consider.

No matter which one I decide upon, I'm excited to have something sorted out for the next few years.

On Friday I had my first (hopefully of many) interviews for a PhD place starting in October. One of the PhD places being offered at Warwick is an LHCb project in conjunction with the Rutherford Appleton Laboratory (RAL). Now, as you probably know, LHCb is one of the detectors at the new Large Hadron Collider at CERN, along with ATLAS and others. Now, you might remember that it was previously noted that the ATLAS experiment uses KDE in their control room. Now, interviewing me were some members of the EPP group at Warwick as well as a member of RAL who was teleconferencing in. When the topic of conversation went to my involvement in KDE, the RAL guy made a point of thanking me and the KDE project for a great DE since apparently they use it in all their offices there. Perhaps if I get this place then there's a chance that there might be a chance for some KDE programming.

This also makes quite the difference from an interview I had last year for an internship at Barclays Capital where not a single person I spoke to seemed to have heard of KDE.

This last term at University has been pretty busy. That's to be expected I guess since it's now my final year but I've been busy with my final year masters project (a particle physics project in collaboration with BaBar) and a course in high performance computing where I've learned everything from SWIG to OpenMP and MPI. My interest was so piqued by the HPC stuff that I've decided that I am going to focus my PhD on that area, now I just need to find somewhere that will take me :)

Anyway, that's the reason I've been somewhat absent from KDE recently. However, now it's the Christmas break and while I do have some Uni work to do, I've got some time for KDE stuff, particularly for KSquares which has unfortunately been almost unchanged since KDE 4.0.0. I'm just about to start work on a full AI system for it. Up until now, the AI had two modes, one which just moves randomly (hardly fun to play against) and another which only takes moves which are immediately the 'least damaging'. Neither of these modes have any sort of forward planning and so I am planning on implementing a simple decision-tree type design to allow the AI to be perfect (this is possible in squares since it is a very closed game).

In related news, I've started using KDevelop 4 (I have been building it for a while now but had been experiencing crashes - these now have mostly stopped). I remember using KDevelop 3 previously and while it was a very good IDE, I couldn't seem to use it for anything more than automating tasks (configuring, building, searching). KDevelop 4, however is a different story. If any of you have been following David Nolden's blog you'll have seen sime of the nice new features it brings. It's more than just auto-completion, it really does allow you to browse your code like a semantically sensible web-site. Your mouse never has to leave the text-area.

On an unrelated note and for those who care, I've also been doing a small bit of work (mostly minor optimisations, documentation and the CMake buildsystem) on my brother's recent project. It's basically a framework to allow the use of Qt and OGRE in the same application (so that a game could, e.g. use Qt to display the GUI, menus etc.). It's called QtOgre and is now available as an OGRE Addon. It was designed to be used in his game project/voxel rendering system Thermite 3D.

Despite the headline, this is a topic which may well be very boring to many people, but if you have no fear then read on (especially if you like elephants)... You probably all remember how with the release of Qt4, Trolltech changed the way they recommended people to #include their classes. Previously one would include the header file describing QDir with #include <qdir.h> but with Qt4 it was changed such that one could do #include <QDir>. That is, if you wanted to include the header for a class you could simply put the classname between the pointy brackets (well actually I think it's recommended to put modulename/classname in there which means you have to look up which module the class is in, but let's ignore that for now). This makes it very easy to know how to include the stuff you need. So, in the run-up to KDE4 there was much discussion about whether KDE should do the same. Some people were against it but it was decided that it doesn't hurt to allow these 'forwarding includes' since the normal includes are still there (the forwarding includes only #include the real headers themselves). Now, it was while working on a new highscore management system for kdegames (I'll probably blog about that later, you're not getting away that easily :D) that I noticed that in our apidox at http://api.kde.org we're still telling people to use the old include style. So, I looked at the doxygen manual and found that it has a feature to specify what the include file for any class should look like (you can see it here and there's also one for namespaces/structs and the like here). Armed with this knowledge I set about updating the kdelibs documentation to use it. It's a simple case of adding, for example: \class KScoreManager kscoremanager.h <KScoreManager> to the documentation block for the class. This makes the difference between this include and this one (see that #include line in the grey box near the top). The problem is, there's loads of classes to do this to and for each class (unfortunately there's sometimes more than one class in a header file) you've got to check whether there's a forwarding include for it (I guess internal classes don't need forwarding includes). In fact, if you download the tarball of the documentation for kdelibs from http://api.kde.org and make the following command from the root directory find . -regex ".*\.html" -not \( -regex ".*source\.html" \) -not \( -regex ".*_8h\.html" \) -not \( -regex ".*_8cpp\.html" \) -exec grep -l --regexp=".*#include <<.*\..*\..*</a>></code>.*" '{}' \; | wc -l you'll find that there are about one and a half thousand classes this needs to be done to. That's a lot to do manually and given the nature of the changes to be made, difficult to do programatically. The good news is that if you call this command (which is sorta the opposite of the other one but without the wc -l) find . -regex ".*\.html" -not \( -regex ".*source\.html" \) -not \( -regex ".*_8h\.html" \) -not \( -regex ".*_8cpp\.html" \) -exec grep -l --regexp=".*#include <<.*\..*[^.].</a>></code>.*" '{}' \; you'll see that there's already some classes doing it properly (Nepomuk, DNSSD and KFadeWidgetEffect). Now, unless someone can think of a way of converting all the documentation automatically then all I can ask is that the next time you're doing some work on a library class, firstly make sure you're installing forwarding headers (preferably 1 per class even if both forwarding headers forward to the same real header) and secondly just add the \class ... line to the class documentation block and make the world a more attractive looking place. P.S. I'd like to dedicate this post to Jesper K. Pedersen, the author of KRegExpEditor without which this post would not have been possible. P.P.S. Okay, so I lied about the elephants but if you do a search and replace with "class"→"elephant" this post is a lot more exciting.