[CN | DE | EN | FR | JA | ES | KO | PT | ZH]

Welcome to another issue of the Brave GNU World, which will be a little more technical this month. But even though some projects are probably of primary interest to developers, one can hope that less-technical readers will also be able to draw new perspectives and inspirations from them.

Twin

The first topic this month is Twin, [5] a multi-window, multi-application text-based environment by Massimiliano Ghilardi. Consequently, Twin is an acronym for "Text WINdows" or (even better) "a textmode window environment."

The project aims at people who seek to have an environment with several windows without needing or wanting all the features of X11 - especially its significant resource hunger.

Combining Twin with Links, a text-mode web browser, only requires about 5% of the resources compared to X11 with the graphical browser Konqueror. All applications that can be used on a console or in a terminal window can also be used under Twin.

In a time where graphic cards are trying to outrace each other with new features and where what was impossible to afford yesterday is available for pocket change the day after, this seems almost anachronistic. But as already explained for the RULE project in the last issue, [6] this is only true for a small part of mankind.

In many places people will depend on using hardware for a long time that has already been declared outdated. This is often also true for schools in financially better-off countries.

But there is also another group that profits from Twin, that is normally not the focus when thinking about new software: blind and visually impaired people. As they may depend on using Braille terminals, they have little use for graphical user interfaces.

With Twin, they can now also use a full environment with multiple windows and applications. In fact Massimiliano tells that he indeed gets a lot of feedback from this group of users, which was initially suprising to him.

Technically speaking, the project consists of a server, called "twin" like the whole project. This server accepts connections from the clients and creates or modifies windows according to their commands. Also the server dynamically manages the different displays and devices.

Twin currently handles the console with mouse support via gpm and every termcap or ncurses compatible terminal with mouse support through the "xterm" mouse protocol, if available. But it is also possible to use X11 by means of a simple X11 driver or the graphically enhanced gfx-driver for output as well as another Twin server on another machine.

The General Graphics Interface (GGI) is also supported, but since it still lacks keyboard support, this most probably makes it rather unsuitable for most applications.

Among the other components are the libraries libTw, which handles the communication with the server, as well as libTT, which as the toolkit library provides an abstraction from of the more graphically oriented server-side functions to the more window/object oriented functions clients prefer. The third library is libTutf, a Unicode library, which allows transferring text from and to unicode. This library will probably become obsolete by using standard libraries some time in the future when the final open issues have been addressed.

And finally there are the clients. Currently there are only a few of them, of which two are built into the server. Both the window manager, which can be configured through a "~/.twinrc" configuration file, and a simple terminal emulating the console have been integrated into the server for technical reasons.

Other clients are an additional terminal emulator (twterm), a login manager similar to xdm/gdm/kdm (twdm), a system monitor (twsysmon), utilities to (de-)register displays with the server as well as other smaller clients that are more suited for testing than real work.

The project originated as a DOS program in 1993, but multitasking problems brought it to a halt pretty soon. It only took up speed again when Massimiliano switched to GNU/Linux in 1999 and ported the project to his new platform.

The project has been written entirely in C, one of the reasons for its small memory footprint - a Twin server usually requires less memory than the Bash shell. And of course Twin is Free Software - its licenses are the GNU General Public License (GPL) for server and clients and the GNU Lesser General Public License (LGPL) for the libraries.

Further development is pursued by Massimiliano in his (rather sparse) free time, and he still has a lot of ideas. First he'd like to complete the toolkit library and its documentation, then more editors, task bars, file managers, web browsers, email programs and TTY based programs should be expanded to use it.

For these tasks Massimiliano explicitly asked to relay his need for help, because there is still so much to do. He for instance seeks volunteers to document the communication library, creating a libTW screensaver, completing twdialog, the Twin equivalent of Dialog or work on twclip, a utility to copy and paste the contents of a clipboard.

Those who are interested in participating should take a look at the mailing list. Users will for instance find Twin already present in the stable branch of the Debian distribution.

C++ Packages

The column continues with some projects that should make the life of C++ developers more easy and were all released by Christian Holm around December 1st 2002. [7]

When people communicate with computers, they need to agree upon a common language to be used in communication. Especially when this communication does not happen in real time or is very complex. That is for instance the case with programming languages or configuration files.

