Re: really crazy crash

Tom Roberts wrote:
> I, too, am in HEP. And what you say is true for students, postdocs,
> and junior faculty that are traditionally involved in simulations and
> analysis. I am trying to provide tools that "even a professor can
> use", and in my experience most of them do not know C++, and have
> little interest in learning.

You must be in a different planet. I don't believe that any serious physicist can do any work without
knowing C++ these days. Hiding C++ is the thing to do if you show always the same very restricted
application, but a bad service you give to your students if you try to discourage them to learn C++.
> While using Root/CINT capabilities is beyond them, they can easily use
> my GUI macro to generate useful plots. Indeed, I use the macro FAR
> more often than Root/CINT, because it is so very much easier.
What do you mean by a "macro", a CINT macro. If yes this contradicts your statement.
GUIs are not too complex to build from a CINT script, and in general users find quickly a way to extend
and improve the interface once they have simple examples.
> A good user interface multiplies the utility of a program many fold --
> or rather, a bad user interface greatly reduces it.
I agree
> The Root browser is OK, but not great, as far as user interfaces go.
> But the Root authors had the foresight to implement GUI primitives,
> permitting the construction of a much more user-friendly interface,
> which is what I am doing.

Could you post your comments, gripes to the ROOT browser? Could you post your script, such that we can
understand what you mean by a good GUI and try to improve the browser or other utilities if we find something interesting in your script.

