-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate PVDisplay and friends? #61
Comments
Note that this inquiry does not include |
Internally pvaClient and some of the pvDatabase tests do appear to use some of these classes, and many of them do appear quite a lot in the normativeTypes/documentation/ntCPP.html text. I will assume though that you have already found those references and have plans for them, and that you're really asking about uses in out-of-tree code. |
Correct. Though indirect usage through interfaces in pvaClient and pvDatabase is also a concern. Given the highly dynamic nature of PVD it will be quite difficult to assess the effects of this change. |
To give some prospective. $ git ls-files src/property|xargs cloc
17 text files.
17 unique files.
0 files ignored.
github.com/AlDanial/cloc v 1.70 T=0.03 s (628.7 files/s, 67164.5 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
C++ 7 92 57 672
C/C++ Header 9 60 645 268
make 1 4 1 17
-------------------------------------------------------------------------------
SUM: 17 156 703 957
------------------------------------------------------------------------------- |
For the record, at APS we are using the timestamp structure for the APSU DAQ code. We are creating it via the StandardField class (getStandardField()->timeStamp()), so as long as StandardField class interface does not change, our DAQ code will not be affected. |
Following the discussion for epics-base/pva2pva#24. I had a look for places where
display.format
is referenced in this module. This led to my looking at a corner of the repo which I've never used. IMO these "helpers" aren't helpful.Is anyone using them?
Either directly, or indirectly through normativeTypesCPP? If not I'll mark them deprecated for removal after the next release. Also the places where they are exposed by normativeTypesCPP.
I'll migrate the pieces which are being used to normativeTypesCPP.
This covers some, or all, of the following.
Headers:
Classes:
Note. If you go searching, be careful not to confuse
pvAlarm.h
andclass PVAlarm
here withPvAlarm.h
andclass PvAlarm
in pvaPy. The pvaPy code is doing the same thing, but doesn't seem to depend on these helpers.The text was updated successfully, but these errors were encountered: