Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: Unbalanced conditional ?
From: Dirk Zimoch <dirk.zimoch@psi.ch>
To: Andrew Johnson <anj@aps.anl.gov>
Cc: tech-talk@aps.anl.gov
Date: Fri, 09 Dec 2011 17:55:28 +0100
I did some tests with the ?: syntax.

Even though unbalanced ?: are generally not valid, unbalanced sub-expressions are accepted and do interesting things.

"(A?B):C" and "A?(B:C)" are accepted and work like "A?B:C"
"SIN(A?B):C" is accepted and works like "A?SIN(B):C"
"A?SIN(B:C)" is accepted and works like "SIN(A?B:C)"

You can add ":VAL" to fix old expressions
That has not exactly the same effect. The old syntax "A?B" raised a CALC/INVALID alarm when A is false. The INVALID can be checked for with IVOA and can be passed to other records with MS links. I do not see a full replacement for this behavior.

Dirk


Andrew Johnson wrote:
Hi Dirk,

On 2011-12-08 Dirk Zimoch wrote:
When I tried to upgrade from 3.14.8 to 3.14.12, I found that some CALC
expressions are not working any more, e.g. "B=0?A"

In 3.14.8 and all previous versions that meant: If B is 0 then set VAL
to A otherwise don't change VAL.

Now, I get the error message:

Unbalanced conditional ?: operators in CALC expression 'B=0?A'
Can't set "recordname.CALC" to "B=0?A"

Was there any good reason for this incompatible change in the CALC
behavior?

Yes, it was really obscure; I didn't know it worked at the time, let alone that it was documented. There was certainly nothing in the code to indicate that it was meant to be legal.

You can add ":VAL" to fix old expressions, which in 3.14.12 and later can be up to 79 characters long.

The change is not mentioned in the release notes
http://www.aps.anl.gov/epics/base/R3-14/12-docs/RELEASE_NOTES.html

Thus I guess the new behavior was not intended and is a bug.

The change was part of a major rewrite of the CALC expression parser that was released as part of 3.14.9 in 2007. Making this legal again would IMHO be a backwards step since there is an easy fix for old expressions and the results are easier to understand.

Sorry, that's just another change you'll have to make when upgrading.

- Andrew


References:
Unbalanced conditional ? Dirk Zimoch
Re: Unbalanced conditional ? Dirk Zimoch
Re: Unbalanced conditional ? Andrew Johnson

Navigate by Date:
Prev: Re: [building EPICS in RHEL-5 64bit] environment variables Pavel Masloff
Next: About the interface LabCA problem that Matlab can't read image data from areaDetector
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Re: Unbalanced conditional ? Andrew Johnson
Next: [building EPICS in RHEL-5 64bit] environment variables Pavel Masloff
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·