EPICS V4 Working Group Face-to-face Meeting at FRIB


  1. Debrief from this week
  2. Plan for 4.4.1 release
  1. Content for each module
  2. Release timetable
  3. Acknowledgement from Module Owners
  1. Rough timetable & content for 4.5.0 release
  2. Merging and renaming easyCPP
  3. Other business


Present: AJ, SV, MK, MD, GS, AA

Scribe: AJ

Debrief from this week

AJ: V4 Overview talk went well yesterday

MK: Think Mark Rivers is going to seriously look at switching AD to using pvData.

MD: We should meet him half-way, make using pvData easier to use.

AJ: See AI on MD from Monday…

MK: Murali talked about several things using V4, don’t understand what they’re actually using it for. Ask Greg to let us know at a future hangout.

Plan for 4.4.1 release

AJ: This is just a bug-fix release, no significant new code (except pvaSrv on 3.15), no easyCPP etc. Mark Rivers reported build problems with the top-level Makefile in the release tarfile.

AJ: Timetable: If Feature Freeze was 5/19, -pre1 would be 6/2, -rc1 would be 6/16 and 4.4.1 would be 6/30

DH: Matej had made several changes to API of pvData, breaking compatibility – some methods have been removed related to copying.

MK: Those went into the things SNS is using which need to be in the release.

AJ: This doesn’t sound like a bug-fix release then, would have to be a 4.5 release. What is the state of the new modules?

MK: Ready to go, haven’t made changes for 2 weeks.

AJ: In that case I’d want to extend the timetable to allow for more development.

DH: NormativeTypesCPP could use additional doxygen documentation, are we going to add those for this release?

MK: Seems to be quite a bit in there. Added since 4.4.0 release.

AA: Can we have pvAccessCPP documentation that doesn’t say “read the Java docs”

AI on MK: Work with MS to document pvAccessCPP API

DH: Need an update to the pvAccess specification too, a year out of date.

AI on MS: Update the pvAccess specification, e.g. type codes changed for additional bounded arrays.

Resolution: No need for a 4.4.1 release, go for 4.5.0 next.

Rough timetable & content for 4.5.0 release

AJ: Content: Add easyPvaCPP and pvDatabaseJava, pvaPy update to use easyPvaCPP, 3.15 build for pvaSrv, other stuff if we hear about it in time.

AJ: When should we aim for the 4.5.0 release? End July

SV, MK: Other responsibilities, better say August.

Merging and renaming easyCPP

SV: Andrew’s plan (I’m not responsible). Move easyPvaCPP into pvAccessCPP module, drop Easy, use the name prefix pva (e.g. pvaChannel). Namespace is currently epics::easyPva, becomes epics::pva.

MK: Sounds fine to me

DH: What’s the logic of moving it into pvAccess?

MK: They really are the same thing

MD: I’d like to have fewer libraries

GS: I don’t want to download extra modules.

AI on MK: Email Matej to explain to him, since he owns the pvAccessCPP module. Marty can also help make the changes.

AJ: Can we keep the history more easily by using git?

MD: In git.

AI on MD: Help MK with the merge, keeping the history.

SV: Can I check stuff out of git and make commits?

MD: Do a fork and publish there, make pull requests. Or continue to use hg until conversion has been finalized.

4.5.0 Release Timetable

Release end of August (Thursday 27th), so rc1 August 13th, -pre1 July 30th, Feature Freeze July 16th. 7-8 weeks from now.

GS: Content as above?

AJ: Yes.

AI on MK: Refactor the easyPvaJava API to match the new pvaCPP.

SV: Request for exception tree, don’t throw the same exception type with each error so I can catch things and not just runtime error.

MK: I will send out an email, please get involved with that.

AI on SV and MD: Help MK to do exceptions right.

Other Business

MD: HG to git conversions don’t work when hg repo has more than one head. pvIocJava and exampleJava.

MK: pvIocJava is dead, don’t convert to git. exampleJava is Greg’s, he has to fix that.

AI on GW: Merge heads in exampleJava before git conversion can be completed.

AI on MK: Merge heads in pvIocJava to leave it in a clean state.

JHL: Gateway Requirements?

RL: I put a link in the notes from Monday’s meeting

AI on AJ: Contact Bob about JHL’s offer and to have him coordinate.

Timo Korhonen joined Hangout

TK: We also have funding available for MS too, Bob is aware of this.

RL: NTTypes, add a tag to hold the time standard.

MK: Should we make the user tag 64 bits? Several people asked for this

AJ: Separate field?

DH: We already have fields that can be different width integers.

MK: Java8 addition of unsigned is not going to be particularly useful.

RL: Timo, has ESS decided on a time standard?

TK: Posix, don’t need to worry about leap seconds.

AJ: Can we make user tag optional 32 or 64 bits, add string for time standard.

MK: time_t has no optional fields, user tag is 32 bits and it required.

RL: User tag should be optional!

DL: Can’t make user tag optional, that would break things.

MK: Don’t want to make any changes at all

GS: Using the user tag already.

DH: Can’t remove the user tag, could add usertag64 field and time standard as optional fields.

MK: Code already handles these types, will need to be changed. Helper functions will not handle the optional fields; code that creates the structures needs to handle optional fields.

RL: Also have to be careful about comparing timestamps, can’t compare TAI with EPICS times directly.

MD: Can we use a byte instead of a string?

<lots of discussion>

0 = POSIX, 1 = TAI, 2 = GPS, 128+ is site-specific.

BOB time (epics Timestamp) is not supported.

Resolution: Add optional time standard field, unsigned byte, if not provided use 0 = POSIX, 1 = TAI, 2 = GPS, other values may be added in the future, values of 128 or more reserved for site-specific standards. Code for handling timestamp structures must be modified to allow creation of extra fields, details TBD.

VV: Versioning of Normative Types: If I serialize a structure into a file, then the type changes (say add units string to table columns), is this handled when I read it back in?

DH: Type ID is a string that helps you identify the structure and rules. How are you saving to the file? You have to include more than just the type ID to know.

VV: Are the serialization and deserialization APIs exposed to the users? Weren’t available a few years ago.

DH: Part of the public methods of the data classes.

MK: pvField has serialize and deserialize methods. It should be there. Look in pvDataJava for example usage.

RL: Refactored into CODEC layer recently.

Meeting closed at 11:10am