On Thu, 2007-11-01 at 10:10 -0500, Andrew Johnson wrote:
> Heinrich du Toit wrote:
> > O let me explain.
> > I want to make some sort of .db file pre-processor that can do some
> > modifications. Mainly macro expansion type stuff.
> > And this I want to use so that some rule stuff can be written in Macro's
> > and not in long complex records and hopefully make it easier to maintain
> > and understand and change. And then maybe also handle some other stuff
> > with the pre-processor to keep thing consistently linked ect... making
> > it more reliable and less prone to human error. Plus the person working
> > with it might not fully understand all the internal stuff of 'n db.
>
> I'm going to assume that you're aware of the dbLoadTemplate() facilties
> of the IOC, and I'd be interested to hear what you need beyond what that
> already provides. I want to try and stop you from reinventing the wheel
> unnecessarily, but I'm not saying that what we have is comprehensive.
>
> You should also be aware of the EPICS Extension MSI (Macro Substitution
> and Include) which implements dbLoadTemplate() expansion on a host
> machine and may speed up IOC boot time if you have lots of templates and
> macros to instantiate.
Actually no - somehow I missed the whole LoadTemplate thing!!!
Wonder how that happen - guess you shouldn't assume things :)
Anyways I went through the documentation and it certainly will do 90% of
what I wanted to do - And no I don't want to reinvent the wheel.
The only thing I think that it doesn't do directly that I would've liked
as sort of writing extra records automatically.
Let me explain:
You have an input record (or more than one)
Then you write some calc and calcout records to do things on that input
record.
Now It would be nice if this thing created the fanout things by itself
so that all the calc and calcout stuff executes after the input
record(s)
Or is there a better way?
Another example of what I want:
So firstly we have all these input records.
Then from them we have some calc and calcout records that outputs some
values that are meant to control the outputs records.
Then we have the output records.
The problem is that multiple calc records and calcout records is meant
for the same outputs record.
So this means that each rule must have a priority.
And then we possible want some combination of sel and calcout rules that
will select the correct records output.
But I guess it should be possible to make this atleast easier with
templates , but not exactly automatic.
Thanks for your help!
>
> If you haven't already done so, have a look at the template facilities
> provided by VDCT. Their use may not be completely obvious (and you
> should ignore the "grouping" features which are not useful) but they
> provide the ability to create template hierarchies and instantiate them.
> VDCT really is the best way to design complex databases at least for
> anyone from an electronics background who is used to schematic diagrams.
>
> In the language of the VDCT template expansion stuff, "macros" pass
> instance information from a parent to a child template, while "ports"
> pass information from a child to its parent; the "information" I'm
> talking about here are macro strings and are not directly related to
> database links although they will often be expanded in them.
>
I'll rather stay away from VDCT
> It is also relatively easy to write a DB file parser in modern scripting
> languages such as Perl and Python, but it is also easy to omit some
> obscure pieces of the syntax. You should be aware that future major
> releases of Base will probably replace the 'C' dbStatic library with
> tools written in Perl (which will have a similar Perl library for
> manipulating the underlying data).
Sounds interesting
>
> HTH,
>
> - Andrew
- Replies:
- Re: lexical analyzer for .db? Ned Arnold
- References:
- lexical analyzer for .db? Heinrich du Toit
- Re: lexical analyzer for .db? Andrew Johnson
- Navigate by Date:
- Prev:
Re: lexical analyzer for .db? Noboru Yamamoto
- Next:
Re: lexical analyzer for .db? Ned Arnold
- 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: lexical analyzer for .db? Noboru Yamamoto
- Next:
Re: lexical analyzer for .db? Ned Arnold
- 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
|