Re: [ROOT] TPolyLine(3D) Streamer problem? - change in the meaning of SPLIT parameter in 3.01/06

From: Rene Brun (Rene.Brun@cern.ch)
Date: Tue Jul 17 2001 - 22:06:32 MEST


Hi Pasha,

Yes, I agree that this feature should have been documented a bit better.
We had hoped to not have to describe this option and to make it automatic
by getting the information from CINT if a class has a custom Streamer or
not.

I am surprised by your statement about the factor 3. Could you send me
an example of a class where you obtain this result?
I take this opportunity to encourage people to migrate to the
automatic Streamers. More details in teh Users Guide.

Rene Brun

On Tue, 17 Jul 2001, Pasha Murat (630)840-8237@169G wrote:

> Gerco Onderwater wrote:
> > 
> > Hi Rene,
> > 
> > As a matter of fact, we just figured out that splitlevel 0 will do the
> > job. A value -1, as you suggested, produces the same results as kTRUE
> > (which is indeed incorrect).
> > 
> > On Tue, 17 Jul 2001, Rene Brun wrote:
> > 
> > > Hi Gerco,
> > >
> > > TPolyLine3D is one of the few ROOT classes still with a hand-written Streamer.
> > > Classes with a hand-written Streamer cannot be used in split mode in a branch.
> > > You can force the branch to not use the split mode and call the Streamer
> > > function by using split=-1. We expect this to be automatic in the next release.
> > > So, in your example, change the line:
> > >
> >
> Dear ROOTers,
> 
> I think that the fact that the meaning of 'split' parameter has changed 
> in 3.01 needs more advertizing. Much more. Everybody using customized Streamers 
> should be warned - this change may affect people in a severe way. A brief comment 
> in the release notes is not enough. 
> 	We'are using hand-written Streamers and I just spent few hours of 
> debugging to figure that after switching to ROOT 3.01/06 we were supposed to 
> change split=0 to split=-1 in the depths of the code, luckily this was caught 
> during the testing.
> 						-best, Pasha
> 
> P.S. In case of no compression customization of Streamers can significantly improve 
>      the I/O performance (I saw improvements by a factor of 3), so it seems to be a 
>      very reasonable option to consider.
> 



This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:52 MET