Relocation and SDL2

Things have been a little quiet here recently. I am pushing ever westward; this time I moved from sunny Littleton, Colorado, to the equally-sunny Mountain View, California. I’m close enough to Google’s headquarters to be able to see their city-wide free wifi on my laptop, but far enough away that I can’t use it.

Relocation is something of a theme. The little coding time I’ve had has mainly been spent moving repositories from Mercurial/BitBucket to Git/GitHub so that I can hang out with the cool kids. Actually, I’ve been using Git exclusively for about five months and find that, when I do need to use Mercurial, I can’t remember how it works. Within the repositories, I’ve done some relocating too: consolidating DS and SDL code.

SDL2 was released not too long ago and I thought I’d have a play and see if it offered anything new. It seems the most important change for my SDL projects was the inclusion of automatic texture format conversion within the library itself, meaning it has built-in support for converting and displaying bitmaps in ARGB1555 format. This means that all of my DS projects no longer need to keep track of two bitmaps - one in ARGB8888 and one in ARGB1555 format - when in SDL mode.

Upgrading to SDL2 has allowed me to merge the SDL and DS codebases together, meaning I now have a single repository that will build for the DS and OSX out of the box. Getting them to build in Windows and Linux should be trivial. Additionally, the makefiles for the DS versions all work with the latest devkitARM. Something must have changed in the build system as all of the makefiles were broken.

In other news, I’ve been tinkering with Woopsi again. The complex, C#-inspired EventArgs system is out and I replaced it with the set of arguments that are relevant to each event. Gadgets no longer support multiple event handlers; each can now have just a single handler. Much tidier.


Gobble Moves to GitHub

Gobble is now stored in a Git repository on GitHib:

Other recent changes to Gobble include the addition of support for per-theme favicon.ico and robots.txt files.

It’s been just over a month since I decided to gradually switch from Mercurial to Git. Thus far the change has been surprisingly enjoyable. Git’s extra flexibility turned out to be a good thing. Somewhat disturbingly, I’ve already forgotten how to perform basic operations with Mercurial. Travis CI is next on my list of new Git-powered toys to investigate.

In other Gobble-related news, I’ve removed Google Analytics from this site. GoAccess is a neat web server log analyser that does everything I want, and it keeps Google’s grubby little paws off my website.



When I first made the switch from Subversion to Mercurial, I tried out most of the available DVCS options: Git, Mercurial, Fossil, Monotone, Darcs and Bazaar. I wanted something that was easy to use, powerful and cross-platform. Only Mercurial and Fossil met the criteria. Fossil’s weird file system handling and lack of built-in Creole or Markdown support in its wiki eventually killed off my enthusiasm for its unique feature set, leaving Mercurial.

Mercurial is possibly the greatest development tool ever created. It completely altered the way I write code and made me immeasurably more productive. Its command line UI is a work of art. Every command is obvious and works exactly as you’d expect. Any chance I get I promote it, especially to the folks who still think that TFS is a really neat idea.

When I was evaluating DVCSes, Git had two main failings:

  • Windows support was second-rate;
  • The UI was designed by Linux programmers and made absolutely no sense.

Though the official Windows client is still an afterthought, Windows support is getting better. Microsoft themselves are adding Git support to TFS and Visual Studio; considering their attitude to Linus Torvald’s other work, this is deeply ironic.

The UI hasn’t improved in the last few years. It still has counter-intuitive commands that are overloaded to perform multiple actions that have little relation to each other. Users are still required to be experts in Git’s data structures in order to use the tool effectively.

Despite these failings, Git has become the de-facto DVCS. It is vastly more popular than any of the others I looked at, including the dreamlike Mercurial.

Microsoft aren’t the only company to have integrated Git into their tools. Xcode 4 uses Git as its default source control system, and Xcode 5 looks to be basing a number of very enticing new features around it. Though I don’t want to, it’s time to add Git to my toolbox.

Here’s my initial Git session:

git init test
vim test.md
git add .
git commit -m "Initial commit."
vim test.md
git commit -m "Edited text."

Working well so far. Now let’s try branching.

git checkout HEAD~1

