Jacek,
I'm sorry. I'm completely lost. I examined the case but there is no
problem on my machine.
>If this can help you, I discovered a better way to "block" byte compiling.
>It the test.cxx looks like ( by mistake ) :
>----------------------------
>#include ...
>
>TH1F *h_x= new TH1F("x","x",100,0.,130.);
>
>Int_t test(ntuple *n)
>{
> h_x->Fill(n->x());
> return 0;
>}
>----------------------------
>the byte compiling will be blocked for good, no matter how many times you
>try ".L test.cxx".
>Note : the h_x pointer in not only "declared/defined" here, but also tried
>to be "initialized". Of course the ".L" will not perform this action ( I
>mean "new" ), but the pointer "h_x" itself will be created ( with 0x0
>value ), if it doesn't already exist. One does not get any warning nor
>error message, though.
h_x pointer should be initialized by ".L". If it wasn't something is
already broken before ".L". The problem does not reproduce on my machine.
The pointer is correctly initialized by ".L".
>It doesn't matter if the "h_x" pointer already existed ( and was really
>"initialized" ), or not. After ".L" of such a test.cxx byte compiling is
>"blocked" for good.
>Another funny feature is - if I don't define "h_x" at all ( and it's not
>defined in the test.cxx ), the n->Loop(test) still works without any
>single warning ( but it takes more time to execute, possibly by every call
>to the test() function it tries to find "h_x" ).
This does not reproduce either. If h_x is not defined, cint reports the
error. The behavior is persistent both on ROOT and bare CINT.
Is there anything special in your environemtn? Or some other thing which
may cause problem?
Thank you
Masaharu Goto
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:33 MET