.============= Meeting 28-Mar-2012 =============

Agenda
======

1. Demo of the archive service - (*David*)

2. review AIs
DH by 27th Mar: Add inserstions into MK's proposed changes document to illustrate the alternative for moving the introspection interface.

MS/GW by Fri 23: Tag all pv*Java and pv*CPP repos beta.1.1. alphaJava and alphaCPP tagged too

3. easyPVA review / Test results (*Marty*)

4. Open Issue.....
structures should  consist of members which consist of name plus a s a type object. This  isn't incoconsistent with PVs knowing there own name - resolve

------------------------ Minutes ----------------------------

Present: BD, DH, MS, RL, GW, DH, NM, GS, TK
Scribe: GW


************
NEW TOPIC: Action Items
************
MS: yes, all repos were tagged.

************
NEW TOPIC: easyPVA review / Test results 
************

Test Results: No, noone ran EasyPVA

GW: There are talks at the meeting (Monday)

************
AI on GW  by next meeting. to test EasyPVA
************

GS: Do we have a meeting next week
BD: Suggests we do.
GW: Meeting as usual next week. (Just without BNL people.)

************
NEW TOPIC: Issue of Definition of a Structure
************
RL: Didn't understand the email description.
DH: Doesn't like present lovation of fieldname in Field. Move instead to a "member" object with name + field.
As well as refactor of Field, refactor also PVField.
Turns out it would be a lot of work.
We're converging on same solution only difference is grouping Field and Field-name into a single object (DH), rather than 2 arrays(MK).
MK: Reply to this prop in email today.
MK: Difference between DH and MK is "structure of arrays" (MK) and "array of structures" (DH). structure of arrays is simpler.
DH: Yes, but natural OO approach is structure as object, with its own interface. OO system eases burden of keeping names and values straight.
If we're that concerned about overhead, there are many places where this inversion would be appropriate.
GW: Physicists don't care too much about the beauty of the interface definitions. The "structure of array" approach seems more appropriate for our users and more efficient in its implementation.
DH: not convinced, but will accept that the implementer (MK) decides.
DH: Will top fieldName disappear?
MS/MK: Yes
DH: Structure name of StructureArrays now goes?
MS/MK: Yes
DH/GW: 
MK: Im ignoring de/serialization issues for now, is that ok for MS to pick up?
MS: Yes, that's fine.

************
RESOLUTION: The definition of Structure's with respect to introspection interface and
FieldName, will be as designed in proposal by Marty. That is, FieldName moves from Field to Structure, and Fields and FieldNames will be accessible from the Structure object (as arrays).
************
http://epics-pvdata.sourceforge.net/alpha/pvDataPVAccessChanges.html

public interface Field {
     Type getType();
     void toString(StringBuilder buf);
     void toString(StringBuilder buf,int indentLevel);
     String toString();
}
public interface Structure extends Field{
         Field getField(String fieldName);
         int getFieldIndex(String fieldName);
         Field[] getFields();
         String getFieldName(int fieldIndex);
         String[] getFieldNames();
}

************
NEW TOPIC: How much work to get pvIOC working on VXWorks? 
************
MS: Find all modules are written the way they should be for VxWorks.
.. we use sourcy?? layer.
GS: When tried to compile on RTEMS we found an error complaining that Thread Name was already in use.
GS: Now [] compiles, but doesn't load - or run.
MS: We need to do continuous integration on VxWorks and RTEMS as well as others.
TK: Dirk is now starting to look into these things.
TK: Detail that's not clear:
      Which parts are needed?
      MK: Ans std::tr1 - the shared pointer interface.
      We do not require Boost as such, we only require std::tr1?
 
 To compile and run EPICS V4 pv* core modules, on VxWorks v6, you must have:

Example: for the target of running PVAS on a v3 ioc, what are the system and tool requirements:

VxWorks 6.01 through 6.65
Which versions of EPICS base?
std::tr1::shared_ptr from http://gcc.gnu.org/gcc-4.0/changes.html version 4.0  
Which version of GCC? 

************
AI on MS: Answer what is the list of pre-requisites for compilation, loading nd execution of
pv* core modules on VxWorks 5 and VxWorks 6. Also on version.h file requried actions.
************
RTEMS IOC compilation and test will be done after vxWorks.

************
NEW TOPIC:  Demo of the archive service - (*David*)
************

./gethist
Error: no channel supplied
Usage: gethist [OPTIONS] channel
       gethist [-h|--help]
see gethist --help for details

