Hi Rene,
Sorry, but my point is I take 2 readable trees and
merge them, I get an unreadable tree. It looks to be because the TStreamer
Info in the output file was simplified by TChain::Merge
In the original file I have this kind of stuff for classes containing only
a static member :
StreamerInfo for class: MPi, version=1
MParticle BASE offset= 0 type= 0
StreamerInfo for class: MK, version=1
MParticle BASE offset= 0 type= 0
the merged file doesn't have that, so I cannot read the tree. I really
think it's a bug.
cheers,
Colin
On Fri, 4 Oct 2002, Rene Brun wrote:
> Hi Colin,
>
> static class members are not streamed.
>
> Note that you can remove several redundant statements in your program.
> See below
>
> Rene Brun
>
> On Fri, 4 Oct 2002, Colin Bernet wrote:
>
> >
> > 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 ROOTMonitorModule",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:13 MET