> constant in INP link is the value taken the next time the link is
processed
Yes, this is the most sensible behavior.
> many record types explicitly check and so don't call dbGetLink() when
plink->type==CONSTANT. Thus for this approach to work will require
changes to the record types
This is true. However, I argue that this is benign for two reasons:
(1) Changes are only needed when and if it is desired that the record
type in question make use of the proposed generalization. If no changes
are made, the behavior does not differ from teh current one. So there is
no pressing need for providers of external record types to adapt their
code.
(2) The changes are simplifications: they eliminate a case distinction
that is necessary to make now, but won't be in the future, instead will
enable more functionality. The code becomes simpler and shorter and
easier to maintain in the long run.
--
You received this bug notification because you are a member of EPICS
Core Developers, which is subscribed to EPICS Base.
Matching subscriptions: epics-core-list-subscription
https://bugs.launchpad.net/bugs/1824277
Title:
Regression in calcout setting constant links at runtime
Status in EPICS Base:
In Progress
Status in EPICS Base 7.0 series:
In Progress
Bug description:
With the 3.15 branch, writing a literal number to a calcout.INP[A-L]
field causes the corresponding [A-L] field to be set to that number.
This works because the calcout record marks the INP fields as
special(SPC_MOD) and the calcout::special() routine calls
recGblInitConstantLink() to initialize the corresponding [A-L] field
from the new link string. I suspect that a number of the synApps
record types (transform, scalc, acalc etc.) probably use this same
technique.
Keenan Lang reported that this doesn't currently work on the 7.0
branch; the value in the [A-L] field doesn't change, which I have
confirmed.
This use of special() to reinitialize constant links is unusual,
normally putting a literal into a link field after record
initialization has no effect, but someone who worked on the calcout
record discovered this way to get it to work.
I think I know what's going on and how to fix it (change
dbPutFieldLink() to call dbAddLink() before the second call to
dbPutSpecial()), but I need to check that this won't break other
cases.
To manage notifications about this bug go to:
https://bugs.launchpad.net/epics-base/+bug/1824277/+subscriptions
- Navigate by Date:
- Prev:
Jenkins build is back to normal : epics-pvaClient-win64 #548 APS Jenkins via Core-talk
- Next:
Build completed: epics-base base-7.0-643 AppVeyor via Core-talk
- Index:
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:
Jenkins build is back to normal : epics-pvaClient-win64 #548 APS Jenkins via Core-talk
- Next:
Build completed: epics-base base-7.0-643 AppVeyor via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
|