This page holds several `projets libres' submitted by members of the LRDE. Some of them are about Free Software Project; in this case, you must read WorkingOnFSFProjects.

The ProjetsLibres2002 and ProjetsLibres2003 can still be read.

Gestion de la bibliothèque de l'école

Le but de ce projet est de concevoir une base de données pour la gestion de la bibliothèque de l'école. Plusieurs outils seront développés pour faciliter l'exploitation des informations contenues dans cette base :

• Administration de la bibliothèque.
• Gestion des emprunts.
• Recherche et réservation de livres.
• Consultation des comptes utilisateurs.
• ...

Ces outils doivent faciliter l'accès à ces informations à travers le web. Dans le cadre de ce projet, on s'appuiera sur un des produits libres existant.

-- RedaDehak

Segmentation semi-automatique du signal de parole

L'objectif de ce projet est de développer un logiciel libre pour l'aide à l'analyse et la segmentation du signal de parole. Il existe actuellement plusieurs produits développés sous matlab ou bien sous license payante. On préférera un logiciel compatible linux et windows en même temps.

http://www.babeltech.com/Products.php?s=106&m=75

-- RedaDehak

Image processing

Olena: interoperability with GIMP

To be done: be able to call from The GIMP some filters provided by Olena

-- ThierryGeraud

Automake: LaTeX Support and tests framework improvement

GNU Automake is a lovely tool to abstract away from "how to build" (the make level) to "what to build". Its benefits for programs, libraries and so forth are well known. It is also quite pleasant for Texinfo documents, but with no convincing support for included images etc.

This projects consists in implementing some LaTeX support, with included sub documents, images and so forth. It will require a full redesign of the approach taken for Texinfo. Actually, you are expected to reimplement the Texinfo support too: Texinfo and LaTeX are extremely similar.

The testing framework provided by Automake should also be improved to support parallel tests, colors, automatic logging etc.

High Perl skills are required, since Automake is written in Perl. Support will be provided by AkimDemaille, and hopefully by Automake's de facto maintainer, AlexandreDuretLutz. The documentation and test suite are to be written too, of course.

Read WorkingOnFSFProjects. -- Akim Demaille

GNU M4

Be sure to read WorkingOnFSFProjects.

Compilation for GNU M4

M4 is a very powerful macro processor. It is used in several big projects such as GNU Autoconf or GNU Bison to perform text expansions. But industrial uses of M4 reveal serious efficiency problems: each time the code is to be executed, it is re-scanned, and re-parsed. This is often needed to support code like:

define([foo], [bar])
define([bar], [baz])
define([baz], [qux])
foo

which produces qux.

The "problem" is that the cycle foo, bar, baz, qux is repeted for each run, and in the end it can be prohibitive. The idea is to implement a sort of compiler for M4 maros that would understand once for all that from foo we can immediately have qux, saving a few evaluations.

Of course, the project must take into account the passing of arguments:

define([foo], [bar($@)])
define([bar], [baz($@)])
define([baz], [qux($@)])
foo(51)

it should be "understood" that foo(51) expands into qux(51), and foo(1, 2, 3) into qux(1, 2, 3) without having to expand the intermediary bar and baz calls. Finally, it should work on less obvious cases:

define([foo], [bar($2, $1)])
define([bar], [baz($2, $1)])
define([baz], [$1 $2])
foo(51)

or even

define([foo], [bar($2, $1)])
define([bar], [baz($2, $1)])
define([baz], [$1 $2])
foo(51, 42)

A suggestion is to introduce a new builtin, bind (as in PostScript) that means "now you can inline calls":

define([foo], [bar($2, $1)])
define([bar], [baz($2, $1)])
define([baz], [$1 $2])
bind([foo])
foo(%1, 42)

-- Akim Demaille

GNU M4: Improvements & Speed ups

GNU M4 is a fast implementation of the M4 language, but more features are desirable to implement demanding projects. There exist an "M5" projects that includes such features, for instance "hard quotes", name spaces etc. In addition, M4 is incredibly inefficient with some programming styles where a more AST like handling could provide dramatic speed up.

This projects consists in studying CVS GNU M4, proposing a series of improvements, and implementing them.

-- Akim Demaille

Comparaison between EDA and genetic algorithms

Estimation of distribution algorithms is a recent research orientation for evolutionary computation that are applied to complex optimization problems. Several algorithms and approaches have already been introduced by different authors in the literature. The goal of this project is to propose a C++ implementation of EDA algorithms for EO library (http://www.eeaax.polytechnique.fr/EO/). A comparaison between EDA and genetic algorithms must be done.

The team should have a good level in mathematics and probability

keywords : EDA, Bayesian networks, evolutionary algorithms.

-- RedaDehak & GeoffroyFouquier

Bison

Be sure to read WorkingOnFSFProjects.

Bison: Burke-Fisher Error Correction

YACC error recovery scheme is quite poor: the author of the grammar has to clutter her grammar with special annotation specifying how to recover from the error. As emphasized, this is not even correction: most of the time, the intent is merely to recover from the error, i.e., continuing as far as we can, while completely ignoring the contents of the erroneous text.

The Burke-Fisher Error Correction (or repair) algorithm tries to address these issues by trying, by itself, insertion, deletion and replacement of various tokens around the error spot. In addition, the user is provide with new directives to specify semantic values of tokens to create.

This scheme is quite efficient, especially because :

• It is nice for the grammar author
• It is nice for the users

The SML YACC provides this service.

The subject consists in implementing Burke-Fisher in Bison, for C output only as a first stage. The main source of documentation is Andrew Appel's ``Modern Compiler Implementation''.

Writing test cases in the current testing framework is a mandatory part of the project.

-- Akim Demaille

Bison: Modularity

Yacc/Bison grammars have well known bad engineering properties, one of which being the lack of modularity: a Yacc/Bison grammar is composed of a single file, which can be huge.

This projects consists in implementing module support in the Bison front end. This will therefore benefit to all the Bison back ends (regular LALR(1), GLR, C++ Parsers...).

The task is more than merely implementing a simple %include: it is a form of %import which is desired, i.e., something that provides interfaces and encapsulation between modules. For instance, two modules might both define a symbol list, but may be both imported into another one without conflict as long as it doesn't import both list symbols.

Modularity should also be introduced for associativity/precedence directives.

This project should be very interesting, especially to people who enjoyed a project such as Tiger.

-- Akim Demaille

Bison: General Improvements

There are many many things that can be done in Bison:

• New Output Languages (Java, Scheme etc.)
• Debugging Grammars (helping the users to understand the conflicts). This topic requires a very deep understanding of Bison internals. But sure to be ready to read mathematical material.
• More graphics (parse tree etc.)
• Including the backtracking parser written by another Epita student.

And many more.

-- Akim Demaille

Bison: Rich report formats

Bison and Yacc produce a report to help the user understand the grammar and the parser. In addition to the plain text report, Bison provides an unsatisfying visual display of the automaton. Both should be replaced by an XML output, and several tools to produce different rendering. In particular, an HTML output would be most useful, with many links to move from conflicts to states to rules to symbols etc.

What is needed:

• Good C programmers
• Know about XML and writing XSD or other XML definition formats
• Be ready to program in XSLT
• Know about HTML
• Be ready to use GraphViz^?

-- Akim Demaille

Profiler Class in C++

For several reasons, sometimes one would like to have profiling data defined by Tasks rather than functions. That rules out tools such as Gprof, Callgrind etc.

This project aims at the implementation of a complete Profiling/Benchmarking toolkit as a set of C++ classes. If properly implemented, that would make a nice addition to Boost, the world-wide known C++ library.

We already have the Timer class (similar to that of tc), but it has too many shortcomings. The reimplementation should be much more powerful and useful.

-- Akim Demaille
to top