The basic problem is that functions for syntax checking and reading or evaluating of such languages can easily become very complex. And when changes of definition or grammar become necessary, this often results in a very time consuming search for bugs.

Additionally, creating such functions tends to be a tedious job without major intellectual feats, which programmers seek to avoid.

For this reason, tools have been created that can automate the translation of definitions of grammar into functions that can read that grammer. Of course this means that the definition of grammar itself needs to be machine readable. The probably most common form of such a definition is the "Lookahead Left to Right Parsing" (LALR) context-free grammar.

One of the best and most-popular LALR(1) parser is Bison, [8] the Yacc equivalent of the GNU Project. Yacc itself stands for "Yet Another Compiler-Compiler" and Bison has deliberately been kept compatible to Yacc in order to ease transition from Yacc to Bison.

An application often working hand in hand with Bison is Flex, [9] which can be used to generate routines that allow dissecting a source input into single expressions, because it automates generation of source code for pattern matching. Flex is also the GNU-counterpart to another program - in this case "Lex"

Hopefully this short introduction was also understandable for not-so-technical readers; if you wish to learn more about this, the web provides some good entry points. [10]

Yacc/Lex--

Both Bison [8] and Flex [9] usually create C source code. Is this code used in C++, they tend to clutter the global namespace; also there are no C++ interfaces available.

For this reason Christian Holm Christiansen has written a group of header files called Yacc/Lexx--, which allow encapsulating the C output of Bison and Flex in C++ classes. In this, the changes to the parser/scanner specifications were deliberately kept at a minimum to allow for greatest possible flexibility.

In fact Flex itself provides capabilities to generate C++ sourcecode, but the output was too inflexible for Christian's liking and also it didn't fit well with the parser classes generated by Bison. Therefore he wanted a common encapsulation for both. In fact it was this asymmetry between the C output of Bison and the C++ output of Flex that made him start this project.

Compared to projects like bison++, which has the advantage of direct C++ output, Christian sees the advantages of his method in being independent from the internals of the employed Yacc/Lex implementation. Therefore it is more stable with respect to changes in the Yacc/Lex projects and not immediately affected by their internal modifications.

But there are also some Yacc/Lex clones displaying odd behaviour and are not POSIX compliant; these can be problematic to use, which is a special problem of this project.

Therefore Christian plans for the close future to test more Yacc/Lex implementations and would be happy to receive help in this area. Also help testing it on other platforms and with different compilers would be very welcome.

Readline--

The GNU Readline Library [11] provides functions that allow integrating a versatile commandline into other projects.

Among the features of GNU Readline are a vi and EMACS mode, it can save old input, recreate it and allow editing it again or also complete the beginnings of previously entered commands similar to the csh shell.

The Readline-- project by Christian Holm Christensen allows C++ programmers to access the GNU Readline Library by means of C++ classes. Not surprisingly, C++ developers seeking to include a commandline interface in their applications are the main target group of this project.

The program originated when Christian himself needed a commandline interface to test his C++ parser, a task during which he also created the previous project.

The largest problem is currently that the library is not yet thread-safe, so it should be handled with care in complex applications. Fixing this and improving the interface are Christian's next plans for the project, because even though the interface is complete, he considers it unintuitive in some places.

Option--

With Option--, Christian provides a C++ parser for commandline options; a library that allows C++ programs to find and evaluate commandline options passed at program start.

The major advantage of the project compared with similar projects is that possible options are represented by template-classes, which makes the project very flexible. Option-- only works for non-positional arguments, though. So if the user needs to be forced by syntax to only use a certain option at a certain position in the commandline, Option-- is not a good choice.

The first lines of this project were written by Christian, when the ROOT project needed command-line options, even though that project later used another solution.

But when he discovered the need for something of the kind himself, Christian completed the project and by now it has gotten so stable that there are little plans besides further tests.

Thread--

The last project by Christian Holm Christensen in this issue is Thread--, a project to use Threads in C++ programs.

Since the concept of "Threads" is most likely not known to all readers, a short explanation is probably in order.

Essentially, all computers work linear. If they get a task, they will complete it step by step in the given order with all their capacity. In most cases, this would only allow running one program at a time, however.

