Re: [Plplot-devel] [Plplot-general] Could someone help with this crash?
Discussion move to plplot-devel as this has moved beyond the initial help request. On Sun, May 30, 2010 at 06:09:01PM -0700, Alan Irwin wrote: On 2010-05-30 12:04-0400 Hazen Babcock wrote: Ok, fixed in v11036. It should now behave like the qtwidget driver, which does not actually call plexit(). The stream is not really closed, but nothing can be plotted anymore so it at least appears closed. In the case of the examples, what happens is that once you click the close box all the subsequent plotting commands become nop's. Hi Hazen: That's great you discovered qtwidget does not use plexit and implemented a solution without plexit for the xcairo case as well. I like your solution of using a flag to turn all operations into no-ops when the window has been closed. I confirm that solution smoothly exits from examples/c/x02c when you close the window regardless of page. Thanks! This is a relatively elegant solution which avoids most of the pitfalls with plplot code being executed after the window has closed. Without full error handling in plplot and rewriting lots of user code it is probably the best we can do. Now a question for Andrew. If you try either -dev qtwidget or -dev xcairo from within octave and close the window are you now happy with the results? Well it works fine. This is not really the main problem with octave though. The big issue is doing something silly which results in plexit being called in plplot crashes octave as well. Not a good solution. Assuming the answer is yes, then we have both C (cairo.c) and C++ (qt.cpp) templates for the proper way to do window closing without plexit clobbering the calling environment, and we should propagate those solutions to -dev xwin, -dev tk, and -dev wxwidgets. Agreed, although perhaps it would be more efficient to do this at the library level rather than the driver level. We would only have to do it once, and then any new interactive drivers would simple have to detect the close window button press and set a flag. Andrew -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Plplot-general] Could someone help with this crash?
On 2010-06-01 09:37+0100 Andrew Ross wrote: On Sun, May 30, 2010 at 06:09:01PM -0700, Alan Irwin wrote: Now a question for Andrew. If you try either -dev qtwidget or -dev xcairo from within octave and close the window are you now happy with the results? Well it works fine. This is not really the main problem with octave though. The big issue is doing something silly which results in plexit being called in plplot crashes octave as well. Not a good solution. Assuming the answer is yes, then we have both C (cairo.c) and C++ (qt.cpp) templates for the proper way to do window closing without plexit clobbering the calling environment, and we should propagate those solutions to -dev xwin, -dev tk, and -dev wxwidgets. Agreed, although perhaps it would be more efficient to do this at the library level rather than the driver level. We would only have to do it once, and then any new interactive drivers would simple have to detect the close window button press and set a flag. Good idea that is also likely to solve the -dev tk issue caused by the recent xwin noop fix (which I had to revert because of the -dev tk issue). Also, to answer your further comment above about plexit, we could also just have that set a noop flag for the device used for the stream rather than exiting. Then when something goes wrong with a device, it can call plexit with impunity and similarly when something goes wrong with the PLplot core library, and from then on all device calls for the stream are turned into noops. To me the core library noop solution with plexit modified to use that solution is such a nice idea that my first instinct is to encourage you and Hazen to implement it before the release. However, yesterday I had to deal with three different regressions that had been introduced by very recent changes, and this is a sobering reminder of the downside of making too many changes close to release. That said, it is probably okay if you can squeeze in the changes today (Tuesday) because it gives all of us a chance to test them on all platforms accessible to us for 3 days prior to the release. However, I would be uncomfortable about the quality of our release if we had much less than 3 days to test. Thus, in the likely event that you and Hazen cannot meet such a quick deadline, then I suggest you should put off further noop changes until after the release. 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 Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Recent testing progress
http://miscdebris.net/plplot_wiki/index.php?title=Testing_PLplot#Testing_Reports shows some recent testing activity for both the test_noninteractive and test_interactive targets for this forthcoming release. Hazen has tested the static libraries/no dynamic devices case on Ubuntu, Andrew has tested the shared libraries/no dynamic devices case on Ubuntu, and I have repeated my CMake-2.8.1 test of the shared libraries/dynamic devices case for Debian using PLplot revision 11049 (which fixes the interactive testing regressions that were recently introduced) and libLASi revision 160 (which is a pre-release version of libLASi-1.1.1 which I urge you all to test as part of your PLplot testing). Andrew's and my results show no release-critical errors, but Hazen's results show he is running into some sort of resource limit for any extensive qt tests he wants to make. In order to help Hazen figure out that issue and also to improve the general reliability of this forthcoming release, we obviously need to expand our testing to many other Linux platforms as well as Mac OS X, and Windows platforms. My understanding is that some of you are close to finishing such tests or have already done so. But such tests are much more useful (e.g., to help find future regressions) if you publicly record the results. Therefore, please take the 5 minutes to do that at http://miscdebris.net/plplot_wiki/index.php?title=Testing_PLplot#Testing_Reports My own plans are to extend testing of PLplot/libLASi to the MinGW/MSYS/Wine case over the next few days using a patched CMake-2.8.1 (that patch is essential for the Wine case), a recent Wine release (1.1.42) which I have not tried before, and the latest release of MinGW (4.5.0). Unfortunately, I just discovered that the 4.5.0 release of MinGW that was previously available at SourceForge is currently being reorganized so the files at http://sourceforge.net/projects/mingw/files/MinGW seem to be temporarily unavailable. So I will wait a few hours today to start working on these tests, but if the delay is too long, I will go back to trying a pre-release version of MinGW 4.5.0 which I have already downloaded and which seemed to work fairly well for my first round of PLplot tests on MinGW/MSYS/Wine. Regardless of what version of MinGW/MSYS I use for this round of testing, I will put notes into our wiki on what needs to be prepared/installed to get the MinGW/MSYS/Wine platform working to build and test software. Those notes should aid any of our Mac OS X and Linux users with Intel-compatible hardware who are interested in helping out with building/testing PLplot on the free (both in the software freedom and monetary senses) MinGW/MSYS/Wine platform. 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 Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Plplot-general] Could someone help with this crash?
On Tue, Jun 01, 2010 at 07:40:06AM -0700, Alan Irwin wrote: On 2010-06-01 09:37+0100 Andrew Ross wrote: On Sun, May 30, 2010 at 06:09:01PM -0700, Alan Irwin wrote: Now a question for Andrew. If you try either -dev qtwidget or -dev xcairo from within octave and close the window are you now happy with the results? Well it works fine. This is not really the main problem with octave though. The big issue is doing something silly which results in plexit being called in plplot crashes octave as well. Not a good solution. Assuming the answer is yes, then we have both C (cairo.c) and C++ (qt.cpp) templates for the proper way to do window closing without plexit clobbering the calling environment, and we should propagate those solutions to -dev xwin, -dev tk, and -dev wxwidgets. Agreed, although perhaps it would be more efficient to do this at the library level rather than the driver level. We would only have to do it once, and then any new interactive drivers would simple have to detect the close window button press and set a flag. Good idea that is also likely to solve the -dev tk issue caused by the recent xwin noop fix (which I had to revert because of the -dev tk issue). Also, to answer your further comment above about plexit, we could also just have that set a noop flag for the device used for the stream rather than exiting. Then when something goes wrong with a device, it can call plexit with impunity and similarly when something goes wrong with the PLplot core library, and from then on all device calls for the stream are turned into noops. To me the core library noop solution with plexit modified to use that solution is such a nice idea that my first instinct is to encourage you and Hazen to implement it before the release. However, yesterday I had to deal with three different regressions that had been introduced by very recent changes, and this is a sobering reminder of the downside of making too many changes close to release. That said, it is probably okay if you can squeeze in the changes today (Tuesday) because it gives all of us a chance to test them on all platforms accessible to us for 3 days prior to the release. However, I would be uncomfortable about the quality of our release if we had much less than 3 days to test. Thus, in the likely event that you and Hazen cannot meet such a quick deadline, then I suggest you should put off further noop changes until after the release. Alan, I think this is a very useful feature, but it does need some thought. Do we for example want a method for the user to reset the flag once they have tidied up, or do they need to close then reopen the stream? We should also have a way of the user querying the flag so they can check for errors and clean up accordingly. I don't have too much time right now, and this is also likely to be quite an intrusive change so I suggest holding off until after the release. Andrew -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Trouble with cmake 2.8.1
I'm trying to build my plplot package for Fedora 14 which has cmake 2.8.1 and for some reason it is not producing versioned libraries for F77 and F95. The same package built fine on F-13 with cmake 2.8.0. Anyone else out there seeing this with 2.8.1? F-13/cmake 2.8.0: Linking Fortran shared library libplplotf77d.so cd /builddir/build/BUILD/plplot-5.9.5/fedora/bindings/f77 /usr/bin/cmake -E cmake_link_script CMakeFiles/plplotf77d.dir/link.txt --verbose=1 /usr/bin/gfortran -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -shared -Wl,-soname,libplplotf77d.so.9 -o libplplotf77d.so.9.1.1 CMakeFiles/plplotf77d.dir/strutil.f.o CMakeFiles/plplotf77d.dir/sfstubs.f.o CMakeFiles/plplotf77d.dir/configurable.f.o libplplotf77cd.so.9.1.1 ../../src/libplplotd.so.9.7.0 /usr/lib64/libltdl.so /usr/lib64/libdl.so ../../lib/csa/libcsirocsa.so.0.0.1 ../../lib/nn/libcsironn.so.0.0.1 /usr/lib64/libqhull.so ../../lib/qsastime/libqsastime.so.0.0.1 /usr/lib64/libm.so /usr/lib64/libfreetype.so -Wl,-rpath,/builddir/build/BUILD/plplot-5.9.5/fedora/bindings/f77:/builddir/build/BUILD/plplot-5.9.5/fedora/src:/builddir/build/BUILD/plplot-5.9.5/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.5/fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.5/fedora/lib/qsastime: F-14/cmake-2.8.1: Linking Fortran shared library libplplotf77d.so cd /builddir/build/BUILD/plplot-5.9.5/fedora/bindings/f77 /usr/bin/cmake -E cmake_link_script CMakeFiles/plplotf77d.dir/link.txt --verbose=1 /usr/bin/gfortran -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -shared -o libplplotf77d.so CMakeFiles/plplotf77d.dir/strutil.f.o CMakeFiles/plplotf77d.dir/sfstubs.f.o CMakeFiles/plplotf77d.dir/configurable.f.o libplplotf77cd.so.9.1.1 ../../src/libplplotd.so.9.7.0 /usr/lib64/libltdl.so /usr/lib64/libdl.so ../../lib/csa/libcsirocsa.so.0.0.1 ../../lib/nn/libcsironn.so.0.0.1 /usr/lib64/libqhull.so ../../lib/qsastime/libqsastime.so.0.0.1 /usr/lib64/libm.so /usr/lib64/libfreetype.so -Wl,-rpath,/builddir/build/BUILD/plplot-5.9.5/fedora/bindings/f77:/builddir/build/BUILD/plplot-5.9.5/fedora/src:/builddir/build/BUILD/plplot-5.9.5/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.5/fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.5/fedora/lib/qsastime: Note the missing -Wl,soname and versioned output. Other differences: F-13 used -DCMAKE_SKIP_RPATH:BOOL=ON -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] tiffqt device hangs in test_noninteractive
Alan W. Irwin wrote: On 2010-05-27 22:58+0100 Andrew Ross wrote: Well clearly the output files should be properly closed. I've now fixed that. You could try again, although I don't think that is the problem. You could try again to check. Potentially more interesting are the open pipes. Yeah, unfortunately this appears to not be the issue as it still locks up for me. I tried throwing in a call to the exit() method by the QApplication instance prior to deletion, but this also did not help. Hazen, have you double-checked yet that isGUI is false for your latest tests? Of course, even if isGUI is false, QApplication may I have verified that isGUI is false. BTW, we should revert the isGUI change before the release for the reasons that Andrew stated. -Hazen -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] tiffqt device hangs in test_noninteractive
On 2010-06-01 18:07-0400 Hazen Babcock wrote: BTW, we should revert the isGUI change before the release for the reasons that Andrew stated. Done (revision 11050). 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 Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Trouble with cmake 2.8.1
On 2010-06-01 16:03-0600 Orion Poplawski wrote: I'm trying to build my plplot package for Fedora 14 which has cmake 2.8.1 and for some reason it is not producing versioned libraries for F77 and F95. The same package built fine on F-13 with cmake 2.8.0. Anyone else out there seeing this with 2.8.1? F-13/cmake 2.8.0: Linking Fortran shared library libplplotf77d.so cd /builddir/build/BUILD/plplot-5.9.5/fedora/bindings/f77 /usr/bin/cmake -E cmake_link_script CMakeFiles/plplotf77d.dir/link.txt --verbose=1 /usr/bin/gfortran -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -shared -Wl,-soname,libplplotf77d.so.9 -o libplplotf77d.so.9.1.1 CMakeFiles/plplotf77d.dir/strutil.f.o CMakeFiles/plplotf77d.dir/sfstubs.f.o CMakeFiles/plplotf77d.dir/configurable.f.o libplplotf77cd.so.9.1.1 ../../src/libplplotd.so.9.7.0 /usr/lib64/libltdl.so /usr/lib64/libdl.so ../../lib/csa/libcsirocsa.so.0.0.1 ../../lib/nn/libcsironn.so.0.0.1 /usr/lib64/libqhull.so ../../lib/qsastime/libqsastime.so.0.0.1 /usr/lib64/libm.so /usr/lib64/libfreetype.so -Wl,-rpath,/builddir/build/BUILD/plplot-5.9.5/fedora/bindings/f77:/builddir/build/BUILD/plplot-5.9.5/fedora/src:/builddir/build/BUILD/plplot-5.9.5/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.5/fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.5/fedora/lib/qsastime: F-14/cmake-2.8.1: Linking Fortran shared library libplplotf77d.so cd /builddir/build/BUILD/plplot-5.9.5/fedora/bindings/f77 /usr/bin/cmake -E cmake_link_script CMakeFiles/plplotf77d.dir/link.txt --verbose=1 /usr/bin/gfortran -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -shared -o libplplotf77d.so CMakeFiles/plplotf77d.dir/strutil.f.o CMakeFiles/plplotf77d.dir/sfstubs.f.o CMakeFiles/plplotf77d.dir/configurable.f.o libplplotf77cd.so.9.1.1 ../../src/libplplotd.so.9.7.0 /usr/lib64/libltdl.so /usr/lib64/libdl.so ../../lib/csa/libcsirocsa.so.0.0.1 ../../lib/nn/libcsironn.so.0.0.1 /usr/lib64/libqhull.so ../../lib/qsastime/libqsastime.so.0.0.1 /usr/lib64/libm.so /usr/lib64/libfreetype.so -Wl,-rpath,/builddir/build/BUILD/plplot-5.9.5/fedora/bindings/f77:/builddir/build/BUILD/plplot-5.9.5/fedora/src:/builddir/build/BUILD/plplot-5.9.5/fedora/lib/csa:/builddir/build/BUILD/plplot-5.9.5/fedora/lib/nn:/builddir/build/BUILD/plplot-5.9.5/fedora/lib/qsastime: Note the missing -Wl,soname and versioned output. Other differences: F-13 used -DCMAKE_SKIP_RPATH:BOOL=ON Hi Orion: Here is what I get by default for CMake-2.8.1, -DCMAKE_INSTALL_PREFIX=$prefix, -DBUILD_TEST=ON, and make VERBOSE=1 plplotf77d make_plplotf77d.out [...] Linking Fortran shared library libplplotf77d.so cd /home/software/plplot_svn/HEAD/build_dir/bindings/f77 /home/software/cmake/install-2.8.1/bin/cmake -E cmake_link_script CMakeFiles/plplotf77d.dir/link.txt --verbose=1 /usr/bin/gfortran -fPIC -g -fvisibility=hidden -shared -Wl,-soname,libplplotf77d.so.9 -o libplplotf77d.so.9.1.1 CMakeFiles/plplotf77d.dir/strutil.f.o CMakeFiles/plplotf77d.dir/sfstubs.f.o CMakeFiles/plplotf77d.dir/configurable.f.o libplplotf77cd.so.9.1.1 ../../src/libplplotd.so.9.7.0 /usr/lib/libltdl.so /usr/lib/libdl.so ../../lib/csa/libcsirocsa.so.0.0.1 ../../lib/nn/libcsironn.so.0.0.1 /home/software/qhull/install/lib/libqhull.so ../../lib/qsastime/libqsastime.so.0.0.1 /usr/lib/libm.so /usr/lib/libfreetype.so -Wl,-rpath,/home/software/plplot_svn/HEAD/build_dir/bindings/f77:/home/software/plplot_svn/HEAD/build_dir/src:/home/software/plplot_svn/HEAD/build_dir/lib/csa:/home/software/plplot_svn/HEAD/build_dir/lib/nn:/home/software/qhull/install/lib:/home/software/plplot_svn/HEAD/build_dir/lib/qsastime: cd /home/software/plplot_svn/HEAD/build_dir/bindings/f77 /home/software/cmake/install-2.8.1/bin/cmake -E cmake_symlink_library libplplotf77d.so.9.1.1 libplplotf77d.so.9 libplplotf77d.so make[3]: Leaving directory /home/software/plplot_svn/HEAD/build_dir' This last stanza you didn't quote, but I assume you have that as well to create the appropriate symlinks. However, the important point is my CMake-2.8.1-based build does have -Wl,-soname,libplplotf77d.so.9 while your F14 CMake-2.8.1 build does not. I suggest you try the same build with a virgin CMake-2.8.1 that you build yourself. IIRC, Fortran support was substantially reorganized for CMake-2.8.1, and it is easily possible that F-14 has screwed up their binary rpm version of CMake-2.8.1 by forgetting, for example, to include one or more of the new Fortran Platform support files in their CMake-2.8.1 rpm. 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
