phoenix.slamd64.com, which normally runs this site, slamd64.com, and several other sites is currently down due to what looks like a hardware failure - it'll be back up again as soon as possible. I've not imported the old blog data in case it spams planet - if it happens, I'd rather only do that once (when it's back up).

In the mean time, my various projects live on Gitorious - let me know if I've missed one you're interested in. Here's a quick summary (sorry, my normal screenshot-dumping-ground is on the server that's down):

Jerboa

A Qt4/Phonon-based cross-platform music player. Actually, the code I've pushed is a nearly-from-scratch rewrite I started a few months back, with much better performance, and nicer code.

FastCgiQt

A library for writing dynamic websites with Qt. This is especially nice combined with QtSql, and the XSLT2 support that entered Qt 4.5. I prefer this to the widget-based approaches, as I like writing my own [X]HTML, and it makes it easy to output RSS/other XML as well.

StatusBoard

A small application for displaying big red/green squares - for example, at Mendeley, we use it to have an at-a-glance indication of if there's any Nagios warnings, or if any of our buildbot processes are failing.

TypoFail

Think typeracer/typespeed, with LAN multiplayer, and written in Qt.

fredemmott-www

The code for this site - uses FastCgiQt

paincc

A small shell script to put in your path, that forces -Wall -Wextra -Werror -Wnon-virtual-dtor -Wold-style-cast -Woverloaded-virtual -fdiagnostics-show-option if you don't want to spend the time figuring out how to do that on whatever build system you're using right now.

Hooq

More on this later; it's a GPLv2+ GUI testing tool from Mendeley for Qt4 applications.

I got another email asking for the code for my interface between SDL's joystick stuff and Qt that I wrote for my final year university project; I've been meaning to tidy this up a little and publish it for some time, but never quite got around to it - well, I finally have:

http://files.fredemmott.co.uk/SDL-joystick-qt.tar.bz2 - just a .h and a .cpp, ISC-licensed.

Now I've actually bothered to write a (QXmlStreamReader-based) XML parser for StatusBoard, it's switched to an XML configuration file. Unfortunately, I've not yet updated the documentation, but it's got a few new features:

• Separation of tests from display units
• User-defined layout (within a grid)
• User-defined commands for rendering

To clarify the latter: StatusBoard can now take any input file, do some variable substitutions, call a command to turn it into a picture, and display the picture. For an example, the following contrived example uses dot (from graphviz) to make a graph; this would be more useful/shiny with a larger and more realistic network graph - I might put up a screenshot of it on our work network tomorrow.

While using git-svn, I frequently need to either look at the diff of a specific commit in trunk, or, to cherry-pick a commit from trunk to the current branch; here's two helpful scripts:

• git-svn-revision - show the commit message and full diff for an svn revision number, assuming that 'master' follows trunk; usage: git-svn-revision 123
• git-svn-merge - cherry pick a commit from master to the current branch, by revision number; usage: git-svn-merge 123

If you chuck these in the same directory as the other git commands (eg /usr/libexec/git-core on Slackware/Slamd64), you can run these like the others; eg "git svn-revision123" and "git svn-merge 123".

It's been a long time since I posted anything; I've been working on a few slackware, slamd64, and jerboa-related things, but I'll hopefully get into those in detail in another blog post.

As a quick post, someone at work mentioned putting an at-a-glance "is something broken" display on a dedicated monitor or few at work; that led to me writing StatusBoard yesterday/today:

If a test doesn't pass, the relevant item turns red. It's configured via JSON (example included), and supports full-screen mode, and has an optional system tray icon. It basically fetches a web address. It supports:

• A different refetch interval for each item
• A pattern for a revision number
• A pattern that must be matched to count as a 'pass'
• A pattern that must be matched to count as a 'failure'
• Another pattern to limit the scope of the 'pass'/'fail' patterns
• HTTP + HTTPS (well, anything QNetworkAccessManager supports)
• Ignoring SSL errors, such as self-signed certificates
• Linux + OSX + (probably, but untested) Windows

