Some distributions (e.g. Arch Linux) have decided to make the "python" command run Python 3 by default. This is a problem for us, because Python 3 is not compatible with Python 2. Most Python ROX applications start like this (e.g. Edit/AppRun):

#!/usr/bin/env python

On Arch Linux, these programs will now fail to start. We can't change the line to run "python2", because that doesn't exist on other systems (e.g. Debian).

To solve this, I've added a 0install feed for Python. If your feed currently looks like this:

E is a "secure distributed pure-object platform and p2p scripting language". I've been writing programs in E for a little over a year now. Here's a quick summary of the cool features I've found so far in this surprisingly overlooked little language.

There was some discussion on the mailing list about which programs are still actively maintained. Here's a diagram showing all the programs we include in the no-network bundle and their release dates (from their Zero Install feeds). Releases without dates aren't shown (these are generally very old releases).

I've been busy recently making loads of improvements for dealing with binary releases and compilation:

• 0compile is now much easier to use.

  First, there's the new autocompile feature, where it takes the URL of a program and downloads and builds it, along with any required libraries. This should make it easier to compile and run programs like ROX-Filer on systems where up-to-date binaries aren't available.

  Secondly, 0compile is easier to use when compiling local source code (e.g. a GIT checkout) - you don't have to do the build in a separate directory and it takes the version information from the feed in the checkout, instead of taking a copy.

  Finally, it's better at tracking new versions of dependencies; if a new version is available then it will prompt you to do a clean build (or revert to the older version).

• 0release is a huge time-saver for making releases. Given the path to the local feed in a GIT checkout it can manage the whole release process for you: creating the release candidate, running the unit-tests, diffing against the previous version, signing the release with your GPG key, uploading to your server, testing the upload and updating the Zero Install feed. All you have to do is confirm the new version number and enter your pass-phrase.

  It's always been useful for releasing Python code, but for C programs it previously only published source code. Now, it can build binaries (possibly using remote or virtual machines to build for multiple platforms) and publish them too, automatically, for any program that can be built using 0compile.

• 0test provides an easy way to run your program's unit-tests with any dependencies, but the clever bit is that you can test combinations of versions. For example, you can test a new release against the last five releases of ROX-Lib with one command.

I've also patched ROX-CLib to use 0compile to compile. This has a number of advantages:

Ever wondered what D would be like if its syntax was inspired by Python instead of C? I had to find out, and the result is Delight.

I find the code easier to read without all the extra braces and parenthesis. Delight inherits all the D goodness: classes, interfaces, templates, exceptions, dynamic bounds-checked arrays, etc. Compared to Python, you get speed and static type checking.

I couldn't resist throwing in a few random changes of my own: built-in logging and a modified type system that checks for null pointers statically. I also removed all global state (static variables), and various other things I don't approve of.

All highly experimental, of course. Get it while it's hot...

Earlier this month, Owen Taylor announced Reinteract ("a system for interactive experimentation with python"). I've been wanting something like this for a while now.

In this article, we're going to turn it into a ROX application. In the past, this has meant taking a copy of a program and renaming and changing things to fit the ROX application structure. The trouble is, the ROX version and the original upstream version diverge over time. So, we're going to look at how improvements in tooling can make things easier for us.

This is a guide for people wanting to translate ROX-Filer (or other ROX projects using GIT) into other languages.

Many ROX applications are developed using the GIT version control system. This is how we keep track of each change to the code (who made it, when and why), alternative lines of development (for trying out new features) and which versions correspond to official releases.

For example, you can click here to view ROX-Filer's repository in your browser, which will show you what we're up to at the moment:

• ROX-Filer's GIT repository

One of the great advantages of open source for library authors is that you get access to your users' unit test suites. Ensuring that your library passes its own test suite before release is good, but sometimes your users are relying on features (or undocumented behaviour) you didn't test. Running their tests too can give you extra confidence, and it's easy to make this happen automatically in your release script.

Recently I created a small command line python utility to process some stuff on a TCP socket connection. I used the standard python SocketServer class because it was dead simple to use for my purposes.

However, as the requirements of the utility grew (a GUI), I hit the main problem with SocketServers - they block - which is not so good for GUIs.

So, instead of using nasty old threading, I worked out how to use gobject.io_add_watch() to do everything in the gobject/gtk main loop. This makes it very simple to have this run in a gtk UI without needing threads.