Software development

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.

Handling pointers with references

While doing some refactoring on soothsayer over the weekend, I was once again reassured that one of the software engineering principles that I always adopt when designing systems still holds true.

The principle in question is the age old tips of preferring C++ references to pointers. As the excellent C++ FAQ Lite simply puts it: ``Use references when you can, and pointers when you have to''.

I had to switch from references to pointers in order to add a new feature. This required a refactoring of the relationships among some core components in the system.

Debugging in the Cygwin environment

Cygwin!

Ah, the joy of debugging. There is nothing quite like spending time unsuccessfully trying to track down a problem in someone else's source code. </sarcasm>

Right... What really makes it bad is when you can't even avail of the set of tools that you've grown accustomed to from working in a Unix environment.

Working in Cygwin is certainly more pleasant than working in a vanilla Windows environment, but it doesn't afford quite the same power and flexibility of working in a native Unix environment.

openmaia and Unicode

Yes!

I just got a working build of openmaia using Unicode enabled wxWidgets libraries.

The changes are simple but quite extensive, since conversion between wxString and char* occur in variuos parts of the code. The patch file is currently more than 1250 lines long, but there is more work to be done.

While the core virtual keyboard works fine, I haven't tested the maiasms component since I don't have access to a mobile phone that I can link up to my laptop.

Converting wxString to C string const char*

wxWidgets is an extensive, free, open-source, and mature cross-platform graphical toolkit. Formerly known as wxWindows, wxWidgets applications look and feel just like a native application, since wxWidgets uses the native graphical toolkit for the target platform it is compiled for.

wxWidgets has an impressive number of features, which makes it an excellent choice for cross platform graphical application development.

One useful feature is support for Unicode. wxWidgets provides a wxString class which abstracts away from standard ASCII encoded strings and Unicode encoded strings.

Death of a deadline

They say the life of a software engineer is a very stressful ride through a thick forest of unmet deadlines and eerie technical problems.

It is not always that bad... but, sometimes, it is even worse. Like yesterday.

I worked on implementing a set of new features. I took hardly any breaks during my coding hours, slaved away in the office, and even worked over the weekend to try and make up for some time.

A few weeks earlier, I genuinely thought that I would be able to complete my tasks within two weeks, and I therefore committed to having the new features implemented in that timeframe.

Syndicate content