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

From: Nicholas Devenish <misnomer_at_gmail.com>
Date: Wed, 6 Jun 2012 16:31:23 +0100


H,

It'a good to see these; I myself have a working example in python, that reads the TFile, TKey and TDirectory classes. I haven't written the generic streamer reading yet, because I haven't had the time to go through the streamer code. I was intending mainly to use it to pull out data, because I don't like to always have the ROOT dependence of pyROOT (and anyway, it loads too slowly for me).

I didn't actually know about the other projects; certainly interesting reading!

On 6 Jun 2012, at 16:19, Sebastien Binet wrote:

>
> 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...)
>
> the end-game being to get rid of the context switches b/w Go and C++,
> and eventually being faster than ROOT I/O (by being concurrent and
> parallel)
> :)
>
> -s
>
> [0] http://root.cern.ch/viewvc/branches/dev/bellenot/JSRootIO/
> [1] http://java.freehep.org/svn/repos/freehep/list/freehep/trunk/hepio/freehep-rootio/src/main/java/?revision=HEAD&bypassEmpty=true
> [2] http://inexlib.lal.in2p3.fr/
>
> --
> #########################################
> # Dr. Sebastien Binet
> # Laboratoire de l'Accelerateur Lineaire
> # Universite Paris-Sud XI
> # Batiment 200
> # 91898 Orsay
> #########################################

Received on Wed Jun 06 2012 - 17:31:37 CEST

This archive was generated by hypermail 2.2.0 : Wed Jun 06 2012 - 23:50:01 CEST