[DE | EN | FR | JA | ES]

Welcome to the 13th issue of Georg's Brave GNU World. This time it will be a little more technical again and I hope that there will be something of interest for all of you.

Gcompte

Gcompte [5] by Fabien Marchewka is one of these small GNU GPL licensed projects that I always like to provide a forum for.

In this case it is a program to keep track of personal finances which is quite a bit simpler and smaller than similar projects like GNUcash. If your only interest is to administrate a single bank account and current projects are too big or too slow for you, you will find Gcompte interesting. The chosen file formats also make Gcompte attractive as it uses standard XML as its internal file format and can also export to HTML and LaTeX.

Since Gcompte is still quite a young project - it is currently at version 0.3.8 - a lot of features are still in the planning stage. This includes the import of "Quicken" files, graphs and automated operations. Thanks to GNU Autoconf/Automake, configuration and installation is rather easy so interested users should not be discouraged by the early version number.

The next topic will probably also be of interest to most people.

Scwm

The "Scheme Constraints Window Manager" (Scwm) [6] is an extensible window manager that even is Turing complete. Originally written by Maciej Stachoviak most of the work is currently done by Greg J. Badros.

The configuration and extension language is Guile Scheme and there is an advanced "constraint solver" which allows setting a set of rules for window positions and sizes. Additionally it is possible to include C- and (with the help of a special adaptor) Fvwm2-modules dynamically; the latter is possible since the Scwm was based on the Fvwm2 sourcecode originally. It should also be remarked that Scwm is a nice way of playing around with the constraint solver.

Among the more or less standard features of Scwm are theme-capability, an integrated interaction- and documentation-system, GNOME compliance, a graphical user interface for configuration and a "proplist" module which allows including WindowMaker proplists. Very remarkable is the possibility to create synthetic key press events. This may not be clear for some people so I should probably say a few words about it. The X Window Environment is basically "event oriented" or rather "differential." Instead of querying - and transmitting - everything all the time, the program determines which events will be of interest for it beforehand. Such an event could for instance be the mouse entering/leaving a window or that a key has been pressed. The possibility to create synthetic key press events means that you could for instance tell Netscape that a certain link has been clicked on although the mouse has never been touched. If I now tell you that under x86 GNU/Linux the IBM ViaVoice package is also supported I am quite sure that I will not have to further encourage your fantasies.

There are more remarkable features and describing them in detail would definitely get out of hand pretty soon so I only mention the "guile-gtk widget bindings" and "extensible window manager hook" in the context of placement procedures as well as the XTest module for real events. If this is just technobabble to you, rest assured that Scwm can very well be used without those.

But of course there are still problems to be solved. According to Greg the biggest of them is the slow startup that can easily take up to 20 seconds. Fortunately a restart is only very seldom necessary because changes in the configuration are applied dynamically. Future plans contain a redesign of the event handling mechanism; maybe based on the Guile Object Oriented Programming System (GOOPS). Additionally the window decorations should be worked on to get an even better and more robust configurability.

Almost everything about the Scwm is licensed under the GNU General Public License so it is Free Software. The only remaining itch is the "Cassowary constraint solver" which license gives it free for research purposes.

I'll continue with a project that can easily be related to the "Church of Emacs."

eev

Being confronted with eev [7] by Eduardo Ochs for the first time I must admit I felt the description was very vague and I couldn't really see what it would be good for. The eev manifesto [8] definitely helped but I only really got to see it after playing around with it. I hope to be able to make this experimental phase a little easier for you.

Eev is an Emacs-LISP library that can be included in Emacs the standard way. After installation you can use it to to interpret the so-called "e-scripts." These are pure ASCII files which - just like normal shellscripts - contain a sequence of commands. It only becomes interesting once you don't just think of the scripts as a way to solve a problem. Their purpose is rather to show another user how certain problems can be solved under Unix. In order to do this, an e-script very often contains several solutions to one problem or solutions to different (preferrably related) problems - so it is hardly ever useful to interpret it as a whole.

Using this is very easy. The e-script gets loaded into the Emacs and the user marks the part that is of interest to her/him. Afterwards this part is being interpreted by the "eev" command which creates a real shellscript that contains the commands of the marked region. The shellscript can then be run in Emacs' shell-mode; its output can be monitored in Emacs. So an e-script is a collection of several shellscripts that can be run by the user partially or even line by line.

The best part about this is the idea to use the LISP capabilities of Emacs to document the e-scripts. Instead of cutting and pasting whole sections from man, info and webpages into the script, the documentation consists of LISP expressions that for instance open a manpage or jump to a certain point in an info file. These expressions can be interpreted with "C-x C-e" which makes Emacs visit the specified piece of information. So this is a kind of "hyperlink" in LISP. Even sourcecode references can be implemented easily this way. With the help of e-scripts you can not only see the solution to a problem, the way to this solution also captured in a lean and efficient way.

