Root Talk

[elc]

Does a perl interface to ROOT exist ? similar to PyRoot (built with swig ?)

elc

[brun]

We do not have a Perl interface. It would be nice to have one built
like PyRoot directly from the dictionaries.
Are you volunteer to make this implementation?

Rene

[elc]

hmm... maybe - if I get round to it I'll let you know and send it on

[brun]

Do not hesitate to contact us if you need help.

Rene

[elc]

Thanks, will have a look at this soon. Probably won't be as complete as PyRoot (callbacks etc) but will try to get shadow classes in perl.

Will keep you posted...

elc

[Eddy Offermann]

Hi,

Any news about the PerlRoot project ?

Eddy

[elc]

Hi Eddy,

the short answer is yes, but maybe not the news you were looking for. I had a look at the way PyRoot and RubyRoot work. I'm not sure if it's possible to build an interface to perl (or java) in this way, i.e. by reading the root dictionaries as I'm not sure if it's possible to make calls directly into the libraries from perl or java. Basically we haven't got the technical knowledge to implement that approach (if it is indeed possible).

1) Perl

What we have done, however, is to build a perl module to enable interaction with root from perl. We used swig (www.swig.org) to generate a perl module which contains shadow classes of any number of root classes, you just need to specify the classes you want in the swig interface file.

The biggest problem with this is that there is no way to distinguish two (or more) perl method calls with the same number of parameters. Hence if you want to call two root methods with the same name and number of parameters but with different signatures then you must tell swig to rename one (or more) of the method calls.
e.g. TH1::Fill(Axis_t, Stat_t w) and TH1::Fill(const char *name, Stat_t w) must be disambiguated by renaming one of them with a swig directive.
In practice there aren't a very large number of cases where this is neccesary.

A few additional swig directives are needed to pass perl arrays to methods in certain cases, and to cast objects returned from certain root calls to different types, e.g.
$datatree = perlroot::TObject_to_TTree($rootfile->Get("MyTree"));

I have made perl versions of all the python scripts in the tutorials directory (well all those called from demos.py).

I've also used my perlroot package to create cgi webpages with forms to select differnent views of data and generate svg graphs/histograms of those data on the fly - it works a treat !

I've built the perlroot.pm for Linux and Windows XP (with .net 2003) and the perl scripts work on both platforms without modification.


2) Java

We have gone through a similar process to make a "JavaRoot" package. The problem here is that Java doesn't support multiple inheritance. You can get round this by making copies of the header files (for swig) and including the method calls from any inherited classes after the first. This process could easily be automated with a script.

Currently we have a Java framework for data filtering and wanted to write some of the filtered data into root files (TTrees). So thus far we have only wrapped TFile, TTree (and related classes), but the process is extensible to any number of classes.



The drawbacks of this approach (for perl and java) are as follows...

1) You have to specify which classes are wrapped - if you want to add classes then you have to include them in the swig interface file and rebuild the module.
2) For perl you have to rename overloaded method calls with the same number of parameters in the swig interface file (or swig will ignore them).
3) You need to make copies of root header files containing R__EXTERN for swig and remove this string (I didn't mention this before - I have a script to do it - it's pretty straightforward).
4) In order to create a root session that stays live when you run the script (with a $tApp->Run(1) you need to edit the TROOT.h to make the constructor public (I didn't mention this before either - my script does this too).
5) For Java you need to create copies of header files for classes with multiple inheritance and include the public method signatures for the inherited classes after the first. (You could write a script to do this).
6) You have to rebuild the module for a new version of root (possibly perl too).


I do a lot of scripting and web page work with perl so I've found it extemely useful to be able to use perl to read root files/trees and to generate histos/graphs. Similarly with Java.
I haven't wrapped any of the gui classes, but there's no reason why you couldn't. I still use c++ for some small apps I have built (either macros or compiled)


