Hi Rene,
I switched to root 3.03/09 (RH6.2), and my biggest problem is now solved
: trees
are now readable even if I don't have the original library. This is a
great feature, and I thank you for that !
Yet... I still have one last tiny problem : My program generates a lot of
small trees that I have to chain together. As I noticed this process gets
really slow when the number of files grows big, I wrote a small merge
program :
#include "TROOT.h"
#include "MiniDST.h" // *
#include "TChain.h"
extern void InitGui();
VoidFuncPtr_t initfuncs[] = { InitGui, 0 };
TROOT root("simpleMP","DATE ROOT Monitor Module",initfuncs);
int main(int argc, char** argv) {
if(argc < 3) {
cerr<<"usage : MergeDST <source files> <output file>"<<endl;
exit(1);
}
MEvent *event = new MEvent();
TChain chain("MDST");
chain.SetBranchAddress("event",&event); // *
for(unsigned i=1; i<argc-1; i++) {
cout<<"source "<<i<<" : "<<argv[i]<<endl;
chain.Add(argv[i]);
}
cout<<"output "<<" : "<<argv[argc-1]<<endl;
chain.Merge(argv[argc-1]);
return 0;
}
I tried it with and without the star stamped lines.
What is happening is that the StreamerInfo in the output files is not the
same as the one in the input files. Some of the classes were removed in
the merge process... these classes are almost empty, they just contain a
static member, eg :
class Particle {...};
class Pi : public Particle {
static double pdgmass;
}
I just want something really simple, just to get the pion mass when
a pion is created. Otherwise everything needed is in the Particle class.
Shouldn't this type of class also be included in the output's file
streamer info ? Am I doing something wrong ?
Right now, As the StreamerInfo is wrong, I cannot read at all the output
file.
thanks,
Colin
On Mon, 23 Sep 2002, Rene Brun wrote:
> Hi Colin,
>
> Please indicate which version of Root and the platform?
>
> see below
>
> On Sun, 22 Sep
> 2002, Colin Bernet wrote:
>
> >
> > Hi rooters !
> >
> > Loading 2 shared libraries, each containing a dictionnary, or a single
> > shared library containing 2 dictionnaries seems to be impossible. In the
> > first case, symbols from the secodn library are not recognized by root,
> > while in the second case, the created objects get stuck at one point for
> > unknown reasons.
> >
> > What I want to do is :
> > 1 - Fill trees (split 99) using classes located in lib1.so
> > 2 - Use MakeClass on one of these trees, modify the code so it compiles,
> > and create a shared library lib2.so out of that.
> >
>
> This should work. Why do you have to modify the code to get it compiled?
> please try version 3.03/09 in case you use older versions.
>
> > The only way to work that out was to create a library demo.so using
> > TFile::MakeProject.
> > in ROOT, I can then do
> > .L demo.so
> > .L lib2.so
> > this works perfectly, despite the fact demo.so, to my point of view,
> > should not be necessary to read a tree containing basic data types.
>
> Using version 3.03, you should be able to read/query a file containing
> classes and not only basic data types, even if you do not have the
> original class library.
> >
> > Now, I have some code in lib1.so that I would
> > like to reuse in lib2.so. I tried to load these libraries in different
> > orders, to link lib1.so as a module inside lib2.so, but nothing works. I'm
> > afraid this is because 2 dictionnaries are conflicting.
>
> if lib2 depends on lib1, you should load lib1 first. I cannot tell you
> more without looking at your classes.
>
> >
> > One could argue that I may use unsplit mode so I get the objects from
> > lib1.so as is inside the tree. I do not want to do that for 2 reasons : I
> > prefer to keep the data independant from the source code by using basic
> > types, and I like to be able to issue complex TTree::Draw commands
> > to have a first look at the data.
>
> I repeat: You can analyze a Tree containing classes, even if you do not
> have the original class library.
>
> Rene Brun
>
>
> >
> > Is there a way to solve this problem without duplicating the source files
> > of lib1 to compile and link them in lib2 ?
> >
> > Many thanks,
> >
> > Colin
> >
> >
>
>
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:51:12 MET