Phython 2.5.2 and ROOT 5.21/06

Hi everybody,
I’m new with pyroot. Yesterday I installed Python 2.5.2 for Windows (intaller), and Root 5.21/06 the .msi package for VC++9. I have VC++ 2008 installed. I added the following variables:

[quote]in PATH -> C:\root\bin; C:\Programmi\Python-2.5.2
in PYTHONDIR -> C:\Programmi\Python-2.5.2
in PYTHONPATH -> C:\root\bin
[/quote]
Then I tried the following:

python C:\root\tutorials\pyroot\demo.py

But it shows me somenthing like that (see attachment) and stops (or maybe freezes). I tried with all pyroot examples, and nothing, they didn’t work.
What you think about? Python version?
Thank you for any help,
Cheers.


Yes, that looks like the GUI does get any update events … Do any of the non-graphical examples work?

Cheers,
Wim

Hi Wim,

I tried with all examples, and nothing, they don’t work.
Thank you for your answer,
Cheers

Well, something must be working, or I’d expect to not even see a window (not even a frozen one), so how about one of the batch examples, e.g. mrt.py?

I don’t know, of course, but I expect it to be something locally to your machine/setup, and since I can’t work on it directly, the best way forward is to find out what exactly does and what does not work.

Cheers,
Wim

Hi Wim,
Thank you for your reply. Sorry, now I will be more exactly:
[ul]benchmarks.py - same problem like demo.py
demo.py - you know
demoshelp.py - same problem like demo.py
DynamicSlice.py - application error: python.exe, AppVer:0.0.0.0, ModName:msvcr90.dll, ModVer: 9.0.21022.8, Offset: 0006c955
FilDir.py - same like demo.py
file.py - same like demo.py
fillrandom.py - application error: python.exe, AppVer:0.0.0.0, ModName:msvcr90.dll, ModVer: 9.0.21022.8, Offset: 0006c955
first.py - application error: python.exe, AppVer:0.0.0.0, ModName:msvcr90.dll, ModVer: 9.0.21022.8, Offset: 0006c955
fit1.py - same like demo.py
formula1.py - application error: python.exe, AppVer:0.0.0.0, ModName:msvcr90.dll, ModVer: 9.0.21022.8, Offset: 0006c955
framework.py - same like demo.py
geometry.py - shows that

na49 : Real Time = 1.47 seconds Cpu Time = 1.44 seconds geometry : Real Time = 0.38 seconds Cpu Time = 0.36 seconds
gerrors.py - like demo.py
graph.py - like demo.py
gui_ex.py - application error: python.exe, AppVer:0.0.0.0, ModName:msvcr90.dll, ModVer: 9.0.21022.8, Offset: 0006c955
h1draw.py - like demo.py
hsimple.py - application error: python.exe, AppVer:0.0.0.0, ModName:msvcr90.dll, ModVer: 9.0.21022.8, Offset: 0006c955
hsum.py - application error: python.exe, AppVer:0.0.0.0, ModName:msvcr90.dll, ModVer: 9.0.21022.8, Offset: 0006c955
mrt.py - shows that:

opening file aptuple.txt ... writing file aptuple.root ... done
multifit.py - application error: python.exe, AppVer:0.0.0.0, ModName:msvcr90.dll, ModVer: 9.0.21022.8, Offset: 0006c955
na49geomfile.py - shows that:

Traceback (most recent call last): File "na49geomfile.py", line 9, in <module> n49.Write() AttributeError: 'NoneType' object has no attribute 'Write'
na49view.py - like demo.py
na49visible.py - shows that:

Traceback (most recent call last): File "na49visible.py", line 6, in <module> ROOT.YK01.SetVisibility( 0 ) File "C:\root\bin\ROOT.py", line 372, in __getattr1 return getattr( self, name ) File "C:\root\bin\ROOT.py", line 394, in __getattr2 attr = _root.LookupRootEntity( name ) AttributeError: YK01
ntuple1.py - like demo.py, and shows that:

qtexample.py - I don’t have qt
rootmarks.py - shows that:

[code]---------------ROOT 5.21/06 benchmarks summary--------------------
TOTAL : Real Time = 0.00 seconds Cpu Time = 0.00 seconds

