Romain Lenglet's old web page

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.

Tom version 2.3 has just been released. Tom is an excellent pattern matching compiler that generates Java™ code to match terms in the form of graphs of Java™ objects. Tom is free software, and released under the GPL.

This reminded me that about one year ago I wrote a Tom specification for Erlang/OTP's Jinterface library, to allow to match Erlang terms represented as Java™ objects that are instances of Jinterface's classes. I wrote it to simplify a Java™ interface to IDX-Tsunami's (now renamed Tsung) system performance monitor. For its first birthday, I have published this specification (jinterface.tom and its support class org.erlang.PatternMatchingUtility), under the LGPL.

Update (2006-05-01): I forgot to include the code of the Java™ class (org.erlang.PatternMatchingUtility) which implements utility methods that are called by the pattern matching code generated when using jinterface.tom. Now, both files are ditributed in an autotooled tarball: jinterface.tom-0.1.tar.gz. Just run ./configure ; make ; make install and files should (hopefully) compile and install in /usr/local/share/java/.

Here is an example of a Java™ class using this specification (the file should be named Test.t to reflect that the code is in Java™ extended with Tom syntax):

public class Test {

    /*
     * Include the JTom-Jinterface specification.
     */
    %include { jinterface.tom }

    /*
     * This is a normal Java method, which code uses Tom's
     * extensions to the Java language.
     */
    protected void matchMessage(OtpErlangObject message) {

        boolean matched;
        long operationIdentifier;
        String nodeName;

        /*
         * The message matches if it has the form:
         * OtpErlangObject message =
         *     new OtpErlangTuple(new OtpErlangObject[] {
         *         new OtpErlangAtom("get_reply"),
         *         new OtpErlangLong(operationIdentifier),
         *         new OtpErlangString(nodeName),
         *         new OtpErlangLong(value) or new OtpErlangDouble(value)
         *     });
         *
         * Match the message, using Tom's "match" syntax, similar to
         * Erlang's "case" construct:
         */
        %match(Term message) {
            tuple(atom("get_reply"),
                long_number(opId),
                string(nN),
                double_number(value)) -> {
                    matched = true;
                    operationIdentifier = opId;
                    nodeName = nN;
                    System.out.println("Matched double value: " + value);
                }
            tuple(atom("get_reply"),
                long_number(opId),
                string(nN),
                long_number(value)) -> {
                    matched = true;
                    operationIdentifier = opId;
                    nodeName = nN;
                    System.out.println("Matched long value: " + value);
                }
        }

        if (matched) {
            System.out.println("Node name: " + nodeName);
            System.out.println("Operation id: " + operationIdentifier);
        } else {
            System.out.println("Message did not match.");
        }
        
    }

}

This file must be compiled with Tom's compiler, to generate the actual pattern matching source code in the Test.java file which can then be compiled as normal Java™ source code:

> tom --static --wall --verbose --pretty Test.t
> javac Test.java

If you installed the jinterface.tom file into /usr/local/share/java/ directory, you must pass an --import /usr/local/share/java/ option to the tom compiler. And add /usr/local/share/java/ to the CLASSPATH so that the Java™ compiler can find the org.erlang.PatternMatchingUtility class.

Some types of terms are still not yet supported by my Tom specification: binaries and new style references. And maybe I should switch to Ant as the build tool for the support class, instead of GNU Automake's horrible support of Java™ (and of almost anything, by the way...). Any volunteers?