From: Alan W. I. <ir...@be...> - 2009-06-23 02:05:26
|
Hi Hazen: As of revision 10066 I have completed all planned build system changes involving the plplot_pyqt4 extension module and the pyqt4_test.py example that uses that. This work has involved a number of changes: * I wasn't having much luck trying to fool CMake into interpreting qt.so as a library (as opposed to how that device driver was built as a CMake module) so I properly solved that issue by building and installing a plplotqt library which uses the same source code as qt.so, but which CMake treats as a library. (Andrew, there is still a visibility issue for the symbols in that C++ library under Linux if you use export CXX='g++ -g -fvisibility=hidden'. Could you take a look at that when you can spare some time?) The resulting library passes the "ldd -r" test both in the build tree and install tree. * The plplot_pyqt4 extension module is now built in bindings/qt_gui/pyqt4. This follows what is done for the gnome2 versus pygcw bindings and seems a slightly more rational organization to me. * I now generate the plplot_pyqt4 Python extension module source code using sip directly. The required directory and flags are configured by invoking python at cmake time in cmake/modules/qt.cmake. To me that is just easier than configuring sip with config.py at build time since there are fewer files to maintain (config.py is now removed since it is no longer needed), you don't have any weird invocations such as touching config.py.in first, and you don't need any special directories because of the extra Makefile produced by the config.py approach. The result extension module is linked against the plplotqt library (as opposed to qt.so) and passes the "ldd -r" test (both in the build tree and install tree). You only get this result if you do not specify -fvisibility=hidden (see question above for Andrew). * I modified pyqt4_test.py a bit so that it would look for the plplot and plplot_pyqt4 extension modules in the correct place. The result was a GUI with nothing plotted but no error messages. I then modified pyqt4_test.py some more to put in some actual plot commands (as part of the initialization which, of course, is not right for the long term), but again I just got a blank GUI with no errors. So there is obviously some more work to do on pyqt4_test.py and possibly plplot_pyqt4.sip to make an example that actually plots more than a blank screen. However, I will leave such further changes to you. I believe all the build system stuff should just work now for you without issues. N.B. it is important that the modules you import with from PyQt4 import QtCore, QtGui in pyqt4_test.py link to the same Qt4 libraries as the plplot_pyqt4 extension module. For my downloaded Qt4.5.1 SDK version of Qt, I arrange that by specifying LD_LIBRARY_PATH appropriately. This is not necessary if plplot_pyqt4.sip is built against the same system Qt4 libraries as QtCore and QtGui point to by default. For both my system Qt4.4 version and the downloadable Qt4.5 version I get the above blank GUI result. I will be most interested to see whether you also replicate the blank GUI for pyqt4_test.py regardless of what plplot commands are used, and, of course, if you have any further build-system questions about the plplotqt library or the plplot_pyqt4 extension module, let me know. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Hazen B. <hba...@ma...> - 2009-06-24 03:18:31
|
Alan W. Irwin wrote: > > * I modified pyqt4_test.py a bit so that it would look for the plplot and > plplot_pyqt4 extension modules in the correct place. The result was a GUI > with nothing plotted but no error messages. I then modified pyqt4_test.py > some more to put in some actual plot commands (as part of the > initialization which, of course, is not right for the long term), but > again I just got a blank GUI with no errors. So there is obviously some > more work to do on pyqt4_test.py and possibly plplot_pyqt4.sip to make an > example that actually plots more than a blank screen. However, I will > leave such further changes to you. I believe all the build system stuff > should just work now for you without issues. > > N.B. it is important that the modules you import with > > from PyQt4 import QtCore, QtGui > > in pyqt4_test.py link to the same Qt4 libraries as the plplot_pyqt4 > extension module. For my downloaded Qt4.5.1 SDK version of Qt, I arrange > that by specifying LD_LIBRARY_PATH appropriately. This is not necessary > if plplot_pyqt4.sip is built against the same system Qt4 libraries as > QtCore and QtGui point to by default. > > For both my system Qt4.4 version and the downloadable Qt4.5 version I get > the above blank GUI result. > > I will be most interested to see whether you also replicate the blank GUI > for pyqt4_test.py regardless of what plplot commands are used, and, of > course, if you have any further build-system questions about the plplotqt > library or the plplot_pyqt4 extension module, let me know. It now builds for me as well, thanks for all your efforts to get this to work! I confirm the blank plots. This is a little puzzling since the example used to work. I'll see what I can do to resolve this. -Hazen |
From: Alan W. I. <ir...@be...> - 2009-07-01 01:13:33
|
On 2009-07-01 02:17+0300 Dmitri Gribenko wrote: > On Wed, Jul 1, 2009 at 1:35 AM, trc<kea...@ya...> wrote: >> You cannot use dynamic_cast to convert the void pointer pls->dev to a QtPLWidget pointer. >> >> The purpose of dynamic_cast is to do a safe (runtime checked) cast >> from a base class to a derived class or vice-versa. As QtPLWidget is >> not derived from void the cast fails. > > There is a C-style cast to a QWidget * first. Its result is then > passed to dynamic_cast, which should work in such case (but does not > for some reason; multiple inheritance problems?). > >> For your code you have to use C++ reinterpret_cast or a C style cast. > > Agreed. I don't see why dynamic_cast should be necessary here. In > any case, 'widget' variable is of type QtPLDriver * and all concrete > types (QtRasterDevice, QtSVGDevice, QtEPSDevice, QtPLWidget) are not > used after the cast. There's also a cryptic comment that I don't > understand "We have to dynamic_cast to make sure the good virtual > functions are called". Everything dynamic_cast can do here is to cut > off all derived types except the specified ones (they would be cast to > NULL, but I don't see why that should be needed). > > Am I missing anything about that code? Thanks Terrence and Dmitri for your ideas about how to solve this issue. I believe Alban will not be able to comment in a timely manner because he is probably out of e-mail contact right now. Given that situation, I suggest you both in consultation make the casting changes you think are right and send me the patch. If I find that examples/python/pyqt4_test.py (in the installed examples tree) suddenly starts working (rather than delivering a blank GUI result) and your patch shows no regressions for any of our extensive tests of the qt devices or for qt_example itself, then I would be happy to commit your patch. Of course, I would be also be happy to make any further changes beyond that commit that Alban thinks are necessary when he is back in contact. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Hazen B. <hba...@ma...> - 2009-06-25 03:49:28
|
Hazen Babcock wrote: > Alan W. Irwin wrote: >> * I modified pyqt4_test.py a bit so that it would look for the plplot and >> plplot_pyqt4 extension modules in the correct place. The result was a GUI >> with nothing plotted but no error messages. I then modified pyqt4_test.py >> some more to put in some actual plot commands (as part of the >> initialization which, of course, is not right for the long term), but >> again I just got a blank GUI with no errors. So there is obviously some >> more work to do on pyqt4_test.py and possibly plplot_pyqt4.sip to make an >> example that actually plots more than a blank screen. However, I will >> leave such further changes to you. I believe all the build system stuff >> should just work now for you without issues. >> >> N.B. it is important that the modules you import with >> >> from PyQt4 import QtCore, QtGui >> >> in pyqt4_test.py link to the same Qt4 libraries as the plplot_pyqt4 >> extension module. For my downloaded Qt4.5.1 SDK version of Qt, I arrange >> that by specifying LD_LIBRARY_PATH appropriately. This is not necessary >> if plplot_pyqt4.sip is built against the same system Qt4 libraries as >> QtCore and QtGui point to by default. >> >> For both my system Qt4.4 version and the downloadable Qt4.5 version I get >> the above blank GUI result. >> >> I will be most interested to see whether you also replicate the blank GUI >> for pyqt4_test.py regardless of what plplot commands are used, and, of >> course, if you have any further build-system questions about the plplotqt >> library or the plplot_pyqt4 extension module, let me know. > > It now builds for me as well, thanks for all your efforts to get this to > work! > > I confirm the blank plots. This is a little puzzling since the example > used to work. I'll see what I can do to resolve this. Using printf debugging everything appears okay. The example is blank because the paint method of the ext_qt driver is getting called as expected. If you resize the window you can see the grey margins, also as expected. Plplot core calls to "plD_line_qt" are processed. The problem seems to be that in the function doPlot the plot buffer is empty. I assume that this driver still works fine for the non-python examples? -Hazen |
From: Hazen B. <hba...@ma...> - 2009-06-25 04:10:00
|
Hazen Babcock wrote: > Hazen Babcock wrote: >> Alan W. Irwin wrote: >>> * I modified pyqt4_test.py a bit so that it would look for the plplot and >>> plplot_pyqt4 extension modules in the correct place. The result was a GUI >>> with nothing plotted but no error messages. I then modified pyqt4_test.py >>> some more to put in some actual plot commands (as part of the >>> initialization which, of course, is not right for the long term), but >>> again I just got a blank GUI with no errors. So there is obviously some >>> more work to do on pyqt4_test.py and possibly plplot_pyqt4.sip to make an >>> example that actually plots more than a blank screen. However, I will >>> leave such further changes to you. I believe all the build system stuff >>> should just work now for you without issues. >>> >>> N.B. it is important that the modules you import with >>> >>> from PyQt4 import QtCore, QtGui >>> >>> in pyqt4_test.py link to the same Qt4 libraries as the plplot_pyqt4 >>> extension module. For my downloaded Qt4.5.1 SDK version of Qt, I arrange >>> that by specifying LD_LIBRARY_PATH appropriately. This is not necessary >>> if plplot_pyqt4.sip is built against the same system Qt4 libraries as >>> QtCore and QtGui point to by default. >>> >>> For both my system Qt4.4 version and the downloadable Qt4.5 version I get >>> the above blank GUI result. >>> >>> I will be most interested to see whether you also replicate the blank GUI >>> for pyqt4_test.py regardless of what plplot commands are used, and, of >>> course, if you have any further build-system questions about the plplotqt >>> library or the plplot_pyqt4 extension module, let me know. >> It now builds for me as well, thanks for all your efforts to get this to >> work! >> >> I confirm the blank plots. This is a little puzzling since the example >> used to work. I'll see what I can do to resolve this. > > Using printf debugging everything appears okay. The example is blank > because the paint method of the ext_qt driver is getting called as > expected. If you resize the window you can see the grey margins, also as > expected. Plplot core calls to "plD_line_qt" are processed. The problem > seems to be that in the function doPlot the plot buffer is empty. I > assume that this driver still works fine for the non-python examples? Poking around a little more... In the function plD_line_qt we are not getting past this statement: #if defined(PLD_qtwidget) || defined(PLD_extqt) if(widget==NULL) widget=dynamic_cast<QtPLWidget*>((QWidget *) pls->dev); #endif if(widget==NULL) return; So the dynamic cast is not working for some reason? printf(" %ld %ld\n", (long)pls->dev, (long)widget); Suggests that pls->dev is valid, or at least not zero, but that widget is still zero after the cast. -Hazen |
From: Hazen B. <hba...@ma...> - 2009-06-29 03:50:55
|
Hazen Babcock wrote: > > Poking around a little more... > > In the function plD_line_qt we are not getting past this statement: > > #if defined(PLD_qtwidget) || defined(PLD_extqt) > if(widget==NULL) widget=dynamic_cast<QtPLWidget*>((QWidget *) pls->dev); > #endif > if(widget==NULL) return; > > So the dynamic cast is not working for some reason? > > printf(" %ld %ld\n", (long)pls->dev, (long)widget); > > Suggests that pls->dev is valid, or at least not zero, but that widget > is still zero after the cast. Hopefully someone can offer a few suggestions here... So far I have: (1) The C++ QtExtWidget constructor is called when the corresponding python object is created. (2) The C++ QtExtWidget destructor is called when the program the ends. (3) The address of the C++ QtExtWidget is not being moved on the Python side. (4) Introspection on the C++ side of the python object says that yes it is a QtExtWidget object. eg. calling this function which I added to plqt.cpp: void plprintaddress(QtExtWidget* widget) { printf("PA %x\n", (long)widget); std::cout << typeid(widget).name() << std::endl; } Gives: PA 1e0d3f0 P11QtExtWidget (5) Forcing the cast (rather than using dynamic_cast) seems to make things work (i.e.: widget = (QtPLWidget *)pls->dev;). (6) Introspection in plD_line_qt like this: std::cout << typeid(pls->dev).name() << std::endl; Gives "Pv" as the type for both the Python originated QtExtWidget object and the C++ originated object (by running the c++/qt_example program). So, any thoughts as to what might be causing the problem with dynamic_cast? thanks, -Hazen |
From: Alan W. I. <ir...@be...> - 2009-06-30 16:58:27
|
On 2009-06-28 20:49-0400 Hazen Babcock wrote: > Hazen Babcock wrote: >> >> Poking around a little more... >> >> In the function plD_line_qt we are not getting past this statement: >> >> #if defined(PLD_qtwidget) || defined(PLD_extqt) >> if(widget==NULL) widget=dynamic_cast<QtPLWidget*>((QWidget *) pls->dev); >> #endif >> if(widget==NULL) return; >> >> So the dynamic cast is not working for some reason? >> >> printf(" %ld %ld\n", (long)pls->dev, (long)widget); >> >> Suggests that pls->dev is valid, or at least not zero, but that widget >> is still zero after the cast. > > Hopefully someone can offer a few suggestions here... > > So far I have: > (1) The C++ QtExtWidget constructor is called when the corresponding > python object is created. > (2) The C++ QtExtWidget destructor is called when the program the ends. > (3) The address of the C++ QtExtWidget is not being moved on the Python > side. > (4) Introspection on the C++ side of the python object says that yes it > is a QtExtWidget object. eg. calling this function which I added to > plqt.cpp: > void plprintaddress(QtExtWidget* widget) > { > printf("PA %x\n", (long)widget); > std::cout << typeid(widget).name() << std::endl; > } > > Gives: > PA 1e0d3f0 > P11QtExtWidget > > (5) Forcing the cast (rather than using dynamic_cast) seems to make > things work (i.e.: widget = (QtPLWidget *)pls->dev;). > (6) Introspection in plD_line_qt like this: > std::cout << typeid(pls->dev).name() << std::endl; > Gives "Pv" as the type for both the Python originated QtExtWidget object > and the C++ originated object (by running the c++/qt_example program). > > So, any thoughts as to what might be causing the problem with dynamic_cast? Hi Hazen: I am just a rank newbie on non-C aspects of C++ like dynamic_cast, but I did (just) look up dynamic_cast, and it appears the casting conditions have to follow certain conditions from the object-oriented point of view before dynamic_cast works. You probably know all this stuff, but just in case, the discussion I found was at http://www.cplusplus.com/doc/tutorial/typecasting/. Its possible the code is violating one of those conditions, but I don't have the object-oriented expertise to figure out what that condition might be. There was mention also there of dynamic_cast not working if the wrong compiler flags having to do with RTTI are being used. But for g++, the default (-frtti) is correct. I also double-checked that -fno-rtti was not being used by mistake by inspecting "make VERBOSE=1" results for a complete build from scratch. There was no mention of rtti anywhere in those results so the (correct) default is being used unless the documentation is all wrong. Also, I double-checked that g++ (rather than gcc) was being used to compile and link qt.so (which contains all the dynamic casts in the now split qt code). So it appears the compilation and linking conditions are perfect. Another approach for debugging this issue is to look carefully at the qt_example.cpp code and also how it is compiled and linked since qt_example works perfectly right now. So you may want to investigate what is different about that code or how it is compiled and linked compared to the sip-generated code, sipAPIplplot_pyqt4.h, sipplplot_pyqt4QtExtWidget.cpp, sipplplot_pyqt4QtPLDriver.cpp, sipplplot_pyqt4QtPLWidget.cpp, and sipplplot_pyqt4cmodule.cpp in bindings/qt_gui/pyqt4 which is compiled and linked into the Python extension module, plplot_pyqt4.so? Another good possibility for figuring this out is you have stated your example used to work when you were ignoring the PLplot build system and simply using python to build plplot_pyqt4.so. If that really is the case, then by use of the svn checkout --revision argument you should be able to go back to exactly what we had before in an independent source code tree. If you confirm that old approach works, but the current approach based on the build system does not work, then that is an important clue to finding out what is wrong with the current approach and detailed comparisons of the old and new source trees and results should find the source of the problem. For example, did the old python-based approach to configuring and running sip produce the same sip-generated source code as the new CMake-based approach to configuring and running sip? I hope one or more of the above ideas will help you arrive at the needed breakthrough. I think your pyqt4 work is important so don't hesitate to get in touch with me off list if you need a (C++ naive, but CMake-smart and svn-smart) sounding board. Anyhow, I wish you the best in figuring out this issue. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: trc <kea...@ya...> - 2009-06-30 22:35:51
|
Alan W. Irwin wrote: > On 2009-06-28 20:49-0400 Hazen Babcock wrote: > >> Hazen Babcock wrote: >>> Poking around a little more... >>> >>> In the function plD_line_qt we are not getting past this statement: >>> >>> #if defined(PLD_qtwidget) || defined(PLD_extqt) >>> if(widget==NULL) widget=dynamic_cast<QtPLWidget*>((QWidget *) pls->dev); >>> #endif >>> if(widget==NULL) return; >>> >>> So the dynamic cast is not working for some reason? >>> >>> printf(" %ld %ld\n", (long)pls->dev, (long)widget); >>> >>> Suggests that pls->dev is valid, or at least not zero, but that widget >>> is still zero after the cast. >> Hopefully someone can offer a few suggestions here... >> >> So far I have: >> (1) The C++ QtExtWidget constructor is called when the corresponding >> python object is created. >> (2) The C++ QtExtWidget destructor is called when the program the ends. >> (3) The address of the C++ QtExtWidget is not being moved on the Python >> side. >> (4) Introspection on the C++ side of the python object says that yes it >> is a QtExtWidget object. eg. calling this function which I added to >> plqt.cpp: >> void plprintaddress(QtExtWidget* widget) >> { >> printf("PA %x\n", (long)widget); >> std::cout << typeid(widget).name() << std::endl; >> } >> >> Gives: >> PA 1e0d3f0 >> P11QtExtWidget >> >> (5) Forcing the cast (rather than using dynamic_cast) seems to make >> things work (i.e.: widget = (QtPLWidget *)pls->dev;). >> (6) Introspection in plD_line_qt like this: >> std::cout << typeid(pls->dev).name() << std::endl; >> Gives "Pv" as the type for both the Python originated QtExtWidget object >> and the C++ originated object (by running the c++/qt_example program). >> >> So, any thoughts as to what might be causing the problem with dynamic_cast? > > Hi Hazen: > > I am just a rank newbie on non-C aspects of C++ like dynamic_cast, but I did > (just) look up dynamic_cast, and it appears the casting conditions have to > follow certain conditions from the object-oriented point of view before > dynamic_cast works. You probably know all this stuff, but just in case, the > discussion I found was at > http://www.cplusplus.com/doc/tutorial/typecasting/. Its possible the code > is violating one of those conditions, but I don't have the object-oriented > expertise to figure out what that condition might be. > > There was mention also there of dynamic_cast not working if the wrong > compiler flags having to do with RTTI are being used. But for g++, the > default (-frtti) is correct. I also double-checked that -fno-rtti was not > being used by mistake by inspecting "make VERBOSE=1" results for a complete > build from scratch. There was no mention of rtti anywhere in those results > so the (correct) default is being used unless the documentation is all > wrong. Also, I double-checked that g++ (rather than gcc) was being used to > compile and link qt.so (which contains all the dynamic casts in the now > split qt code). So it appears the compilation and linking conditions are > perfect. > > Another approach for debugging this issue is to look carefully at the > qt_example.cpp code and also how it is compiled and linked since qt_example > works perfectly right now. So you may want to investigate what is different > about that code or how it is compiled and linked compared to the > sip-generated code, sipAPIplplot_pyqt4.h, sipplplot_pyqt4QtExtWidget.cpp, > sipplplot_pyqt4QtPLDriver.cpp, sipplplot_pyqt4QtPLWidget.cpp, and > sipplplot_pyqt4cmodule.cpp in bindings/qt_gui/pyqt4 which is compiled and > linked into the Python extension module, plplot_pyqt4.so? > > Another good possibility for figuring this out is you have stated your > example used to work when you were ignoring the PLplot build system and > simply using python to build plplot_pyqt4.so. If that really is the case, > then by use of the svn checkout --revision argument you should be able to go > back to exactly what we had before in an independent source code tree. If > you confirm that old approach works, but the current approach based on the > build system does not work, then that is an important clue to finding out > what is wrong with the current approach and detailed comparisons of the old > and new source trees and results should find the source of the problem. For > example, did the old python-based approach to configuring and running sip > produce the same sip-generated source code as the new CMake-based approach > to configuring and running sip? > > I hope one or more of the above ideas will help you arrive at the needed > breakthrough. I think your pyqt4 work is important so don't hesitate to get > in touch with me off list if you need a (C++ naive, but CMake-smart and > svn-smart) sounding board. Anyhow, I wish you the best in figuring out this > issue. > Hi Hazen, Alan, You cannot use dynamic_cast to convert the void pointer pls->dev to a QtPLWidget pointer. The purpose of dynamic_cast is to do a safe (runtime checked) cast from a base class to a derived class or vice-versa. As QtPLWidget is not derived from void the cast fails. For your code you have to use C++ reinterpret_cast or a C style cast. Kind regards Terrence |
From: Dmitri G. <gri...@gm...> - 2009-06-30 23:17:54
|
On Wed, Jul 1, 2009 at 1:35 AM, trc<kea...@ya...> wrote: > You cannot use dynamic_cast to convert the void pointer pls->dev to a QtPLWidget pointer. > > The purpose of dynamic_cast is to do a safe (runtime checked) cast > from a base class to a derived class or vice-versa. As QtPLWidget is > not derived from void the cast fails. There is a C-style cast to a QWidget * first. Its result is then passed to dynamic_cast, which should work in such case (but does not for some reason; multiple inheritance problems?). > For your code you have to use C++ reinterpret_cast or a C style cast. Agreed. I don't see why dynamic_cast should be necessary here. In any case, 'widget' variable is of type QtPLDriver * and all concrete types (QtRasterDevice, QtSVGDevice, QtEPSDevice, QtPLWidget) are not used after the cast. There's also a cryptic comment that I don't understand "We have to dynamic_cast to make sure the good virtual functions are called". Everything dynamic_cast can do here is to cut off all derived types except the specified ones (they would be cast to NULL, but I don't see why that should be needed). Am I missing anything about that code? Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gri...@gm...>*/ |
From: Alban R. <a.r...@im...> - 2009-07-01 07:59:51
|
Alan W. Irwin wrote: > On 2009-07-01 02:17+0300 Dmitri Gribenko wrote: > > Thanks Terrence and Dmitri for your ideas about how to solve this issue. > > I believe Alban will not be able to comment in a timely manner because he is > probably out of e-mail contact right now. Given that situation, I suggest > you both in consultation make the casting changes you think are right and > send me the patch. If I find that examples/python/pyqt4_test.py (in the > installed examples tree) suddenly starts working (rather than delivering a > blank GUI result) and your patch shows no regressions for any of our > extensive tests of the qt devices or for qt_example itself, then I would be > happy to commit your patch. Of course, I would be also be happy to make any > further changes beyond that commit that Alban thinks are necessary when he > is back in contact. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting software > package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > ------------------------------------------------------------------------------ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > Hello all, Actually, this is one of the few days I am in contact, so: - I must have misunderstood something about dynamic casts because I believed that QtPLDriver* widget=(QtPLDriver*)(pls->dev) would have created a "pure" QtPLDriver* object, and thus the member functions called after this would have been e.g. QtPLDriver::drawLine rather than e.g. QtRasterDevice::drawLine (no call of the virtual functions). This was the meaning of my "cryptic comment". - There is a simple and straightforward way to fix that without worrying about RTTI or whatever (well, at least for that): just define plD_whatever functions for every kind of driver, using simple C-casts. I'm afraid lots of these matters exceeded my knowledge in C++, but I'm interested by the explanations you provide! Alban |
From: Alan W. I. <ir...@be...> - 2009-07-01 23:43:34
|
On 2009-07-01 08:58+0100 Alban Rochel wrote: > Hello all, > > Actually, this is one of the few days I am in contact, so: > - I must have misunderstood something about dynamic casts because I > believed that QtPLDriver* widget=(QtPLDriver*)(pls->dev) would have > created a "pure" QtPLDriver* object, and thus the member functions > called after this would have been e.g. QtPLDriver::drawLine rather than > e.g. QtRasterDevice::drawLine (no call of the virtual functions). This > was the meaning of my "cryptic comment". > - There is a simple and straightforward way to fix that without worrying > about RTTI or whatever (well, at least for that): just define > plD_whatever functions for every kind of driver, using simple C-casts. > > I'm afraid lots of these matters exceeded my knowledge in C++, but I'm > interested by the explanations you provide! Today, I have been taking a different tack looking at this from the point of view of sip configuration following the instructions in http://www.riverbankcomputing.co.uk/static/Docs/sip4/using.html. There they make a big deal of python versus C++ ownership of objects. And they advocate using the /TransferThis/ directive to deal with the issue. However, it turns out that directive gives you syntax errors unless it is applied to a "parent" argument that is the first argument without any default value. Accordingly, this demands the order of arguments in QtPLWidget and QtExtWidget be changed (I left the default parent parameter as zero in qt.h, but not in plplot_pyqt4.sip since sip would not allow that). For what it is worth, here is the patch for this change: Index: bindings/qt_gui/pyqt4/plplot_pyqt4.sip =================================================================== --- bindings/qt_gui/pyqt4/plplot_pyqt4.sip (revision 10102) +++ bindings/qt_gui/pyqt4/plplot_pyqt4.sip (working copy) @@ -22,7 +22,7 @@ %End public: - QtPLWidget(int i_iWidth=QT_DEFAULT_X, int i_iHeight=QT_DEFAULT_Y, QWidget* parent=0); + QtPLWidget(QWidget* parent /TransferThis/, int i_iWidth=QT_DEFAULT_X, int i_iHeight=QT_DEFAULT_Y); virtual ~QtPLWidget(); void clearWidget(); @@ -44,7 +44,7 @@ %End public: - QtExtWidget(int i_iWidth=QT_DEFAULT_X, int i_iHeight=QT_DEFAULT_Y, QWidget* parent=0); + QtExtWidget(QWidget* parent /TransferThis/, int i_iWidth=QT_DEFAULT_X, int i_iHeight=QT_DEFAULT_Y); virtual ~QtExtWidget(); void captureMousePlotCoords(double *x, double *y); Index: bindings/qt_gui/plqt.cpp =================================================================== --- bindings/qt_gui/plqt.cpp (revision 10102) +++ bindings/qt_gui/plqt.cpp (working copy) @@ -497,7 +497,7 @@ #endif #if defined (PLD_qtwidget) || defined(PLD_extqt) -QtPLWidget::QtPLWidget(int i_iWidth, int i_iHeight, QWidget* parent): +QtPLWidget::QtPLWidget(QWidget* parent, int i_iWidth, int i_iHeight): QWidget(parent), QtPLDriver(i_iWidth, i_iHeight) { m_painterP=new QPainter; @@ -893,8 +893,8 @@ #endif #if defined(PLD_extqt) -QtExtWidget::QtExtWidget(int i_iWidth, int i_iHeight, QWidget* parent): - QtPLWidget(i_iWidth, i_iHeight, parent) +QtExtWidget::QtExtWidget(QWidget* parent, int i_iWidth, int i_iHeight): + QtPLWidget(parent, i_iWidth, i_iHeight) { cursorParameters.isTracking=false; cursorParameters.cursor_x=-1.0; Index: include/qt.h =================================================================== --- include/qt.h (revision 10102) +++ include/qt.h (working copy) @@ -343,7 +343,7 @@ public: // Parameters are the actual size of the page, NOT the size of the widget // Call QWidget::resize for that - QtPLWidget(int i_iWidth=QT_DEFAULT_X, int i_iHeight=QT_DEFAULT_Y, QWidget* parent=0); + QtPLWidget(QWidget* parent=0, int i_iWidth=QT_DEFAULT_X, int i_iHeight=QT_DEFAULT_Y); virtual ~QtPLWidget(); @@ -395,7 +395,7 @@ Q_OBJECT public: - QtExtWidget(int i_iWidth=QT_DEFAULT_X, int i_iHeight=QT_DEFAULT_Y, QWidget* parent=0); + QtExtWidget(QWidget* parent=0, int i_iWidth=QT_DEFAULT_X, int i_iHeight=QT_DEFAULT_Y); virtual ~QtExtWidget(); Index: drivers/qt.cpp =================================================================== --- drivers/qt.cpp (revision 10102) +++ drivers/qt.cpp (working copy) @@ -895,14 +895,14 @@ if (pls->xlength <= 0 || pls->ylength <= 0) { - widget=new QtPLWidget; + widget=new QtPLWidget(); pls->dev=(void*) widget; pls->xlength = (int)widget->m_dWidth; pls->ylength = (int)widget->m_dHeight; } else { - widget=new QtPLWidget(pls->xlength, pls->ylength); + widget=new QtPLWidget(NULL, pls->xlength, pls->ylength); pls->dev=(void*) widget; } Index: examples/python/pyqt4_test.py =================================================================== --- examples/python/pyqt4_test.py (revision 10102) +++ examples/python/pyqt4_test.py (working copy) @@ -33,7 +33,7 @@ print "init" QtGui.QMainWindow.__init__(self, None) - self.plot = plplot_pyqt4.QtExtWidget(800, 800, self) + self.plot = plplot_pyqt4.QtExtWidget(self, 800, 800) self.setCentralWidget(self.plot) plplot_pyqt4.plsetqtdev(self.plot) Index: examples/c++/qt_PlotWindow.cpp =================================================================== --- examples/c++/qt_PlotWindow.cpp (revision 10102) +++ examples/c++/qt_PlotWindow.cpp (working copy) @@ -35,7 +35,7 @@ plotMenu->addAction("Histogram", this, SLOT(plotHistogram())); plotMenu->addAction("Interactive Selection", this, SLOT(interactive())); - plot=new QtExtWidget(QT_DEFAULT_X, QT_DEFAULT_Y, this); + plot=new QtExtWidget(this, QT_DEFAULT_X, QT_DEFAULT_Y); setCentralWidget(plot); The result builds and installs without issues, and the installed qt_example builds and runs without (valgrind or any other) issues. However, pyqt4_test.py still provides just a black GUI with no plot drawn (sigh). So the above patch works as well as the present situation, but no better. Thus, it only appears to be useful as an indication of where QtPLWidget and QtExtWidget are resident in the source code, and as an example that shows the /TransferThis/ sip directive is (at least) not the complete answer. Hazen, if you want to try out further sip directives having to do with object ownership, the above patch might be a good start for you. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Hazen B. <hba...@ma...> - 2009-07-02 17:14:53
|
Alban Rochel wrote: > Hello all, > > Actually, this is one of the few days I am in contact, so: > - I must have misunderstood something about dynamic casts because I > believed that QtPLDriver* widget=(QtPLDriver*)(pls->dev) would have > created a "pure" QtPLDriver* object, and thus the member functions > called after this would have been e.g. QtPLDriver::drawLine rather than > e.g. QtRasterDevice::drawLine (no call of the virtual functions). This > was the meaning of my "cryptic comment". > - There is a simple and straightforward way to fix that without worrying > about RTTI or whatever (well, at least for that): just define > plD_whatever functions for every kind of driver, using simple C-casts. I went ahead and implemented this fix for the extqt driver only as that is the driver that the PyQt4 bindings are using. If I ever figure out what the underlying issue is will try and clean up the ugliness I've added via this copy-paste approach. -Hazen |
From: Alan W. I. <ir...@be...> - 2009-07-02 22:08:39
|
On 2009-07-02 13:14-0400 Hazen Babcock wrote: > Alban Rochel wrote: >> Hello all, >> >> Actually, this is one of the few days I am in contact, so: >> - I must have misunderstood something about dynamic casts because I >> believed that QtPLDriver* widget=(QtPLDriver*)(pls->dev) would have >> created a "pure" QtPLDriver* object, and thus the member functions >> called after this would have been e.g. QtPLDriver::drawLine rather than >> e.g. QtRasterDevice::drawLine (no call of the virtual functions). This >> was the meaning of my "cryptic comment". >> - There is a simple and straightforward way to fix that without worrying >> about RTTI or whatever (well, at least for that): just define >> plD_whatever functions for every kind of driver, using simple C-casts. > > I went ahead and implemented this fix for the extqt driver only as that > is the driver that the PyQt4 bindings are using. If I ever figure out > what the underlying issue is will try and clean up the ugliness I've > added via this copy-paste approach. Thanks, Hazen, for dealing with this subtle issue. The result passes my much-beloved ldd -r tests for qt.so, libplplotqt.so, qt_example, and plplot_pyqt4.so. Also, qt_example continues to work well and continues to give a clean valgrind result As of revision 10114, I got rid of the old version of the pyqt4 example since the new one supersedes it, and I fixed the issue with the new example that occurred for a non-standard PLplot installation prefix. The new pyqt4 example works fine for me which I was very happy to see! Now that you have gotten pyqt4 to work correctly with PLplot, I am looking forward to you extending the present example and/or adding additional pyqt4 examples to demonstrate the pyqt4 PLplot possibilities that have now opened up. What do you think of removing the pyqt3 example (prova.py and qplplot.py) in examples/python now that we have a working pyqt4 example? Maintenance releases of pyqt3 continue as can be seen at http://freshmeat.net/projects/pyqt/releases/301031. So we cannot justify removing our pyqt3 example based on pyqt3 no longer being viable, but on the other hand, nobody has worked on our pyqt3 bindings or our one pyqt3 example since they were donated years ago, and we now seem to have a pyqt4 alternative that is being actively developed and used by you. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Hazen B. <hba...@ma...> - 2009-07-05 16:23:11
|
Alan W. Irwin wrote: > Now that you have gotten pyqt4 to work correctly with PLplot, I am looking > forward to you extending the present example and/or adding additional pyqt4 > examples to demonstrate the pyqt4 PLplot possibilities that have now opened > up. I've expanded the present example to match the C++ Qt example. > What do you think of removing the pyqt3 example (prova.py and > qplplot.py) in > examples/python now that we have a working pyqt4 example? Maintenance > releases of pyqt3 continue as can be seen at > http://freshmeat.net/projects/pyqt/releases/301031. So we cannot justify > removing our pyqt3 example based on pyqt3 no longer being viable, but on > the > other hand, nobody has worked on our pyqt3 bindings or our one pyqt3 > example > since they were donated years ago, and we now seem to have a pyqt4 > alternative that is being actively developed and used by you. We probably should remove it. I think that the right way to support PyQt3 would be similar to how we now support PyQt4, with the appropriate .sip file and the Qt driver. -Hazen |
From: Alan W. I. <ir...@be...> - 2009-07-06 02:23:33
|
To Hazen and Geoff: (Geoff should be interested in the last paragraph.) On 2009-07-05 12:23-0400 Hazen Babcock wrote: > Alan W. Irwin wrote: >> Now that you have gotten pyqt4 to work correctly with PLplot, I am looking >> forward to you extending the present example and/or adding additional pyqt4 >> examples to demonstrate the pyqt4 PLplot possibilities that have now opened >> up. > > I've expanded the present example to match the C++ Qt example. Thanks. That demonstrates the power of pyqt4 much better than before and also looks good. > >> What do you think of removing the pyqt3 example (prova.py and qplplot.py) >> [...]nobody has worked on our pyqt3 bindings or our one pyqt3 >> example >> since they were donated years ago, and we now seem to have a pyqt4 >> alternative that is being actively developed and used by you. > > We probably should remove it. I think that the right way to support PyQt3 > would be similar to how we now support PyQt4, with the appropriate .sip file > and the Qt driver. DONE (revision 10120). Thanks for your guidance on this issue. I also took this opportunity to remove the hand-crafted pyqt3 interface to PLplot and write up what is going on with the change from pyqt3 to pyqt4. The interface cuts went pretty deep in bindings/python/plplot_widgetmodule.c, but I have proved to my satisfaction that the remainder of that file (which now only implements Geoff's python access to plframe) still builds and runs without issues. For example, pytkdemo still works the same as before (i.e., with the issues I mentioned previously to Geoff, but no new ones). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |