Experimental Physics and Industrial Control System
On 10/13/10 7:19 PM, Ben Franksen wrote:
> On Mittwoch, 13. Oktober 2010, J. Lewis Muir wrote:
>> On 10/13/10 10:08 AM, 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.
>>
>> I don't think there should be anything wrong w/ using features
>> supported in the EPICS IOC shell. The problem is the crawlers. The
>> crawlers were fragile; they made assumptions about the st.cmd file.
>> To solve a problem relatively quickly, sometimes this is OK, but then
>> in a case like this, one has to go back and fix it. It could still
>> be the right decision. Maybe one just needs some test cases to
>> ensure the crawler works for the cases needed or some checking script
>> to ensure the crawler is still working.
>>
>> A robust crawler would actually be able to parse the IOC shell input,
>> constructing an abstract syntax tree or converting the input into
>> some other useful form, dealing w/ variable substitutions, etc., so
>> the task of the crawler could be implemented correctly. This is
>> obviously much more work.
>
> Reverse engineering is always an approximation and especially in this
> case. Note that the startup file can call functions written in C. Do
> you want to reverse engineer the C code, too? If not, than there is
> absolutely no guarantee possible; making assumptions is the *only*
> practical way to get anything that works in most cases. When it breaks
> you fix it by adding another special case. Of course, over time this
> process of improving the crawlers, refining your assumptions, etc will
> turn them into a monster with a million special cases that nobody wants
> to maintain.
>
> This way lies madness.
But if the C code calls the EPICS functions for creating records, then
it still works.
Lewis
- Replies:
- Re: Calling an iocsh "sub-script" Eric Norum
- References:
- Calling an iocsh "sub-script" Angus Gratton
- Re: Calling an iocsh "sub-script" Josh Stein
- Re: Calling an iocsh "sub-script" J. Lewis Muir
- Re: Calling an iocsh "sub-script" Ben Franksen
- Navigate by Date:
- Prev:
Re: Calling an iocsh "sub-script" Stephen Lewis
- Next:
Re: problem with tpmac-3-7 (loading IOC munch file results in undefined symbol error) Andrew Johnson
- 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" Eric Norum
- 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