Experimental Physics and Industrial Control System
> From [email protected] Fri Dec 22 16:42 CST 1995
> Date: Fri, 22 Dec 95 12:42:34 HST
> From: [email protected] (Nick Rees)
> To: [email protected]
> Subject: Ascii databases
> Content-Type: text
> X-Sun-Charset: US-ASCII
> Content-Length: 1300
>
> I have started looking at Marty's new ascii database software and, on
> the whole, I like it a lot. However, I don't like the path construct -
> it seems restrictive and, in particular, it depends on the ascii files
> staying in the same relationship in the directory structure to work. If
> I move my code around I don't want to have to edit it to get it to
> work.
>
> At a bare minimum I suggest that dbAsciiExpand take at least one
> option, -I <path>, and its behaviour be identical to that of the C
> precompiler. (If you hadn't used # as a comment character I would have
> suggested using the precompiler itself). Like for the precompiler, the
> -I option should be able to be repeated a number of times to build up a
> list of search paths.
>
> This will allow application environments to build a database
> construction rule similar to normal compilation rules for C include
> files. (This is something we know how to do and know works...)
>
> I have had a brief look at the code and I feel that it can't be that
> difficult to do, but of course Marty might enlighten me on this :-).
>
A primary goal of the new way of handling the database definitions is that
ascii files work the same on both the development platforms and on vxWorks.
This lead to the decision NOT to use the c preprocessor.
Another goal was quick loading of ascii files. Thus the path mechanism is
not as general as that supported by the c preprocessor, i.e. the rules
always determine a unique place to locate an include file. The rules
work very well on Unix (less than 1 second to load all menus, record types,
devices, and drivers supplied with base). On vxWorks if NFS is used performance
is still acceptable. If NFS is not used then there is about a 2 second
overhead for every file opened. This is not acceptable (> 2 minutes to load).
This is the only reason for dbExpandAscii.
A last goal that we have always had for Application S/R systems is to allow
developers to simultaneously work on applications using different epics
releases. That is why getrel creates soft links to base, etc. The App S/R
systems in turn create soft links to base in any sub directories necessary.
dbExpandAscii assumed the same model. The only other method I can think of
is to use environment variables to define things such as base. This
would mean that the application developer has to continually change the
vales of the environment variables whenever he/she moves between applications.
I could have dbExpandAscii accept a -I flag but it would only
be a starting place. It would not follow the normal C rules. I am afraid
that it might be more confusing than useful. Please note that dbExpandAscii
is a very small program since the static database access library does
all the work.
As regards to using # as the comment character. This is what is used by
most shells (csh sh ksh bash). I think that this is a better choice than
/* */ for what we are doing. Since the c preprocessor is not used I purposely
used
include
rather than
#include
Thus the user realizes immediately that he/she does not have all the facilities
of the c preprocessor available.
One additional comment. Jeff Hill pointed out that using the word ascii
everywhere is not a good idea. I am going to change things so that .db is the
normal extension for all database related files. I also want to combine
dbLoadAscii and dbLoadRecords into one utility called dbLoadDatabase. The
word ascii will probably disappear everywhere.
Marty Kraimer
- Navigate by Date:
- Prev:
Siemans Programmable Logic Controllers John Quintana
- Next:
Returned mail: Cannot send message for 1 hour Marty Kraimer
- 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:
Siemans Programmable Logic Controllers John Quintana
- Next:
Re: Ascii databases Nick Rees
- 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