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.
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.
Imagine adding a new parameter to SCTGEN's configuration. If the configuration file was a data file, you would have to:
#include'ing the header file and referencing the parameter's global variable.
If the configuration file were a Tcl script, you would only have to:
#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.
Tcl_GetVar()is a string, you may need to perform a numeric conversion; e.g.,
integer = atoi (Tcl_GetVar (...)) ;
set parameter value
Which is preferable, a code-intensive, configuration data file or a simple configuration script?
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 ...
Definemethod of the
dpstatusobject saves the field name and data type ("unsigned long" is the default) for future reference and computes the address of the field in the status block.
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.
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.