On 10/13/10 11:45 AM, Ben Franksen wrote:
> On Mittwoch, 13. Oktober 2010, Josh Stein wrote:
>> I would like to point out one warning with these embedded scripts -
>> there is a very real possibility of breaking some higher level tools
>> which rely on 'crawling' the startup command files for information.
>> This very issue has just cropped up here at APS when the st.cmd
>> structure of a number of our production IOCs was cleaned up during a
>> recent 3.14 upgrade.
>>
>> In essence, some of our crawlers were unable to parse relevant tags
>> since they failed to show up in the st.cmd file itself as those tags
>> were moved to one or more of the 'sub-scripts'.
>>
>> For now, the crawlers at APS are being re-written to follow the
>> indirection. This is yet another example of how fragile the system
>> structure can grow over time; the hooks into various parts actually
>> increase the risk of things breaking as time progresses.
>
> Yup. Reverse engineering installed files is a simple and clever solution
> to the practical problem of finding out what is actually installed. But
> *of course* it is liable to break whenever the *structure* of the
> installed stuff changes.
>
> The obvious solution to the dilemma is to create a central service that
> serves as source to both the installed files *and* the big picture
> (e.g. Irmis) and presumably other stuff like alarm handlers etc. But
> how can we design something like that while still retaining the easy
> editability (and the ability to use version control systems) that we
> have with plain text files? This is the million dollar question we have
> been discussing at BESSY ever since it became clear that a growing
> number of Oracle database tables (with a specific set of tables for
> each kind of device/application) is *not* an easily editable and
> maintainable solution in the long run.
Hi, Ben.
I would agree that putting everything in a relational database is not an
easily editable solution.
Of course, the problems people are trying to solve may vary widely, so
Irmis or similar may be a good solution for some situations.
I agree that having one source for all the information is good. If one
lets the EPICS IOC shell .cmd files be the source, and if the goal is to
determine what EPICS PVs are defined after loading the .cmd files, then
I think a possible solution would be some kind of dry-run mode where one
could load .cmd files and the EPICS internals that construct records
would write the name and type (and any other info considered to be
important) of each record they would create to a file, but not actually
create the record. The record name and type pair would allow
determining every possible PV name. I'm sure plenty of people have
thought of this problem in general, so maybe there's a better way. But
the idea here is to not have some separate program trying to figure this
stuff out; instead make the EPICS internals capable of reporting it
right when they would have actually created the record.
Lewis
- Replies:
- Re: Calling an iocsh "sub-script" Stephen Lewis
- References:
- Calling an iocsh "sub-script" Angus Gratton
- RE: Calling an iocsh "sub-script" Mark Rivers
- Re: Calling an iocsh "sub-script" Josh Stein
- Re: Calling an iocsh "sub-script" Ben Franksen
- Navigate by Date:
- Prev:
Re: Calling an iocsh "sub-script" J. Lewis Muir
- Next:
problem with tpmac-3-7 (loading IOC munch file results in undefined symbol error) Jay Steele
- 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: Calling an iocsh "sub-script" Ben Franksen
- Next:
Re: Calling an iocsh "sub-script" Stephen Lewis
- 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
|