Updated pyROOT in current master (6.23/01)

[LeWhoo]

@etejedor

Hello @LeWhoo,

Thank you for the complete report! My answers below:

1. Please #include "ROOT/TPyDispatcher.h" instead, that one should be there. So I understand you are using TPyDispatcher from C++, instead of just using it to program callbacks from Python?

Thanks. This fixes it, although the first time I ran it I got:

Info in <TUnixSystem::ACLiC>: creating shared library /home/lewhoo/workspace/etos/cpp_helpers/etos_dispatcher_C.so
cling::DynamicLibraryManager::loadLibrary(): libPyROOT.so: cannot open shared object file: No such file or directory

Afterwards, it disappeared. The small inconvenience is that ROOT/TPyDispatcher.h is incompatible with old pyROOT. Not terrible if we are making the switch, however, if compatibility could be maintained with small effort, this could help.

I use TPyDispatcher in C++ only when something is missing in Python. That was the case for some TGListView signals, and this solution has been suggested by wlav here:

TGListView signals

Hello, I am trying TGListView to work in pyROOT (just to mention - there is no proper documentation how to use it and every mistake makes software crash…). I cannot receive a signal when clicked. Should print my messagem but does nothing: class pDataFlowWindow(ROOT.TGMainFrame): # Handler of the list events def handle_list(self): print "dbl click" # # Constructor def __init__(self, parent, width, height): ROOT.TGMainFrame.__init__(self, parent, width, height) self.MainFrame = ROOT.TG…

It’s been a long time ago… has it been updated?

2. This indicates that libcppyyX_Y.so is being loaded twice, which should not happen. Do you have a multi-Python (2&3) ROOT build? It could be that, for some reason, libcppyy2_7 and libcppyy3_X are both being loaded. I couldn’t reproduce it in a master multi-python build when running gui_ex.py with Python2 as you did. You say this happens when you do Ctrl+D on the Python interpreter?

Yes, I have a multi-Python build now. This happend when I press the “Exit” button in the app after running “python2 -i gui_ex.py”. It exits OK when I press Ctrl+D. The sample exits ok with the button in python2 though.

3. It looks like it is calling recursively the MapSubwindows in Python, instead of calling the method of the superclass. This doesn’t look right, I’ll investigate. Good that it does not seem to block you though.

Thanks. Tell me if I can help.

4. What is the type of main_window.GetParent() ? It looks like it’s giving you a Python proxy of type TGMainFrame which points to the right C++ object, but not a pMainFrame proxy. It could be that old PyROOT found already a Python proxy for that C++ object in its cache (a pMainFrame proxy), but that does not seem to happen now, so you get a brand new TGMainFrame proxy.

Both in the old and new pyROOT it is <class ‘ROOT.TGFrame’>

Thanks for your answers!