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

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

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.