Top Up Prev Next Bottom Contents Index Search

14.4 Command-line Settable States

In the Ptolemy releases before Ptolemy0.6 the C programs generated by Ptolemy in the CGC domain did not take any command-line arguments. The state values of the various stars were set during compilation and thus hard-coded into the program. In order to change a state variable, the code had to be recompiled again (i.e. the universe had to be re-run within Ptolemy). This was time consuming, and it also placed unnecessary load on the machine. In Ptolemy0.6 and later, the CGC domain can generate C code that allow users to set the state values from the command-line, which allows runs with different parameters to be executed and compared quickly and easily.


14.4.1 C code generated to support command line arguments

A sample of the additional code generated to support command-line arguments is shown below:

struct {
double FOO;
double BAR;
} arg_store = {1.0, 0.01,};

void set_arg_val(char *arg[]) {
int i;
for (i = 1; arg[i]; i++) {
if ((!strcmp(arg[i], "-help")) \
||(!strcmp(arg[i], "-HELP")) \
||(!strcmp(arg[i], "-h"))) {
printf("Settable states are :\n
FOO\tdefault : 1.0\n
BAR\tdefault : 0.01\n");
if (!strcmp(arg[i], "-FOO")) {
if (arg[i + 1])
arg_store.FOO = atof(arg[i + 1]);
if (!strcmp(arg[i], "-BAR")) {
if (arg[i + 1])
arg_store.BAR = atof(arg[i + 1]);

/* main function */
main(int argc, char *argv[]) {
double value_11;
double value_12;
. // End of Declaration
. // Begin of Initialization
value_12 = arg_store.BAR;
value_11 = arg_store.FOO;
. // Code
The default values (set by the "edit-parameters" command) are stored in the struct arg_store. The function set_arg_val(argv) scans the list of command-line arguments for FOO and BAR and sets the corresponding member in arg_store. It also builds up the help message (consist of the settable state names and their default values) to be printed when the program receives a '-h', '-help' or '-HELP' option. The state values are initialized to the corresponding arg_store members during the variable initialization stage. By doing this, a state will get its default value if it is not set on the command-line.

14.4.2 Changes in pigiRpc to support command line arguments

The pragma mechanism in the Target base class is used to specify the state that is to be made settable via command-line arguments as well as to store the name to be used on the command-line. In CGCtarget, these are stored as a character string in a TextTable* mappings (a pointer to a HashTable in which the data value and index are character strings) via the overloaded pragma() member functions.

A function, isCmdArg(const State* state), is used to check whether 'state' is to be set by a command-line argument. It calls CGCTarget::pragma() and scans through the StringList returned for the state's name. If found, the mapped name is return. Otherwise a null string is return.

Four new protected CodeStream are added to CGCTarget to store the additional codes:

cmdargStruct stores the struct members.
cmdargStruct stores the default values.
setargFunc stores the code segment in set_arg_val().
setargFuncHelp stores the built-up help message. Four new public member functions and four private ones are also added to CGCStar to generate the codes:

cmdargStates() calls cmdargState() to generate the members of
struct arg_store using the mapped name returned by isCmdArg().
calls cmdargStatesInit() to generate the default values of the settable states.
setargStates() calls setargState() to generate the code segment to match the mapped name to the command-line options.
calls setargStatesHelp() to build up the help message.
These are called in the CGCTarget::declareStar(CGCStar* star) function after the global and main declarations have been generated. CGCStar::initCodeState(const State* state) is modified to generate the required initialization code if state is to be settable from the command-line.

In order for a $val state to be settable from the command-line, it has to be changed to a reference state. The expandVal() member function is overloaded in CGCStar to check if the "name" state is to be made settable from the command-line. If so, it is added to the list of referenced state so that it will be declared and initialized.

14.4.3 Limitations of command line arguments.

Currently, this implementation works only for scalar states with float or integer values. Extension to other types of state should be straight forward by simply adding the appropriate struct member declaration code in CGCStar::cmdargState(const State* state). The cmdargStatesInit(), setargState(), setargStatesHelp() and initCodeString() member functions need to be modified accordingly to generate codes for the initialization, setting function, help message and assignment respectively of the new state variable.

Also, there is no provision to check for duplicate command-line names. If there are duplicates, Ptolemy will simply generate multiple struct members with the same name, and error will result in the generated code. To get around this, a new Tk interface could be written to specify and set the settable states and checking can be done at that level. Alternatively, it might be a better idea to use the put() method in CodeStream to add the struct member with its unique handle to the appropriate CodeStream. That way, there will not be duplicate struct members and state-variables could still reference the same member, so that two or more states could be set to the same value from a single argument on the command-line.

Another limitation is that the command-line capability only works for states of blocks at the top level. It will not work for states of Galaxies and Universes, and states that referenced other settable states. This could probably be solved by modifying the pragma mechanism to ensure that pragmas at the top level propagate all the way down to the contained blocks. By doing this, states will inherit pragmas from their parent galaxies so that these can be picked up by the isCmdArg() function, and the appropriate codes can be generated.

Certain states will affect the overall scheduling of the whole system, e.g. the factor of upsampling and downsampling stars, and changing these would mean that new code needs to be generated since the scheduling is hard-coded into the generated code. Thus these should not be allowed to take values from the command-line. A new attribute can be introduced to identify those states that should not be settable from the command-line. Warnings can then be generated if users attempt to specify these for command-line setting.

Top Up Prev Next Bottom Contents Index Search

Copyright © 1990-1997, University of California. All rights reserved.