Re: [Plplot-devel] Wishlist: a verbose testing option
Doing gdb sessions in the build tree is pretty tricky because of all the setup (e.g., setting environment variables) you have to do first. So I don't recommend it except for rare emergencies where you get errors in the build tree but not the install tree. Furthermore, ctest doesn't have a facility to pass options on to plplot-test.sh so we have to choose the plplot-test.sh options for the build tree at cmake time which would not be very convenient for you. So for the above reasons I am not completely keen on your idea. However, if you still are keen after considering what I have said above, then please send me a patch with the implementation (not only the changes to plplot-test.sh.in, but the extra logic required in the various test_*.sh.in files). Assuming the patch looks okay, I can deal with the cmake details so that there is a cmake option such that ctest runs plplot-test.sh with both the --verbose and --debug options. My problem is that I'm building RPM packages and so it's pretty much impossible to do the testing in the install tree. I'll work on a patch. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Wishlist: a verbose testing option
On 2008-08-14 08:14-0600 [EMAIL PROTECTED] wrote: My problem is that I'm building RPM packages and so it's pretty much impossible to do the testing in the install tree. I'll work on a patch. Thanks in advance, Orion. I suggest instead of using --debug, you use --extra-verbose as the name of the plplot-test.sh option. That name is more consistent with what you want (more verbosity). Internally in plplot-test.sh and test*.sh, you could still use the verbose_test environment variable, but assign numerical values to it (0 for no verbosity, 1 for the current level you get with the --verbose option, 2 for the extra verbosity you want). BTW, there is an --extra-verbose option for ctest. As far as I can tell, our current ctest results are identical with that option or the ctest --verbose option. If we have access to that when running our tests (I am about to ask that question on the CML), then we can choose the plplot-test.sh verbosity at ctest run time rather than cmake time, which should be considerably more convenient. 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 __ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Wishlist: a verbose testing option
On Thu, Aug 14, 2008 at 08:14:25AM -0600, [EMAIL PROTECTED] wrote: Doing gdb sessions in the build tree is pretty tricky because of all the setup (e.g., setting environment variables) you have to do first. So I don't recommend it except for rare emergencies where you get errors in the build tree but not the install tree. Furthermore, ctest doesn't have a facility to pass options on to plplot-test.sh so we have to choose the plplot-test.sh options for the build tree at cmake time which would not be very convenient for you. So for the above reasons I am not completely keen on your idea. However, if you still are keen after considering what I have said above, then please send me a patch with the implementation (not only the changes to plplot-test.sh.in, but the extra logic required in the various test_*.sh.in files). Assuming the patch looks okay, I can deal with the cmake details so that there is a cmake option such that ctest runs plplot-test.sh with both the --verbose and --debug options. My problem is that I'm building RPM packages and so it's pretty much impossible to do the testing in the install tree. I'll work on a patch. It is really not that hard to work in the build tree. All you usually need to set is PLPLOT_LIB to point to the data directory in the source tree. Andrew - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Wishlist: a verbose testing option
On Tue, Aug 12, 2008 at 03:45:39PM -0700, Alan Irwin wrote: On 2008-08-11 19:59-0700 Alan W. Irwin wrote: On 2008-08-11 14:43-0600 Orion Poplawski wrote: Wishlist: a verbose testing option that would output the actual command executed for each test. I have implemented a proof of concept of this idea (revision 8636) for our C examples. Please try it out and let me know what you think. Andrew, as a major user of the ctest command, I especially ask you to have a look at how I did this (since I am no scripting expert) and the results for ctest --verbose. Please feel free to change any part of my implementation. If you like what you now see for the C examples (and nobody else objects to how much output there is now with the ctest --verbose command), I will propagate the idea to the rest of the test_*.sh.in scripts except for the octave one. Alan, In principal I like the idea of being able to see the examples as they are exectuted. I wonder whether the whole command line is necessary though. Perhaps just echoing the example name would suffice and would prevent too much unnecessary clutter in the output? For testing purposes this is what is required. For a given test you know what the driver is and what the output files will be. I find looking through Testing/Temporary/LastTest.log useful and all this extra information could make it more difficult to find useful error messages. For test_octave.sh.in I will rely on you for that needed propagation since octave expertise is required to read in the verbose_test environment variable into octave and echo the commands to generate the various p and x octave examples. Alternatively, it might be a good idea to reduce test_octave.sh.in as much as possible to the form of the other test scripts so, e.g., the looping through the various examples is done in the shell rather than in octave. Obviously, there will be a bit more latency with that approach, but hopefully it would not be noticeable, and I think it would be valuable to remove some of the mystery from test_octave.sh.in by doing as much as possible in the shell. Note, I committed the original version of test_octave.sh, but that was under heavy instruction from our octave expert at that time, Jaoa Cardoso, and I will be the first to admit I had no clue what I was doing. :-) So I think a complete rewrite of test_octave.sh.in by our current octave expert (you) would be a good idea. I am inclined to stay with the current single instance of octave. The overhead of starting octave ~40 times is not insignificant. Once we agree on a format I can add the necessary octave code. Andrew - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Wishlist: a verbose testing option
Andrew Ross wrote: In principal I like the idea of being able to see the examples as they are exectuted. I wonder whether the whole command line is necessary though. Perhaps just echoing the example name would suffice and would prevent too much unnecessary clutter in the output? For testing purposes this is what is required. For a given test you know what the driver is and what the output files will be. I find looking through Testing/Temporary/LastTest.log useful and all this extra information could make it more difficult to find useful error messages. Perhaps another --debug option? What I find hard is when a test is segfaulting finding the command I need to execute to reproduce it directly so that I can run it under gdb. I agree for normal operation the command is not necessary and may be harmful. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane [EMAIL PROTECTED] Boulder, CO 80301 http://www.cora.nwra.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Wishlist: a verbose testing option
On 2008-08-13 22:13+0100 Andrew Ross wrote: In principal I like the idea of being able to see the examples as they are exectuted. I wonder whether the whole command line is necessary though. Perhaps just echoing the example name would suffice and would prevent too much unnecessary clutter in the output? For testing purposes this is what is required. For a given test you know what the driver is and what the output files will be. Thanks for that feedback which has convinced me terse is better. I have therefore changed test_c.sh.in accordingly. I have also made a change there so the extra output you get in verbose mode occurs in the natural position before the execution of the command rather than afterward. As of revision 8644 I have used a similar style for all the other test*.in files except test_octave.sh.in which I made no changes to. [...]Once we agree on a format I can add the necessary octave code. Thanks in advance. 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 __ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Wishlist: a verbose testing option
On 2008-08-13 15:19-0600 Orion Poplawski wrote: Andrew Ross wrote: In principal I like the idea of being able to see the examples as they are exectuted. I wonder whether the whole command line is necessary though. Perhaps just echoing the example name would suffice and would prevent too much unnecessary clutter in the output? For testing purposes this is what is required. For a given test you know what the driver is and what the output files will be. I find looking through Testing/Temporary/LastTest.log useful and all this extra information could make it more difficult to find useful error messages. Perhaps another --debug option? What I find hard is when a test is segfaulting finding the command I need to execute to reproduce it directly so that I can run it under gdb. I agree for normal operation the command is not necessary and may be harmful. Sorry, Orion, I missed your comment before I made the changes. There are two possible use cases here. Just as a general principle, I think debugging in the install tree is just a whole lot cleaner than in the build tree so I highly recommend it. Doing gdb sessions in the install tree is quite simple because no environment variables have to be set, and you know where everything is. For that case, your suggested --debug option for plplot-test.sh only has limited usefulness for those who are already familiar with running examples in the install tree. However, I suspect you were considering just the build-tree case when you made your proposal, and see below for the limitations in that case. Doing gdb sessions in the build tree is pretty tricky because of all the setup (e.g., setting environment variables) you have to do first. So I don't recommend it except for rare emergencies where you get errors in the build tree but not the install tree. Furthermore, ctest doesn't have a facility to pass options on to plplot-test.sh so we have to choose the plplot-test.sh options for the build tree at cmake time which would not be very convenient for you. So for the above reasons I am not completely keen on your idea. However, if you still are keen after considering what I have said above, then please send me a patch with the implementation (not only the changes to plplot-test.sh.in, but the extra logic required in the various test_*.sh.in files). Assuming the patch looks okay, I can deal with the cmake details so that there is a cmake option such that ctest runs plplot-test.sh with both the --verbose and --debug options. 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 __ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Wishlist: a verbose testing option
On 2008-08-11 19:59-0700 Alan W. Irwin wrote: On 2008-08-11 14:43-0600 Orion Poplawski wrote: Wishlist: a verbose testing option that would output the actual command executed for each test. I have implemented a proof of concept of this idea (revision 8636) for our C examples. Please try it out and let me know what you think. Andrew, as a major user of the ctest command, I especially ask you to have a look at how I did this (since I am no scripting expert) and the results for ctest --verbose. Please feel free to change any part of my implementation. If you like what you now see for the C examples (and nobody else objects to how much output there is now with the ctest --verbose command), I will propagate the idea to the rest of the test_*.sh.in scripts except for the octave one. For test_octave.sh.in I will rely on you for that needed propagation since octave expertise is required to read in the verbose_test environment variable into octave and echo the commands to generate the various p and x octave examples. Alternatively, it might be a good idea to reduce test_octave.sh.in as much as possible to the form of the other test scripts so, e.g., the looping through the various examples is done in the shell rather than in octave. Obviously, there will be a bit more latency with that approach, but hopefully it would not be noticeable, and I think it would be valuable to remove some of the mystery from test_octave.sh.in by doing as much as possible in the shell. Note, I committed the original version of test_octave.sh, but that was under heavy instruction from our octave expert at that time, Jaoa Cardoso, and I will be the first to admit I had no clue what I was doing. :-) So I think a complete rewrite of test_octave.sh.in by our current octave expert (you) would be a good idea. 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 __ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
