Benjamin Franksen wrote:
Hi Marty
On Friday 18 February 2005 18:12, you wrote:
I have again updated dbd.html which is available via
http://www.aps.anl.gov/asd/people/mrk/epics/base/V4
I have received a lot of input from Andrew. Many of the changes result
from Andrew's suggestions.
I have not received any input from anyone else. I guess that means
everyone thinks it is great :-)
I began writing this as soon as I got your first message. Then I got stuck
because I had the feeling I need to understand the problems better before
sending comments. I still think so but anyway, here we go:
(1) I don't think type BOOL is needed. We can use a MENU instead, e.g.
menu(menuBool) {
choice(menuBoolFalse,"False")
choice(menuBoolTrue,"True")
}
Perhaps bool is such a fundamental data type that we should support it?
(2) The keyword "registrar" is obscure, IMO. Why not name it something like
"function" (in accordance with keyword "variable")?
Andrew,
What about this and also variable. What do we want to do for V4?
(3) record support's special: At the moment, special processing is not as
useful as it could be. This is because the new value is only accessible after
the old value has been overwritten. We can save the old value in another
field (permanently wasting storage) or we can malloc/free storage in pass 0/1
(wasting processing time). Ideally we would want (the possibility to) to save
the old value temporarily on the stack.
I order to do this, we must give a function argument to the special routine,
so that special can be defined like this:
long special(putAction *put, dbAddr *pdbaddr, putArgs *pargs)
{
do_stuff_before_the_put();
put(pargs);
do_stuff_after_the_put();
}
The 'pass' argument is no longer needed, but instead we need to pass a routine
that actually overwrites the field, together with the needed arguments (like
dbr type, options, etc) packed together into a structure 'putArgs'.
Interesting thought. Of couse storage must be obtained for putArgs but
that is not much difference than dbAddr.
(4) include "filename": At the moment it is used for two purposes:
(a) At the beginning of a record type declaration. This is poor man's
inheritance. It can be replaced by *naming a struct or record type* to be
included at this point. (The same goes for the new 'struct'). Like this:
struct(dbCommon) {
fields...
}
record(name) {
inherit "dbCommon"
fields...
}
The "inherited" part can be declared in the same file, or imported from
another one (see (b) below).
The same mechanism can be used for menus.
(b) At the top-level: This is poor man's modularization. But complete textual
inclusion is often too coarse. I propose a limited form of module import
(allowed only at the top-level):
import <module-name> (<element-name>, ...)
for element-wise import (i.e. only the listed names are imported) or
import <module-name> [ hiding (<element-name>, ...) ]
for importing everything, where the optional 'hiding' clause can be used to
list names that should not be imported. <module-name> would be the filename
of the imported module without the extension.
I will let Andrew comment about include since he has thought more about
parsing dbd files than anyone.
More comments will follow...
Ben
- Replies:
- Re: EPICS base V4: iocCore database Benjamin Franksen
- Re: EPICS base V4: iocCore database Andrew Johnson
- Navigate by Date:
- Prev:
Re: [Fwd: RE: EPICS base V4: iocCore database] Ralph Lange
- Next:
Re: EPICS base V4: iocCore database Marty Kraimer
- Index:
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: dataAccess Jeff Hill
- Next:
Re: EPICS base V4: iocCore database Benjamin Franksen
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|