EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: macro substitution
From: [email protected] (Nick Rees)
To: [email protected]
Date: Fri, 9 Feb 96 12:14:48 HST
Jims comments:

> 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.

Could some of this change with Marty's new stuff? What Marty hasn't got
in his new system yet is variable substitution (at least, I can't see
it in his December notes), but I gather he wants to do this by his
response to this thread - then he can get rid of dbLoadTemplates as
well as dbLoadRecords.

A suggestion is that we might have a database file fragment like the
following:

set gizmo telescope
include "gizmo_database.db"
set gizmo accelerator
include "gizmo_database.db"

where gizmo_database.db contains:

record( ao, $(gizmo):output ) {
.
.
.
}

This assumes the new keyword in the ascii database definition is "set"
(it could be "define"). This would provide a mechanism similar to
dbLoadTemplates, but not the same. I don't really like the
dbLoadTemplates that much - it doesn't really extend to the new
database system so well because it really has to be performed as a
extra step.

> The core substitution engine should be very simple... 

... much of Jims message deleted (but I agree with most of its
sentiments about simplicity and allowing multiple syntaxes)...
>
> 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.

I think you could arrange this by having a substitution file being an
include file... i.e, you could have:

include "telescope_substitutions.db"
include "gizmo_database.db"
include "accelerator_substitutions.db"
include "gizmo_database.db"

I don't think the macro mechanism itself has to know much about
substitution files - that is up to the application.

> ------------------------------------------------
> 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.

(Pedantic point) should we have literal `$' represented by \$ (shell
syntax) or $$ (make syntax)?

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

This also highlights differences between shell and make syntaxes.

I would like to add a point (which works in make, but not in csh):

5) A=$(B$(C)) should work...

On balance (and at the moment - my feelings may change) I would lean
towards a make syntax rather than a shell syntax.

The other question I have is should you have some ability to enforce
scope on definitions? With Capfast the variable definitions have a
defined scope, but in most other cases I can think of the scope is
global. Certainly the second example above doesn't work without global
scope and make doesn't either. On the other hand, you could presumably
have two calls in you library (macPush and macPop?) which allow you to
enforce a simple stack mechanism and ensure variables go out of scope
if you want them to do so.

Anyway, that is my two cents worth...

Nick Rees

Joint Astronomy Centre                    Ph:       +1 (808) 961-3756
660 N. Aohoku Place                       Fax:      +1 (808) 961-6516
Hilo, HI.  96720                          Internet: [email protected]


Navigate by Date:
Prev: Displaying edd/dm screens on a dumb terminal Michael A. Oothoudt
Next: Re: macro substitution Jim B. Kowalkowski
Index: 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: macro substitution William Lupton
Next: Re: macro substitution Jim B. Kowalkowski
Index: 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·