If anyone is interested in this I can post the swig interface files, script to generate the modified headers for swig, and instructions for compiling (pretty straightforward - basically you run swig, compile the output, and link to the root and perl (or java) libs). A few lines shell script on linux (or a pain in .net ). I have vcproj files for windows tho.


Sorry for slow reply but I realised it was going to take me a while to write this.

elc

[cplager]

I for one would be quite interested in the perl interfaces. Please post examples when you have time.
Thanks,
Charles

[brun]

I have no doubts that you will make the Perl interface using SWIG or equivalent. However, I believe that this is the wrong way.
You will have to regenerate your interface every time there is a change in ROOT. This will become unmaintainable.
The solution is to use the dictionary in memory as we do for Python or ruby.

We already had a JavaRoot interface (using SWIG). This interface had been written by Subir Sarhar. See:
http://sarkar.home.cern.ch/sarkar/jroot/main.html

If you do a lot of scripting on the web, you might be interested by Carrot.
see: http://carrot.cern.ch

Rene

[tcsoka]

There is one major diffence in the way modules are imported in perl and python. With Python, one just needs a .so / .dll, and so in memory generation is possible. Perl, however requires that the .pm, is generated. This holds the mapping between perl objects and functions, and the corresponding c / c++ calls (via an intermediate .so /.dll).

I don't think that there is a way around this (someone correct me if I'm wrong please), so even if the .so could deal with in memory generation of all the root classes, a static .pm would still need to be built every time root changes.

[salvaire]

Dear all,

Since 6 months, I develop a wrapper for Perl, Python, Ruby, (Ocaml) with SWIG
for Root.

The building is fully automatic (Autoconf, Automake with Swig patch), except
some special case like

TH2::TH2 (const char * name, const char * title, Int_t nbinsx,
const Float_t * xbins, Int_t nbinsy, const Float_t * ybins);

TH2::TH2 (const char * name, const char * title, Int_t nbinsx,
const Float_t * xbins, Int_t nbinsy, const Double_t * ybins);

that require to ignore the float version, float doesn't exist in Script language.

This is no more difficult to switch to Root 4, or compile RFIO support with
Root 3.10.03 in the H1oo framework at Desy.

Also, if I understand well the PyRoot stuff, you use Cint to translate Python
<-> Root. If it's really the case, I have some doubt about the performance and
the problem due to Cint limitations with ISO C++.

I'm not sure to have the time to release a candidate before September (I
will take some hollydays). It miss some documentation in particular.

I'd like to have some interaction with the Root team to solve some technical problems,
like Garbage Collector problem. Why Root crash if the GC delete a TH1 before the
canvas for example?

[wlav]

Hey,

> Also, if I understand well the PyRoot stuff, you use Cint to translate Python <-> Root.

Yes, that is the way it is done. Although still different from what you may think.

> If it's really the case, I have some doubt about the performance

Note that most of the action is usually in the user code (python) and/or in the library
code (ROOT/C++). As such, the performance of the bridge in betweem does usually
not matter that much as long as it is at the "good enough" level.

That said, I would really like to see PyROOT go head-to-head against the SWIG
generated bindings in a set of benchmarks like the ROOT tutorials.

> I'd like to have some interaction with the Root team to solve some technical
> problems, like Garbage Collector problem. Why Root crash if the GC delete a
> TH1 before the canvas for example?

ROOT uses a notification scheme for graphics/geometry etc. objects. Please have
a look at the bindRootObject function in RootWrapper, the ObjectHolder destructor
and the MemoryRegulator class of PyROOT to see one way of getting a workable
solution.

Cheers,
Wim

[brun]

We have seen several implementations of ROOT/Python or Runby interfaces using SWIG. None of these interfaces were faster than the technique used by Pyroot.
see, eg

http://alcaraz.home.cern.ch/alcaraz/PythonRoot/

A direct interface from the ROOt/CINT dictionary is the only one really
maintainable in the long term. In addition it offers an automatic interface to any shared library containing a CINT dictionary.

Rene