Nick West | 1 Feb 2006 11:40
Picon
Picon
Favicon

[ROOT] FW: Exception catching across a call to ProcessLineFast

Dear RootTalk,

Is there a limitation on ProcessLineFast that prevents code from 
catching an exception thrown from code called via ProcessLineFast?

i.e.

  try { gROOT->ProcessLineFast("MyFunction()"); }
  catch(object-thrown-by-MyFunction) { ...}

and if not, can anyone see what's wrong with the attached macro 
where the catch works fine for a direct call but fails when the 
call goes via ProcessLineFast.  

Note I am using ACliC; I am not expecting exception handling 
to be handled within CINT.

I am running Scientific Linux SL Release 3.0.4 (SL) 
             gcc version 3.2.3 2

With ROOT 4.04/02 build 12 September 2005
 - the failing catch terminates the program.

With ROOT 5.08/00 build 13 December 2005
 - the failing catch reports:-

  Error: C++ exception caught :0:

and ROOT recovers but I have lost the exception information.

(Continue reading)

nasim | 1 Feb 2006 15:47
Picon
Picon

Re: [ROOT] summation of histograms


Hi Rene,
Thank you for the reply. But still there is a problem in drawing the 
histogram
if we have 
TH1F h4= n1*(*h1)+n2*(*h2)+n3*(h3)...
where n1 ,n2 and n3 are the normalization factors how can I draw 
the results (h4 is not a pointer).

I aslo thought if I multiply the first histogram :
histo->Multiply(h1,n1);
and then add it to others

histo->Add(h2,h3,n2,n3);
I am not sure about how to use multiplication and adding function in this 
case. 

Histo needs to be difined as an TH1F. how can I possibly do that

Many Thanks,
Nasim

On Mon, 30 Jan 2006, Rene Brun wrote:

> Do, for example
> 
> TFile *f1 = new TFile("file1.root");
> TH1 *h1 = (TH1*)f1->Get("myhist");
> TFile *f2 = new TFile("file2.root");
> TH1 *h2 = (TH1*)f2->Get("myhist");
(Continue reading)

Tristan Beau | 1 Feb 2006 16:31
Picon
Picon

[ROOT] is TTreeSQL dumping the whole table ?


Hello,

   I just discovered the new classe TTreeSQL. I tried to use it with  
a code such as :

TSQLServer *s = TSQLServer::Connect("mysql://dbserv/db","user","pwd");
TTreeSQL *t = new TTreeSQL(s,"db","atable");

   But then it crashes my session probably because the "atable" table  
is too big. Is TTreeSQL dumping the whole table with the constructor  
TTreeSQL ? This is a problem while accessing to very big tables ( > 1  
Go ). Which way should I use in such a case ?

   Thank's in advance,

                                Tristan

---
Tristan Beau       http://www.apc.univ-paris7.fr/~beau/
AstroParticules et Cosmologie
11 pl. M. Berthelot, 75231 Paris cedex 05
tel: +33 1 44 27 14 46 ,        fax: +33 1 43 54 69 89

Rene Brun | 1 Feb 2006 16:48
Picon
Picon

Re: [ROOT] summation of histograms

As soon as you have more than 2 objects to add, it is more efficient
to write the following look, assuming an array TH1 *h[N]
and an array of scale factors w[N]

   for (i=1;i<N;i++) h[0]->Add(h1[i],w[i]);

Above, I add all into h[0]. Copy h[0] to another histogram
if you want to preserve the original histo.

Rene Brun

On 
Wed, 1 Feb 2006, nasim wrote:

>
> Hi Rene,
> Thank you for the reply. But still there is a problem in drawing the
> histogram
> if we have
> TH1F h4= n1*(*h1)+n2*(*h2)+n3*(h3)...
> where n1 ,n2 and n3 are the normalization factors how can I draw
> the results (h4 is not a pointer).
>
> I aslo thought if I multiply the first histogram :
> histo->Multiply(h1,n1);
> and then add it to others
>
> histo->Add(h2,h3,n2,n3);
> I am not sure about how to use multiplication and adding function in this
> case.
(Continue reading)

Philippe Canal | 1 Feb 2006 17:38
Favicon

RE: [ROOT] is TTreeSQL dumping the whole table ?

Hi Tristan,

The size of the database should not cause a crash.
However there was a bug recently fixed (in the CVS repository)
that provoked a crash if the table contain any character string 
columns.

Please try with ROOT from the head of the repository.  If it
still does not work, please send me a stack trace of where it
crashed.

Cheers,
Philippe. 

-----Original Message-----
From: owner-roottalk <at> pcroot.cern.ch [mailto:owner-roottalk <at> pcroot.cern.ch]
On Behalf Of Tristan Beau
Sent: Wednesday, February 01, 2006 9:31 AM
To: roottalk <at> pcroot.cern.ch
Subject: [ROOT] is TTreeSQL dumping the whole table ?

Hello,

   I just discovered the new classe TTreeSQL. I tried to use it with  
a code such as :

TSQLServer *s = TSQLServer::Connect("mysql://dbserv/db","user","pwd");
TTreeSQL *t = new TTreeSQL(s,"db","atable");

   But then it crashes my session probably because the "atable" table  
(Continue reading)

Philippe Canal | 1 Feb 2006 19:25
Favicon

RE: [ROOT] FW: Exception catching across a call to ProcessLineFast

Hi Nick,