Rene Brun
>
>
> Tom Roberts
>
>
> Gordon Watts wrote:
>> Hi Tom,
>> Sorry for poking my nose where it doesn't belong. I'm from the HEP
>> community and seeing that statement blow just blew me off my chair -
>> in HEP we couldn't get any physics done w/out C++ - everyone knows it
>> and we depend on every machine having a compiler! Profs in their 50's
>> and 60's have taken time to learn it so they can make plots, etc.
>>
>> Are you in the astro community? Or something else? Just curious.
>> Many thanks!
>>
>> Cheers,
>> Gordon.
>>
>>> -----Original Message-----
>>> From: owner-roottalk_at_root.cern.ch [mailto:owner-roottalk_at_root.cern.ch]
>>> On Behalf Of Tom Roberts
>>> Sent: Wednesday, April 23, 2008 4:25 PM
>>> To: Rene Brun
>>> Cc: Lorenzo Moneta; 'ROOT Talk'
>>> Subject: Re: [ROOT] really crazy crash
>>>
>>> I thought that ".L file.C+" depends on the existence of a C++ compiler.
>>> I have many users who have no compiler, as they are physicists and have
>>> no use for C++.
>>>
>>> How can I test for the ability to use the compiler? I have noticed that
>>> for large .root files the scan in my macro runs more slowly that I
>>> would
>>> like. So I could write a small macro that tests for C++ and then loads
>>> the real macro using it if present, or not.
>>>
>>>
>>> Tom Roberts
>>>
>>>
>>> Rene Brun wrote:
>>>> Note that the recipe indicated by Lorenzo works everywhere, including
>>>> Windows.
>>>>
>>>> Rene Brun
>>>>
>>>> Tom Roberts wrote:
>>>>> Lorenzo Moneta wrote:
>>>>>> If you have a so long macro I recommend you first to compile it
>>> with
>>>>>> AClic,
>>>>>> do :
>>>>>> .L test5.C+
>>>>>> In this case the #includes must be there
>>>>> I distribute my macro to many users, most of whom are physicists,
>>> not
>>>>> computer experts, and many of whom use Windows. I cannot depend on a
>>>>> C++ compiler being installed on the user's system. So I don't want
>>> to
>>>>> do this unless absolutely required.
>>>>>
>>>>> Axel has indicated he found this particular problem and has fixed
>>> it,
>>>>> so I'll not change anything I'm doing, for now (though I will put in
>>>>> all the #include-s). I still need to address the actual problem in
>>> my
>>>>> big macro (related to TTreeFormula in some way I have not yet
>>> isolated
>>>>> into a short test).
>>>>>
>>>>>
>>>>> Tom Roberts
>>>>>
>>>>>
>>>>>> Lorenzo
>>>>>>
>>>>>> On Apr 22, 2008, at 11:19 PM, Tom Roberts wrote:
>>>>>>
>>>>>>> I am trying to debug a >2000 line Root macro by isolating the
>>>>>>> problem into a small macro (it works on 5.12-16 but crashes on
>>>>>>> 5.18). I keep getting frustrated by seemingly trivial crashes that
>>>>>>> do not seem to be the real problem. Here is another one that
>>> crashes
>>>>>>> on 5.16 and 5.18 (Linux, Fedora Core 8).
>>>>>>>
>>>>>>>
>>>>>>> I thought CINT permitted one to omit the #includes in a macro
>>> file.
>>>>>>> This seems to not be the case, except for the remarkable fact that
>>>>>>> it works, but crashes on ".q".
>>>>>>>
>>>>>>> Specifically: if I do:
>>>>>>> .L test5.C
>>>>>>> .q
>>>>>>> root crashes.
>>>>>>>
>>>>>>> If I do:
>>>>>>> .X test5.C
>>>>>>> .q
>>>>>>> it prints "Ntuple 'VirtualDetector/Det1' opened" (i.e. the macro
>>>>>>> worked correctly) and then crashes on the .q.
>>>>>>>
>>>>>>> Indeed, all that is needed is a declaration "TNtuple *ntuple" in
>>> the
>>>>>>> class to make this crash on .q.
>>>>>>>
>>>>>>> If I uncomment the #include, all is well. Note that no #include of
>>>>>>> TFile.h seems to be needed, and attempts to display this problem
>>>>>>> with TFile all failed.
>>>>>>>
>>>>>>> What is the difference between TFile and TNtuple?
>>>>>>> Do I really need to #include the class header for every Root class
>>> I
>>>>>>> use in a macro?
>>>>>>> How does the macro execute correctly but crash on .q?
>>>>>>>
>>>>>>> (my big macro does crash on .q, but it normally calls
>>>>>>> gApplication->Terminate(0) which does not crash, so this is not a
>>>>>>> problem to my users.)
>>>>>>>
>>>>>>>
>>>>>>> Tom Roberts
>>>>>>> // test5.C
>>>>>>>
>>>>>>> //#include <TNtuple.h>
>>>>>>>
>>>>>>> class PlotNtuple {
>>>>>>> TFile *file;
>>>>>>> TNtuple *ntuple;
>>>>>>> public:
>>>>>>> PlotNtuple(const char *filename, const char *ntuplename);
>>>>>>> void scan();
>>>>>>> };
>>>>>>>
>>>>>>> PlotNtuple::PlotNtuple(const char *filename, const char
>>> *ntuplename)
>>>>>>> {
>>>>>>> file = 0;
>>>>>>> ntuple = 0;
>>>>>>>
>>>>>>> file = new TFile(filename,"READ");
>>>>>>> if(file->IsZombie()) {
>>>>>>> printf("Cannot read '%s'\n",filename);
>>>>>>> file = 0;
>>>>>>> return;
>>>>>>> }
>>>>>>> ntuple = dynamic_cast<TNtuple*>(file->Get(ntuplename));
>>>>>>> if(!ntuple) {
>>>>>>> printf("Cannot find NTuple '%s'\n",ntuplename);
>>>>>>> return;
>>>>>>> }
>>>>>>> printf("Ntuple '%s' opened\n",ntuplename);
>>>>>>> }
>>>>>>>
>>>>>>> void PlotNtuple::scan()
>>>>>>> {
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> void test5()
>>>>>>> {
>>>>>>> PlotNtuple *pn=new
>>>>>>> PlotNtuple("g4beamline.root","VirtualDetector/Det1");
>>>>>>> pn->scan();
>>>>>>> }
>>>>>>> <g4beamline.root>
>>
>
Received on Thu Apr 24 2008 - 07:14:44 CEST