SCTGEN Scripting Language

February 23, 1995

At a recent design meeting, a considerable amount of time was spent discussing the exact nature of SCTGEN's configuration file. Between Stan muttering "... nothing procedural about it ..." and Karen crossing her fingers at me to ward off the demons invoked by my speaking of an "initialization script", I was tempted to turn to Dave and knock some sense into him by knocking him up side the head with a belaying pin (a nautical term, probably incorrect).

I'm at a loss to understand why everyone was so adamant that the SCTGEN configuration file not be a script. I would like to propose that the Tool Command Language (Tcl) be used as the scripting language for all phases of SCTGEN processing, from initialization to termination. Tcl is a shell-like command language

Using Tcl would benefit SCTGEN in the following ways:

Tcl is a small, but rich language that supports looping constructs, conditional statements, string manipulation, arithmetic, etc. It could be used in roles as simple as implementing a "database" for configuration parameters and in roles as complex as initiating and controlling the distribution of data generation tasks on multiple workstations. The discussion that follows focuses on using Tcl for the SCTGEN configuration file.

There's no software to write.

To read and execute the "initialization script" requires only 4 lines of code:

    #include  "tcl.h"
    Tcl_Interp  *interpeter ;

    interpreter = Tcl_CreateInterp () ;
    Tcl_EvalFile (interpreter, "configuration file name") ;

It's that simple. Setting the value of a configuration parameter in Tcl is done with the "set" command:

    set parameter value

Retrieving the value of a parameter from within C or C++ code is a one-liner:

    value = Tcl_GetVar (interpreter, "parameter", 0) ;

Tcl's associative arrays (i.e., arrays indexed by strings instead of integers) and/or [incr Tcl]'s classes provide the means for partitioning parameters into logical groups and for handling namespace problems.

Tcl-based applications are easily maintained and updated.

Imagine adding a new parameter to SCTGEN's configuration. If the configuration file was a data file, you would have to:

  1. Modify the SCTGEN header file to declare a global variable that will contain the new parameter's value. Modifying the header file will most likely require that all of SCTGEN be recompiled.

  2. Modify the configuration loading code to read and parse the new parameter's value. Depending on your data file format, existing configuration files may be rendered obsolete by these changes.

  3. Update the code that will use the new parameter by #include'ing the header file and referencing the parameter's global variable.

  4. Create a configuration data file containing the new parameter.

If the configuration file were a Tcl script, you would only have to:

  1. Update the code that will use the new parameter:
        #include "tcl.h"
        char  *value ;
        value = Tcl_GetVar (interpreter, "parameter", 0) ;
        if (value == NULL)  value = default_value ;
    By supplying a default value if the parameter is not specified, existing configuration files will remain usable.

    Since the value returned by Tcl_GetVar() is a string, you may need to perform a numeric conversion; e.g.,
        integer = atoi (Tcl_GetVar (...)) ;
  2. Add a "set" command to the configuration script:
        set parameter value

Which is preferable, a code-intensive, configuration data file or a simple configuration script?

"There's nothing procedural about initialization."
"A configuration file should not be executable."

Why and why not, respectively? When the gentle server running on the LZP rack answers a network connection request from a client, it loads a series of Tcl scripts that define the layouts of the various subsystem status blocks. For example, the DP status block is defined by the following Tcl commands:

    set dpstatus [Region #auto DPSTATUS -mapFunction mapSTS]
    #    MEDS status header.
    DefineStatusHeader $dpstatus
    #    DP information.
    $dpstatus Define tpceRequest
    $dpstatus Define dataSetSize
    $dpstatus Define transferSize
    $dpstatus Define dataSetName string 40
    $dpstatus Define targetHost string 40
    ... define the remaining fields in the status block ...

There's nothing much procedural about this Tcl code, except for, well ...

With a script-based, configuration file, you don't have to make use of the scripting language's procedural capabilities. With a data-based, configuration file, you don't even have the option of using procedural capabilities, should they prove useful or necessary.

Performance, Performance, Performance.

Tcl was clocked at over 6000 commands per second on a DEC workstation back in the late 1980's. At this rate, you wouldn't notice or be bothered by any difference in speed between the processing of a configuration data file and the interpretation of a configuration script. If you're still not convinced, think of all the script-programmable, text editors in the world: Emacs, TPU, and about a zillion PC-based editors. Few people, except for the occasional JOVE malcontent, complain about their response time.

Alex Measday  /  E-mail