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.

• memory_size:   This specifies the memory size used by the VCODE interpreter. The default is 1048576 () double precision floating point numbers (64 bits each on most machines).

• interp_file: The executable file for the interpreter for this configuration. The default is nesl_path/bin/vinterp.

• temp_dir: This is the directory to which the VCODE source file and the output from the VCODE interpreter are written each time an expression is executed. If the remote machine shares a file system with the local machine, this should be a shared directory so that both NESL (running locally) and the VCODE interpreter (running remotely) can access it. The default is /tmp/.

• rsh_command: This is the command used to initiate remote execution. If both the local and remote machine support rsh and the user name is the same locally as remotely, then this can simply be rsh machinename. If the remote user name is different, then rsh -l username machinename should work. Of course, the user needs to set the .rhosts appropriately at the remote host (see your local manual page for rsh(1), and note that some sites may restrict its use because of security considerations). If your system does not support rsh, but supports some other command for remote procedure calls, it may be possible to substitute that. The default for rsh_command is the empty string, specifying that the VCODE interpreter should be executed locally.

• machine_name: This is used to specify the remote machine's name. It is only used to print messages for the user, so it need not be the ``official'' name. The default is the empty string.

• plot_file: The NESL graphics routines work by starting a subprocess from within the VCODE interpreter using the spawn function. This subprocess is then passed commands from the interpreter through a pipe to its standard input, and translates them into X11 calls. The file that is used to invoke the subprocess is specified by plot_file. The default is nesl_path/bin/xneslplot .

• foreground_command: The shell script  used for foreground execution. The script is first searched for on the user's path, and then in *nesl_path*/bin. The default is foreground-unix.

• background_command: The shell script used for background execution. It is searched for as above. The default is background-unix.

• max_time: The maximum number of seconds allowed for background jobs. This can be overridden with the max_time option of the name &= command.

• arguments: This string is passed directly to the shell scripts specified by foreground_command and background_command. It can be used for various purposes, such as specifying the number of processors for the CM-2 or CM-5 implementations. The default is the empty string.

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.