I was recently working on a bootstrap script that, among other things, needed to install a fairly large number of apt packages. The list of packages was pre-existing, and had grown organically over several years. As most apt users would know, many packages require a significant number of dependenecies, and so it's pretty likely that any significant list of apt packages would include at least some transitive redundancy. So, mostly as a mental exercise, I started pondering how I could go about reducing any set of required apt packages to tha minimal set that would still include all of the same dependencies.

It actually proved to be pretty easy in the end. But first, I needed to find a reliable way to fetch the list of dependencies for any given package. The apt-cache utility does the job, but I had to sort through some misinformation online re the command's output format. You read about that in the previous Pipes in apt-cache Output post.

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.

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 property¹. 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()

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

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.

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.

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.

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

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.