So in fact this isn't really a complicated idea. It also allows to create an archive of solutions to certain standard problems on the net which could make learning Unix much easier for a lot of users. To achieve this it is planned to make eev a standard part of GNU Emacs and figure out how eev could be ported to other editors like "vi." The e-script database is already in the process of being created and Eduardo's plans to create scripts for the installation, usage and troubleshooting of Debian GNU/HURD as well as outfitting other Debian packages with e-scripts.

The next project has been brought to me by a reader. He sent mail basically telling me that this project sounds really interesting, but he doesn't quite understand it; so I should work my way into it and then write about it.

Pliant

Pliant [9] by Hubert Tonneau is a very ambitious project under the GNU General Public License Version 2 that has seen design work for over 15 years now. But what is Pliant?

First of all Pliant is a programming language that seeks to get rid of the barrier between low level languages like C and high level languages like Java or LISP. In order to achive this Pliant works on two levels. First of all there is the "Expression" level in which Pliant resembles LISP in several aspects and which contains a rather powerful "eval" semantic. The second level is the "Instruction" one which is very much like a subset of C. The concept of Pliant says that compiling is nothing else but bringing a program from the Expression to the Instruction level. This is done by a dynamic compiler plus optional "meta functions" which are provided by the program or by libraries. Due to the machine oriented structure of the Instruction level, Pliant programs are then theoretically as fast as ones written in C.

Pliant also removes the need for cryptic configuration files because they are implemented as dynamically interpreted Pliant code. This means that configuration files also have the whole spectrum of conditionals, includes and so on. But the biggest advantage is having a single syntax for all configurations: Pliant.

In order to use this the applications have to be written in Pliant of course which is why Pliant is also a set of standard applications that offer the traditional functionality. Servers for HTTP, FTP, SMTP and POP3 already exist. In this context it should also be noted that Pliant does have a file system including TCP, HTTP, FTP and SMTP which means that URLs can be treated like normal files.

All this lets Pliant blur the border between programming and configuration which was one of the motivations for developing it. The step that has to be overcome in order to get into programming is lowered since the same language framework used for configuration can be used for programming.

And finally Pliant is also a "high-level" operating system. It runs directly on the Linux kernel or on a standard Posix or Windows system. Pliant is then the only user-space process which can work free of glue code and legacies. Since there is only a single process needed to run a HTTP server, the system is potentially very stable.

All these aspects are Pliant; which brings me to the current status.

The current main problem is that the standard code-generator does not have current optimisations and can only create code for the i386 processor - although the "Posix" code-generator allows running Pliant on several systems including GNU/HURD. This immediately brings me to what will come next. First of all Hubert is looking for someone who would like to to work on the codelgenerator for Intel chips or do a port to the Alpha processor. He is currently working on a database system and plans on writing a graphical toolkit which will then be the basis for the Pliant wordprocessor. A spreadsheet should come somewhere between the completion of graphical toolkit and wordprocessor since it should be very easy to implement in Pliant.

Although this project is probably mainly of interest to insiders I hope to have conveyed this extremely interesting idea.

I'd like to close with a project that is not directly related to computer science because it goes a little more into the "Free Science" direction.

Worldwide Botanical Database

Jean-Marc Vanel sent the address to his homepage for a "Worldwide Botanical Database" [10]. Currently, knowledge about the flora of our planet is spread over a lot of libraries and herbaria which forces scientists to travel in order to get to the information. This often slows down the scientific progress or stops it altogether.

In order to protect the different species on our planet effectively it is paramount to first understand them. So his goal is to create a botanical database that contains descriptions, pictures and geographical distributions for all plants on the planet.

Unfortunately biologists usually lack the necessary background required to realize such a project whereas most computer scientists do not have the required biological background. This is why Jean-Marc Vanel asks all interested people from computer science and biology to get in contact with him so the project can be realized.

...until the next time

This brings me once again to the final words. First of all there is rather sad news from Norway. For his work on giving people the opportunity to play the DVDs they purchased legally, the Norwegian government has laid charges against Jon Johansen. Especially when looking at the positive development that countries like France have shown, it is really questionable to take legal measures against the development of Free Software. I very much hope the whole thing will have resolved itself before this column has been released. If it is not, I ask you to look out for protest actions and participate in them. If possible, I will create some sort of link or information on the Brave GNU World or my personal GNU homepage.

But there is also good news. A heartfelt thanks goes to Denis Bodor from the Linux Magazine France who gave me a big stack of magazines at the Linux Expo/Linux World in Paris. Now I finally have the physical proof that the column is being printed in France.

That's about it for now. Please don't hesitate to contact me [1] in case of questions, ideas, comments or projects that should be featured.