Here are the Python results I am getting on the MinGW/MSYS/wine 32-bit platform (on my 64-bit hardware):
python Missing examples : Differing postscript output : 03 04 05 06 08 09 11 12 14a 15 16 17 18 19 20 21 22 23 25 26 29 33 Missing stdout : Differing stdout : 14 23 These results were obtained from comprehensive_test.sh configured to test just the case of shared libraries for the test_noninteractive target in both the build tree and CMakeified installed examples tree. I believe the Python results above are the first extensive testing reported for Python on a Windows platform. Despite the large number of differences reported above, the actual diff results are not that bad; all of them correspond to a maximum difference of only one unit in the last place as verified by ndiff except for just the following three examples: 17 (large diffs, but no noticable differences can be seen using the gv viewer). 19 (page 3 is completely messed up for the python version which is strange because page 4 [identical to page 3 except for the "Baltimore" label] looks good). 25 (large diffs, but no noticable differences can be seen using the gv viewer). A closer look at the first few lines of diffs for example 25 showed a polyline drawing issue. Some redundant points were being put in the closed polyline for the Python case. So I attribute at least this part of the large diff to roundoff errors propagating to the choice of whether polylines need an extra point to be closed. That may be the reason for the example 17 differences as well. In general, though from all the many one-unit-in-last-place differences reported above, 32-bit python on Windows appears to have a lot of numerical noise compared to its C counterpart. I have no idea why, or whether that numerical noise problem also exists for all 32-bit Python platforms. The example 14 stdout differences are due to the Python messages appearing in scrambled order, e.g., Enter graphics output file name: Demo of multiple output streams via the psc driver. Running with the second stream as slave to the first. "Demo of multiple output streams via the psc driver. Running with the second stream as slave to the first." comes from the first stream and "Enter graphics output file name" comes from the second stream of that example. I don't have a clue how the messages from the second stream get output first for Python, and vice versa for C, but there it is. The example 23 stdout differences will appear on any 32-bit platform where the python version outputs the FCI as 0x80000000L while the C version drops the L suffix. In sum, I believe there are mundane explanations for most of the above diff results so Python is basically working properly on 32-bit Windows. I therefore strongly encourage all our Windows users (and especially our Windows testers) to download and install Python for Windows following the instructions at http://www.miscdebris.net/plplot_wiki/index.php?title=Install_Python so that Python will automatically become part of the Windows build, install, and test of PLplot from then on. 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 __________________________ ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
