Re: More problems with CINT

By speaking of "my application" you are actually referring to the application which I compiled with ACliC, correct?

If not, I'm afraid I would need another "very similar" mail from you to understand how else I could.

If yes, however then the answer is nothing prevents me from calling ROOT classes from within there.

But,

its not "my application" anymore then. It's not an even application anymore. It's a dynamically loaded library. It's not int main( ) and ROOT is the owner, not bash is.

ROOT uses my binary. And I'm not saying that this shouldn't happen - but I'd prefer an API - isn't that the common way how to do it in C++? Something (ROOT) offeres functionality (plotting graphs) and provides it to programmers through an API - not uses an interpreter or dynamic linker to tangle up one's binary in its own execution and then run it.

I'll send this to the M/L, maybe someone can help us sorting this apparent misunderstanding out.

After all, again, what is the problem?!

The problem is that all this interpreter and aclic stuff makes matters more complicated than they have to be. A CINT dictory? An API wouldnt even know about such a thing! Strange Warnings when compiling witch AClic although the source code is just perfectly fine? There would not be anything "Aclic" in use with an api. With an API you could simply program C++ as you always do and normally operate with header files - just like with any other API. It would be easy, straight forward, disentangle matters and render CINT and aclic and all the other stuff totally irrelevant.

Cedri

