On 2012-02-17 21:42-0700 Orion Poplawski wrote: > On 02/08/2012 11:25 AM, Alan W. Irwin wrote: >> On 2012-02-08 07:44-0000 Andrew Ross wrote: >> >>> On Tue, Feb 07, 2012 at 09:28:27PM -0700, Orion Poplawski wrote: >>>> On 01/28/2012 12:27 PM, Andrew Ross wrote: >>>>> On Sat, Jan 28, 2012 at 08:02:17AM -0700, Orion Poplawski wrote: >>>>>> On 01/28/2012 01:04 AM, Andrew Ross wrote: >>>>>>> Orion - the changes were committed to svn last week. Have you >>>>>>> tried since then? >>>>>>> If so and it still fails, can you provide details? >>>>>> >>>>>> Sorry, forgot to check. But split is still used in test_octave.sh.in >>>>>> and test_octave_interactive.sh.in. >>>>> >>>>> Orion, >>>>> >>>>> No problem. Thanks for spotting the test scripts. I'd overlooked that >>>>> one. Now fixed as well. >>>>> >>>>> Andrew >>>> >>>> Finally was able to build (due to other Fedora issues). All looks good >>>> now. Thanks. >>> >>> Glad to hear it. >> >> Orion, it is good that you can now build octave, but what is the >> run-time story? >> >> To discover that you have to run the test targets for octave. You can >> find those from >> >> make help |grep test_octave >> >> which on my system produces >> >> ... test_octave_psc >> ... test_octave_qtwidget >> ... test_octave_tk >> ... test_octave_wxwidgets >> ... test_octave_xcairo >> ... test_octave_xwin >> >> Considering all the trouble we had with API changes in octave in the >> old days from one version to the next, I would be surprised but quite >> pleased if all those (especially the interactive ones after >> test_octave_psc) worked for you. >> >> For my Octave 3.2.4 version from Debian squeeze (which is the oldest >> version of Octave we currently support) I have just now tried all >> these test targets. test_octave_wxwidgets (the wxGC version of the >> wxwidgets device driver) generated a segfault. Apparently from the >> comments in the scripts, that always happens whenever multiple plots >> are tried. So that adds a non-octave issue hat needs to be fixed for >> the wxwidgets device driver. But the rest of the devices are well >> maintained, and for them I got no segfaults or any other obvious >> run-time errors and mostly consistent interactive results. >> >> Do you get similar good interactive results (except for >> test_octave_wxwidgets) for 3.6.0? >> >> Same question for you, Andrew, for whatever version of Octave you are >> testing at the moment. >> >> If all three of us can produce good interactive results for octave, >> then it is probably time to consider making the above interactive >> tests (except for test_octave_wxwidgets) a dependency of the >> test_interactive target. (I didn't do that before because >> in the old days a lot of those interactive tests failed.) >> >> Since all the p?? examples appear to be working now for the >> interactive case, it may also be time to expand the list of examples >> that are tried for test_octave_psc. Currently that is i=[1:6 8 9 13 15 >> 21]. Of course, since test_octave_psc is already a dependency of the >> test_noninteractive target, adding such examples should be done with >> some caution. >> >> Alan > > Not sure I follow everything here, but here's what I've done. Every build > runs: > > ctest -V -E 'compare|qt' > > and that completed fine.
-V is okay (verbose) but -E compare|qt' excludes the critical test which compares all language results with the C results for the standard examples and also all tests related to qt. Therefore, those ctest results will be much too limited in my opinion. I suggest instead you run ctest -V or better yet make test_noninteractive The latter is a bit more comprehensive than ctest (something we could fix for ctest). Also, both ctest and make have parallel options which allow the user to take advantage of multi-cpu systems. The principal advantage of the test_noninteractive target is it handles all dependencies correctly (so you don't have to run "make all" first [which executes more than the needed dependencies] like you do for ctest). Another advantage of the test_noninteractive target is it exists and has the same comprehensive testing effect for the CMake-based build system for the installed examples. The principal advantage of ctest is it can be configured to send its results automatically to a dashboard. That is a really powerful capability. The kitware folks check the git version of cmake that is intended for their next release that way on as many different platforms as they can get volunteers to test. I think we should also organize such automatic ctest-based testing for PLplot, but I have not yet been able to do that due to too many other things on my agenda these days. > > In the installed packages I see plplot-test.sh claims to have an > --interactive_octave option, but: > > [root@vmf17 examples]# ./plplot-test.sh --interactive_octave > > Never heard of an interactive device called psc. Either this > is not a legitimate interactive device for PLplot or else > plplot-test.sh.cmake needs some maintenance to include this > interactive device in the list of possible PLplot interactive devices. As the error message implies, the default psc device is not an interactive device. So you must specify an interactive device, e.g., ./plplot-test.sh --interactive_octave --device=xwin Instead, you could run the test_octave_xwin target as suggested above (i.e., execute "make test_octave_xwin"). That target and the other interactive octave targets I listed above deal properly with all dependencies and eventually runs the ./plplot-test.sh --interactive_octave command with appropriate interactive device. I hope this explanation helps you to better understand our non-interactive and interactive test systems. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 __________________________ ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
