Re: Displaying graphs before main() returns

Hi Rene!

On 31 May 2006, at 16:51, Rene Brun wrote:

> Hi Roland,
>
> You seem to ignore that from the command line, you can do
>
> root > .x myscript.C (executed via CINT interpreter)
> root > .x myscript.C+ (compiled via ACLIC using the native compiler)
> root > .x myscript.C+g (same but compiled in debug mode).
>
> In all cases you can run under the debugger (eg gdb)
> gdb root.exe
>

Yes, of course it is not impossible. Only, to set a break point in myscript, I'd have to jump through some hoops. Also, giving command line options is more cumbersome. Another problem is the use of external libraries which require certain flags to be passed to the compiler. There's certainly a way with CINT (I don't know), but it is more complicated than the trivial Makefile.

> In addition from the command line you can load any plug-in library.

This is not about possible/impossible, it is about ease of use for different types of application.

> Rene
>
> Roland Kuhn wrote:
>> Hi Rene!
>>
>> On 31 May 2006, at 13:02, Rene Brun wrote:
>>
>>> Hi Roland,
>>>
>>> Could you clarify what you mean by
>>> "My experience goes exactly in the opposite direction"?
>>>
>> Your main point is that people don't know what they're doing, give
>> useless bug reports and increase general unhappiness. My
>> experience is that some user asks me "why does my script crash"
>> and the only efficient way to get an answer is to run it in gdb or
>> valgrind, which is more complicated for a script than for a
>> compiled program. The other problem is that users are lazy and
>> forget to program proper cleanup procedures, producing questions
>> like "why does this crash if executed twice". To my mind the most
>> important point, however, is reproducability. When I do an
>> analysis I have to make sure that I can exactly redo every single
>> step and always get the same result. This is no longer true in
>> case of a script because it depends on the internal state of the
>> CINT. Of course, using proper discipline it is also possible to
>> start a fresh ROOT session for every iteration, but if everyone
>> had this kind of discipline, then we wouldn't be discussing this...
>>
>> Don't get me wrong, I think that CINT is a pretty cool feature for
>> rapid testing and interactive analysis. But I think it is fatal
>> that the lead developer so very strongly discourages the use of
>> standalone applications.
>>
>> Finally, writing a main program with standard event loop is really
>> _trivial_. The only problem is that there is no error message (or
>> the like) which informs the ignorant user that an event loop would
>> be beneficial.
>>
>>> The main program syndrom
>>> ========================
>>> Of course, nobody prevents you to write your own main program.
>>> This is necessary when you implement your own event loop.
>>> By event loop, I mean graphics/system event loop.
>>>
>>> It is much better to execute a script (interpreted or compiled)
>>> from the ROOT prompt. This script can load automatically one or
>>> more shared libs (plug-ins). Making plug-ins makes your program
>>> more modular. It also greatly facilitates our job. In particular,
>>> we see many reports where people do not understand what is an
>>> event loop. They forget to instantiate a TApplication (or TRint)
>>> object. They forget to send the makefile to build the
>>> executable, etc.
>>>
>>> Rene Brun
>>>
>>> Roland Kuhn wrote:
>>>> Hi Rene!
>>>>
>>>> On 30 May 2006, at 08:37, Rene Brun wrote:
>>>>
>>>>> If you create your own executable (with a main) and this
>>>>> application has graphics,
>>>>> you must create a TApplication object. See example in $ROOTSYS/
>>>>> test/hworld.cxx
>>>>> It is in general a very bad idea to create your own main
>>>>> program. You better execute scripts
>>>>> from the ROOT prompt.
>>>>>
>>>> Could you elaborate on this? My experience goes exactly in the
>>>> opposite direction.
>>>>
>>>> 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------
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>> 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------
>>
>>
>>
>>
>

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