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 User Interface Reference Manual

Previous Chapter Next Chapter Table of Contents


The Help Facility

A simple context-sensitive help facility is provided to describe the syntax of odin-commands and the currently available object types and parameter types. If a user types a question-mark anywhere in an odin-command, Eli provides a description of what could appear at that location in the odin-command.

Source Type Help

If a list of the declared source object type-names is desired, a question-mark can be put in place of the extension for a file:

-> sets?
?*? Known Suffix Types:
.lex_code ..... Basic symbol coding
.reqmod ....... Names of required files overridable by the user
.reqsym ....... Entry point symbols of required modules
.dapto ........ Specification of events and messages for monitoring
.delit ........ Literals to be deleted from the finite-state machine
.specs ........ Set of specifications defining the desired processor
.cola ......... Options for the parser generator cola
.finl ......... Operations to be executed after finishing
.gnrc ......... Generic module specification
.head ......... Information to be prefaced to attribution modules
.init ......... Operations to be executed before starting
.libs ......... Libraries to include in the link
.lido ......... Attribute grammar written in LIDO
.perr ......... Parser error recovery information
.roff ......... nroff/troff input
,eqn .......... eqn input
.bib .......... TeX bibliograph database
.clp .......... CLP specification
.con .......... Concrete syntax
.ctl .......... Control options for LIGA processing
.dvi .......... Device-independent formatted file from TeX
.gla .......... Structure of comments and named terminals
.map .......... Concrete/Abstract syntax mapping
.oil .......... OIL specification
.pdl .......... PDL specification
.phi .......... Files to be included at specified places
.ptg .......... PTG specification
.str .......... String table initialization
.sym .......... Symbolic grammar mappings
.tex .......... TeX formatter input
.tnf .......... Specification of a hypertext document
.ygi .......... input grammar for the Tregrm tree-building parser generator
,vw ........... a view-path system model
.dg ........... Odin Derivation Graph
.fw ........... FunnelWeb specification
.ps ........... Postscript file
.sm ........... system model of source code files
,v ............ RCS version control file
.a ............ object library archive
.f ............ Fortran77 source code
.l ............ scanner grammar
.y ............ YACC input

This should be interpreted to mean that Eli will understand the types of the following source files (among others):

sets.specs
fortran.con
build.HEAD.phi

Derivation Help

If a list of possible derivations is desired, a question-mark can be put in place of the derivation name, and Eli responds with a list of the possible object types that can appear at that position:

-> sets.specs :exe :?
*?* Possible Derivations:
name .......... name of a file
dir ........... directory of a file
exe ........... Executable program
label ......... label of a file
warn .......... warnings
help .......... Hypertext presentation of messages
warning ....... Standard presentation of warning messages
error ......... Standard presentation of error messages
err ........... errors
filename ...... filename of a file
depend ........ source dependencies
profile ....... execution profile
redo .......... redo this object step
redo_errs ..... redo all steps with errors
diff .......... differences between two files
rcp ........... archive
roff .......... nroff/troff input
eqn ........... output from eqn
tbl ........... output from tbl
nroff ......... output from nroff
stdout ........ standard output from a test run
output ........ output files from a test run

This should be interpreted to mean that Eli will understand the following derivations (among others):

sets.specs :exe :help
sets.specs :exe :redo
sets.specs :exe :depend

Parameterization Help

If a list of the possible parameter types is desired, a question-mark can be put in place of the parameter, and Eli responds with a list of the possible parameter types that can appear at that position:

-> sets.specs :exe +?
*?* Possible Parameters :
ignore ........ Prefix of include file names to be ignored
lib ........... a library name
lib_sp ........ name of a directory in an library search path
prof_data ..... trace file
prof_flags .... prof flags
default ....... default value
other ......... another file
f_dest ........ file destination
d_dest ........ directory destination
mp ............ macro package
cmd ........... host command
need .......... run dependency

This should be interpreted to mean that Eli will understand the following derivations (among others):

sets.specs :exe +ignore ...
sets.specs :exe +d_dest ...
sets.specs :exe +prof_data ...

A more exact form of parameter help can be specified by indicating which derivation you intend to apply to the parameterized object:

-> sets.specs :exe +? :profile
*?* Possible Parameters :
prof_data ..... trace file
prof_flags .... prof flags

This should be interpreted to mean that Eli will understand the following derivation (among others):

sets.specs :exe +prof_data=foo :profile

Since the +cmd parameter is not relevant to the derivation from :exe to :profile, it is not listed.

Variable Help

A list of the available variable names is generated in response to the request ?=:

-> ? =
Dir MaxBuilds BuildHosts Size KeepGoing History
LogLevel ErrLevel WarnLevel HelpLevel VerifyLevel

A description of the possible values that can be assigned to a given variable is generated in response to the Variable = ?:

   -> LogLevel = ?
   0: No log information is generated.
   1: Build commands are echoed.
   2: And Eli commands.
   3: And names of objects with errors.
   4: And names of objects generated by tool scripts.
   5: And names of objects generated by internal tools.
   6: And names of objects deleted.
   7: And names of objects touched by broadcast.


Previous Chapter Next Chapter Table of Contents