next up previous contents index
Next: Bugs Up: Installing NESL Previous: Building Stand-alone NESL

Machine configurations


The top-level NESL command defconfig     is used to define new configurations. Machine configurations are mostly used for remote execution, but can also be used to define aspects of the environment for local execution, such as the amount of memory allocated by the VCODE process, or a VCODE\ interpreter  file other than the default. This section describes defconfig and outlines how remote execution is implemented. The mechanism for remote execution was designed to be quite flexible; we hope that you will be able to adapt it to the idiosyncrasies of your environment.

Machine configurations for your local site should be defined in the config.nesl file  in the top-level directory. This file includes several example configurations. Users can also specify their own configurations by using defconfig either from the interpreter or within a file (it is common to put defconfigs within the .nesl init file)  . The syntax for defconfig is:

 defconfig name ¯
[,memory_size := n]
[,interp_file := str]
[,temp_dir := str]

[,rsh_command := str]
[,plot_file := str]
[,machine_name := str]

[,foreground_command := str]
[,background_command := str]

[,max_time := n]
[,arguments := str];

This command takes several optional arguments, described below. These optional arguments can appear in any order. In its simplest form, defconfig name, it defines a configuration with all the default settings. In the following, nesl_path refers to the pathname to the nesl distribution.

Remote execution  works as follows: After NESL writes out the vcode file, it starts up a subprocess by executing one of the background-* or foreground-* scripts from the bin directory. The script to be used is specified by the foreground_command and background_command in the configuration definition. NESL passes these scripts the following 7 arguments:

  1. rsh_command: This is passed directly from the configuration. The scripts are set up so that if this argument is the empty string, the interpreter will run locally.

  2. interp_file: Passed directly from the configuration.

  3. memory_size: Passed directly from the configuration.

  4. temp_dir: Passed directly from the configuration.

  5. job_ident: A unique job identifier (used to generate filenames).

  6. max_time: Passed directly from the configuration.

  7. arguments: Passed directly from the configuration.

NESL always writes the VCODE program to the file temp_dir/job_ident_code. VCODE, in turn, writes the result to the file temp_dir/job_ident_output, where NESL expects to find it. With background mode, two additional files temp_dir/job_ident_err and temp_dir/job_ident_check are created. The err file is used to store all output generated during the execution of the VCODE interpreter, including any errors. The check file is written to after the VCODE interpreter has completed, and is used so that NESL can determine when it can read the result. It should be noted that if the job was successful, all these files are deleted after being read.

It might be necessary to create new background and foreground scripts for your local site. Looking at the existing scripts should help in defining new ones.

next up previous contents index
Next: Bugs Up: Installing NESL Previous: Building Stand-alone NESL

Guy Blelloch
Tue Nov 28 18:37:09 EST 1995