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. 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. A good user interface multiplies the utility of a program many
fold -- or rather, a bad user interface greatly reduces it. 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.
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 - 02:30:41 CEST