Hmm. You are in ‘detached HEAD’ state.

vim test.md
git add .
git commit -m "Branch edit."
git checkout master

Warning: you are leaving 1 commit behind, not connected to any of your branches. That’s unexpected. I have no idea what it means. Mercurial allows multiple heads on the same branch; doesn’t Git?

git log --oneline

e48b1bf Edited text. 6739f7f Initial commit.

Two commits. I made three. Yikes.

At this point I decided that the only way I was going to learn to use Git properly was if I forgot everything I knew about Mercurial and approach Git as an entirely new tool. I’m up to chapter 3.6 of the Git book and it’s making more sense. The command aliasing function goes some way to alleviating some of the pain of the insane UI, it has some exceptionally cool features, and suddenly I find that I’m looking forward to using it.

As a test run, I’ve migrated the Super Foul Egg iOS source code to GitHub:


Blogging with Mercurial from the Rocky Mountains

It’s been a while since the last update, but I do have a good excuse. I’ve upped sticks and moved from dingy Birmingham, in the UK, to sunny Littleton, Colorado, in the USA.

So, who’s hiring?

I’ve decided to start blogging about those experiences, but rather than flood this blog with personal posts I’m making a separate blog. But what blogging platform to use? It’s not going to have much traffic, I don’t want to put any admin time into it, I don’t want comments or tags or categories. All I want is to be able to post text as quickly as possible using Markdown.

It would be great if there was a blogging platform for Mercurial like the one available to Github users, but I’ve looked around and haven’t been able to find one. So why not write one?

Here’s my list of requirements:

  • Displays blog posts in reverse chronological order (newest first).
  • Posts are written in Markdown and reformatted into HTML automatically.
  • Posts are stored in a repository on BitBucket.
  • Pushing to the posts repository automatically updates the blog.
  • Allows paging through blog posts.
  • Includes an “Archive” page that lists all blog posts.
  • Has an RSS feed.
  • Maintains a cache of blog posts to minimise queries to BitBucket’s API.
  • Looks a bit like WordPress’ “TwentyEleven” theme, as that’s my favourite theme at the moment.

After a couple of evenings of hacking, here’s the result:

And here’s a demo:

A blog powered by BitBucket and Mercurial. Neat!

I’ve included instructions for getting a BitBlogger instance up and running on AppHarbor, a .NET hosting site that offers a basic freemium option. As BitBlogger doesn’t use any local storage or background events (BitBucket notifies it of changes, rather than BitBlogger needing to poll for updates), it doesn’t need anything above the free package.

I’ve copied bits and pieces of the TwentyEleven theme’s CSS file in order to replicate some of the appearance, so the licence for this application is the GPL rather than my preferred MIT licence. If anyone feels like putting together a simple and very legible theme to replace the current look and feel, I’ll be able to switch it over.


Installing Hatta on Windows

I’ve been trying to find a replacement for a SharePoint 2007 wiki that was foisted on my team. If you’ve ever used SharePoint’s standard wiki system, you’ll know that it’s just a cruddy wiki-like front-end for a ropey CMS. Browsers other than IE have the WYSIWYG editor disabled and the user is left to edit raw HTML. Wiki markup? What’s that?

I’ve got a number of requirements for the replacement.

Must be cross-platform

As I find myself developing in both C# and Objective-C, I need a wiki for half a dozen trusted users that works in Windows and on the Mac.

Must use a standard wiki markup

I’d prefer Markdown or Creole. As long as I’m not forced to drop into HTML or use a WYSIWYG interface I’ll be reasonably happy.

Must be easy to set up

Preferably I just want to run an installer and have the wiki running. Every dependency I need to install and set up - web server, database server, scripting language - is a mark against it.

Must be simple

I neither need nor want authentication systems, online help, sandboxes, advanced formatting, styles, drawing APIs or file uploading. Just a way to store short, linked text documents.

Must use a DVCS as its storage system

If the wiki stores its data in a DVCS I can clone it and take it home with me.

What I really want, I realised, is an open-source version of BitBucket’s wiki. I’ve looked at dozens of systems. The most promising are MoinMoin version 2, which unfortunately isn’t finished yet, and Hatta.

