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

Agenda

  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

Minutes

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