Romain Lenglet's old web page

I am back from Portland, OR, USA. I have attended the ACM SIGPLAN Erlang workshop, the ACM SIGPLAN ICFP conference, and the CUFP workshop. I have taken a few photographs of all events.

The article about Dryverl that I have presented in the Erlang workshop, and the presentation's slides, are freely available.

I have written a small module for the decoding of Palm® Datebook database files: palm_db.erl and palm_db.hrl. Datebook database files contain all the appointments of a Palm® PDA.

Note that it can only decode database files that have been archived by a synchronization software. It does not implement a synchronization conduit, i.e. it cannot do synchronization on the fly. Implementing a conduit would have been much more difficult, because it would have required to integrate into an existing PDA synchronization framework such as KDE's Kitchensync framework, etc.

To implement this module, I have read the official Palm® file format documentation, and I have looked at the implementation of p5-Palm, a collection of Perl5 modules for reading and writing Palm® database files. It must be noted that my rewriting into Erlang is much concise and readable than that Perl implementation. Erlang's binary pattern matching feature really makes a difference. Although Perl is unsurpassed when manipulating text, I believe that Erlang is the best programming language to manipulate binary data, even in small script-like modules like this module.

I have developped a small module that uses the palm_db module for generating files for the GNU Emacs Diary application: palm_datebook_to_diary.erl. This module is not complete: it does not support repeated entries, nor alarms, etc. Yet, it is still useful in practice.

To use it, you must first save your Datebook database using your synchronization software. For instance, when I use KDE's Kpilot under GNU/Linux, that database is saved in file: ~/.kde/share/apps/kpilot/DBBackup/pda_profile_name/DatebookDB.pdb. To decode this file and generate an Emacs Diary file, execute:

> erl -noshell -run palm_datebook_to_diary start ~/.kde/share/apps/kpilot/DBBackup/pda_profile_name/DatebookDB.pdb -run init stop > ~/diary

Then, in Emacs, you can display the diary for the current date by executing the M-x diary command.

The code of those modules is distributed under the GPL.

I have contributed a patch to Autoconf's Erlang-related macros, adapted from a patch sent to me by Ruslan Babayev. The AC_ERLANG_CHECK_LIB macro has been modified to set the ERLANG_LIB_VER_library variable when checking for the presence of a library library. The macro sets it to the version number of the library, in addition to setting the ERLANG_LIB_DIR_library variable to the path of the library directory. For instance, to check the presence of the erl_interface library, and to get its version, you can include those lines in your configure.ac file:

