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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: lexical analyzer for .db? |
From: | Ned Arnold <[email protected]> |
To: | Heinrich du Toit <[email protected]> |
Cc: | [email protected] |
Date: | Fri, 2 Nov 2007 08:30:16 -0500 |
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!
I'll rather stay away from VDCT
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.
It is also relatively easy to write a DB file parser in modern scriptingSounds interesting
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).
HTH,
- Andrew