MINUTES OF TELECON, 16-JUL-2013

See minutes below

Agenda as followed

0. Preliminaries

1. Release process status [2], *all*  
-> 2nd Topic

We should be at feature freeze by Friday the 19th [3]. Is that realistic
bearing in mind that now alphaJava is being replaced by easyPVA. Do we need
a hierarchical checklist that tagging is complete, from pvData* up to example*? -
some way for higher up MOs to know that lower level MOs are finished.

2. David's analysis of pvData [4,5].  
-> 1st topic

David has made a very thorough analysis of pvData-md, and Marty's comments. He's
made some significant suggestions too. Let's see how to proceed on these. If I can
summarize:

 1. Use of casting and templates, David suggests use of visitor. And follow-up
 suggestion for the implementation;

 "On visitor pattern. This can implemented as normal, as I suggested, using a
 virtual member function. The actual   implementation for  PVScalarValue and PVValArray
 can be implemented in one line each, once, using templates."

 2. convert functionality is different from old api

 3. Safety of use of "take" "reuse" mechanism.

 4. Can't call the template copyIn on a PVIntArray etc. only on a PVScalarArray.


[1]
 http://epics-pvdata.sourceforge.net/home.html#usefulinfo
[2]
 http://epics-pvdata.sourceforge.net/release.html
[3]
 http://epics-pvdata.sourceforge.net/release.html#time-table
[4] pvData discussion thread,
 http://sourceforge.net/mailarchive/forum.php?thread_name=5B7A62384C1DF4489186ABF43720BAD255BF037B%40EXCHMBX03.fed.cclrc.ac.uk&forum_name=epics-pvdata-devel
[5] pvData-md thread,
 http://sourceforge.net/mailarchive/forum.php?thread_name=5B7A62384C1DF4489186ABF43720BAD255BF033D%40EXCHMBX03.fed.cclrc.ac.uk&forum_name=epics-pvdata-devel

MINUTES

PRESENT: AJ, DH, GW, GS, MD, MK, NM, MS

SCRIBE: MK

CHAIR: GW

******

NEW TOPIC: David’s comments about pvDataCPP-md

******

GW: question for David: Are we converging?

DH: Yes but worried about some details.

And better way to do some things.

GW: Can we make subset that avoids void *?

DH: Yes.

Conversions can be made better by visitor pattern.

Visitor would be at PVScalar/PVScalarArray level.

MD: Questions about visitor implementation.

All possible types leads to many methods.

Concern about details.

DH/MD: “take” will be dropped from interface.

MK: [is concerned about write access to the arrays. A new copy must be made for each

access. That’s going to be a huge problem.

MD: But this method will probably always use less memory than the existing proposed method.

When accessing a large object, like image, use the “free list”.

MK: Will the free list be an array of chunks.

MD:Free list would be just as in epics base.

It can even *be* the free list from epics base.

But it would also have the same problems as only working when the chunks are the

same size [is that right scribe].

MD: viewUnsafe will be dropped.

MK: Well, this is significantly different to the existing api. What happens when you don’t have a free list.

MK: What do other people think?

DH: +1 on new api

MS: There are problems, but it seems good in all. Only improvement would be to re-write for improving multi-threading thread safety.

MS: Current impl. is an improvement, but it has issues - use of free list for large arrays.

AJ: There is little difference between the problem solved here, and that solved by Mark Rivers in areaDetector. It’s a widely addressed problem, and one has to decide how to approach it.

MK: Well, can the code for managing free list be included in pvData.

MD: Yes, you mean with a small wrapper? Ok Yes, that’s fine.

MS: It seems unavoidable to use a lock and copy for large arrays.

MD: And for many large arrays there will always be problems where allocations for each array is >10% of [virtual] memory size. It’s not worthwhile to try to code for such a special case.

AJ: Well, maybe we should just ensure the api can work for that case but not implement it yet.

MD: Agreed, but not at this point.

GW: Proposal: Can we can reach an agreement?

Is there a test bench for performance?

MS: Only private use for now.

GW: Need for performance testing benchmark.

MS: Have some now.

MS: [To MD] would you expect your re-write to improve performance of a single client acq?

MD: Yes, because … [missed it]

AJ: must decide on what is desired for performance test.

MS: add timeStamp so that performance can also be measured for each unit test.

GW: add number of times to run each test.

AJ: Not part of unit tests.

GW: A separate facility based on micro unit tests?

AI on GW/AJ and group: Write a document describing performance tests to be written and the requirements for a framework to take these measurements. Java and C++ implementations may have different needs. Unit tests (not part of this doc) need to test correctness and performance.

New Topic: Release readiness.

AJ: Had no time to update complete document.

Things added module owners and version numbers.

 

Conclusion: We will keep the present form of the release.html document, as it is for the 4.3 release, and re-address how this document will change in the light of each module having

its own life, for the next release.

AI on AJ: AJ will put “data” tables (section 5) at the top (become section 2).

Meeting ends: 16:35 UTC.