Blogs

Debugging Java applications remotely can be extremely useful when the machine you are debugging on does not have access to the source, or when the application you would like to debug is run within a complex wrapper or framework (i.e. Maven).

If you ever wished to debug a Java application remotely using Eclipse, here is how you do it.

If you ever make the big mistake of trying to install a Microsoft operating system on your machine, you will know that lots of things can go awfully awry.

This Slashdot article warns that a default setting may be dramatically shortening the life of your laptop's hard drive due to an aggressive power-saving feature / acpi bug / OS configuration.

If the load cycling count has a high value, compared to the expected life time of the hard drive and the expected maximum load cycle count, then your hard drive might be affected too.

Just returned from a life changing, perspective shifting trip to the Indian subcontinent.

You can find a detailed account of what happened here.

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.

Soothsayer now builds and runs on Solaris 10!

Porting soothsayer to Solaris 10 was a breeze. No changes were required to soothsayer core code. There were a few minor issues with the curses library and the Standard Template Library (some definitions in the curses header conflicted with standard vector and standard list code), but they were quickly resolved.

I successfully built and tested soothsayer with Sun Studio 10 and Sun Studio 11 compilers.

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.