Skip to content
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

Open
mdavidsaver opened this issue Jan 16, 2019 · 5 comments
Open

Deprecate PVDisplay and friends? #61

mdavidsaver opened this issue Jan 16, 2019 · 5 comments

Comments

@mdavidsaver
Copy link
Member

mdavidsaver commented Jan 16, 2019

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:

  • pv/alarm.h
  • pv/control.h
  • pv/display.h
  • pv/timestamp.h
  • pv/pvAlarm.h
  • pv/pvControl.h
  • pv/pvDisplay.h
  • pv/pvEnumerated.h
  • pv/pvTimeStamp.h

Classes:

  • AlarmSeverityFunc
  • AlarmStatusFunc
  • Alarm
  • Control
  • Display
  • TimeStamp
  • PVAlarm
  • PVControl
  • PVDisplay
  • PVEnumerated
  • PVTimeStamp

Note. If you go searching, be careful not to confuse pvAlarm.h and class PVAlarm here with PvAlarm.h and class PvAlarm in pvaPy. The pvaPy code is doing the same thing, but doesn't seem to depend on these helpers.

@mdavidsaver
Copy link
Member Author

Note that this inquiry does not include StandardField (the type definitions), only the instance helper classes.

@anjohnson
Copy link
Member

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.

@mdavidsaver
Copy link
Member Author

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.

@mdavidsaver
Copy link
Member Author

To give some prospective. src/property/ currently constitutes ~6% of the ~15k lines of code which are pvDataCPP.

$ 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
-------------------------------------------------------------------------------

@sveseli
Copy link
Contributor

sveseli commented Jan 18, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants