I expect that there'll be several good puzzles that come out of the ICFP competition last weekend. Here's one to start us off.

The problem statement explains the format of a binary file that contains a data dump for a program to run on a virtual machine. How the machine works isn't important for this question, suffice it to say that it has two memory areas: One is for the program itself which is held as 32 bit integers. The other memory area is data memory which is held as 64 bit double precision floats. From the specification document:

The Orbit executable format stores the values for the instruction memory and the initial contents of the data memory. These values are stored in the exe- cutable format in sequential order, starting with the values for address zero. Instructions are stored as 32-bit words, encoded according to the format de- scribed in sections 2.2 and 2.3. Data memory values are stored as 64-bit double precision floating point values. Both instruction and data values are stored in the binary format in little-endian byte order.

The pairing of a 32-bit instruction and a 64-bit data value constitutes a 96-bit frame in the executable file. The order of the instruction and data values varies, depending on the frame address. For frames corresponding to even addresses, the first eight bytes of the frame contain to the double data value, while the next four bytes constitute the instruction value. Conversely, for frames corresponding to odd addresses, the first four bytes contain the instruction value and then next eight bytes contain the data value.

During the competition we were wondering if the strange format was only to annoy us, but afterwards I realised that there is another more subtle reason. What good explanations for this format can you come up with?

I only heard that the ICFP competition was approaching over last weekend when I was putting the Fost 4 release together. Since then I've been starting to put a team together based around the BarCamp Thailand participants.

At the moment we have a few very talented developers who are going to put some serious effort in, a few who will probably drop in from time time and we even have a support group who will cheer us on.

Membership is open, you don't need to be involved with BarCamps, be in Thailand or even be a developer. If you want to join the team then you should do something along these lines:

1. Make sure that your computer is properly set up and you have internet access. If you're going to come to the Felspar offices let me know so I can send you a map. Space isn't infinite, but it won't matter if you're somewhere else as we expect to be working with people all over the internet, at least in Thailand.
2. Head over to http://support.felspar.com/ and register an account there. Email me (privately, don't spam the list) your log in name. I need to add you the project team and add the same credentials to the subversion repository.
3. Once you can get to the project homepage, post a bit about yourself to the team introduction thread.
4. I'll also supply you with an SVN repository URL. You should be able to check out from it and check in to the sandbox. We'll start to fill up trunk properly when the competition starts.

The project pages and the subversion repository will be private to team members until after the competition when they'll be open to anybody to read. At the moment we expect that we'll be using mostly Python with maybe some C++ or other things depending on what the problem is.

Last year I entered on my own and didn't have much time to put into it. My little rover still managed to get into the second round of heats though which I found flabbergasting!

Given who's already joined the team for this year I think we can do a lot better, even if I don't do anything at all — maybe especially if I don't do anything at all :)

There were certainly times over the past few days that I wasn't sure if we were going to get anything useful released to stable branches in our Subversion repository for our planned release of Fost 4 today.

The intention is now to work towards a release every three months (on the 21st of March, June, September and December). We may also put out additional service releases on the 21st of other months.

The current status page shows a number of useful aspects of the libraries that are stable right now¹ [1There isn't much documentation online yet for these, but that should change over the course of the next few weeks.]. There's a load of good stuff in there, but the really interesting bits are those that are not yet stable — especially the new database abstractions that are going in to the O/RM.

The new O/RM layer isn't really an object/relational mapping at all, it's more than that. The database drivers abstract things at a much higher level which means that we can support non-relational databases as well. There's a JSON database included that is fully transactional and works with the same object persistence database driver API that the Postgres and Microsoft SQL drivers implement.

And as we're eating our own dogfood this web site and several others are running on a Fost 4 base, although most of the top part of the web stack is still FOST.3™. As well as making extensive use of the stable parts of the stack, the web sites are also using much of the more experimental code, for example the new database drivers.