The source is available via git, under the GPLv3.

git clone http://git.fredemmott.co.uk/repo/statusboard/

See the README file for build/configuration instructions.

An announcement mostly recycled from 12.1, and 12.0 in turn:

Slamd64 12.2 is released, and is an incremental improvement over 12.1, including:

• Linux 2.6.27.7
• GCC 4.2.4
• Apache HTTPD 2.2.10, with SSL support and PHP 5.2.8
• Updated development tools
• KDE 3.5.10
• XFCE 4.4.3
• Mozilla Firefox 3.0.5
• Mozilla Thunderbird 2.0.0.19
• Sun Java (JRE and JDK) 6u11

Like previous releases of Slamd64, 12.2 provides seamless FHS-compliant 32-bit compatibility, via a multilib system (/lib for 32-bit libraries and /lib64 for 64-bit libraries). This provides easier and increased support for both existing 32-bit software (in most cases, you can just install a package designed for Slackware with no special work needed), and for 64-bit binaries too (which require /lib64/ld-linux-x86-64.so.2 to be present) such as the NVidia drivers, without requiring compatability symlinks which clutter the root directory and remove the separation of 32 and 64-bit binaries.

nspluginwrapper is still included in c/, allowing you to easily use 32-bit browser plugins (such as Adobe Flash) in the included 64-bit browsers, such as Firefox and Konqueror - given the availability of prerelease 64-bit versions of Adobe Flash Player and Sun's Java Plugin, this will hopefully vanish soon.

As per usual, there's several people that really deserve my thanks:

• Carlos Corbacho - again, a huge amount of contributions to Slamd64, in many areas.
• Andrew Brouwers - many contributions and support.
• Joshua Wood - many contributions and support.
• Patrick Volkerding - for making Slackware
• Everyone who's helped with bug reports or support on the forums/IRC
• The residents of a variety of IRC channels (you know who you are)
• Distributions I have taken compatability patches from; especially Cross-LFS, Gentoo, and OpenSUSE

Additionally, as announced previously, support for 11.0 will be dropped shortly.

On an unrelated note:

Firstly, as a bit of context, I think that in large applications, having a more detailed type system than just "scalar", "array", and possibly objects really helps, and speeds up debugging, and helps bring up errors at compile time instead of runtime, which is always a good thing. I don't see how this doesn't apply to large web applications equally as desktop applications; to an extent, Java servlets seem to be almost what I want; unfortunately, I don't like Java (I won't go into that here) - and I like Qt :)

Because of this, I've started writing FastCGI-Qt, a library to make writing FastCGI applications using C++/Qt as simple as possible - as demonstrated by the example on the first page of the documentation (more are linked at the bottom of that page).

It is currently only tested under Apache HTTPD 2.2 with mod_fastcgi-2.4.6, but supporting other servers is on my to-do list.

The current feature set is:

• Handle communication with the mod_fastcgi, and create instances of your class as necessary to respond to each request.
• Makes HTTP headers and POST data available.
• Parses any form-encoded variables on the query string.
• Provides a stream interface for reading POST data (responders will be created before POST data has been received).
• Parse variables defined in form-encoded POST data (this blocks if the POST data is form data and there is still un-received POST data.
• Defaults to a content-type of text/html and 200 OK status, but this can be overridden if nothing's been sent to the client yet.
• Each application executes requests in parallel, in a thread pool of QThread::idealThreadCount() (typically the number of cores in the system) threads.
• It should handle multiple requests multiplexed over one socket, but mod_fastcgi doesn't do this, so it's untested.

My short-term plans for it include:

• Adding output buffering support.
• Adding support for FastCGI authorizers, not just responders.
• Providing a Responder subclass that you can inherit from and maps request URLs to public slots.
• Writing something non-trivial using it.

It's under the ISC license (with the exception of an internal header file from the fastcgi dev kit, which is under the fastcgi license); there's also QxtWeb which is somewhat similar, but uses SCGI instead of FastCGI, has a different end-user API from what I'm aiming for, and (currently) is only under a GPL-incompatible license.

It's been a while since I've blogged, mostly because of being fairly busy at work (more on that once the refactor branch is done), though I have found time for some work on a couple of C++/Qt hobby projects:

Jerboa's had a fairly major UI change (well, given the amount of UI there is, there's not much to change), and while the toolbar takes up much more space, I think it's better and more consistent. I also got around to making a DMG for mac users (windows users: MSI coming soon, builds and works fine though - linux users: cmake/qt4.4 from source). I've still not managed to hit my feature plan for 0.3 yet - when it's done ¬_¬.

