Re: Displaying graphs before main() returns

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.

Ciao,

                     Roland

--
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
-----BEGIN GEEK CODE BLOCK-----
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+++
------END GEEK CODE BLOCK------










application/pgp-signature attachment: This is a digitally signed message part