Hi,
Many thanks for your replies,
> replacing the line:
> X11.FindBestVisual: yes
> by
> X11.FindBestVisual: no
... didn't help ...
(Hi, Jiri, I also had the idea of checking system variables, but nothing
really interesting was there.)
In the meantime ... I got more experience ... if I have a "big window" and
I many times try ".class TVector" then sometimes it works properly and
sometimes it breaks ... no idea what the problem is (I also tried to set
X11.Sync to yes, but it didn't help).
Well, maybe it is a bug in RH7.1 system libraries (just a precaution
... the system has all RH7.1 updates applied ...) ???
> For your second problem, replace the line:
> #if !defined (__CINT__) || defined (__MAKECINT__)
> by
> #if !defined (__CINT__)
I'm sorry that I did not tell you in my previous mail how to get around
this problem. Of course, if rootcint does not see "Api.h" it does not
break ! What is more interesting - one can completely remove the line
"#include <Api.h>" and the code will still compile !!!
While working on this problem, however, I noticed that there is an
additional problem that I missed in 3.02/07 ...
Let's look at the history ... the whole thing concerns TF77 ...
pre 2.25/03 - I'm not sure when Masa implemented
G__isinterpretedp2f, but it WAS WORKING like a
charm
2.25/03 - problems with G__INTERPRETEDFUNC - a "brutal
fix" implemented in TF77.cxx and [df]test.cxx,
- "for (i = 0; i < 1; i++) sub(x, y, w);"
automatically bytecompiles the "sub"
3.01/06 - "for (i = 0; i < 1; i++) sub(x, y, w);" NO
LONGER automatically bytecompiles the "sub" when
called inside of a macro
3.02/07 - "for (i = 0; i < 1; i++) sub(x, y, w);" AGAIN
automatically bytecompiles the "sub", ... but ...
- problems with G__BYTECODEFUNC discovered, no fix
for now (I've just realized it today)
3.03/09 - "for (i = 0; i < 1; i++) sub(x, y, w);" AGAIN NO
LONGER automatically bytecompiles the "sub" when
called inside of a macro, ... plus
- the same problems with G__BYTECODEFUNC ... plus
- problems with Api.h
Looking at the above history ... do you gently try to tell me something ???
For example that I should stay away from G__isinterpretedp2f & Co. ???
Best regards,
Jacek.
P.S. Of course, you might get curious what G__BYTECODEFUNC problems exist
in 3.02/07+ .... well, get a 3.02/07 (mine is on RH6.2, egcs-1.1.2),
then unpack the TF77.tar.gz, then :
cd TF77
export CERNLIBDIR=/cernlib_home/2001/lib
gmake
./root.exe
root [0] .x dtest.cxx
*** Break *** segmentation violation
Root > Function dtest() busy flag cleared
root [1] .q
The "sub" got bytecompiled inside of the "dtest()", and ... ***
Then edit dtest.cxx and comment out the line number 106, then :
root [0] .x dtest.cxx
This time "sub" is always interpreted (slow) and everything works ...
Jacek.
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:51:12 MET