I've also been working on a typing game, called TypoFail - only source so far for it though, and a screenshot or two:

The first is a clone of the amazing timewaster TypeRacer, though without the lag issues that annoy me over wireless; the latter is a clone of the venerable 'typespeed' game.

In the first mode, you type the quote as quickly as possible, and your score is your WPM. In TypeSpeed mode, your score is the number of characters in complete words you typed before you fail (10 words reaching the right hand edge of the field is a failure).

The game supports multiplayer (and pops up mini game windows showing your opponent's state), though requires a manually set-up standalone server at the moment. One neat thing about the quotes mode is that it reads fortune-format files, so you can easily load up whatever quotes you like - it'll even recognize ones which look like a dictation/IRC log:

Both of these applications are pure Qt4, and work fine on Windows, Linux, and OSX - though TypoFail's networking requires JsonQt, which it contains in a git submodule.

As of a few days ago, JsonQt can translate both ways between QVariantMap objects and JSON strings (see the tests for examples). Someone sent a link to QJson my way; after a quick look, here's a couple of advantages and disadvantages of each:

• JsonQt doesn't depend on bison, Boost::Spirit, or anything except a compiler, cmake, and Qt - easier for windows builds, and means I don't have to worry about syntax changes between one version of $parserGenerator to the next.
• QJson is written using bison - if bison's your thing, this can make it easier to fix errors.
• QJson can handle the top-level JSON "thing" being an array, not an object - JsonQt requires it to be an object.
• JsonQt provides both translation both ways

The last point I think is due to me misreading json.org - though it's easy enough to change (make it so that the main public functions take/return QVariants instead of QVariantMaps, and if trying to parse as an object fails, try to parse as an array).

Update: QJson has the bison-generated files in SVN, in addition to the bison source files.

Due to a mixture of only hearing about JSON recently, and being curious about how much of my compiler design course I remembered, I made a pure-Qt parser for JSON; it can either produce a full tree-structure using a mixture of QVariants, QVariantLists, and QVariantMaps, or, if you've got flat JSON, it can directly write properties on a QObject - as a contrived example:

JsonQt::JsonToProperties parser;
parser.parse("{\"objectName\" : \"badger badger badger\"}", this);
QASSERT(objectName() == "badger badger badger");

The code is in my git repository; construction of JSON strings from QObject properties or QVariant structures is on my todo list.

I've got a fairly high spec machine at home:

• Q9300
• 2 8800GT graphics cards
• 8GB RAM

Having got most of the way through packaging KDE 4.1.1 for Slamd64, I gave it a try - with one monitor on each of my non-SLIed graphics cards using the (beta) nVidia binary driver and Xinerama.

It was terrible; though the following helped a little:

In xorg.conf:

Option "AllowGLXWithComposite" "true"
Option "AddARGBGLXVisuals" "true"
Option "RenderAccel" "true"
Option "UseEvents" "false"
Option "TripleBuffer" "1"
Option "DamageEvents" "1"
Option "BackingStore" "1"
Option "PixmapCacheSize" "70000"
Option "OnDemandVBlankInterrupts" "true"
Option "AllowSHMPixmaps" "0"
Option "DisableGLXRootClipping"

On each X session:
nvidia-settings -a InitialPixmapPlacement=2 -a GlyphCache=1

This was still unusable.

Now to see if people read more than half my blog post before commenting :) After plugging both monitors into the same graphics card and disabling the other (no twinview on SLI...) it absolutely flies - subjectively, it 'feels' faster than KDE 3, even with all the fancy effects on (including wobbly windows - except for resizing with wobbly windows on isn't so great). As it turns out, the X stuff above does do a difference in this setup.

I'm really impressed by it's performance and the other improvements that have gone in since I've last been able to build and run KDE4, and I hope that the poor performance of nVidia's drivers without lots of tweaks doesn't give too many people an incorrect impression.

I've got a fairly high spec machine at home:

• Q9300
• 2 8800GT graphics cards
• 8GB RAM

Having got most of the way through packaging KDE 4.1.1 for Slamd64, I gave it a try - with one monitor on each of my non-SLIed graphics cards using the (beta) nVidia binary driver and Xinerama.

It was terrible; though the following helped a little:

In xorg.conf:

Option "AllowGLXWithComposite" "true"
Option "AddARGBGLXVisuals" "true"
Option "RenderAccel" "true"
Option "UseEvents" "false"
Option "TripleBuffer" "1"
Option "DamageEvents" "1"
Option "BackingStore" "1"
Option "PixmapCacheSize" "70000"
Option "OnDemandVBlankInterrupts" "true"
Option "AllowSHMPixmaps" "0"
Option "DisableGLXRootClipping"

On each X session:
nvidia-settings -a InitialPixmapPlacement=2 -a GlyphCache=1

This was still unusable.

Now to see if people read more than half my blog post before commenting :) After plugging both monitors into the same graphics card and disabling the other (no twinview on SLI...) it absolutely flies - subjectively, it 'feels' faster than KDE 3, even with all the fancy effects on (including wobbly windows - except for resizing with wobbly windows on isn't so great). As it turns out, the X stuff above does do a difference in this setup.

I'm really impressed by it's performance and the other improvements that have gone in since I've last been able to build and run KDE4, and I hope that the poor performance of nVidia's drivers without lots of tweaks doesn't give too many people an incorrect impression.

Huge thanks to Jon Chambers who's provided Jerboa (the music player formerly known as YANIHP) with the following icon:

In a pleasantly surprising turn of events, QSvg can render the source flawlessly :)

