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: Rec Proc Monitor no longer in EPICs 7 record reference documentation. |
From: | "Johnson, Andrew N. via Tech-talk" <tech-talk at aps.anl.gov> |
To: | "Wang, Andrew" <wang126 at llnl.gov> |
Cc: | EPICS tech-talk <tech-talk at aps.anl.gov> |
Date: | Sun, 26 Sep 2021 02:58:15 +0000 |
Hi Andy,
On Sep 25, 2021, at 1:12 AM, Wang, Andrew via Tech-talk <tech-talk at aps.anl.gov> wrote:
Good question. The tables in the new versions of the Record Reference documentation that describe the record fields are now generated automatically from the DBD files at build time, so they will always match the definition used by the code (with the exception
of a few columns for fields that can be configured at load-time, such as the VAL field of a waveform record). The main text does have to be edited by hand though, so it can still get out of date.
The information in the Rec Proc Monitor column that was present in previous versions of the field tables cannot be extracted from the DBD file. It showed “Yes” if the record-type’s process() routine could post monitors on that field, and the answer for
that has to come from the C code. As a result it is more likely to get out of date as the C code changes.
It would be possible to add the column back into the tables and require hand-annotation of the fields that should show “Yes”, but this would take a combination of some programming effort and edits to all of the record type DBD files to add that annotation.
I’m not too keen on adding the column back though, since it would easily get out of date as the code gets changed, but it would be relatively easy for the text to provide a list of the fields that have monitors posted on them by the process() routine. That
still requires all the DBD files to be edited to add the list, but that might make it more obvious that the information is provided by hand so is more likely to be fallible.
It does not (I’m not sure how it could, is there something deeper in your question?). The set of fields that do post monitor updates has changed slightly over the years, in most cases we have added monitors rather than take them away though.
HTH,
- Andrew
--
Complexity comes for free, simplicity you have to work for.
|