PC Thoughts

I recently posted an AWK script for combining GPX and HRM files into TCX format. This script is really handy when you have GPX files with or without matching HRM files, but what if you have HRM files without GPX files?

It did not immediately occur to me that there'd be any value in converting lone HRM files to TCX, since I think of TCX as being geographic location focused (which is not strictly true). However, prompted by Conrad, it became apparent that I could indeed convert HRM files (without GPX files) to TCX, and indeed, I already 30 or so such HRM files that I'd been entering into Strava manually (stationary trainer sessions, and weights workouts).

Following on from my gpx2tcx AWK script and Windows batch file, I now present what will probably the last separate component in the series... my gpx2tcx.sh Bash shell script.

This script is similar in nature to the Windows equivalent presented earlier, however it is considerably more flexible. Unlike the Windows batch file, this Bash script supports a number of command line arguments that allow its operation to be tweaked more easily.

I've previously presented a GPX + HRM to TCX AWK script (see this post). And while this script can be very useful on its own, I've also written a Windows batch file, and a Bash script to make use of that AWK script a little easier. In this quick post, I'll be presenting the former of the two - ie the Windows batch file.

Three of the most common file formats for recording exercise data are HRM, GPX and TCX. HRM is an older proprietary, but open, standard created and maintained by Polar, which deals with heartrate information, as well as speed, cadence, altitude and power. GPX is another older standard which deals primary with geolocation data from GPS receivers. TCX is a newer format that effectively supports all that HRM and GPX support combined, and then some.

My shiny new Polar RCX5 (which I really like) happens to export data (via the Polar WebSync application) as separate HRM and GPX files (for legacy reasons, no doubt). Whereas Strava (which I also really like) supports GPX and TCX imports (amoung others). So of course, I can import my GPX files from the RCX5 to Strava pretty easily, however, that will provide Strava with no heartrate nor cadence data, since the GPX format does not support those.

So the question I faced was: how to combine the GPX and HRM files from my RCX5 to a single TCX file? Since I found no appropriate tools readily available, I wrote my own ;)

Apache Qpid™ is a high performance open-source message queuing system. But there's no point me telling you all about it - just check it out over at http://qpid.apache.org/.

The Qpid project provides two different message brokers, and several client APIs. However it did not yet have a PHP client API, so I set about writing one :)

Although the PHP binding I created is SWIG-based, it was not as straight-forward as writing a simple SWIG interface file, and compiling... no sir! First off, running SWIG on the standard Qpid headers in PHP mode resulted in SWIG seg-faulting. So after reporting that bug to SWIG (it has since been fixed, yay!) and developing a workaround, I then had to solve a number of small issues, and then write some Qpid Variant ⇔ PHP type-mapping routines.

Writing managed (aka .NET) sinks for Exchange Server 2000 / 2003 SMTP events requires Primay Interop Assemblies to wrap Exchange's COM-based event sink interfaces. If you don't know what PIAs are, then I suggest you read Primary Interop Assemblies (PIAs) - MSDN. But chances are, if you weren't already at least aware of the existence of PIAs, then the rest of this post is probably not something that will interest you ;)

Now, there are no official binary PIAs for Exchange Server 2000 / 2003. However, Microsoft does provide such PIAs in "source" form (not really source code as such... but we'll get to that) that you can download and compile yourself. There is an MSDN article that explains how to use the Exchange Server PIA wrappers, however I strongly recommend you download the code and read the included "Writing Managed Sinks for SMTP and Transport Events.doc" file instead - it is far more up to date than the MSDN article in areas that are quite significant (such as the actual build process).

Having owned an N900 for a little while now (casting my vote for openness and freedom in the mobile space), I've been eagerly waiting for a MeeGo release that I could install on my N900 and play with. That moment came a little over one week ago! :) So, after waiting for my nice new class-10 microSDHC card to arrive (cheaper to buy online with shipping, than to buy locally), I finally had a play last weekend. I was a little dissapointed :|

Although I had expected a lot of bugs and instabilities, and my overall expectations were quite low at this stage, I was still quite surprised at just how incomplete MeeGo Handset is. I guess my unrealistic expectations stemmed from the fact that the current MeeGo handset release has the version number "1.1" - that implies to me that it should be "fairly complete" (albeit with bugs, etc). However, it is more inline with what I would call a version "0.1".

A couple of weeks ago, I upgraded my Windows XP machine to Windows 7. I used the Windows 7 Family Pack special, which includes three Windows 7 upgrade licenses in one pack for better value.

Now, the back of the Family Pack box says:

Which is completely fine with me, because I always do a fresh install anyway, for performance reasons. So, with all my important data backed up, I formated the disk and proceeded to install.

The initial stages of the installation were pleasantly slick - feeling much more refined than good old XP, but the pleasantries were put on hold when it came time to enter my product key, which was consistently rejected! :(

I've been experimenting with QtSvgDialGauge in a personal project, and so far, I like it a lot! :)

For those who don't know, QtSvgDialGauge is nice SVG-based dial/gauge widget, which is part of the Qt Embedded Widget demos. You can see it (and several other embedded widgets) in action in the Qt Embedded Widgets Catalog and Qt Patient Care Demo applications. And you can download the source for both applications here.

Now, the Qt Embedded Widget demos includes three SVG-based skins for the QtSvgDialGauge class: Tachometer, Thermometer, and Amperemeter...

With most non-trivial Qt projects that I create, I like to include a pre-pre-build command in the qmake project file. I'll explain why as we go, but first off, let's look at what I mean by "pre-pre-build" (it is not at all a standard term).

The typical build process (as performed by make) looks something like this:

1. For the given target, check if any of the target's dependencies have been updated since it was last (re)built.
   
   1. If no dependencies have changed, do nothing - we're done ;)
   2. If one or more dependencies have changed, then:
      1. Build each dependent target.
      2. Build this target.
      3. If appropriate, link this target with its dependencies.

That is, of course, a gross oversimplification... but it will do the purpose of this post.

Now, like most Qt developers, I use qmake to generate the Makefiles that drive the build process. Qmake, being an excellent tool, allows you to customise the generated Makefiles in many, many ways. For example, you can add custom commands to be executed just before or after the link step (1.b.3 above) via the QMAKE_PRE_LINK and QMAKE_POST_LINK variables.

However, qmake does not provide a QMAKE_PRE_BUILD variable for adding pre-build commands, and certainly no QMAKE_PRE_PRE_BUILD variable either. The former, it turns out, is pretty easy to achieve anyway, but the latter (the topic of this post) is a little bit trickier.