As is obvious, the name of my music player, YANIHP, leaves much to be desired; following a suggestion of Jason Donenfeld (thanks), I'm going to rename it to Jerboa - though I could do with a little help:

Does anyone have the time and ability to make me an SVG icon featuring this animal in some way, and willing to license it freely for use in Jerboa? If so, I'd really appreciate it, as I am completely talentless at drawing.

Update: the code is in my git repository, and I've also made an OSX bundle for PPC and x86 Tiger and Leopard. It builds on Windows, but unfortunately I've not been able to make a package as my Vista partition currently won't boot and I haven't had the time to look into it yet.

I've written a small bash CLI interface to MPRIS players, available at http://files.fredemmott.co.uk/mprisshell.sh.

It's currently rather limited in functionality:

Usage: mprisshell.sh [command]
Commands:
  play                          Start playing the current track
  pause                         Pause the current track
  playpause                     If a track is playing, pause it; otherwise, play the current track
  next                          Skip to the next track
  previous                      Skip to the previous track
  incVolume [percentage]        Increase the volume by 10%, or the given percentage
  decVolume [percentage]        Decrease the volume by 10%, or the given percentage

It sends the above commands to the first MPRIS-capable player found; this includes the latest git head of YANIHP, Amarok 2, Audacious, and others. It's meant for normal users, not developers, for example as a program to bind to media keys.