AC_ERLANG_CHECK_LIB(erl_interface)
AC_MSG_NOTICE([erl_interface version: \"$ERLANG_LIB_VER_erl_interface\"])
AC_MSG_NOTICE([erl_interface directory: \"$ERLANG_LIB_DIR_erl_interface\"])

Those new ERLANG_LIB_VER_library variables can be used for two purposes:

• To check that the installed version of a library matches a specific version or range of versions.
• To automatically rewrite .rel files to contain the versions of libraries that are actually installed. I will write about this in a future article, since Ruslan also sent me a nice application skeleton that makes use of those features. This deserves a separate article.

To compare version numbers, I recommend to use the AX_COMPARE_VERSION macro that is part of the Autoconf Macro Archive, a collection of freely reusable GNU Autoconf macros. In Debian GNU/Linux, it is distributed in the autoconf-archive package. For instance, the following configure.ac file snippet checks that the Erlang/OTP stdlib library is installed, and that its version is greater or equal to 1.14:

AC_ERLANG_CHECK_LIB(stdlib, [],
    [AC_MSG_ERROR([Erlang/OTP stdlib library not found but required])])
AX_COMPARE_VERSION([$ERLANG_LIB_VER_stdlib], [ge], [1.14], [],
    [AC_MSG_ERROR([Erlang/OTP stdlib library version >=1.14 required])])

Or better, to be more pedantic and to fit better with the standard behavior of Autoconf's macros, notably to support Autoconf's caching capability:

AC_ERLANG_CHECK_LIB(stdlib, [],
    [AC_MSG_ERROR([Erlang/OTP stdlib library not found but required])])
AC_CACHE_CHECK([whether the version of the Erlang/OTP stdlib library matches],
    [erlang_cv_lib_vercheck_stdlib],
    [AX_COMPARE_VERSION([$ERLANG_LIB_VER_stdlib], [ge], [1.14],
     [erlang_cv_lib_vercheck_stdlib="yes"],
     [erlang_cv_lib_vercheck_stdlib="no"])])
AS_IF([test "$erlang_cv_lib_vercheck_stdlib" = "yes"], [],
    [AC_MSG_ERROR([Erlang/OTP stdlib library version >=1.14 required])])

The configuration test above could be refactored into a reusable macro. However, since it uses the AX_COMPARE_VERSION macro which is not included in GNU Autoconf, there is no chance that it could be included into the official GNU Autoconf project. And because the needs for checking Erlang/OTP library versions probably vary too much between projects, it seems better that anyone takes this configuration code snippet and adapts it to his needs in his own configure.ac file.

To use this new version of this Autoconf Erlang macro, you either have to wait for the next release of Autoconf (version 2.60b?), or to use Autoconf's current version 2.60 and to follow the following steps. Create a directory in your project root directory, e.g. named acmacros. In that directory, create a file, e.g. named erlang-new.m4, which contains only the new defiinition of the AC_ERLANG_CHECK_LIB macro. You can download my own erlang-new.m4 file. Project-specific macros have precedence over the macros installed with Autoconf. Therefore, this new definition of AC_ERLANG_CHECK_LIB will be used instead of the one in Autoconf.

In addition, to use the Autoconf Macro Archive's AX_COMPARE_VERSION, you must copy its ax_compare_version.m4 file into the acmacros directory. In the Debian GNU/Linux package, this file is installed in /usr/share/autoconf-archive.

Then, to use those project-specific macros, one only has to give the path to the macro directory to aclocal, which will scan the files in that directory automatically:

> aclocal -I acmacros
> autoconf

Here you are! In a future article, I will write about Ruslan's ideas to automate the configuration of Erlang/OTP .rel and .app files.

The development of gtknode, the Erlang binding for the GTK+ library, is now hosted as a Google Code project. gtknode was previously included in the Jungerl collection of Erlang code on Sourceforge.

The version on Google Code (version 0.15) is the latest version from Mats Cronqvist, the author of gtknode. This version includes my improvements of the build system using GNU Autoconf (and my GNU Autoconf macros) and GNU Automake.

Mats Cronqvist also added a new example application, sherk, which is a preliminary version of a graphical front-end to Mats' (unpublished?) sherk profiler.

There has been no officially released tarball archive for this version, but you can create a tarball archive from the source code by taking the following steps:

1. Download the source code, using Subversion:

   > svn checkout http://gtknode.googlecode.com/svn/trunk/ gtknode
   > cd gtknode
   

2. Generate the configure script, using GNU Autoconf (version 2.59c, or 2.60, or later is mandatory!):

   > aclocal
   > autoconf
   

3. Generate the Makefile.in files, using GNU Automake (version 1.9.5 or later is mandatory!):

   > automake
   

4. Now, create a temporary tree for building, and generate the Makefile files ready for using:

   > mkdir /tmp/build
   > cd /tmp/build
   > ...../configure
   

5. Now, you should be able to create a distributable tarball archive of the source code:

   > make dist
   

These steps create a gtknode-0.15.tar.gz in the current directory. After uncompressing this file, you get the same content as after step 3 above.

To build gtknode, execute the classical command triplet:

> ..../configure
> make
> make install

After installing, you can execute the examples. For instance, go into the installed examples/points directory, and execute:

> erl -sname test -s points start

I have a GTK+-related bug when starting the top example, which replaces the old simple example. I have to investigate into this. I was not able to test the sherk profiler front-end example, since I have not yet found where I can download Mats' sherk profiler from.

Update (2006-09-05T00:17): the top bug has been corrected by Mats in the Subversion repository revision 5. Here is a screenshot that proves that it works now: