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

Products and Parameters Reference

Previous Chapter Next Chapter Table of Contents


Testing a Generated Processor

After all of the inconsistencies detected by Eli have been removed from a set of specifications, the generated processor must be run with typical input data to verify that the specifications actually describe the desired behavior. Since improper processor behavior is always due to a specification error, the specifications must be altered whenever such behavior occurs. This means that a new processor must be generated and testing continued. The products and parameters described in this section allow the user to remain within the Eli system during this entire process.

cmd -- Command Line to be Executed

+cmd

A specification of a command line to be executed by the host machine. This parameter is a list of the words of the command line. Each word is specified by an odin-expression, and may be either a string or a file. Files are specified by parenthesized odin-expressions; strings are not parenthesized:

+cmd=(sets.specs :exe)
+cmd=diff (result) (expected)
+cmd=sort -u

stdout -- Standard Output from Processor Execution

:stdout

A file containing the result of applying a filter to another file. The filter is specified by the +cmd parameter attached to the filtered file. If no +cmd parameter is attached to the filtered file then the result is simply the filtered file itself.

A typical situation is to use the generated processor to filter a data file:

data +cmd=(sets.specs :exe) :stdout

output -- Files Resulting from Processor Execution

:output

The execution directory after applying a filter to a file. The filter is specified by the +cmd parameter attached to the filtered file. If no +cmd parameter is attached to the filtered file then the result will be an empty directory.

A typical situation is to use the generated processor to filter a data file. If the generated processor creates files as a side effect of processing the data, these files will be in the derived directory:

data +cmd=(sets.specs :exe) :output

run -- Execute the Processor in the Current Directory

:run

Execution of a specified command line in a specified directory. This derivation must be applied to a directory object, and requires a +cmd parameter (see cmd -- Command Line to be Executed).

. +cmd=(sets.specs :exe) (input) :run
testdir +cmd=myprog -u (input (sets.specs :exe) :stdout) :run

Every request for run re-executes the command, regardless of whether anything on which the execution depends has changed. No other products can be derived from run. In particular, it is not possible to obtain warning messages or error reports by appending :warning or :error (see warning -- Warning Messages and Error Reports) to this derivation. If a warning message or error report is generated, Eli will specify the derivation step for which warning or abort status was set. The target of the derivation should be changed to this step, followed by :warning or :error, and the modified request submitted to Eli.

Debugging -- Debug a Program Interactively at the Source Level

:dbx
+core=( file ) :dbx
:gdb
+core=( file ) :gdb

dbx starts an interactive session with the source-level debugger of the machine on which Eli is running. This session allows controlled execution of the generated processor. Execution takes place in the current working directory, and all of the source files of the generated compiler are made available. dbx must be used with the debug parameter (see debug -- Request debugging information in object files).

Alternatively, gdb can be used to use the GNU debugger gdb instead of dbx. Both dbx and gdb check the environment variable ELI_DEBUGGER. If ELI_DEBUGGER is set, then its value is taken as the name of the debugger to be used. The debugger whose name is the value of ELI_DEBUGGER must accept the same parameters as either the Berkeley debugger dbx or the GNU debugger gdb. After setting ELI_DEBUGGER, use either dbx or gdb to activate your program, depending upon which set of parameters is appropriate.

An existing core file can be supplied by specifying the core parameter.

Every request for dbx or gdb re-executes the generated processor, regardless of whether anything on which the execution depends has changed. No other products can be derived from dbx or gdb. In particular, it is not possible to obtain warning messages or error reports by appending :warning or :error (see warning -- Warning Messages and Error Reports) to this derivation. If a warning message or error report is generated, Eli will specify the derivation step for which warning or abort status was set. The target of the derivation should be changed to this step, followed by :warning or :error, and the modified request submitted to Eli.

Monitoring -- Monitor a program at the specification level

:mon
:mongdb

mon starts an interactive session with the Noosa monitoring system (see Monitoring Reference Manual). This session allows execution monitoring of the generated processor at the level of the specifications used to generate it. This concentration on the specification level contrasts with the use of debuggers to monitor the processor's execution in terms of its source code (see Debugging -- Debug a Program Interactively at the Source Level).

mongdb allows specification-level monitoring to be mixed with source-level debugging using gdb (see Debugging -- Debug a Program Interactively at the Source Level). When using this mode of monitoring, the source-level debugger has control of the executing program and runs as a child of the monitoring system. Consequently, the monitoring system is inactive whenever the debugger is at its prompt level. These derivations can be affected by the setting of the ELI_DEBUGGER environment variable. If this variable is set, it is assumed to be a gdb-compatible debugger. Thus you can use other debuggers that support the same command-line options. For example, graphical debuggers such as ddd can be used.

The mon and mongdb products imply the monitor parameter (see monitor -- Request monitoring support) which causes the system to produce a processor that includes the monitoring code. The arg parameter (see arg -- Supply Command Line Parameters) can be used to specify command-line arguments to the program being monitored.

The following two derivations have the same effect:

sets.specs +monitor +arg=(input) :mon
sets.specs +arg=(input) :mon

monitor -- Request monitoring support

+monitor

If the monitor parameter is used, Eli includes monitoring support in the generated processor. Processors containing monitoring support can be monitored at the specification level using the Noosa monitoring environment (see Execution Monitoring Reference) via the mon, or mongdb products (see Monitoring -- Monitor a program at the specification level), which automatically imply the monitor parameter. For mongdb to be useful, the debug parameter must also be used (see debug -- Request debugging information in object files).

arg -- Supply Command Line Parameters

+arg='item …'
+arg=(file)

The specified items are supplied as command line parameters to the generated processor when it is executed by mon or mongdb. An item is any sequence of non-white-space characters other than apostrophes. Items are separated by white space. Any number of items may be specified.

debug -- Request debugging information in object files

+debug

If the debug parameter is used, all compilations are given the -g flag. This causes the compilers to provide additional information for the source-level debuggers dbx(1) and gdb. See Debugging -- Debug a Program Interactively at the Source Level. In conjunction with the monitor parameter (see monitor -- Request monitoring support), debug enables the use of mongdb. See Monitoring -- Monitor a program at the specification level.

printtokens -- Request Token Printing Code

+printtokens

If printtokens is specified, the generated processor will print the source text coordinates, internal code and intrinsic value for each basic symbol as it is read. This listing is useful to verify that the lexical analysis specification is correct, and also to obtain a frequency distribution of the kinds of basic symbols appearing in a program.


Previous Chapter Next Chapter Table of Contents