Hi Colin,
Could you send me (not to the list) a small tar file with all the files
necessary to reproduce the problem (small files only please)
Rene Brun
On Mon, 7 Oct 2002, Colin Bernet wrote:
>
> 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