python API not retrieving some bank columns about hipo HOT 7 CLOSED

The initial implementation was for ints and floats, the doubles and longs were not yet readable.
I will add them in.

from hipo.

The interface is added for reading LONG and DOUBLE columns from python.
A new example file is added to the directory (readclas12.py) which reads and prints
RUN::config bank columns, and now the LONG type variables are read correctly.
@maskass, try it and let me know if it works.

from hipo.

Hi, thanks! I think there's an issue with signed/unsigned 32 bit int.
Example, using hipo-utils -dump on /work/clas12/vmascagn/ltcc_run006380.hipo I can see that the value for the timestamp in the RUN::config banks is (first 3 events): 3777609644, 3777624727, 3777705682

Then I run this code and from the output I can see that the unsigned 32 bit from the hipo bank ends up int a signed 32 bit int.

# assuming the code runs in hipo/extensions/python dir...
from hipolib import hreader
reader = hreader('../../slib/')
f = reader.open('/work/clas12/vmascagn/ltcc_run006380.hipo')
reader.define('RUN::config')
counter = 0
while reader.next():
    print('RUN timestamp',reader.getEntry('RUN::config',"timestamp"))
    print("-"*30)
    counter += 1
    if counter > 3:
        break

Output

file open handle =  1
RUN timestamp [-517357652]
------------------------------
RUN timestamp [-517342569]
------------------------------
RUN timestamp [-517261614]
------------------------------
RUN timestamp [-517254709]
------------------------------

from hipo.

the value -517342569 is the 3777609644 in the unsigned form.
The values in the bank are signed, that's why I wrote the interface
to return signed variable. I can of course change it to always return
unsigned long.
Another option is to convert the values you get into unsigned variable, isn't that possible in python?

from hipo.

Python (version 3 and later) has one int version only which is 64 bit (or arbitrary longer if necessary). I think there is no way from the number itself of knowing whether that -517342569 comes from a 3777609644 cast into a signed 32 bit int or from a -517342569. Neither from it's datatype (which will always result as int). It means that a proper "conversion" unaware of the data source is not possible. Of course I know it comes from a timestamp in a CLAS hipo file, so I could simply add 2**32 if negative. But I would suggest to do this in the interface.

from hipo.

I had a feature that was not properly assigning the return types from c library.
It's all fixed now. and I made it to convert to unsigned integer of 64 bits.
Here is the printout of first two events from hilo-utils:

* NODE * group =  10000, item =  11, type = 11, size =       38
           run :       5988
         event :     964560
      unixtime : 1545211321
       trigger :         33
     timestamp : 114834421448
          type :          0
          mode :          0
         torus :     1.0000
      solenoid :    -1.0000
* NODE * group =  10000, item =  11, type = 11, size =       38
           run :       5988
         event :     964561
      unixtime : 1545211321
       trigger :          5
     timestamp : 114834607940
          type :          0
          mode :          0
         torus :     1.0000
      solenoid :    -1.0000

And printout from python:

event #  0  bank size =  1
event      =  [964560]
trigger    =  [33]
unixtime   =  [1545211321]
timestamp  =  [114834421448]
event #  1  bank size =  1
event      =  [964561]
trigger    =  [5]
unixtime   =  [1545211321]
timestamp  =  [114834607940]

The values for unixtime and timestamp match. Let me know if this works @maskass.

from hipo.

Perfectly fine now! Thank you.

Valerio

from hipo.