Eli   Documents Get Eli: Translator Construction Made Easy at SourceForge.net.
    Fast, secure and Free Open Source software downloads

General Information

 o Eli: Translator Construction Made Easy
 o Global Index
 o Frequently Asked Questions
 o Typical Eli Usage Errors

Tutorials

 o Quick Reference Card
 o Guide For new Eli Users
 o Release Notes of Eli
 o Tutorial on Name Analysis
 o Tutorial on Type Analysis
 o Typical Eli Usage Errors

Reference Manuals

 o User Interface
 o Eli products and parameters
 o LIDO Reference Manual
 o Typical Eli Usage Errors

Libraries

 o Eli library routines
 o Specification Module Library

Translation Tasks

 o Lexical analysis specification
 o Syntactic Analysis Manual
 o Computation in Trees

Tools

 o LIGA Control Language
 o Debugging Information for LIDO
 o Graphical ORder TOol

 o FunnelWeb User's Manual

 o Pattern-based Text Generator
 o Property Definition Language
 o Operator Identification Language
 o Tree Grammar Specification Language
 o Command Line Processing
 o COLA Options Reference Manual

 o Generating Unparsing Code

 o Monitoring a Processor's Execution

Administration

 o System Administration Guide

Mail Home

Eli System Administration Guide

Previous Chapter Next Chapter Table of Contents


Examples of Package Use

Each example uses a cache directory with an explicit name given by a -c parameter. If you don't generally work on more than one project at a time, then you may wish to omit the -c parameter and use the same cache for every project (see Name of the cache).

All of these examples assume that you have installed eli in directory `/opt/eli' (see Installing Eli).

Using a single additional package

The Eli packages understand LALR(1) grammars and how to use them to generate deterministic parsers. Unfortunately, some languages are very difficult to describe using such grammars.

A package named bisonglr is available from the Eli web site. It uses the Bison parser generator's "GLR" facility to create parsers for grammars that cannot easily be rewritten to make them LALR(1). This package assumes that you have the Bison parser generator available in your path, under the name bison. No change in specifications is required; the package handles all of the necessary translations and integration.

Suppose that you have downloaded the bisonglr package and unpacked it to your home directory. Then the following command builds a cache called GLRCACHE in your home directory. Assuming that $ODINPATH is empty, GLRCACHE is built from the bisonglr package plus the standard Eli and Odin packages (see Packages in the cache).

eli -c $HOME/GLRCACHE -R -p $HOME/bisonglr
Note that absolute path names are used for both the cache directory and the package directory.

If you frequently worked on languages whose grammars required the bisonglr package, you could add it to the Eli package library by making the request:

-> $HOME/bisonglr +d_dest=(/opt/eli/lib/Eli) :installpkg
After making this request, the next time you build a cache the standard Eli packages will include bisonglr.

Maintaining distributed packages

The text for the Eli system is kept in a CVS repository. For the purposes of this example, assume that you have checked out a copy of the distribution directory `Elidistrib'. The name of your working directory will therefore be `Elidistrib'. The directory containing the standard Eli package collection is then `Elidistrib/Eli/pkg', and the directory containing the standard Odin package collection is `Elidistrib/Odin/pkg'.

You will use your working directory to develop and test changes to the standard packages, ultimately checking in the final version. During the development process, you want to run Eli with certain package directories from your working directory substituted for the corresponding directories in `/opt/eli'.

For example, suppose that your working directory is a subdirectory of your home directory and you need to debug the gla package. The following command will build the cache `DBGCACHE' in which the gla package from your working directory takes the place of the standard gla package:

eli -c $HOME/DBGCACHE -R -p $HOME/Elidistrib/Eli/pkg/gla

If you need to work on several packages at once, a good strategy is to create a new package collection directory and populate it with symbolic links to package directories in your working directory:

mkdir $HOME/pkg
ln -s $HOME/Elidistrib/Eli/pkg/gla    $HOME/pkg
ln -s $HOME/Elidistrib/Eli/pkg/parser $HOME/pkg
ln -s $HOME/Elidistrib/Eli/pkg/pgs    $HOME/pkg
...
You then put the names of the packages you want to work on into `$HOME/pkg/PKGLST' and build the debug cache with the following command:

eli -c $HOME/DBGCACHE -R -p $HOME/pkg
Once you have finished debugging, you can leave the `pkg' directory with its symbolic links in place. When you need to debug other packages, you add any new links and edit `PKGLST' to name the packages on which you want to work. Links to currently-uninteresting packages remain for future debugging sessions, but because their names are not listed in `PKGLST' they are ignored.

Developing additional packages

A package being developed requires a package directory. It is often useful to make that directory a subdirectory of the `$HOME/pkg' directory (see Maintaining distributed packages). It can then be used either singly or in combination with other packages being debugged.

All of the additional packages developed to date are kept in the Packages directory of the CVS repository. If you are developing an additional package for Eli, you might decide to check out the Packages directory and develop your package in a subdirectory of the resulting working directory. This is generally not a good idea. The reason is that you will ultimately want to use a CVS import command to add your package to the repository. That command expects a directory distinct from your working directory. A subsequent checkout with the -d parameter will add the imported directory to your working directory. If the package directory that you developed is a subdirectory of your working directory, it will have to be moved before the checkout takes place. Thus it is better develop the package in a directory (such as `$HOME/pkg') that is disjoint from your working directory.


Previous Chapter Next Chapter Table of Contents