On 02.04.2010 12:03, Rene Brun wrote:
> My mails seem to start now in a very similar way.
> What prevents you to call ROOT classes from your application. We have
> hundred of very large applications doing that.
> What is the problem?
>
> Rene
>
> Cedric Sodhi wrote:
>> No, we misunderstand eachother! I know how ROOT can be used (I've read
>> the important parts of the manual - dont worry ;) ) Right now:
>>
>> Start ROOT -> Root starts your script (either interpreted or compiled
>> and dynlinked)
>>
>> If ROOT offered an Application Porgramming INTERFACE, it would be an
>> interface accessible from outside of ROOT! No starting ROOT at all!
>> ROOT does not invoke your script (compiled or not) - Your Program
>> invokes ROOT routines!
>>
>> There could, after all, be a "rootd" daemon running which serves as
>> the backend to the api and manages resources (the API faciliates ICP
>> between your program and the actual ROOT backend) - but the point is
>> that you could write a binary that utilizes root - not one that is
>> utilized BY root!
>>
>> Cedric
>>
>> On 02.04.2010 11:39, Rene Brun wrote:
>>> Think about it! :)
>>>
>>> Again, I do not understand your question. We do what you ask for since
>>> day 1 of ROOT.
>>> see the numerous tutorials in $ROOTSYS/tutorials, eg
>>> tutorials/graphs/graph.C
>>> And you can do it
>>> -from the command line, eg
>>> root > TGraph g(10)
>>> -from an interpreted script
>>> root > .x graph.C
>>> -from ACLIC
>>> root > .x something.C+, something.C++, something.C++g, etc
>>>
>>> from the interpreter and scripts, you do not even have to include the
>>> header files.
>>>
>>> see the very first pages of the Users Guide.
>>>
>>> Note that (as explained in the Guide) you can also call interpreted
>>> scripts from your compiled code via, eg
>>> gROOT->ProcessLine(".x myscript.C"); //or anything executable with
>>> CINT/ACLIC
>>>
>>> Rene
>>>
>>> Cedric Sodhi wrote:
>>>> But in order to do so, you have to compile your Sourcecode
>>>> w/Aclic/create a dictionary. It's not a standalone API which I can
>>>> address through "ROOT Header files". ROOT is the driver, not one of
>>>> your C++ binaries is. An API I can adress from an arbitrary binary. An
>>>> API doesnt run the binary as ROOT does it. Imagine
>>>>
>>>> #include <root>
>>>>
>>>> int main( ) {
>>>> root::TGraph *myROOTGraph = new root::TGraph( 10 );
>>>> myROOTGraphh->Draw( "AL" );
>>>> return 0;
>>>> }
>>>>
>>>>> g++ myprog.cpp
>>>>> ./a.out
>>>>
>>>> * Graph is rendered *
>>>>
>>>>
>>>> Wouldn't that be beautiful? No more hassle with an interpreter - plain
>>>> C++ and ROOT provides an API!
>>>>
>>>> Think about it! :)
>>>>
>>>> --CS
>>>>
>>>>
>>>> On 02.04.2010 11:04, Rene Brun wrote:
>>>>> I do not understand your question. From the interpreter (CINT and/or
>>>>> ACLIC) you can call any ROOT class.
>>>>> You can also call any C++ compiled class library if you have generated
>>>>> the dictionary for your classes
>>>>> via either rootcint or gccxml.
>>>>>
>>>>> Rene
>>>>>
>>>>> Cedric Sodhi wrote:
>>>>>> Hi Rene, yes I know about ACliC. But if you dont mind me asking:
>>>>>>
>>>>>> Wouldnt an API be a more desirable target, than just another
>>>>>> interpreter?
>>>>>>
>>>>>> I agree the ACliC thing could be regarded as some sort of API but if
>>>>>> one could just write the source in c++ and use the ROOT headers to
>>>>>> interface with a ROOT API which provides all the wrapping and
>>>>>> functionality, that would be great!
>>>>>>
>>>>>> I know I'm not in the position to request anything but I'm just
>>>>>> thinking that a solid API would be a more sustainable intention (and
>>>>>> thereby forgoing the interpreter completely).
>>>>>>
>>>>>> Rene Brun wrote:
>>>>>>> Just a remark on your question and in particular the style of your
>>>>>>> question:
>>>>>>> We have never pretended that CINT is an ISO compliant C++
>>>>>>> interpreter. CINT is fulfilling its role as interpreter
>>>>>>> for the vast majority of tasks that it is supposed to do.
>>>>>>> All CINT users know that we have a trivial, simple, C++ compatible
>>>>>>> option for CINT scripts by using
>>>>>>> the ACLIC interface to the native compiler. To use it (as explained
>>>>>>> in the very first pages of the ROOT Users Guide) do
>>>>>>> root > .x myscript.C+
>>>>>>> instead of
>>>>>>> root > .x myscript.C
>>>>>>>
>>>>>>> It is our hope that in the not too distant future, we can upgrade
>>>>>>> ROOT to use the LLVM compiler and its Just In Time features
>>>>>>> as a better solution. ACLIC has been found simple to use, you do not
>>>>>>> have to rewrite your scripts into another language,
>>>>>>> you can compile your scripts directly with a native compiler
>>>>>>> providing that your script is written in valid C++. The transition
>>>>>>> to LLVM should be transparent to our users.
>>>>>>>
>>>>>>> Rene Brun
>>>>>>>
>>>>>>> Cedric Sodhi wrote:
>>>>>>>> Hey John, ok I tried that and no errors, puh! But now there is a
>>>>>>>> even stranger problem:
>>>>>>>>
>>>>>>>> It's AW-FULLY slow. You wouldn't believe how slow that is, did you
>>>>>>>> try it? If run as a binary it runs at just fair speed but in root
>>>>>>>> every getline appears to take a whole second! I'm now going to bed
>>>>>>>> so I will not reply for a while, thanks for your help - i would
>>>>>>>> certainly be screwed without you guys :-)
>>>>>>>>
>>>>>>>>
>>>>>>>> John Idarraga wrote:
>>>>>>>>> Hello Cedric,
>>>>>>>>>
>>>>>>>>> Seems to work if you do this instead
>>>>>>>>>
>>>>>>>>> std::deque< double > * result;
>>>>>>>>> result = new std::deque< double >;
>>>>>>>>>
>>>>>>>>> I can't explain why. Can you try see if it works for you ?
>>>>>>>>>
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>> On Thu, 2010-04-01 at 23:36 +0200, Cedric Sodhi wrote:
>>>>>>>>>> Hello (again), as if I had made no progress I'm back at that very
>>>>>>>>>> simple file parser that made me contact this mailing list for the
>>>>>>>>>> first time but which I eventually dropped for other reasons.
>>>>>>>>>> Again, ISO compliant code (I know, in terms of CINT that holds no
>>>>>>>>>> relevance at all) and again an error which I dont understand,
>>>>>>>>>> attached code, error message:
>>>>>>>>>>
>>>>>>>>>> Error: Can't call deque<double,allocator<double> >::deque<double
>>>>>>>>>> >() in current scope auswertung.cpp:9:
>>>>>>>>>> Possible candidates are...
>>>>>>>>>> (in deque<double,allocator<double> >)
>>>>>>>>>> *** Interpreter error recovered ***
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Received on Fri Apr 02 2010 - 12:21:18 CEST