January 2006 Archives

2006-01-27

Patch to add support for Erlang/OTP in GNU Autoconf

I have just submitted a patch to Autoconf, on the Autoconf patches mailing-list, that allows to easily:

  • auto-configure paths to Erlang/OTP tools (erl and erlc for now);
  • determine the paths of the installed Erlang/OTP environment and of installed libraries;
  • determine paths for installing built Erlang modules;
  • use Erlang as an Autoconf test language (and it is actually used in my patch to determine the Erlang root path and libraries paths).

That patch is a set of M4 macros that can be used in configure.ac Autoconf files, to automatically configure any Erlang project. My macros are very configurable: many options can be set through environment variables and options to the generated configure scripts, configuration caching is fully supported, etc. I have used those macros personally in my projects for a few month now, and they work fine.

If you want to use that macro file, you must copy my erlang.m4 file (from my patch) directly into the directory of standard Autoconf's macro files (/usr/share/autoconf/autoconf on Debian), then list it into Autoconf's main macro file (autoconf.m4) and update Autoconf's macro cache file with the following commands (as root):

> cd /usr/share/autoconf/autoconf/
> echo 'm4_include([autoconf/erlang.m4])' >> autoconf.m4
> autom4te --language=autoconf --freeze --output=autoconf.m4f

To have an idea of how to use those macros in your own configure.ac, take a look at the dummy configure.ac and Makefile.am files that I sent along with my patch.

It must be noted that my erlang.m4 cannot be correctly parsed by Automake's aclocal program. The reason is that it incorrectly parses macro definitions which names contain round brackets, such as AC_LANG_COMPILER(Erlang) in that definition taken from my erlang.m4 file:

