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
<1996>
1997
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
<1996>
1997
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
|