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.
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.
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 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.