AC_DEFUN([AC_LANG_COMPILER(Erlang)],
...

aclocal considers that such a definition is incorrect, although it is actually correct and even mandatory as of Autoconf's test language support framework (one must use round brackets in those macro names, there is no other way!). As a consequence, one cannot include those macros in a project's acinclude.m4 file, or in a m4/ subdirectory of a project along with a ACLOCAL_AMFLAGS = -I m4 line in the main Makefile.am file, or even as a share erlang.m4 file in /usr/share/aclocal or /usr/share/aclocal-1.9: in all those cases, the macros are parsed (incorrectly!) by aclocal. The only solution is therefore to directly include my erlang.m4 file directly into the Autoconf project, which was my motivation to submit that patch.

Hopefully, aclocal is meant to disappear in the future, which is a Good Thing.

Perspectives to this work would be to add support of Erlang in Automake, but that is a lot more difficult and is less interesting to me...


Posted by Romain Lenglet | Permanent Link | Categories: Debian GNU/Linux, Erlang/OTP | Comments

2006-01-26

Playing with gtkNode, a GTK+ 2.0 wrapper library for Erlang

gtkNode is part of Jungerl, the “the Jungle of Erlang code”, i.e. a bag of unrelated pieces of Erlang code. gtkNode is a wrapper for the native GTK+ library, version 2.x. gtkNode is intended as a replacement for Erlang's standard gs GUI application which is based on Tcl/Tk. I am not a fan of GTK+ or Gnome (I am a happy user of KDE), but there is still no KDE wrapping library for Erlang. So let's give gtkNode a try!

First, download all the Jungerl libraries source code from the Jungerl project's CVS repository:

> cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/jungerl login
> cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/jungerl co -P jungerl

To build the gtkNode library, you need to install some packages, in addition to Erlang/OTP (package erlang on Debian). Since only bare Makefile files are provided with gtkNode, and sources are not “autotool'd”, we have to guess which packages are necessary. I have guessed that at least the GCC compiler and the development headers for GTK+ and Glade are necessary (and all their dependencies):

> sudo apt-get install bash gcc-4.0 make pkg-config libgtk2.0-dev libglade2-dev

In addition, if wrapper code for your installed version of GTK+ (e.g. Debian sid provides GTK+ version 2.8.10) are not provided in the gtkNode sources (only wrapper code for GTK+ versions 2.4.9 and 2.6.8 are provided by default, cf. files in the gtkNode/priv/gen directory), you must also build the wrapper generator. However, this may not be necessary if you apply my patch that adds the generated wrapper code for GTK+ 2.8.10, see below.

Anyway, you must apply my patch, which rewrites a few shell scripts to avoid the use of tcsh, and to correctly determine the path to installed Erlang applications:

> cd jungerl
> wget -O - http://www.berabera.info/oldblog/lenglet/erlang/gtkNode_2006-01-26.patch | patch -p1
> cd lib/gtkNode

That patch also includes the generated wrapper code for GTK+ 2.8.10. However, if you still want to build the generator (e.g. you have a different version of GTK+), packages for Python must be installed, and you must manually create a missing directory:

> sudo apt-get install python2.3
> cd priv/generator
> mkdir ebin
> make

This generates the proper wrapper files for your installed version of GTK+. Those files must be moved to be usable to build the gtkNode library:

> cp gen/*.h ../gen
> make clean

Now, it is possible to actually build gtkNode:

> cd ../../src
> make

If you don't have emacs installed, like me, and hence don't have the etags program installed, the make command above fails. You must edit the Makefile file and remove TAGS dependency from the all: target line, and execute make again. The TAGS file generated by etags is not essential here.

To build and execute the two provided examples (simple and points):

> cd ../examples
> make
> (cd simple ; erl -sname test -pa ../../ebin -s simple start)
> (cd points ; erl -sname test -pa ../../ebin -s points start)

It is important to name the started Erlang node, by giving a -sname or -name option, since it must communicate with the independent gtkNode-linux native node, implemented by the priv/bin/gtkNode-linux binary program just compiled above, and which handles all GUI stuff using GTK+. The -pa option gives the path to gtkNode's compiled Erlang modules.

The simple example is a sort of graphical top. Here is what it looks like:

gtkNode simple example

The points example displays colored dots at random coordinates in a canvas, with the color of the clicked button (red, blue or green). Here is what it looks like:

gtkNode points example

About the appearance of those applications: I am using KDE's window manager's “Soft fusion” theme for window decoration, and the Plastik theme for widget decoration. GTK+ applications, including the ones above, use KDE's Plastik theme through the gtk-qt theme engine (package gtk2-engines-gtk-qt on Debian). Erlang GUI applications never looked so nice! ^_^


Posted by Romain Lenglet | Permanent Link | Categories: Debian GNU/Linux, Erlang/OTP | Comments

2006-01-12

Three steps to make a conference look more attractive

Here are a few steps to make a conference look more attractive:

  1. Put the name of a nice touristic place directly into the conference's name. Doesn't a “39th Annual Hawaii International Conference on System Sciences” (HICSS'06) sound much more attractive than a simple “International Conference on System Sciences”?
  2. Make the conference happen in winter, preferably just after new year's vacations (so that it feels like a vacation extension...). Surely, January 4-7 makes Hawaii attractive to foreigners (nowadays, the temparature here in Tokyo is about 5°C).
  3. On the conference website, put a picture of attendees wearing casual Hawaiian shirts.

Posted by Romain Lenglet | Permanent Link | Categories: Research | Comments

2006-01-04

Here is a feed crawler again...

Again, yesterday and today we get hits in our server's log from what looks like a robot with IP address 209.237.230.104:

209.237.230.104 - - [03/Jan/2006:18:44:19 +0900] "GET /~lenglet HTTP/1.0" 301 324 -
209.237.230.104 - - [03/Jan/2006:18:44:20 +0900] "GET /~lenglet/ HTTP/1.0" 200 31782 -
209.237.230.104 - - [03/Jan/2006:18:44:20 +0900] "GET /atom.xml HTTP/1.0" 404 282 -
209.237.230.104 - - [03/Jan/2006:18:44:21 +0900] "GET /rss.xml HTTP/1.0" 404 281 -
209.237.230.104 - - [03/Jan/2006:18:44:21 +0900] "GET /index.xml HTTP/1.0" 404 283 -
209.237.230.104 - - [04/Jan/2006:16:47:22 +0900] "GET /~lenglet HTTP/1.0" 301 324 -
209.237.230.104 - - [04/Jan/2006:16:47:22 +0900] "GET /~lenglet/ HTTP/1.0" 200 31782 -
209.237.230.104 - - [04/Jan/2006:16:47:23 +0900] "GET /atom.xml HTTP/1.0" 404 282 -
209.237.230.104 - - [04/Jan/2006:16:47:23 +0900] "GET /rss.xml HTTP/1.0" 404 281 -
209.237.230.104 - - [04/Jan/2006:16:47:23 +0900] "GET /index.xml HTTP/1.0" 404 283 -

This looks exactly like the hits I recently got from Feedster's crappy robot which was looking for RSS feeds from my web page. I had to send an email to Feedster, which they quickly responded to, and they soon stopped hitting our server.

Are they back with a revenge? Or have they sold the code of their buggy robot to someone else? Anyway, 209.237.230.104 is none of their addresses: it belongs to United Layer, an ISP which is probably hosting the robot that generates the hits I observed.

I have addedd yet another entry in my Apache .htaccess configuration file to deny any access to 209.237.230.104... When will these people learn how to respect standards, including the Robots Exclusion Standards?!


Posted by Romain Lenglet | Permanent Link | Categories: Web | Comments

2006-01-03

New article: Installation of Debian GNU/Linux Sarge on an AOpen i915GMm-HFS motherboard

I have written a new “howto” article, about the Installation of Debian GNU/Linux Sarge on an AOpen i915GMm-HFS motherboard. We spent a few hours fighting with that beast: that is worth an article... ;-)


Posted by Romain Lenglet | Permanent Link | Categories: Debian GNU/Linux | Comments