---------------ROOT 5.21/06 benchmarks summary (in ROOTMARKS)-----
For comparison, a Pentium IV 2.4Ghz is benchmarked at 600 ROOTMARKS
You must run the ROOT benchmarks before executing this command[/code]
shapes.py - like demo.py
staff.py - shows that:

Traceback (most recent call last): File "staff.py", line 64, in <module> fillTree() File "staff.py", line 43, in fillTree for line in open( 'cernstaff.dat' ).readlines(): IOError: [Errno 2] No such file or directory: 'cernstaff.dat'
surfaces.py - application error: python.exe, AppVer:0.0.0.0, ModName:msvcr90.dll, ModVer: 9.0.21022.8, Offset: 0006c955
test.py - nothing
tornado.py - like demo.py
tree.py - like demo.py
zdemo.py - like demo.py
[/ul]

If you need more information, please ask me.
Thank you for your help,
Cheers.

Thanks for the details! :slight_smile:

Not sure anymore that this is a local thing, though …

The crashes that you have above appear to originate in TCanvas::Update()/::Resize()/::etc, called (eventually) from TSystem::ProcessEvents(). This is the function that’s supposed to make sure that GUI windows get events and don’t freeze up.

The stacktrace points rather deep inside ROOT. Not sure what has changed to cause this:

#0 0x90031aac in wait4 ()
#1 0x90054c04 in system ()
#2 0x02a1e54c in TUnixSystem::StackTrace() ()
#3 0x02a1c248 in TUnixSystem::DispatchSignals(ESignals) ()
#4
#5 0x029a2488 in TQObject::LowPriority(char const*, char const*) ()
#6 0x02a02c54 in TClass::GetBaseClass(TClass const*) ()
#7 0x02a02c94 in TClass::GetBaseClass(TClass const*) ()
#8 0x02a02c94 in TClass::GetBaseClass(TClass const*) ()
#9 0x02a08844 in TClass::InheritsFrom(TClass const*) const ()

More later, when I know more …

Cheers,
Wim

I am also seeing similar graphics problems with ROOT 5.23/02 and Python 2.5.4

If I run ‘python demo.py’ from the command line, the TControlBar window is drawn, but its contents do not, and then freezes.

It does seem like any of the tutorials that need graphical interaction fail, since the simple non-interactive tutorials such as mrt.py or geometry.py execute fine.

Any help with this is greatly appreciated!

I should update this and say I am seeing this with the WINDOWS version of ROOT, specifically the VC++ 9 version of 5.23/02.

The linux version seems to work fine

Hi,

tomorrow, I’ll have access to a Windows box and I’ll try again to see whether I can reproduce this.

Cheers,
Wim

The freezing occurs b/c the feed of OS events happens from a different thread than the one on which the TCanvas was created. I don’t have a solution yet.

Cheers,
Wim

Hi,

just to say that I’m still working on this one, but unfortunately I have limited Windows time (there were changes in the Windows implementation of TWinNTSystem::DispatchOneEvent that broke the threading, so it’s a pure Windows problem). No solution yet …

Cheers,
Wim

Hi,

does anyone know if TCanvas problems are fixed in root 5.24? I´m not quite shure if I should update…

Greetings from Aachen

Hi,

sorry, not yet. Bertrand manage to localize the problem to the exact change, though, so that’s progress, but there’s no solution yet.

Of course, one can still run an application if it is GUI only (by putting the main loop on the same thread), but that’s not helpful for interactive work if both the GUI and CLI need to be active (unless the canvas is created from the dispatching thread, which would work as well, but is an awkward way to work).

Cheers,
Wim

Has this issue been addressed?

I currently use ROOT 5.20 with python 2.5 and have the above issue for all versions after 5.20.

Hi,

no, it’s still broken. I’ve asked help from the windows expert, but no solution yet (there was one possible solution, but it just moved the race condition around). Since the problem was introduced in the event handling of windows by ROOT, I can’t solve it on the PyROOT site, even if I knew what to do. I’ll ask again …

Cheers,
Wim

Is there a bug tracking # or something to keep track of this issue?

Thanks

Hi,

there are two threads on this forum and a private one, but no savannah report AFAIK.

Cheers,
Wim

I opened:

savannah.cern.ch/bugs/?59945