Re: Displaying graphs before main() returns

From: Roland Kuhn <>
Date: Wed, 31 May 2006 22:32:11 +0200

Hi Valeri!

On 31 May 2006, at 21:03, Fine, Valeri wrote:

> Hello Roland,
>> Hi Valeri!
>> On 31 May 2006, at 19:33, Fine, Valeri wrote:
>>> Hello Roland
>>> May I comment one thing?
>>> You wrote:
>>>> This is no longer true in case of a script because it depends on
> the
>>>> internal state of the CINT.
>>> It seems to me you suppose that making your own so-called "stand-
>>> alone"
>>> application linked against of ROOT libraries you get rid of the
>>> "internal state of CINT"
>>> All your conclusions are based on this hypothesis.
>> Not the ones about debug-ability.
> May be , but ...
> As soon as the debug-ability is concern I do not see any big
> difference
> between ROOT that loads some custom shared library and the custom C++
> application that loads another custom shared library, do you?
> I think the comparison of the ROOT running C++ script and C++
> application is not correct one.
> One should compare ROOT loading the pre-compiled shared library
> with the
> simplest script if any and C++ application loading the third party
> shared library

The point was that I normally do not dynamically link my 'custom shared library', which enables me to do

prompt> gdb analyze
(gdb) br some_function
(gdb) run -i infile -o outfile

which is definitely more direct than the approach suggested by Christian, which assumes that first a sleep(10) has been placed at a convenient location to enable the user to press ^C before the intended break point is actually reached for the first time. Using shared libraries is a limitation in some situations. And let's face it: the average user does not create an application which dynamically loads different shared libraries based on program input.

> I think the difference would have been subtle.
>>> However, it is not correct. Many ROOT classes do use the CINT
>>> internally
>>> (the best example is the ROOT Signal / Slot communication).
>>> In other words, your proof of the advantages of the stand-alone
>>> ROOT-based applications is based on false premises.
>>> Assuming the "internal state of CINT" does exist one may have
> conclude
>>> that making his own "stand alone" application doesn't eliminate it
> at
>>> all.
>> Your statement is theoretically correct, I should have phrased mine
>> differently. In an interactive session all previously entered
>> commands can potentially influence the running analysis script, thus
>> the result of the analysis could depend on what the user did before
>> running the script. Of course, if the script is 100% bug free and the
>> programmer has taken the CINT environment into account, there should
>> be no interference. The problem could also be avoided by always
>> running the analysis script in a fresh root session. But mistakes
>> happen. And this kind of mistake is not possible with an application
>> that does not offer the command line prompt.
>> This argument is not hypothetical but based on personal experience.
> Hmm. I do not understand.
> If one does not want any ROOT prompt he/she should not ask for that
> prompt.
> root.exe -b -q mymacro.C

Yes, of course. But it needs to be done and remembered.

>>> Therefore, one is advised to use CINT interpreter as the tool to
>>> prototype the application and ACLiC to use it in "production" mode.
>> Interpreter and ACLiC certainly are very useful tools, but not the
>> only ones.
> Sure !!!
> However, to avoid misleading conclusion and time lost one should
> use the
> correct premiss.
> The presuppositions:
> 1. Stand-alone ROOT-based code doesn't use CINT
> 2. One can not avoid ROOT prompt
> are not correct ones.

Yes, as I already said in my last mail.

> 3. debugging the ROOT-based code needs a lot patience and
> qualification
> 4. debugging the more/less complex CINT script is near impossible
> are correct one.

This last point is exactly what made me write my first email in this thread. In view of this statement it might not be a bad idea at all to run a ROOT-based application with its own main().

> Anyway, I do not think the 1 & 2 are cause of 3 & 4.

I don't think I ever implied that.



TU Muenchen, Physik-Department E18, James-Franck-Str., 85748 Garching
Telefon 089/289-12575; Telefax 089/289-12570
CERN office: 892-1-D23 phone: +41 22 7676540 mobile: +41 76 487 4482
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things.
	-Doug Gwyn
Version: 3.12
GS/CS/M/MU d-(++) s:+ a-> C+++ UL++++ P+++ L+++ E(+) W+ !N K- w--- M 
+ !V Y+
PGP++ t+(++) 5 R+ tv-- b+ DI++ e+++>++++ h---- y+++

Received on Wed May 31 2006 - 22:31:55 MEST

This archive was generated by hypermail 2.2.0 : Mon Jan 01 2007 - 16:31:58 MET