./gethist -h
./gethist --help
gethist

Usage: gethist [OPTIONS] channel
       gethist [-h|--help]
see gethist --help for details

Options

Mandatory arguments to long options are mandatory for short options too.

-h,--help              display help
-s,--start=START_TIME  query archive for results starting from START_TIME
-e,--end=END_TIME      query archive for results up to END_TIME
-f,--file=FILENAME     output results of archiver query to file named FILENAME
-n,--title             print channel name, preceeded by #, before results  
-x,--scientific        results of archiver query request outputted using
                       scientific (i.e. exponent/mantissa) format 
-d,--fixed             results of archiver query request outputted using
                       scientific (i.e. exponent/mantissa) format
-o, --fields           specifies which fields to output, in which order 
-p,--precision=PREC    results of archiver query request given to precision PREC
                       Default value is 6.

Description

gethist queries the Channel Archive Server for the data for the channel specified
by channel argument between the -s,--start and -e,--end flags. The format
for the start and end parameters is that of the date -d command. The defaults
are "1 hour ago" for start and "now" for the end.

The data returned by the archive server is outputted in columns, formatted
according to the -x,--scientific, -d,--fixed and -p/--precision options.
For the fixed option, the precision specifies the number of decimal places. For
scientific it specifies the number of decimal places of the mantissa. The default
is neither scientific nor fixed formatting. In this case the value is formatted as
fixed or scientific, the format being value-dependent.

If the -n,--title option is selcted the channel name, preceeded by'#', is outputted
before the archived values. If the -t,--header option is selected the column name,
preceeded by'#', is outputted before the values.

The choice of fields and the order in which they are outputted can be selected by the
-o,--field option. The argument for this option consist of a sequence of characters
representing the possible fields
t    floting point time, in seconds, past EPICS epoch
v    the archived value
D    the date and time string of the archived value
A    A string based on the alarm status and severity
s    seconds past UNIX epoch
n    nanoseconds
S    The alarm status, as an integer
V    The alarm severity, as an integer

Output by default goes to the standard output along with any logging information.
It can be directed to a file using the -f,--file option. Logging information
will still be outputted to standard out.

EXAMPLES:

./gethist -s "20 years ago" -e "10 January 2012" -tn -f out.txt -x -p 12 fred

#fred
#timePastEpoch(s)    #value               #Date                     #Alarm
496169397.856321000   7.355487346649e-02  Wed Sep 21 17:49:57 2005  NO ALARM
496169401.996447000   1.682446300983e-01  Wed Sep 21 17:50:01 2005  NO ALARM
496169410.052636000   2.558367252350e-01  Wed Sep 21 17:50:10 2005  NO ALARM
496169420.109690000   3.173123300076e-01  Wed Sep 21 17:50:20 2005  NO ALARM
496169430.100015000   2.159405648708e-01  Wed Sep 21 17:50:30 2005  NO ALARM
496169440.081932000   4.953919649124e-01  Wed Sep 21 17:50:40 2005  NO ALARM
496169450.089935000   3.187555372715e-01  Wed Sep 21 17:50:50 2005  NO ALARM
496169450.699760000   0.000000000000e+00  Wed Sep 21 17:50:50 2005  Disconnected
496169450.699760000   0.000000000000e+00  Wed Sep 21 17:50:50 2005  Archive_Off
496169537.905713000   0.000000000000e+00  Wed Sep 21 17:52:17 2005  Disconnected
496

./gethist -s "20 years ago" -e "10 January 2012" -tn -f out.txt -x -p
 12 -o tsnvADSV fred


#timePastEpoch(s)    #secsPastEpoch  #nsecs     #value               #Alarm        #Date                     #Status  #Severity
496169397.856321000       496169397  856321000   7.355487346649e-02  NO ALARM      Wed Sep 21 17:49:57 2005        0          0
496169401.996447000       496169401  996447000   1.682446300983e-01  NO ALARM      Wed Sep 21 17:50:01 2005        0          0
496169410.052636000       496169410   52636000   2.558367252350e-01  NO ALARM      Wed Sep 21 17:50:10 2005        0          0
496169420

GS: Asks can I ask for archive of >1 channel at a time:

./gethist -s "20 years ago" -e "10 January 2012" -tn -f out.txt -x -p 12 fred janet

ANS: You could do that by appending channels to the output, then piping to sort.

GS: Does the server side support >1 index?

DH: The shell script supplies the server name in its call to the client side. Each server 
is associated with one index. 

Meeting ends