Hatta is a fantastic little wiki. Its features include:

  • Cross-platform (written in Python)
  • Simple but attractive interface
  • Mercurial storage system
  • Creole syntax (for the most part)
  • Built-in web server

It comes in two forms. You can download it as a pre-compiled binary, with all dependencies included, for OSX and Windows. Alternatively, you can download it as a pure Python solution, though this entails setting everything up yourself.

I started out with the binary distribution, which was very easy to get up and running, but I quickly ran into problems. The binaries are now 4 minor revisions out of date, and according to the author the chances of them being updated are slim to none. Worse, the binary regularly freezes up. That’s no use as a centralised wiki.

Trying to get the plain old Python version working in Windows is a pain as there’s no documentation for it, so here’s how to do it.

Installing Hatta in Windows

Firstly, we need to get Python set up and install Hatta’s dependencies.

  • Download Python 2.7.2 from python.org. Hatta will not (currently) work with Python 3.
  • Install Python using all of the default settings (just keep hitting “Next”).
  • Download “setuptools” from pypi.python.org. Assuming you’re using a 64-bit version of Windows you’ll need to download the “ez_setup.py” script and run it like this:
C:\Python27\python.exe .\ez_setup.py
  • Open up a command line as admin and enter the following:
cd C:\Python27\Scripts
.\easy_install-2.7.exe werkzeug
.\easy_install-2.7.exe pygments

That’s Python installed and two Python packages that Hatta is dependent on. Next we’ll need to download Hatta itself and integrate it with Mercurial.

  • Download Hatta from hatta-wiki.org. You’ll need the zipped version.
  • Unzip Hatta to C:. This should give you the following paths:

Etc. You don’t have to put Hatta in the root of C: but it simplifies this guide.

  • Download the Mercurial source code from mercurial.selenic.com. The binary builds are of no use to us.
  • Extract the tarball.
  • Open the extracted directory and locate the “mercurial” folder.
  • Copy the “mercurial” folder to C:\Hatta\ (giving you the folder C:\Hatta\mercurial\hgweb etc).
  • Copy the “hgext” folder to C:\Hatta
  • Open the “mercurial” folder in C:\Hatta.
  • Open the “pure” folder.
  • Copy the contents of “pure” into the “mercurial” folder (giving you C:\Hatta\mercurial\bdiff.py etc).

We’re done! What we’ve done is copy the parts of Mercurial required by Hatta into the Hatta directory. Yes, this is an ugly hack, but it’s the easiest way of getting Hatta up and running. When new versions of Mercurial get released, you’ll need to delete the “mercurial” and “hgext” folders and upgrade them with the latest source (remembering to fiddle about with the “pure” folder).

You can now test the installation by opening a command line and typing:

C:\Python27\python.exe C:\Hatta\hatta.py

Point your web browser at http://localhost:8080 and, if everything has gone to plan, you’ll see the Hatta editor page.


BitSyncPy Updated

BitSyncPy, my Python 3 utility for pushing/pulling/cloning/etc a whole directory of Mercurial repositories with BitBucket, has had a few updates. It now works under OSX (and should therefore work with Linux). It can also force local repository names to be lower case when cloning.


BitBug and BitBugPy

Another pair of C#/Python programs. This time it’s an idea branched from BugBare, my distributed bug tracker. The real problem with distributed bug trackers is their complete lack of utility and visibility for people who aren’t programmers on the project in question. BitBug dumps the distributed part and is really just a command line interface to BitBucket. All bugs are stored in BitBucket’s issues database. They obviously don’t work offline, but they’re as quick to use as BugBare and come with a ready-made web interface.

The two programs are here:

Of the two, BitBugPy is the tidier program. It uses the BitBucketAPI library for all BitBucket interaction, so the script itself is tiny. Again, it uses Python 3.2 (release candidate) so I’m sure 99% of the world won’t be able to use it. I’d look into making it a Mercurial extension, but - shock! - Mercurial is written in Python 2, not 3, and I’m not interesting in backporting it.

