From: Alan W. I. <ir...@be...> - 2008-12-18 09:19:58
|
Here is the current ctest compare status of the examples as of revision 9180. c++, f77, f95, java, python, and perl are now perfect except for the historical example 19 problems and the new example 31 issues which I plan to fix later today (Thursday). Here is the status of the rest of the languages. octave Missing examples : 19 Differing postscript output : 31 Missing stdout : 01 02 03 04 05 06 07 08 09 10 11 12 13 15 16 18 20 21 22 23 24 25 26 27 28 29 30 31 Differing stdout : tcl Missing examples : 19 31 Differing postscript output : 11 13 15 16 20 Missing stdout : Differing stdout : ada Missing examples : 31 Differing postscript output : 03 09 13 15 29 Missing stdout : Differing stdout : 23 ocaml Missing examples : Differing postscript output : 15 29 31 Missing stdout : Differing stdout : 31 I assume that Andrew will deal with the octave stdout issue. ndiff shows that tcl examples 11 and 20 differences with the corresponding C versions are just due to rounding, but it also shows that appears not to be the case with 09 13 and 15. (Those examples also show a modest file length difference with the corresponding C examples.) I hope Andrew will look at those three examples as well to reduce their differences just to rounding issues (as shown by ndiff). I am going to leave the Ada changes to Jerry because I just have too hard a time with that language and similarly I will leave the OCaml changes to Hez. In sum, that means the only examples responsibility I have left is the example 31 versions for all languages (other than Ada and OCaml), and I plan to finish off that responsibility later today (Thursday). But I must get some sleep first. 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: Alan W. I. <ir...@be...> - 2009-01-08 00:33:02
|
With some initial help from me, Andrew has just finished integrating example 17 into our tests. That finishes the work of integrating our existing examples into the tests. Here is the current example status (determined running "make test" in the installed examples tree) for my Debian testing platform with everything default (e.g., using numpy and Tcl-8.5). I have excluded c++, f77, f95, and perl/pdl from these results because all those bindings were perfect according to this test. java Missing examples : 19 Differing postscript output : Missing stdout : Differing stdout : octave Missing examples : 19 Differing postscript output : 21 Missing stdout : Differing stdout : python Missing examples : 19 Differing postscript output : Missing stdout : Differing stdout : tcl Missing examples : 17 19 Differing postscript output : Missing stdout : Differing stdout : ada Missing examples : Differing postscript output : 17 Missing stdout : Differing stdout : adathick Missing examples : Differing postscript output : 17 Missing stdout : Differing stdout : ocaml Missing examples : 17 Differing postscript output : Missing stdout : Differing stdout : The API exercised by example 19 is not straightforward to implement, but it's been done for Fortran (both f77 and f95) so hopefully somebody will take up this challenge for java, octave, and python. My understanding is that Arjen is working on this issue for Tcl. 17 is missing for Tcl and OCaml, but it should be less of a challenge than implementing the API for 19. My understanding is that Hez is working on OCaml example 17. Jerry has already remarked on the example 17 issue for Ada. Instead of four different legends, the Ada plots show the same (last) legend. Jerry, perhaps it is time to try the Ada lists for some help with this Ada/C interfacing issue? IIRC, octave was perfect before (except for missing ex 19) for me and Andrew's commit messages for example 21 imply that example was previously perfect for him. Thus, I believe the octave issue for example 21 has been recently introduced (with revision 8637). If you look at the first page of the Octave and C plots the random data are quite different. That seems a major clue, but there doesn't seem to be anything obvious in bindings/octave/demos/x21.m that is causing this difference, and I also don't spot anything obvious in the revision 8637 commit. Andrew, could you take a look? 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: Andrew R. <and...@us...> - 2009-01-08 06:44:33
|
On Wed, Jan 07, 2009 at 04:32:54PM -0800, Alan Irwin wrote: > > IIRC, octave was perfect before (except for missing ex 19) for me and > Andrew's commit messages for example 21 imply that example was previously > perfect for him. Thus, I believe the octave issue for example 21 has been > recently introduced (with revision 8637). If you look at the first page of > the Octave and C plots the random data are quite different. That seems a > major clue, but there doesn't seem to be anything obvious in > bindings/octave/demos/x21.m that is causing this difference, and I also > don't spot anything obvious in the revision 8637 commit. Andrew, could you > take a look? I woke up this morning and realised the cause of this. Currently test_octave.sh runs all the tests from a single octave process. I suspect this is the cause since plrandd is now used in 2 examples (17 and 21) and so example 21 will give different results now since the random number generator will already have been called in example 17. I will look at this later. Andrew |
From: Arjen M. <arj...@wl...> - 2009-01-08 07:37:52
|
> tcl > Missing examples : 17 19 > Differing postscript output : > Missing stdout : > Differing stdout : > > The API exercised by example 19 is not straightforward to implement, but > it's been done for Fortran (both f77 and f95) so hopefully somebody will > take up this challenge for java, octave, and python. My understanding is > that Arjen is working on this issue for Tcl. > > 17 is missing for Tcl and OCaml, but it should be less of a challenge than > implementing the API for 19. My understanding is that Hez is working on > OCaml example 17. > I was surprised to see example 17 missing yesterday. But then I started to convert the C code into Tcl and I noticed that the plstrip* functions are not available within the Tcl bindings. So it is not just a matter of missing example code. With the exception of one new type of data, adding the interface will not be problematic. I am ignoring the plsError() function in the C code - certainly for the moment. There is a way to implement it (via Tcl_LinkVar()), but I do not think it is worth the effort right now. I will implement example 19, as I have thought of a convenient way to do it. Regards, Arjen |
From: Andrew R. <and...@us...> - 2009-01-08 15:01:10
|
On Thu, Jan 08, 2009 at 08:37:36AM +0100, Arjen Markus wrote: > > tcl > > Missing examples : 17 19 > > Differing postscript output : > > Missing stdout : > > Differing stdout : > > > > The API exercised by example 19 is not straightforward to implement, but > > it's been done for Fortran (both f77 and f95) so hopefully somebody will > > take up this challenge for java, octave, and python. My understanding is > > that Arjen is working on this issue for Tcl. > > > > 17 is missing for Tcl and OCaml, but it should be less of a challenge than > > implementing the API for 19. My understanding is that Hez is working on > > OCaml example 17. > > > > I was surprised to see example 17 missing yesterday. But then I started > to convert the C code into Tcl and I noticed that the plstrip* functions > are not available within the Tcl bindings. So it is not just a matter > of missing example code. > > With the exception of one new type of data, adding the interface will > not be problematic. Arjen, That's great - thanks. > I am ignoring the plsError() function in the C code - certainly for the > moment. There is a way to implement it (via Tcl_LinkVar()), but I do not > think it is worth the effort right now. Several other languages ignore the plsError function in example 17. This is not strictly part of the common api anyway. > I will implement example 19, as I have thought of a convenient way > to do it. That would also be great. I think it should be possible to call java functions from C, but I need (at least) a few hours working out how to do it with swig and the jni. That leaves octave and python. Octave should also be possible, if messy, but will also require some learning on my part. Andrew |
From: Werner S. <sm...@ia...> - 2009-01-08 07:52:42
|
Hi Andrew, > > I woke up this morning and realised the cause of this. Currently > test_octave.sh runs all the tests from a single octave process. I > suspect this is the cause since plrandd is now used in 2 examples (17 > and 21) and so example 21 will give different results now since the > random number generator will already have been called in example 17. This sounds reasonable, since the corresponding variables are static. Just call plseed(5489) in the octave examples before plrandd(), this will set the random number generator to the default seed. No need to do this for the other bindings as long as a new process is started for every example. Regards, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Andrew R. <and...@us...> - 2009-01-08 14:54:42
|
On Thu, Jan 08, 2009 at 08:52:21AM +0100, Werner Smekal wrote: > Hi Andrew, > > > > I woke up this morning and realised the cause of this. Currently > > test_octave.sh runs all the tests from a single octave process. I > > suspect this is the cause since plrandd is now used in 2 examples (17 > > and 21) and so example 21 will give different results now since the > > random number generator will already have been called in example 17. > > This sounds reasonable, since the corresponding variables are static. > Just call > > plseed(5489) > > in the octave examples before plrandd(), this will set the random > number generator to the default seed. No need to do this for the other > bindings as long as a new process is started for every example. Thank's Werner. I'd actually delved into the code for the magic value anyway. I have included this in all the other implementations of example 21 since plseed is not tested anywhere else. This showed up bugs in the f77 and f95 bindings to plseed which I have also fixed. I've also documented plrandd and plseed in api.xml. They were currently missing, which was how they had got missed off when I checked the api coverage in the examples recently. I should probably go back to plplot.h to ensure the documentation is complete. Andrew |
From: Andrew R. <and...@us...> - 2009-01-08 20:56:12
|
On Thu, Jan 08, 2009 at 02:54:35PM +0000, Andrew Ross wrote: > > Thank's Werner. I'd actually delved into the code for the magic value > anyway. I have included this in all the other implementations of example > 21 since plseed is not tested anywhere else. This showed up bugs in the > f77 and f95 bindings to plseed which I have also fixed. I've also > documented plrandd and plseed in api.xml. They were currently missing, > which was how they had got missed off when I checked the api coverage in > the examples recently. I should probably go back to plplot.h to ensure > the documentation is complete. I've been back and cross checked with plplot.h. The only common API functions missing from docs and examples are plhls, plrgb and plrgb1 which are depreciated according to the source. I've now marked these as such in plplot.h. The only two others missing are plot3dcl and plsurf3dl. These are closely related to plot3dc and plsurf3d so usage should be clear. Andrew |
From: Alan W. I. <ir...@be...> - 2009-01-15 19:31:31
|
Due to Andrew and Arjen's extremely recent efforts, java, python, and tcl join c++, f77, f95, perl, and ocaml to give perfect PostScript and stdout comparison results with the corresponding C examples. Here are the only remaining issues: octave Missing examples : 19 Differing postscript output : Missing stdout : Differing stdout : ada Missing examples : Differing postscript output : 17 Missing stdout : Differing stdout : adathick Missing examples : Differing postscript output : 17 Missing stdout : Differing stdout : This summary looks substantially better than our last release, and when you consider how much more extensive the testing now is behind the scenes, this result actually represents a tremendous improvement over our last release. Thanks to everyone who helped get us this far. 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: Andrew R. <and...@us...> - 2009-01-16 09:39:58
|
On Thu, Jan 15, 2009 at 11:31:24AM -0800, Alan Irwin wrote: > Due to Andrew and Arjen's extremely recent efforts, java, python, and tcl > join c++, f77, f95, perl, and ocaml to give perfect PostScript and stdout > comparison results with the corresponding C examples. Here are the only > remaining issues: > > octave > Missing examples : 19 > Differing postscript output : > Missing stdout : > Differing stdout : > > ada > Missing examples : > Differing postscript output : 17 > Missing stdout : > Differing stdout : > adathick > Missing examples : > Differing postscript output : 17 > Missing stdout : > Differing stdout : > > This summary looks substantially better than our last release, and when you > consider how much more extensive the testing now is behind the scenes, this > result actually represents a tremendous improvement over our last release. > > Thanks to everyone who helped get us this far. I have looked at octave. matwrap - which is used to automatically generate the octave bindings does not support function pointers so we will have to roll our own support for those functions using this. This is not insurmountable since octave provides support for calling from C. It is probably easier than trying to add support to matwrap. It won't happen pre-release though. Once this is in place we can implement plmap and plmeridians (and also full versions of plcont etc) and add example 19. This will then complete the common API for all bindings I believe! I still want to work a bit more on tidying up the java and python interfaces for using function callbacks. Now I know how to do it there is no reason not to allow java to use user-supplied pltr functions for example. Again, probably not worth holding up a release for. I think it can be done in a backwards compatible way since java allows multiple versions of a method with different arguments. Andrew |
From: Andrew R. <and...@us...> - 2009-01-16 10:40:34
|
On Thu, Jan 15, 2009 at 11:31:24AM -0800, Alan Irwin wrote: > Due to Andrew and Arjen's extremely recent efforts, java, python, and tcl > join c++, f77, f95, perl, and ocaml to give perfect PostScript and stdout > comparison results with the corresponding C examples. Here are the only > remaining issues: > > octave > Missing examples : 19 > Differing postscript output : > Missing stdout : > Differing stdout : > > ada > Missing examples : > Differing postscript output : 17 > Missing stdout : > Differing stdout : > adathick > Missing examples : > Differing postscript output : 17 > Missing stdout : > Differing stdout : > > This summary looks substantially better than our last release, and when you > consider how much more extensive the testing now is behind the scenes, this > result actually represents a tremendous improvement over our last release. > > Thanks to everyone who helped get us this far. On a 32-bit Linux system results are not (quite) so good. I note the problems above, plus python Missing examples : Differing postscript output : Missing stdout : Differing stdout : 23 tcl Missing examples : Differing postscript output : 03 14a 17 21 Missing stdout : Differing stdout : 21 For python $ diff x23c_psc.txt x23p_psc.txt 1c1 < For example 23 prior to page 12 the FCI is 0x80000000 --- > For example 23 prior to page 12 the FCI is 0x80000000L This is with python 2.5.2. I imagine this is because the FCI constant is a long rather than standard integer on a 32-bit system since python does not have unsigned int. Or it may be a python version thing? For tcl the differences with 03 and 14a are just a single line where an integer differs by one. I put this down to rounding error. This is with tcl8.4. Example 21 requires tcl 8.5. Example 17 I see large differences, but again often only rounding errors. This is hard to compare because a small error can lead to the axes rescaling at a different time which produces large differences in the postscript output. Visually the final results looks good. Andrew |
From: Andrew R. <and...@us...> - 2009-01-16 11:04:51
|
On Fri, Jan 16, 2009 at 10:40:24AM +0000, Andrew Ross wrote: > On Thu, Jan 15, 2009 at 11:31:24AM -0800, Alan Irwin wrote: > > Due to Andrew and Arjen's extremely recent efforts, java, python, and tcl > > join c++, f77, f95, perl, and ocaml to give perfect PostScript and stdout > > comparison results with the corresponding C examples. Here are the only > > remaining issues: > > > > octave > > Missing examples : 19 > > Differing postscript output : > > Missing stdout : > > Differing stdout : > > > > ada > > Missing examples : > > Differing postscript output : 17 > > Missing stdout : > > Differing stdout : > > adathick > > Missing examples : > > Differing postscript output : 17 > > Missing stdout : > > Differing stdout : > > > > This summary looks substantially better than our last release, and when you > > consider how much more extensive the testing now is behind the scenes, this > > result actually represents a tremendous improvement over our last release. > > > > Thanks to everyone who helped get us this far. > > On a 32-bit Linux system results are not (quite) so good. > > I note the problems above, plus > > python > Missing examples : > Differing postscript output : > Missing stdout : > Differing stdout : 23 > tcl > Missing examples : > Differing postscript output : 03 14a 17 21 > Missing stdout : > Differing stdout : 21 > > For python > > $ diff x23c_psc.txt x23p_psc.txt > 1c1 > < For example 23 prior to page 12 the FCI is 0x80000000 > --- > > For example 23 prior to page 12 the FCI is 0x80000000L > > This is with python 2.5.2. I imagine this is because the FCI constant > is a long rather than standard integer on a 32-bit system since python > does not have unsigned int. Or it may be a python version thing? > > For tcl the differences with 03 and 14a are just a single line where an > integer differs by one. I put this down to rounding error. This is with > tcl8.4. Example 21 requires tcl 8.5. Example 17 I see large differences, > but again often only rounding errors. This is hard to compare because a > small error can lead to the axes rescaling at a different time which > produces large differences in the postscript output. Visually the final > results looks good. To follow up my own post - switching to tcl8.5 gives perfect results, so this is not a 32-bit issue. Perhaps we should add a note that tcl 8.5 is recommended, although previous versions will work? Andrew |
From: Arjen M. <arj...@wl...> - 2009-01-16 11:10:29
|
> On Fri, Jan 16, 2009 at 10:40:24AM +0000, Andrew Ross wrote: > > To follow up my own post - switching to tcl8.5 gives perfect results, so > this is not a 32-bit issue. Perhaps we should add a note that tcl 8.5 > is recommended, although previous versions will work? > You should get the same perfect results if you add: set tcl_precision 17 to the beginning of the test. This will instruct Tcl 8.4 to do the same as Tcl 8.5 does by default. (Perhaps this should be added to the README or to the examples themselves.) Regards, Arjen |
From: Andrew R. <and...@us...> - 2009-01-16 11:19:33
|
On Fri, Jan 16, 2009 at 12:10:22PM +0100, Arjen Markus wrote: > > On Fri, Jan 16, 2009 at 10:40:24AM +0000, Andrew Ross wrote: > > > > To follow up my own post - switching to tcl8.5 gives perfect results, so > > this is not a 32-bit issue. Perhaps we should add a note that tcl 8.5 > > is recommended, although previous versions will work? > > > > You should get the same perfect results if you add: > > set tcl_precision 17 > > to the beginning of the test. This will instruct Tcl 8.4 to do > the same as Tcl 8.5 does by default. (Perhaps this should be > added to the README or to the examples themselves.) P.S. This is not necessary on a 64-bit system - presumably the default precision is higher there and I get perfect results even with tcl 8.4. Andrew |
From: Andrew R. <and...@us...> - 2009-01-16 11:18:08
|
On Fri, Jan 16, 2009 at 12:10:22PM +0100, Arjen Markus wrote: > > On Fri, Jan 16, 2009 at 10:40:24AM +0000, Andrew Ross wrote: > > > > To follow up my own post - switching to tcl8.5 gives perfect results, so > > this is not a 32-bit issue. Perhaps we should add a note that tcl 8.5 > > is recommended, although previous versions will work? > > > > You should get the same perfect results if you add: > > set tcl_precision 17 > > to the beginning of the test. This will instruct Tcl 8.4 to do > the same as Tcl 8.5 does by default. (Perhaps this should be > added to the README or to the examples themselves.) We should certainly document that somewhere. If fact, we should probably add it into the scripts automatically if the tcl version is < 8.5. Andrew |
From: Alan W. I. <ir...@be...> - 2009-01-16 17:55:38
|
On 2009-01-16 11:18-0000 Andrew Ross wrote: > On Fri, Jan 16, 2009 at 12:10:22PM +0100, Arjen Markus wrote: >>> On Fri, Jan 16, 2009 at 10:40:24AM +0000, Andrew Ross wrote: >>> >>> To follow up my own post - switching to tcl8.5 gives perfect results, so >>> this is not a 32-bit issue. Perhaps we should add a note that tcl 8.5 >>> is recommended, although previous versions will work? >>> >> >> You should get the same perfect results if you add: >> >> set tcl_precision 17 >> >> to the beginning of the test. This will instruct Tcl 8.4 to do >> the same as Tcl 8.5 does by default. (Perhaps this should be >> added to the README or to the examples themselves.) > > We should certainly document that somewhere. If fact, we should probably > add it into the scripts automatically if the tcl version is < 8.5. Arjen may well be right that "set tcl_precision 17" will completely fix the problem for Tcl-8.4, but that needs to be confirmed. Also, there is an issue of the best place to make that change (i.e., could it be done centrally or does it have to be done for each example), and once the change is done, additional cross-platform testing of all examples will be required. All that is going to take time, and we are only two days away from our release on Sunday. Arjen, if you can quickly figure out the best implementation and get a commit done in the next few hours (or by early Saturday (your time zone) at the latest), then that would give the rest of us a chance to test your changes before the Sunday release. Otherwise I think you should wait to deal with this issue post-release, and simply state in README.release that the Tcl examples give identical results to the C examples for Tcl-8.5, but there is a precision issue we hope to deal with before the next release for Tcl-8.4. 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: Arjen M. <arj...@wl...> - 2009-01-16 18:25:18
|
> > All that is going to take time, and we are only two days away from our > release on Sunday. Arjen, if you can quickly figure out the best > implementation and get a commit done in the next few hours (or by early > Saturday (your time zone) at the latest), then that would give the rest of > us a chance to test your changes before the Sunday release. Otherwise I > think you should wait to deal with this issue post-release, and simply > state > in README.release that the Tcl examples give identical results to the C > examples for Tcl-8.5, but there is a precision issue we hope to deal with > before the next release for Tcl-8.4. > Hi Alan, I built PLplot with Tcl 8.4.12 but to my astonishment I am not getting _any_ differences anymore - examples 3, 11, 15, 16, 20 all give perfect matches. The easiest way to see if tcl_precision will make a difference on other platforms is to add the following line in the file pltcl.c, just before the return of AppInit(): Tcl_SetVar( interp, "tcl_precision", "17", TCL_GLOBAL_ONLY); this way you set the value from the start and only need to change a single file. (Alternatively you would have to add "set tcl_precision 17" to all files x01, x02, ...) What a timing for a Heisenbug or one of its cousins! Regards, Arjen |
From: Andrew R. <and...@us...> - 2009-01-16 19:56:52
|
On Fri, Jan 16, 2009 at 07:25:03PM +0100, Arjen Markus wrote: > > > > > All that is going to take time, and we are only two days away from our > > release on Sunday. Arjen, if you can quickly figure out the best > > implementation and get a commit done in the next few hours (or by early > > Saturday (your time zone) at the latest), then that would give the rest of > > us a chance to test your changes before the Sunday release. Otherwise I > > think you should wait to deal with this issue post-release, and simply > > state > > in README.release that the Tcl examples give identical results to the C > > examples for Tcl-8.5, but there is a precision issue we hope to deal with > > before the next release for Tcl-8.4. > > > > Hi Alan, > > I built PLplot with Tcl 8.4.12 but to my astonishment I am not > getting _any_ differences anymore - examples 3, 11, 15, 16, 20 all > give perfect matches. > > The easiest way to see if tcl_precision will make a difference on > other platforms is to add the following line in the file pltcl.c, > just before the return of AppInit(): > > Tcl_SetVar( interp, "tcl_precision", "17", TCL_GLOBAL_ONLY); > > this way you set the value from the start and only need to change > a single file. (Alternatively you would have to add "set tcl_precision 17" > to all files x01, x02, ...) > > What a timing for a Heisenbug or one of its cousins! Well I've reverted to tcl 8.4. With standard svn tcl Missing examples : Differing postscript output : 03 14a 17 21 Missing stdout : Differing stdout : 21 With Arjen's "fix" I get tcl Missing examples : Differing postscript output : 21 Missing stdout : Differing stdout : 21 Looks promising to me. Arjen, is there anything to lose by adding this in by default to pltcl.c? We could do this just for the version < 8.5 case if that is possible. Andrew |
From: Alan W. I. <ir...@be...> - 2009-01-16 20:01:45
|
On 2009-01-16 19:25+0100 Arjen Markus wrote: > >> >> All that is going to take time, and we are only two days away from our >> release on Sunday. Arjen, if you can quickly figure out the best >> implementation and get a commit done in the next few hours (or by early >> Saturday (your time zone) at the latest), then that would give the rest of >> us a chance to test your changes before the Sunday release. Otherwise I >> think you should wait to deal with this issue post-release, and simply >> state >> in README.release that the Tcl examples give identical results to the C >> examples for Tcl-8.5, but there is a precision issue we hope to deal with >> before the next release for Tcl-8.4. >> > > Hi Alan, > > I built PLplot with Tcl 8.4.12 but to my astonishment I am not > getting _any_ differences anymore - examples 3, 11, 15, 16, 20 all > give perfect matches. > > The easiest way to see if tcl_precision will make a difference on > other platforms is to add the following line in the file pltcl.c, > just before the return of AppInit(): > > Tcl_SetVar( interp, "tcl_precision", "17", TCL_GLOBAL_ONLY); > > this way you set the value from the start and only need to change > a single file. (Alternatively you would have to add "set tcl_precision 17" > to all files x01, x02, ...) > > What a timing for a Heisenbug or one of its cousins! Exactly! Because you cannot reproduce the precision issue with Tcl-8.4, let's wait to deal with this until post-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 __________________________ |
From: Alan W. I. <ir...@be...> - 2009-01-16 20:06:08
|
P.S. Since the Tcl-8.4 precision issue only occurs on some platforms, I also suggest we don't say anything about this in our release notes since this may just be a Tcl-8.4 issue on some platforms rather than something intrinsic to PLplot. 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: Andrew R. <and...@us...> - 2009-01-16 20:21:08
|
On Fri, Jan 16, 2009 at 12:05:58PM -0800, Alan Irwin wrote: > P.S. Since the Tcl-8.4 precision issue only occurs on some platforms, I also > suggest we don't say anything about this in our release notes since this may > just be a Tcl-8.4 issue on some platforms rather than something intrinsic to > PLplot. Alan, I think it is a 32-bit / 64-bit issue since I see the problems on my 32-bit Ubuntu system but not on my (nearly) identical 64-bit system. I would like others to confirm this. Andrew |
From: Alan W. I. <ir...@be...> - 2008-12-20 02:25:02
|
Here is the compare status as of revision 9212. c++ Missing examples : Differing postscript output : Missing stdout : Differing stdout : f77 Missing examples : Differing postscript output : Missing stdout : Differing stdout : f95 Missing examples : Differing postscript output : Missing stdout : Differing stdout : java Missing examples : 19 Differing postscript output : Missing stdout : Differing stdout : octave Missing examples : 19 Differing postscript output : Missing stdout : Differing stdout : python Missing examples : 19 Differing postscript output : Missing stdout : Differing stdout : tcl Missing examples : 19 Differing postscript output : 11 13 15 16 20 Missing stdout : Differing stdout : perl Missing examples : Differing postscript output : Missing stdout : Differing stdout : 31 ada Missing examples : 31 Differing postscript output : 15 29 Missing stdout : Differing stdout : 23 ocaml Missing examples : Differing postscript output : 15 29 31 Missing stdout : Differing stdout : 31 I created this result with "make -j3 test" in the install tree which is much faster than running the equivalent test using the "ctest" command in the build tree if you have a multi-processor box. This result represents a large improvement and extension of the example implementations over the last few days mostly due to Andrew's efforts. I assume the Ada and OCaml issues will be straightforward to resolve because those languages have been perfect in the recent past. Perl/PDL has also been perfect in the recent past and is almost perfect now. The remaining perl stdout difference for example 31 should be resolved as soon as some straightforward fixes that I have discussed off-list with Doug are implemented for the external PDL::Graphics::PLplot module. Andrew and I are currently investigating the PostScript differences for tcl using ndiff. Some are just rounding, but others sometimes appear to be something more depending on platform. The remaining issues are due to example 19 and have historically been difficult to resolve. This extension to our testing framework for PLPlot now covers most of our common API and should make it much easier to maintain PLPlot. I have written a paragraph about that important step forward in README.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 __________________________ |
From: Hazen B. <hba...@ma...> - 2008-12-22 16:07:16
|
Hello, In the process of updating the webpage, I've discovered that example 21 segfaults on my new linux box. I'm running Ubuntu 8.10 (64bit). hl:~/opensource/plplot-working/plplot-CBS-1$ uname -a Linux hbabcock-laptop 2.6.27-9-generic #1 SMP Thu Nov 20 22:15:32 UTC 2008 x86_64 GNU/Linux hl:~/opensource/plplot-working/plplot-CBS-1$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) Based on printf debugging, I believe the crash occurs in plgriddata(). I thought it might be qhull related, but it doesn't look like qhull has changed since 2003. The example will run "fine" if I pull plgriddata out of the for loop (so that it only gets called once) and ask for type 0 (GRID_CSA?) interpolation. It will crash if I try type 1 interpolation. It will also crash if the function is inside the for loop, but is set to always use type 0 interpolation. Ideas? -Hazen |
From: Alan W. I. <ir...@be...> - 2008-12-22 18:48:58
|
On 2008-12-22 11:07-0500 Hazen Babcock wrote: > > Hello, > > In the process of updating the webpage, I've discovered that example 21 > segfaults on my new linux box. I'm running Ubuntu 8.10 (64bit). > > hl:~/opensource/plplot-working/plplot-CBS-1$ uname -a > Linux hbabcock-laptop 2.6.27-9-generic #1 SMP Thu Nov 20 22:15:32 UTC > 2008 x86_64 GNU/Linux > > hl:~/opensource/plplot-working/plplot-CBS-1$ gcc -v > Using built-in specs. > Target: x86_64-linux-gnu > Configured with: ../src/configure -v --with-pkgversion='Ubuntu > 4.3.2-1ubuntu11' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs > --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr > --enable-shared --with-system-zlib --libexecdir=/usr/lib > --without-included-gettext --enable-threads=posix --enable-nls > --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 > --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc > --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu > --host=x86_64-linux-gnu --target=x86_64-linux-gnu > Thread model: posix > gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) > > Based on printf debugging, I believe the crash occurs in plgriddata(). I > thought it might be qhull related, but it doesn't look like qhull has > changed since 2003. > > The example will run "fine" if I pull plgriddata out of the for loop (so > that it only gets called once) and ask for type 0 (GRID_CSA?) > interpolation. It will crash if I try type 1 interpolation. It will also > crash if the function is inside the for loop, but is set to always use > type 0 interpolation. > > Ideas? In our extensive pre-release testing nobody noticed such a segfault. However, one good possibility is you are configuring PLplot in a way that is different from what we tested. Therefore, please give all the PLplot build details to give others at least a chance of replicating the segfaults your are seeing. Your report (in fact any bug report) should include the following: (1) cmake options (2) cmake output (3) make output Your report (in fact any bug report) should also include all the details about how you are running example 21. Build tree or install tree? ctest or command line? Which specific drivers have you tested, etc. Ideally, you should be running example 21 in the install tree as follows: examples/c/x21c -dev svg -o test.svg Or you could use -dev psc instead. The reason I suggest these devices is they have no external dependencies. In general, the reason you should run the example like above is it is only a small step from there to rebuilding and installing with the gcc -c option and using valgrind to figure out the memory management problem that is causing the segfault. I am also using gcc 4.3.2. My system is 64-bit like yours. My kernel is one version earlier than yours (2.6.26), but I doubt that will make any difference in this case. Right now, valgrind gives a perfect result for example 21 on my Debian testing system using -dev psc, but that is probably because my build was done in a different way then yours. So please give the requested details so we have a chance, at least, to replicate the bug you have found. 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...> - 2008-12-23 19:03:21
|
Alan W. Irwin wrote: > > In our extensive pre-release testing nobody noticed such a segfault. > However, one good possibility is you are configuring PLplot in a way > that is different from what we tested. Therefore, please give all the > PLplot > build details to give others at least a chance of replicating the > segfaults your are seeing. > > Your report (in fact any bug report) should include the following: > > (1) cmake options > > (2) cmake output > > (3) make output > > Your report (in fact any bug report) should also include all the details > about how you are running example 21. Build tree or install tree? > ctest or > command line? Which specific drivers have you tested, etc. > > Ideally, you should be running example 21 in the install tree as follows: > > examples/c/x21c -dev svg -o test.svg > > Or you could use -dev psc instead. > > The reason I suggest these devices is they have no external > dependencies. In > general, the reason you should run the example like above is it is only a > small step from there to rebuilding and installing with the gcc -c option > and using valgrind to figure out the memory management problem that is > causing the segfault. > > I am also using gcc 4.3.2. My system is 64-bit like yours. My kernel is > one > version earlier than yours (2.6.26), but I doubt that will make any > difference in this case. Right now, valgrind gives a perfect result for > example 21 on my Debian testing system using -dev psc, but that is probably > because my build was done in a different way then yours. So please give > the > requested details so we have a chance, at least, to replicate the bug you > have found. Apologies for leaving out all the details. I've tried to assemble them in the attached files. The problem is: hl:/usr/local/share/plplot5.9.1/examples$ ./c/x21c Plotting Options: < 1> ps PostScript File (monochrome) < 2> psc PostScript File (color) Enter device number or keyword: 1 Enter graphics output file name: x21.ps Segmentation fault hl:/usr/local/share/plplot5.9.1/examples$ -Hazen |