In order to allow working on several programs simultaneously — the so-called "multi-tasking" — the executing kernel of the computer, the processor, jumps from task to task. Each of these tasks in turn is again worked on in a strictly linear fashion, but the method allows splitting the computers capacity between different programs.

As the programs and their tasks become more complex, working only strictly linear within a program is increasingly unsatisfactory. A solution to this problem is threading. Threads allow splitting programs into different "task threads" that again can be worked on linearly to solve different subunits of the complex problem.

The interaction and communication between these different threads of course also needs to be coordinated and controlled, a functionality which can be accessed by means of Thread-- from C++.

Different from similar projects like Boost::Thread, ZThread or Common C++, Thread-- does not distribute preprocessor macros throughout the source code. Implementation specific parts are instead put into Traits. This makes the library quite small and extensible.

Christian originally began working on Thread-- in order to test the thread-safety of Readline-- and according to him it works fine on GNU/Linux, but GCC versions of 2.95.x and below are problematic, so it is advisable to check for the GCC version.

The other problems are semaphores under Solaris and Threads under Win32; he could not test it on other platforms. Help with these problems as well as information about other platforms is very welcome.

So far enough of the projects written by Christian. Regular readers of the Brave GNU World will have noticed that two essential pieces of information are still missing. These will now be provided.

First: the programming language used for all projects is C++ with the GNU Autotools and second: all projects are available as Free Software under the GNU Lesser General Public License (LGPL) available. All of them can be found on the C++ page of Christian. [7]

6th EC Framework Progamme

As mentioned in issue 40 [12] of the Brave GNU World, the FSF Europe [13] wrote a recommendation [14] to the European Commission on April 30th, 2002. The recommendation, which was supported by over 50 parties throughout Europe, first explained the advantages of Free Software for the region Europe and European countries in order to then suggest giving Free Software priority status.

The background for this recommendation was the 6th Framework Programme [15] for European funding of Research and Development, which was decided upon last year. These programs always run for four years and contain most of the European funds for the scientific area. In this, one of its main goals is to further the European economy and society through funding of research and development.

Although the 5th Framework Programme already contained some first initiatives for Free Software, the 6th Framework Programme originally did not plan to further Free Software in any way. Therefore the FSF Europe issued the aforementioned recommendation.

On December 17th 2002 the 6th Framework Programme was finalized and it seems that the recommendation to make Free Software the preferred form for project proposals has been heard. The "Information Society Technologies" (IST) Work Programme, in which the funding of computer science and information technology is handled, now contains a statement that can give Free Software projects in the evaluation process.

This effectively means that the whole budget of the IST Work Programme, containing 1725 million Euro, has been opened for Free Software. This is most likely the largest sum that was ever available for Free Software funding; although of course not exclusively in this case.

In order to now support companies, universities and research centers to launch projects for and with Free Software within this framework, the FSF Europe sent out a request [16] on December 18th 2002, in which it asks all interested parties to get in touch.

The goal is to possibly create a Free Software project for each of the important areas addressed in the 6th Framework Programme, in order to avoid seeing these funds spent on proprietary software. Because areas like eDemocracy, eHealth or eSecurity could have massive effects on our future and must be addressed with Free Software.

It takes a lot of time and effort to set up these projects and to get them organized and coordinated with the administration in Brussels, but the FSF Europe will do as much as it can to see Free Software projects use the possibilities that it created.

TUX&GNU@school

Towards the end of this issue it is my pleasure to point readers to another remarkable column. Mario Fux, himself a long-time reader of the Brave GNU World, began last year to write a similar column dedicated specifically to Free Software in school.

By now he has finished 5 issues of the "TUX&GNU@school" column in German and English, which has found its new home on the FSF Europe home page. [17] I wish Mario, as well as Christian Selig and Kristian Rink, who support him as a kind of editorial board, all the best for the future and encourage especially — though not only — readers from the educational field to take a look at it.

Until next month

Enough Brave GNU World for this month, as usual I'd like to ask for questions, ideas and comments by mail. [1]

This address is also where project proposals should be sent. And I'd like to encourage all authors to take the time. It may seem suspiciously like writing documentation, but it is a good way to inform other people about your project.

And also please do not worry about your project not being important enough. In fact I still have to encounter a project that would not be interesting enough to at least write a few interesting lines about it.

So much for now, until next month.