Soothsayer

soothsayer: the intelligent, extensible, predictive text entry platform

Autoconf, Automake, SWIG, Python distutils

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.

automatic autotool invocation of aclocal

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.

wrapped by a python

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!

didn't mean to be modest, to be honest

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.

predicting the future one word at a time

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.

Syndicate content