To Werner, Hazen, and Jerry: Without decent colour maps, PLplot is pretty useless so colour issues are release critical by definition. Therefore, I hope all three of you with access to OS X will give the current plspal1 issues on Mac OS X that were discovered by Werner your immediate attention.
Hazen and Jerry, do you confirm the issues Werner is seeing on Mac OS X? As far as I know he has only tested for qt, but I assume this issue is device independent. Could you make sure your experiments (with revision 10358, see below) include the following experiments I asked Werner to try? On 2009-08-28 10:29-0700 Alan W. Irwin wrote: > So to summarize the experiments I would like you to try, please see whether > -dev psc also produces the example 16 warning messages and please see > whether can you reproduce similar issues for example 10 using -cmap1. > > Once the new warning messages have identified exactly where in the code the > problem is occurring, could you please try a gdb session (or printf's > scattered around plspal1) to see exactly what is going wrong? > There have been two changes recently which I assume will not affect the issue that Werner discovered, but I mention them for completeness and just in case that assumption is incorrect. * At Arjen's suggestion, I changed the fuzz factor for floating point comparisons from 1.d-12 to 1.d-4. However, for the default "typedef double PLFLT" case, I expect floating point errors in quantities read in from palette files will be of order 1.d-16. Thus, this change should make no difference in that case. For the "typedef float PLFLT" you get when you specify -DPL_DOUBLE=OFF to cmake, I expect the floating-point errors in quantities read in from palette files will be of order 1.d-6. So for -DPL_DOUBLE=OFF this change will make an important difference (which is why Arjen suggested it), but otherwise not. * This morning I found four palette files (cmap0_alternate.pal, cmap0_white_bg.pal, cmap1_blue_yellow.pal, and cmap1_radar.pal) which had no svn:eol-style property assigned at all and others had native line endings (meaning they would have different line endings depending on what platform those files were checked out on). I think it is best that these PLplot input files have the exact same form whether obtained from our release tarball or svn so I have changed the svn:eol-style property to LF (Unix line endings) for all of them as of revision 10358. Regardless of platform, I don't see how line endings will make any difference to either cmap0_palette_read or plspal1 since they both use fgets from the C library. On Linux, fgets reads everything up to and including the line feed corresponding to the line end. I think Mac OS X line endings are also Unix (so the above property change should make no difference in any case) and I assume fgets act there the same as on Linux. For Windows, I assume fgets also reads everything up to and including the line feed regardless of whether that line feed is proceeded by a CR or not. Therefore, as far as I know changing to the LF property should generate the same results for cmap0_pallette_read and plspal1 on all platforms. So my assumption is the above two changes should make absolutely no difference to Werner's bad OS X results, but I need confirmation of that assumption from Werner and also confirmation of Werner's bad results on OS X by our other developers for revision 10358. If you do get differences from Werner's results, then it is important to see what is different about his Mac OS X system (Darwin version, etc., compared to yours) so give plenty of details if you cannot confirm his (bad) result. I believe I have done everything possible from this end to make it straightforward to debug this plspal1 issue on OS X, but ultimately one of you guys with access to Mac OS X has to sit down and actually debug the issue until you come up with a fix. Hopefully that will be in a timely manner (i.e., in the next few days) so we don't have to hold the release for the fix. 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 __________________________ ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
