Re: (experimental) pure-Go ROOT I/O (but just I, not O, and only for TFile,TKey and TDirectory)

From: Sebastien Binet <binet_at_cern.ch>
Date: Thu, 14 Jun 2012 19:08:02 +0200

hi,

Sebastien Binet <binet_at_cern.ch> writes:

> hi there,
>
> following CHEP and the JSRootIO presentation (reading ROOT files w/
> JavaScript, w/o ROOT installed) I wondered if I could do the same with
> Go :)
>
> so here it is:
> https://bitbucket.org/binet/go-root
>
> not everything has been implemented, so it is more a proof of concept
> rather than anything else: right now, the main feature is the groot-ls
> executable which can (recursively) dump the hierarchical structure of
> any ROOT file (well, it worked on all the ROOT files I tested.)
>
> I mainly got inspiration from:
> - JSRootIO [0]
> - java's hep.root.io [1]
> - inexlib [2] (a pure C++ header library to read/write ROOT files)
>
> The nice thing of go-root, besides not having to install ROOT, is that I
> don't need to:
> - first create a C/C++ object to be filled by the ROOT I/O (via SWIG or
> Reflex)
> - then fill pure Go structures from those objects (or "go-ify" these
> C/C++ objects, the same process than the "pythonization" in PyROOT)
>
> ie: there is no additional buffering.
>
> of course, reimplementing everything is cumbersome, not to mention error
> prone, so...
>
> would there be an option which would allow me to have my cake
> and eat it ?
>
> perhaps registering custom streamers which would indicate the ROOT I/O
> to de-serialize, say, the TTree payload directly into the Go equivalent
> structures, w/o having to pass thru additional "buffering" ?
>
> e.g. instead of de-serializing the Event payload of a TTree which
> consists in:
> class Event {
> public:
> std::string name;
> std::vector<float> px;
> std::vector<float> py;
> //...
> };
>
> one would de-serialize it into a Go struct like that:
> type Event struct {
> Name string
> Px []float64
> Py []float64
> }
>
> (the memory layouts of a std::string and std::vector<T> don't
> necessarily match Go's string and []T...)

so? nobody bites the bait?

looking back into my archives, I dug up a discussion about the T/P separation mechanism provided by ROOT:
http://root.cern.ch/svn/root/trunk/io/doc/DataModelEvolution.txt

but I am unsure this would totally get rid of the buffering issue I was alluding to.

-s

-- 
#########################################
# Dr. Sebastien Binet
# Laboratoire de l'Accelerateur Lineaire
# Universite Paris-Sud XI
# Batiment 200
# 91898 Orsay
#########################################

  • application/pgp-signature attachment: stored
Received on Thu Jun 14 2012 - 19:08:29 CEST

This archive was generated by hypermail 2.2.0 : Tue Jun 26 2012 - 11:50:01 CEST