Software

Since my trusty softmodded xbox died on me, I have been forced to hook up my laptop to the TV whenever I wanted to enjoy a movie on the big screen. I quickly got tired of fumbling with cables all the time, so I resolved to find a used original XBOX and once again softmod it to install XBMC on it.

I'd like to share with you a precious software gem: Scintilla.

Scintilla is an amazingly powerful text editing component. I am coding Prompter, a presage based demo application, on top of the Scintilla editing control because of Scintilla's impressive features, primarily portability and autocompletion support.

I always thought that VMWare Server is a great piece of software. It is a fast and convenient way to run my soothsayer builds on a Windows platform without actually having to get dirty running it on my (real) hardware.

However, it has a couple of shortcomings that I can no longer live with:

• it is not free as in freedom (although it is free as in beer)
• it does not work with the latest kernels (its kernel modules do not build with the latest kernel sources)

Not to fear, my friend, for QEMU and VirtualBox are excellent alternatives to VMWare!

multithread.org has been updated and is now running on the latest release of the excellent content management system Drupal.

Changes are mainly under the hood. I tried to retain the look and feel of the original site, except where I made improvements to the layout and styling of a few elements.

Recently, I created a Python binding for Soothsayer and integrated it into the build system using some Autotools magic and a few custom m4 macros obtained from the Autoconf Macro Archive.

The first solution I put in place was largely based on this (very good) tutorial. In a nutshell, this is how it worked:
- configure.ac runs a few checks to determine whether SWIG and Python are available, using the AC_PROG_SWIG and AM_PATH_PYTHON macros respectively. If the user enabled the Python binding module with the --enable-python-binding, then the SWIG_ENABLE_CXX and SWIG_PYTHON macros are invoked to setup SWIG flags.
- the bindings directory contains the SWIG interface file, which needs to be parsed through the SWIG tool to generate the wrapper (a C++ source file and a Python source file).
- during a build run, Makefile.am in the bindings directory contains targets that cause SWIG to process the interface file to generate the wrapper, then compile the generated wrapper, and finally link with the wrapper object and the soothsayer shared library into a Python _soothsayer loadable extension module.
- during an install run, the generated files and library are installed into the Python extensions directory.

However, this solution had a couple of problems that I could not force myself to overlook:
- the generated sources had to be generated into the source tree, rather than in the build tree, in order for the macro defined primitives to work.
- the AC_PYTHON_DEVEL macro, required by SWIG_PYTHON, fails to detect a default Python installation on Windows/Cygwin (requiring the user to tweak the LDFLAGS when configuring the package to work around the problem).
- it does not use the recommend Python way to build Python extension modules.

If your autoconfiscated project uses local autoconf macros, then the initial bootstrapping will involve running `aclocal -I path/to/local/m4/macros'.

This is all fine and dandy, but during development the autotools might have to regenerate the aclocal.m4 file. When this happens, aclocal will be run without the -I flag, resulting in undefined macros errors. How to fix them?

The fix consists of adding the following substitution to your configure.ac:

AC_SUBST(ACLOCAL_AMFLAGS, "-I path/to/local/m4/macros")


This will ensure that we aclocal is automatically invoked by make, it will be called with the specified -I flag.

What do you get when you cross a best of breed intelligent predictive text entry platform with a fast dynamic object-oriented programming language?

Why, of course, you get a python binding for soothsayer!

I just added a feature and fixed a bug in soothsayer. Nothing special about that, one would think.

What makes this bug significant is that it affected the simulator component. soothsayer comes with a simulator program that takes a file and reads each character from the input file and sends it to the soothsayer prediction engine. The simulator counts the number of key presses required to enter the desired text using the soothsayer prediction engine and the number of key presses required to enter the same text with no prediction enabled.

It's not something I usually do. It is actually something I have never done. So please indulge me for a few bytes of text.

Ladies and gentlemen, it is now time for a shameless plug.

Soothsayer 0.4 has been released. You can head over to the recently redesigned soothsayer project website to learn more about the latest release and try it out for yourself.

It is official. The AIX operating system has taken that special place in my heart that was once reserved to Windows.

That's right! AIX is now the operating system that I have most hatred and contempt for.

What kind of operating system is not capable of performing the most basic function of killing a process?

You would hope that the answer to that question would be 'None'

Take a look at the following `topas' output:

Topas Monitor for host:    henk3                EVENTS/QUEUES    FILE/TTY
Mon Jul 16 15:28:48 2007   Interval:  2         Cswitch    5099  Readch      988