0. Preliminaries

1. Feature/Housekeeping work (*Andrew*) [2], 20 mins.

  As requested in Andrew's email, *module owners take a look at changes and be prepared

  to comment*

2. Monitor plugin review (*Marty*) [3], 20 mins.

  *Andrew*, *Ralph* note that Marty asks for your input. Note also [3] contains an attached

  description file.

3. Preliminary experiences with easyPVA through Matlab (Greg), 20 mins.

  Some examples of getting data, particularly modelled optics, and early comments on

  easyPVA error handling support. Will follow a talk like [4] if there's time.


Greg for Greg and Andrew.

[1] http://epics-pvdata.sourceforge.net/home.html

[2] http://sourceforge.net/p/epics-pvdata/mailman/message/32255761/

[3] http://sourceforge.net/p/epics-pvdata/mailman/message/32260092/

[4] http://sourceforge.net/p/epics-pvdata/mailman/message/32226303/






0.  Preliminaries

GW, AJ: Suggest to postpone “Monitor plugin review” session when Ralph will be present.

MK: We can I find documentation on V3 monitoring?

AJ: None present. I can point MK where to look in the code.

MK: Please do.

1. Feature/Housekeeping work

AJ: Did people review the changes?

MS: Yes, I did, and I approve them

MK: Yes, it looks good. Only issue for seen is that merging back in will be prone to error. Must be careful.

MK: Using cp -a, or [AJ) dasking mercurial to create a backup is the key.

MS: pvDatabase has a dependency on pvaSrv (in its examples). examples are necessary.

AJ: pvaSrv is part of our regular code base [so is that an issue?]

MS: pvDatabase has dep on pvAccess - so confirming, pvAccess can’t have dep on pvDatabase - OK.

AJ: note, when you run makeBaseApp you can use templates, so you could create templates in pvDatabase.

[AJ - won’t be able to give example]

Conclusion: AJ will merge housekeeping branch for all cpp products (inc pvDatabase) and after that MK/MS can complete changes for pvAccess API etc.

2. Monitor plugin review

Monitor plugin review is Postponed until Ralph can look at it and Marty can check out monitor plugins.

3. Preliminary experiences with easyPVA through Matlab

GW: gives a demo.

BD/MD: Why not using NTNameValue for twiss?

GW: Because for twiss (and many other use cases) the names of the fields will never change. NTNameValue was writen for a dynamic system of names - where the names chnage call to call. That’s more complicated to code and slower to execute than is needed for twiss parmaters, where the names of the parameters never change. Better to have a 2nd NT type called something like NTStaticNamedValue - where it’s just a PVStructure of scalars or scalar arrays.

GW: I am writing requirements for channel finder usage at SLAC.

GW: easyPVA needs to much error handling (e.g. check for isOK())

GW: First acquisition always fails after netowork restore.

GC:  What you would like to do/see if one stage fails?

GW: I want to be able to do exception handling. Phy. do not like (know) exception handling, so it must be possible to have them disabled. I like and want exception handling.

GC: What you would do with exceptions?

GW: Depends. Usually there are 3 cases:

1. Display in a dialog.

2. Printed to stderr.

3. Log (to some central place/service).

TK: Have you think about making code you have done in Matlab reusable/generic? e.g. to have a set of routines that would convert NTTypes to MatLab types (and vice versa).

GW: Yes.

TK: Any other things (other than exception handling) you spotted in easyPVA?

GW: Graceful disconnect… I have a list to be sent on the mailing list.

Meeting ends: 9:10 PCT