I began integrating the scripting code into the Simulation this week. This follows some interesting reduction issues that can be summarised by the following example. The current method takes text from a script file, removes the white space (tabs, spaces carriage returns etc), converts this code to byte code (referring to arithmetic/logical operators, variables etc), then the byte code is interpreted and any error is reported.

As text is always presented, the creation of byte codes - an entire and coherent set of byte codes - seems redundant as these codes are used and discarded progressively.

Far more important is the error handling that is needed for integrated scripting. Two examples relating to this is infinite loops and actual error handling.

If a user inadvertently writes an infinite loop - that is a loop with no end (10: goto 10;) - you don't want the Simulation to freeze. Within the scripting code, there is an interpreter loop that takes the byte code and runs the code. There is a counter inside this loop and every so often it triggers the mouse/quit/handle external events section of the Simulation. This has taken some rewriting in separating the needed OS end code and code that isn't critically needed in an exit situation.

To-date the kind of errors the Noble Ape Simulation is presented primarily came through programmer error and through the file handling. Programmer error was minimised through testing the changed code between releases and regular use testing. Whilst not perfect, it eliminated most of the problems. As the files save from and opened by the Simulation are text and user editable, the file handling code to-date has featured the breadth of the error handling in the Simulation. This error handling has been rather minimal.

The interpreter code presents not only file handling code, but also taking this user editable code and interpreting it within the Simulation core in such a way that a number of additional problems can surface - the infinite loop is a single example.

The error handling within the Simulation needed to be rewritten to allow for a breadth of file parsing and interpreter errors. The choice was to have no tolerance for error or to allow some errors that occur and break a simulation cycle but don't terminate the Simulation. The method of reporting errors now comes through the brain window. If there are any errors found, they are reported immediately through the brain window and this can be cleared by starting a new Simulation.

Following the integration of scripting in the Simulation, the final work is writing the documentation. This new code presents a number of challenges. First, I can't fully test this code before releasing the software. For this reason I'm considering an extraordinary release which would put the executable on the Noble Ape site but not do a traditional version release update.


The project formerly known as DarwinAtHome, now working under the name BiotaAtHome, continues. The name change aligns the project with and reduces some of the work with the definition of the project through the website.

The draft white paper and the new brief project page can be seen through;

Following this Mailout, I'm hoping for a confirmation date for the launch of the white paper. Per my narrative on the project through my personal log, getting a number of new folks involved with the project with the right skill-set will guarantee the success of the development. It is an interesting test case of developing a project through a shared need rather than a focused project plan. The white paper is intentionally vague as the minute objectives of BiotaAtHome will be defined by the breadth and abilities of those involved.

I am sure there will be plenty more on this project in future mailouts as the development continues in parallel to Noble Ape.

Hope all is well with you all,

Tom Barbalet, 26 April 2005.

Noble Ape - Mailout Archive