Skip to main content

· 6 min read
Ubuntu logo

Whilst pondering a thought-experiment related to installing Ubuntu packages (more on that in another post), I was looking to understand the output of the apt-cache depends command. However, while doing a quick Google search, I found that the top two results were wrong - one subtly (though sort-of right), the other blatently wrong. So, I did a little digging to figure it out for myself.

Before we get to the right answer, let's start with those top two results. The first search result says:

As you guessed the | indicates "or". The control line normally shows foo | bar, but apt-cache depends appears to reformat it by showing each alternative on its own line and prefixing the first with the |. In other words, the pipe flags the preferred option and the next line is the alternative.

(emphasis mine)

This is actually pretty close, but not quite true, as we'll soon see.

· 2 min read
CMake mark

I'm currently shitfing some common CMake code from various disparate projects to common shared CMake modules. The first of these is some code for locating Qt's documentation tag files for linking Doxygen-based documentation to Qt's documentation. The resutling FindQtDocs module is now availble on GitHub here.

The module works by using either Qt's qtpaths (from Qt 6.2.0 onwards) or qmake (before Qt 6.2.0) to fetch Qt's QT_INSTALL_DOCS property1. Once the QT_INSTALL_DOCS path is known, the module simply looks for the requires Qt modules' *.tags files, setting the relevant CMake variables following the usual find_package conventions, such as:

find_package(QtDocs COMPONENTS Core Bluetooth)
if (QtDocs_FOUND)
message(DEBUG "Do things with ${QtDocs_Core_TAGS} and ${QtDocs_Bluetooth_TAGS}")
endif()

Footnotes

  1. Support for the -query option was added to qtpaths in Qt 6.2.0. It works the same as qmake's -query, but presumably was added to assist the gradual removal of qmake, since CMake is now Qt's preferred build system.

· 4 min read

Having recently ported this site to Docusaurus, I though it would be interesting (to me, at least) to document some of the history of this site's transitions over the past 17 years!! 😯 So let's go...

Blogger(.com) (2006 ~ 2008)

Starting in 2006, this site began as a very simple Blogger page, called PC Thoughts. "PC", of course, being my initials (Paul Colby).

Original PC Thoughts header

· 2 min read
PMDA++ logo

I've recently been working with Performance Co-Pilot (PCP) - specifically, creating some PCP add-ons (known as PMDAs) for exposing custom application metrics to PCP.

While doing so, it became pretty clear to me, that although PCP's PMDA C API is very efficient, a good quality C++ wrapper could significantly cut PMDA development and maintenance time (for people like me, at least), while also increasing runtime safety by building-in all of the checks and balances that most PMDAs (should) perform, in a generic reusable manner.

This sounded like a bit of fun, and suited my present hunger for some more advanced C++ API design work, so went about implementing such a library.

· 10 min read
Amazon SQS queue icon

While considering using Amazon SQS for a project recently, I was surprised at just how little SQS performance data was available on the Internet. In particular, while there's a bit of information available regarding throughput, there is very little information I can find regarding message latency.

Indeed, as long as SQS can scale horizontally, throughput is really not very important at all (within reason of course). But latency cannot usually be improved by scaling, so if latency is too high to be acceptable for any given project, then scaling is unlikely to ever change that.

As latency is so important for the project I had in mind, I decided to throw together a very small set of simple SQS benchmarking scripts to get an idea of what sort of latency (and throughput) we can expect from SQS.

· 3 min read
Boost Logo

From time to time I find myself building Boost on Windows. There's a number of small things that need to be done to make that happen. Having had to "rediscover" the build process each time, I recently decided to create a small Windows command script to automate most of the process.

As I find the build script extremely useful, I figured it would be worth posting it here to inspire others in similar circumstances.

· 5 min read
Polar WebSync logo

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 had 30 or so such HRM files that I'd been entering into Strava manually (stationary trainer sessions, and weights workouts).

· 6 min read
gpx2tcx.sh screenshot

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.

· 12 min read
Polar RCX5

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 ;)