Present: AJ, SV, MK, MD, GS, AA
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.
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.
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.
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.
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?
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.
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