The C# version - BitBug - uses my MurkyCommando library as its command line UI. Since playing with the various command line argument parsers in Python I’m a lot less happy with it now.

They are both rather limited at the moment, mainly because the API offered by BitBucket is still a work in (very slow) progress.



Combining Python, the best parts of BitSync and BitBucketAPI has produced BitSyncPy. This is a very short Python 3 script that will:

  • Connect to BitBucket’s API using a user-supplied username and password;
  • Get a list of the remote repositories belonging to a specified user;
  • Get a list of local repositories in a specific path;
  • Print the total number of remote and local repositories;
  • List any repositories that are local but not remote;
  • Clone all repositories that are remote but not local;
  • Pull/update all repositories that are both local and remote.

It’s essentially the same utility as the C# version of BitSync, but it’s a fraction of the size and should be cross-platform. Note, however, that it uses the new argparse module included in Python 3.2 (yep, I’m running the release candidate) and so won’t work without modifications in the stable version of Python 3.1. It won’t work in Python 2 either.


Farewell to SourceForge

SourceForge has been Woopsi’s source code host since October 2007. They’ve been a great host. They offer some excellent features, and haven’t charged me a thing for nearly 3 years of diligently caring for my code. However, both technology and “social” coding techniques have improved since I adopted Subversion. I’ve found modern distributed version control systems to be faster and more flexible than Subversion, whilst the forking capabilities provided by sites such as GitHub and BitBucket make collaborating with other coders incredibly easy.

A request from Lakedaemon that I move Woopsi to a DVCS finally convinced me that it was time to move on, so I’ve switched from Subversion to Mercurial. Woopsi and its associated sub projects are now hosted on BitBucket:

The SourceForge page remains in place as it’s impossible to close a SourceForge site that has code committed to it. It now includes a notice indicating that the project has moved.


Loose Ends

I have released a few other projects to the tinterwebs recently, but haven’t as yet announced them.


First up is version 3.0 of ALite, a simple data-access and data validation framework for .NET4:


This version simplifies much of the framework. I went off on a wild tangent before moving the repository from SourceForge to BitBucket and started implementing features such as pseudo-transaction support. I even tried real transaction support using the classes from the System.Transactions namespace, but ran into so many nasty problems that it quickly became obvious that it wasn’t going to work.

Instead, ALite now works much more like Igmongonious. It uses a document (key/value store) to store the values of properties, which simplifies and speeds up the undo system. Swathes of code have been refactored to make the framework easier to use.

The “changelog” document seems to be inaccurate so I can’t give a complete breakdown of everything that has changed. Fortunately, no-one but me is crazy enough to use this library.

I moved the repository from SourceForge to BitBucket for a number of reasons. SourceForge has done some neat things with their UI and added a host of exciting new features, but:

  • BitBucket is a better fit for small projects like this. SourceForge’s insistence on manually vetting all projects doesn’t seem to have alleviated the amount of junk projects in its database, but it does increase the amount of work necessary to get what should be a minor project up and running.

  • Mercurial is magnitudes faster than SubVersion, particularly when SubVersion is lumbered with SourceForge’s horribly slow SVN servers.

  • BitBucket projects come equipped with a Creole-based wiki. Though SourceForge has recently added a per-project MediaWiki installation to their suite of features, Creole is notably terser than MediaWiki markup. The wiki is much simpler, which again is perfect for smaller projects. The entire wiki can be pulled down as a Mercurial repo allowing local editing and change tracking.


Next up is Chroma-X, my ill-fated, unfinished and unfortunately-named shoot-em-up for the GP2X:


Nothing new in here, but the sourcecode is browsable and easily accessible. Incidentally, I managed to get the game running on a GP2X Wiz. I was disappointed to discover that it was slower on the Wiz than it was on the GP2X F-200, which put a damper on my Wiz coding plans.

Canvas UI

Lastly, my canvas UI project is also now on BitBucket:


Since the last version I’ve fixed a few bugs and added plenty of new features, including:

  • Window close and depth buttons;
  • Scrolling lists;
  • Shadows on label text for disabled buttons;
  • Separation of GUI definition from library code.