I’ve just discovered Rosetta Code not long ago, and found it quite fun to browse around in. It shows you the code for various programming tasks in different programming languages. While looking at the Quicksort page, I noticed that it didn’t have a CMake version, so I decided to try writing one.

function (quicksort array_var)
    set (array ${${array_var}})
    if ("${array}" STREQUAL "")
        return ()
    endif ()

    set (less)
    set (equal)
    set (greater)
    list (GET array 0 pivot)

    foreach (x ${array})
        if (x LESS pivot)
            list (APPEND less "${x}")
        elseif (x EQUAL pivot)
            list (APPEND equal "${x}")
        else ()
            list (APPEND greater "${x}")
        endif ()
    endforeach ()

    set (array)
    if (NOT less STREQUAL "")
        quicksort (less)
        list (APPEND array ${less})
    endif ()
    list (APPEND array ${equal})
    if (NOT greater STREQUAL "")
        quicksort (greater)
        list (APPEND array ${greater})
    endif ()
    set ("${array_var}" ${array} PARENT_SCOPE)
endfunction ()

set (a 4 65 2 -31 0 99 83 782 1)
quicksort (a)
message ("${a}")

I’ve worked with CMake for years, and I think it’s a good build system, but I really wish it had switched to a saner language. The CMake language is actually pretty simple and consistent at the syntax level: everything is in the form command(string), where the string syntax is slightly confusing but still rather understandable once you’ve figured out the quoting and variable expansion mechanisms. It’s how that string argument is used that can be messy, inconsistent, and ambiguous. Effectively, it’s as if every command had its own syntax.

Around 2008, there was an experiment to allow writing CMake scripts in Lua. The project never caught on and was abandoned. I think part of the reason was that the thread discussing it in Lua’s mailing list was single-handedly derailed into pointless bickering (which reminds me of the poisonous people talk).

CMake is stuck with a mediocre programming language for the foreseeable future. It’s not as bad as it sounds, though. The simplicity of the syntax has its advantages, and writing CMake buildfiles rarely gets frustrating. It would make a terrible general programming language, but as a build system scripting language it’s workable.

Exaile recently switched from Bazaar to Git. Dustin Spicuzza, who has been leading the Exaile project recently, initiated this plan and the rest of the team were in full agreement. But why did we switch? Put simply, it was because all of us prefer Git to Bazaar. However, that’s an oversimplification of my stance on the whole DVCS thing.

After the BitKeeper debacle, distributed version control system became the hottest buzzword around, and in a short while the three major contenders became obvious: Bazaar, Git, and Mercurial. At the time I already had experience with SVK (a semi-DVCS that extends Subversion), which I had used on Ruby.NET and Exaile, but when Adam moved Exaile to Bazaar, I went all-in on Bazaar.

I loved nearly everything about Bazaar, and I instantly “got” it. This was in contrast to Mercurial, which I gave up trying to understand, and to Git, which I wouldn’t have started using if I didn’t have to use it at work. I really wanted Bazaar to be popular. I still agree with the general sentiment that it has excellent usability, especially compared to Git.

But its modest popularity crashed under Git’s dominance; Git was getting all the attention and all the improvements while Bazaar stagnated. Bazaar’s biggest promise from the start, that it would eventually be optimised for speed, either came too late or never materialised—I still don’t know which. Its code documentation languished, and I had to go digging around just to write a simple commit bot.

During casual chat among the active developers at #exaile, we found that our collective knowledge of Bazaar had deteriorated so much that we couldn’t remember how to perform some relatively simple operations. We decided to move on. Right now most of our services have moved to GitHub. We’re still keeping the Launchpad site to refer to old bugs and for the web translation service (the latter is not available on GitHub).

Note: I wrote this article in full in 2014 but only decided to publish it in 2019, by which time it was obviously not timely anymore. It still expresses my thoughts quite well, so I’m publishing it belatedly, but backdated in order to not confuse people.

I was browsing the xfce4-dev mailing list when I stumbled on a request for comment by Steve Dodier-Lazaro (who I knew in the past through the #exaile IRC room) on his article regarding the design of authorisation UIs.

The article covers a lot of ground, from current issues plaguing these UIs (in Windows UAC dialog, gksu, etc.), to the types of operations in Wayland that are planned to require authorisation, to brainstorming ideas for moving forward. A lot of issues are still unsolved and I suspect will be years away from being solved, but I’m glad that people are talking about them. The article also calls for further academic research on fixing these issues.

The next version of Exaile, which was to be version 0.3.3, will be version 3.3.0. We feel that the 0.x versioning was more confusing than actually useful or representative of the development process; in addition, the new versioning avoids long version numbers like 0.3.2.1.

In related news, Exaile 3.3.0 is going to be released soon. The RC is already out; please help us test it and iron out last-minute bugs.

If you’re compiling a piece of code and getting an error message saying something about PUSHL or “invalid suffix for PUSH”, it means you’re feeding x86 assembly code to an x86_64 assembler.

Possible causes:

• The code you’re trying to compile really does contain x86 assembly, perhaps inlined from C, but you’re targeting x86_64.

• Your toolchain somehow contains a mix of x86 compiler and x86_64 assembler. Try cleaning up your PATH.