Hi I’m working on a borrowed Windows computer (an oscilloscope) with cygwin installed. It has Python 2.5.2 and ROOT 5.25/02, but I can’t “import ROOT” from the python interpreter (no module named ROOT). It does have /root/lib/ROOT.py.
I’m hoping that before I waste my time trying to get this to work: can I enable PyROOT to work on this computer by simply setting those important environment variables? Is it possible that ROOT was compiled “without python”, or is that not even a concept?
is there also a libPyROOT.pyd (or libPyROOT.dll that can be copied into libPyROOT.pyd)? If so, it may be only a matter of setting up PYTHONPATH. Check within python what the current path is:[code]
import sys
sys.path[/code]
and make sure all the slashes/backslashes work out (standard pb on cygwin, I’m afraid), with paths to both ROOT.py and libPyROOT.pyd visible in sys.path.
Both ROOT.py and libPyROOT.dll live in /root/lib, so I did export PYTHONPATH=/root/lib:$PYTHONPATH.
In Python, I can now do import ROOT (which has no problem) and I can do for example print ROOT.name, but as soon as I try to access the actual ROOT stuff inside, it hangs the entire bash/cygwin window, without any messages. For example this happens with s = ROOT.TString(‘abc’).
The same thing happens after I made a copy of libPyROOT.dll called libPyROOT.pyd.
switch off the GUI thread:import ROOT
ROOT.PyConfig.StartGuiThread = False
although I’ve never seen it being an issue unless a TCanvas was created first, this is typically the reason for code hanging. There’s a fix for this Windows-specific issue (the handling of events is different in ROOT proper) in more recent versions of ROOT, although I’ve still seen freezes after that fix.
Setting that variable to False does not cause a hang, but the hang still occurs afterwards. I tried poking around the ROOT module with tab-completion, and even this causes a hang (I tried tab-completing from ROOT.gROOT…)
ROOT.py adds filename completions to the tab completions (you can find that code at the top of ROOT.py), which may be slow on a slow file system with lots of files, but I can’t see how it can hang. It should be easy enough to comment out that particular code and see whether it helps.
In general, though, gROOT is initially a wrapper (so that a call to gROOT.SetBatch() can succeed without loading of graphics libraries before it). When something else is touched, be it a different class like TString, or different methods (by tab-completing on gROOT), that’s when all of ROOT gets initialized (including graphics, if need be).
As a further experiment, can you do:import ROOT
ROOT.PyConfig.StartGuiThread = False
ROOT.gROOT.SetBatch()as well as the question whether TCanvas works from root.exe on this machine?
Ah, you may have led me to the fundamental problem.
I can put in those three lines of code from python without hanging, but then any further tests cause the same kind of hang. I checked also during the hanging that the process is not using lots of CPU, so I don’t think it’s just loading ROOT very slowly.
The more fundamental problem might be that when I try to run /root/bin/root or root.exe, I get the following message:
“root: can’t figure out DISPLAY, set it manually
In case you run a remote ssh session, …blalba”
I can start up the interpreter with root -b, and then I can create a canvas with TCanvas c1; c1.Draw(); (without errors), but there is obviously no visible canvas.
how about starting python with the -b user option (note the extra dash):[code]$ python - -b
import ROOT
etc.[/code]which should have the same effect as root.exe -b? (Although other than SetBatch() and switching off the GUI thread, I don’t know what else -b could affect.)
Thanks for the efforts Wim. I ended re-writing my PyROOT script into pure ROOT (which was desired anyways to interoperate with non-pythonized co-workers). So in this particular case, the problem is gone, and I hope to never need to use this particular oscilloscope again.