Experimental Physics and
Industrial Control System

[email protected] (Jim B. Kowalkowski) · Fri, 9 Feb 1996 08:37:07 -0600

William,

>------------------------------------------------
>From [email protected] Tue Feb  6 16:45 CST 1996
>
>Dear all,
>
>I'm thinking in terms of a library with prototypes something like:
>
>a) long macOpen ( MAC_HANDLE *handle );
>b) long macIoctl( MAC_HANDLE  handle, char *name, void *value );
>c) long macRead ( MAC_HANDLE  handle, char *name, char *value, long maxlen );
>d) long macWrite( MAC_HANDLE  handle, char *name, char *value );
>e) long macClose( MAC_HANDLE  handle );
>
>f) long macParse( MAC_HANDLE handle, char *defns );
>g) long macSubst( MAC_HANDLE handle, char *src, char *dest, long maxlen );
>
>h) long macReport( MAC_HANDLE handle );
>
>This library could be used directly by applications which need to support
>macro substitution.
>
>A "macsub" (or "mactool"?) application would be written which would use the
>above library and use a command like:
>
>macsub a=b,c=d e=f -Iaaa -Ibbb
>
>to parse a file like:
>
># comment
>%include filename
>%xxx = ppp
>%yyy = $(xxx)
><arbitrary text containing macro references>
>
>There would also be options to read and write specified files, control the
>comment character, control the command prefix, change the macro substitution
>characters etc.
>
>Syntax would be a loose subset of corresponding GNU make syntax.
>
>Any comments?
>
>William
>

Just a note:

I feel that one of the important uses for this library is dbLoadRecords()
which runs on the IOC.  This tools should not be openning any more than one
file.  The substitions are required to be on the vxWorks command
line as they are today and nothing must be embedded in the ".db", except
the $(var) variables.  In other words, I feel that in many instances that
embedding substitution information at the top of files is not appropriate.

Requested modifications:

The core substitution engine should be very simple.  I should be able
be able to give the library a set of variable/value pairs, get a handle,
then later use that handle to to substitions.  A layer on top of this
library could add the ability to turn a string of the form
"var=value,var2=val2,...." into the variable/value pairs required by the
substutution library.  This is how I would like to see the variable/value
pairs to look (in a C program) to initialize the substitution table:

char* pairs[] = {
  "variable1","value1",
  "variable2","value2",
  "variable3","value3"
  };

int macOpen(MAC_HANDLE* h, char* subs[]); /* new open call */
int macModify(MAC_HANDLE* h, char* subs[]); /* add/replace substitutions */
int macConvert(char** subs[], char* string); /* new call */

The macConvert() calls could change the string in the form of
"x=one,y=two..." and convert it to the "char* p[]" representation.

The pairs variable above is an example of the data structure returned
by the convert function (or built by a user).  Obviously the even indexed 
items are the variables, the odd are the corresponding values.

Rationale:

1) New convertion routines can be added so variable/value pairs can be
   represented in different ways. One not-so-good example is
   dbLoadTemplates() where the following is allowed:

   vars{ a,b,c,d }
   value1{ 5,6,7,8 }
   value2{ 10,11,12,13 }

   macNewConvert(char** subs[], char* vars[], char* values[]) could
   be used to support this format without changing the core substitution
   library.

2) Parsing strings in the form "a=1,b=3,..." into a simple internal format
   is very useful.  I have a need to do this is several other projects.
   It would be nice to be able to reuse this code.

------------------------------------------------
>From [email protected] Thu Feb  8 15:36 CST 1996
>
>Marty Kraimer commented:
>> An important application is the static database access library. This library
>> should support macro substitutions. If we do this the utilities
>> dbLoadDatabase (previously called dbLoadAscii) and dbLoadRecords can 
>> be merged.
>
>Should we also be considering incorporating the "substitution file" syntax
>supported by subtool and dbLoadTemplate? Or should this remain unchanged
>but (eventually) use the new macro library (which would remain ignorant
>of templates)?
>
>William
>

I think it is important to retain a "substitution file" type of syntax
for tools such as dbLoadTemplates().  It permits the files that the
substitutions are being performed one to be unaware of how they are being
used.  I feel this is an important attribute.  I will argue this point
further if required.  Hopefully I'm not missing something in your proposed
design that allows these types of substitutions.

------------------------------------------------
Important design issues and considerations for variable substitution:

All of the following are probably known, but must be stated so we are sure 
that everything gets tested and nothing gets overlooked - please add to
the list if I've missed something.

1) Allow syntax such as "A=$(B),B=$(C),C=3"
   or "pv_name=$(subsystem)$(sector)$(crate),subsystem=RF,sector=5,crate=7"

2) Dissallow and print an error message for "A=$(B),B=$(C),C=$(A)".

3) Allow "A=\$(B)" to assign $(B) to A instead of the value of B.

4) Allow A=\,,B=\",C="this,is\" a test",C='this,\' is a test'
   to perform as expected.

Items 3 and 4 are checked by what I called macConvert(), 1 and 2 are
probably checked by the core library.

Jim

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System