Romain Lenglet's old web page

Since I changed my job in December 2006, I have finally moved this blog to my new personal server, but only for archival purposes. I will no more update this blog. Please visit my new website and blog at http://www.berabera.info/. I hope that you will enjoy the new design as much as I do!

My current position at the Tokyo Institute of Technology funded by the JSPS ends today. Today, I have cleared my office. And I am now on vacation, for several weeks, before I start my new job.

Because of that, I have not been very active online during the last weeks. And as I don't have Internet access at home, I will be mostly offline during the several weeks to come. But I will also have more time to work on my Erlang-related projects (Dryverl, Erlang-related macros in GNU Autoconf...), to develop a new backend supporting Griffin Technology's AirClick USB wireless remote-controller for LIRC (I already have developped a stand-alone program supporting it, based on the libusb, and which I developped by reverse-engineering), to restart playing the classical guitar and learning Csound (I bought The Csound Book), etc., etc.

This will be a very geeky vacation, indeed. (^_^)

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:

I have made the first official release of Dryverl: Dryverl version 0.1. An example “Hello World” Erlang-to-C binding's specification and test program are included in that release.

I have spent my afternoon finishing the configuration and build process based on GNU Autoconf, Automake and Libtools: the dryverl-0.1.tar.gz archive file is built automatically from the SVN repository and when installing, it build another dryverl_hello-0.1.tar.gz archive file for the example, which is then installed in the documentation directory. The dryverl_hello-0.1.tar.gz is itself an Autotools-based archive file, providing an automatic configuration and build process. This archive file is like a “template”, which can be reused and tweaked by users to easily create archive files for building and distributing their own Erlang-to-C bindings.

I have tested that all combinations of C port driver configurations that can be generated by Dryverl are working (with or without input binaries passed by reference, driver set to asynchronous mode or not, etc. etc.), although only a few combinations are covered by the included “Hello World” example. I did not want to make that example too complex at first.

I still have to write a tutorial for Dryverl.

I officially announce the creation of the Dryverl project.

Dryverl is an Erlang-to-C binding “assembly language”. Dryverl lets you specify and control in details all the steps of a Erlang-to-C function call, while hiding implementation details and making it much easier to implement a binding than writing it by hand. The Dryverl “compiler” is implemented as a set of XSLT stylesheets that generate the Erlang and C source code that implements a binding, given a specification of the binding in the Dryverl XML language.

Dryverl is a rewrite of Scott Lystig Fritchie's EDTK, for which I had published two patches. Actually, since I published those patches, I preferred rewriting EDTK almost from scratch. I have written a detailed comparison between Dryverl and EDTK 1.1.

The current discussion on the Erlang-questions mailing-list about Erlang-to-C bindings was a very good occasion to make this project well-known. I have not yet finished the documentation (tutorial, etc.), but... this project had to be announced one day, anyway! ^_^ And Dryverl is already sufficiently mature to be used, in part thanks to Serge Aleynikov who helped me testing it and reported bugs and patches. Thanks also to the ObjectWeb Consortium for hosting this project.

Any contributions to Dryverl are welcome.

Oh, and if you wondered why I drew a “panda-D” in the logo: it is here only because it is cute. ^_^
Update: Some people find that it looks more like a frog or a fish (or even like a tired hunchback). Hmmm...

GNU Autoconf version 2.59c has been packaged for the Debian GNU/Linux Sid distribution. This version contains macros for configuring Erlang projects. There is no need to install my autoconf-erlang package anymore, except in other releases of Debian GNU/Linux with older versions of GNU Autoconf.

Some time ago, Libroscope (a news site in French about Free Software) published a benchmark (in French) of the openness of 23 software projects. They defined and used the following 10 non-technical criteria:

1. Does the project use aggressive marketing methods? (e.g.: make a Google search and compare the number of advertising pages with the number of technical / functional information pages)
2. What is the software license?
3. Are sources available?
4. Is the version control (CVS, etc.) repository readable by anyone?
5. Are there public archives of mailing lists?
6. Is the bug tracker publicly accessible?
7. Are external contributions welcome?
8. Is the project based on open standards and technologies, or on proprietary ones?
9. Is there a “developer-oriented” documentation (e.g. APIs) publicly available for anyone?
10. Misc. (e.g. decision making is not public, or essential features are implemented in proprietary plugins...).

How well does the Erlang/OTP project do according to these criteria? Here is my (highly subjective) opinion:

1. OK: The Erlang/OTP community is essentially a technical community. Ericsson does not do aggressive marketing.
2. OK: The license (EPL) is a copyleft Free Software license.
3. OK: Yes, all sources are available.
4. NOT OK: There is no way to access the current development code, although snapshots are published more or less regularly between releases.
5. OK: Yes, mailing lists archives are public.
6. NOT OK: There is no public bug tracker. For bugs reported by external contributors, though, the erlang-bugs mailing list archives may be considered as sort of a bug tracker.
7. OK: Yes, contributions are welcome.
8. OK: Yes, Erlang/OTP uses a lot of open standards: ASN.1, SNMP, etc.
9. NOT OK: Yes and no. All public libraries and APIs meant to be used by developers are very well documented. But the interpreter internals lack documentation. For instance, where to find information about the implementation of the garbage collector?
10. OK

Result: Erlang/OTP's development process is only “70% open”. I really miss access to the repository and to the bug tracker, and I also miss documentation about the interpreter internals.