The CINT interpreter whether it is called directly from the prompt
or via ProcessLine(Fast) has its own exception handler (to avoid
that the interpreter crashes upon an exception).  To disable it
(and to re-enable it) use :
   gROOT->ProcessLine(".exception");

and your code will properly work.

Cheers,
Philippe.

-----Original Message-----
From: owner-roottalk <at> pcroot.cern.ch [mailto:owner-roottalk <at> pcroot.cern.ch]
On Behalf Of Nick West
Sent: Wednesday, February 01, 2006 4:40 AM
To: roottalk <at> pcroot.cern.ch
Subject: [ROOT] FW: Exception catching across a call to ProcessLineFast

Dear RootTalk,

Is there a limitation on ProcessLineFast that prevents code from 
catching an exception thrown from code called via ProcessLineFast?

i.e.

  try { gROOT->ProcessLineFast("MyFunction()"); }
  catch(object-thrown-by-MyFunction) { ...}

(Continue reading)

Philippe Canal | 1 Feb 2006 20:22
Favicon

RE: [ROOT] i/o of objects with multiple references

Hi Sue,

Currently TClonesArray intentionally does not register to the 
TBuffer the addresses of its content as individual objects.

In particular this means that upon storing your std::map, the
TBuffer does not know that it has already saved those objects
and thus save them a 2nd time (and will restore them separately).

Changing the behavior of TClonesArray would slow down the 
typical case so we would prefer not to.

Also this would not prevent the same problem from re-appearing
if you decided to split your object so that the TClonesArray and
the map are in 2 different branches.

In addition, we currently have no means for the user to indicate
whether an STL collection containing pointers own or does not own
the objects pointed to.  So for now, we assume (to avoid memory
leaks) that they do own it.  This assumptions is used only in the
I/O code and has any effect only if the user does not explicitly
clear the collection before or after reading an entry in a TTree 
(So for example via TTree::Draw).

So for theses reasons I recommend a slight modification of your
implementation where instead of having a direct link between
the pointer and the weight, you make it indirect.

For example you could use a map<int,float> where the int is an 
index (or uniqueId) representing the Hit (for example this number 
(Continue reading)

Tristan Beau | 2 Feb 2006 09:18
Picon
Picon

Re: [ROOT] is TTreeSQL dumping the whole table ?


Hi,

   I tried the latest version of ROOT (I got it from the CVS  
repository), version  5.09/01  16 December 2005, compiled with gcc  
3.4.3.
   The TTreeSQL constructor works on the machine used (the first test  
with root 5.08.00 was on my laptop), but it takes a lot of time and  
requires a lot of network data transfer.

   Then, I tried some plots with some t->Draw("onefield") statements.  
And it seemed to me that each time the whole table is copied. After 5  
or 6 plots, my machine (SL 4.1) killed the root.exe process which  
fullfilled the memory ( 1 GB + 2 GB of swap). Then I got no stack  
trace on stdout / stderr.

   The table has roughly 1 millions of rows with 400 columns each...
		
					Tristan

On 1 Feb 2006, at 17:38, Philippe Canal wrote:

> Hi Tristan,
>
> The size of the database should not cause a crash.
> However there was a bug recently fixed (in the CVS repository)
> that provoked a crash if the table contain any character string
> columns.
>
> Please try with ROOT from the head of the repository.  If it
(Continue reading)

Hajime Nanjo | 2 Feb 2006 11:36
Picon
Picon
Favicon

[ROOT] problem on ROOT I/O with TClonesArray of TVector3

Dear ROOT developers,

A class named "B" has a member "fA", which is a TClonesArray of a class "A".
The class "A" has two members, "int val" and "TVector3 tv".

I succeeded in ROOT I/O with the class "B" but
found a strange behavior as follows.

Two operations,  "tree->Draw("B.fA.tv.fZ")"
and              "tree->Draw("B.fA.tv.Z()")"
return the same result as expected.

But "tree->Draw("B.fA.tv.Z()","B.fA.val==1")"
returns a wrong result,
which is differ from the result of
"tree->Draw("B.fA.tv.fZ","B.fA.val==1")".

Could you fix the strange behavior?

I use ROOT version 5.09/01 under Scientific Linux 4.1. 
The source file are attached.
The usage is as follows.

tar xvzf test.tgz
cd test
source make.sh
./write

root
root [0] .x draw.C
(Continue reading)

Philippe Canal | 2 Feb 2006 15:35
Favicon

RE: [ROOT] is TTreeSQL dumping the whole table ?

> but it takes a lot of time and requires a lot of network data transfer.

We still need to optimize this portion of the code :(.

> After 5  or 6 plots, my machine (SL 4.1) killed 
> the root.exe process which fullfilled the memory ( 1 GB + 2 GB of swap). 

I'll try to see if I can spot any memory leak.  Could you try running
with valgrind?

Thanks,
Philippe

-----Original Message-----
From: Tristan Beau [mailto:beau <at> in2p3.fr] 
Sent: Thursday, February 02, 2006 2:18 AM
To: Philippe Canal
Cc: roottalk <at> pcroot.cern.ch
Subject: Re: [ROOT] is TTreeSQL dumping the whole table ?

Hi,

   I tried the latest version of ROOT (I got it from the CVS  
repository), version  5.09/01  16 December 2005, compiled with gcc  
3.4.3.
   The TTreeSQL constructor works on the machine used (the first test  
with root 5.08.00 was on my laptop), but it takes a lot of time and  
requires a lot of network data transfer.

   Then, I tried some plots with some t->Draw("onefield") statements.  
(Continue reading)


Gmane