Hi Phil,
As a package, definitely. Regards, Arjen From: Phil Rosenberg [mailto:p.d.rosenb...@gmail.com] Sent: Friday, September 16, 2016 4:25 PM To: Arjen Markus; Alan W. Irwin Cc: plplot-devel@lists.sourceforge.net Subject: RE: [Plplot-devel] Bug in notcrossed() function of plfill.c Hi Arjen I'm just trying to reproduce your Cygwin problems, but I can't get plplot to build with wxWidgets on. Do you know if you installed wxWidgets as a package or from source? Sent from my Windows 10 phone From: Arjen Markus<mailto:arjen.mar...@deltares.nl> Sent: 16 September 2016 08:08 To: Alan W. Irwin<mailto:ir...@beluga.phys.uvic.ca>; Phil Rosenberg<mailto:p.d.rosenb...@gmail.com> Cc: plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net> Subject: RE: [Plplot-devel] Bug in notcrossed() function of plfill.c Hi Alan, Phil, I tried Phil's example on Cygwin - PLplot as built on my installation does have a wxWidgets driver - but unfortunately that fails to run: *** PLPLOT ERROR, ABORTING OPERATION *** unknown error in plD_init_wxwidgets., aborting operation *** PLPLOT ERROR, ABORTING OPERATION *** unknown error in plD_bop_wxwidgets., aborting operation *** PLPLOT ERROR, ABORTING OPERATION *** unknown error in plD_line_wxwidgets., aborting operation ... I then tried it with other drivers, but none demonstrated the sort of problem Phil mentions (I did not quite expect that to happen, but it never hurts to try). Regards, Arjen Arjen Markus Sr. Adviseur/Onderzoeker T +31(0)88335 8559 E arjen.mar...@deltares.nl<mailto:arjen.mar...@deltares.nl> [Logo]<http://www.deltares.com/> www.deltares.com<http://www.deltares.com/> Postbus 177 2600 MH Delft <http://www.twitter.com/deltares> <http://www.linkedin.com/company/217430> <https://www.facebook.com/pages/Deltares/154189334634001> Please consider the environment before printing this email > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] > Sent: Tuesday, September 13, 2016 11:59 PM > To: Phil Rosenberg > Cc: Arjen Markus; > plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net> > Subject: Re: [Plplot-devel] Bug in notcrossed() function of plfill.c > > On 2016-09-13 10:44+0100 Phil Rosenberg wrote: > > > On 13 September 2016 at 03:27, Alan W. Irwin > > <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>> > wrote: > >> There is a substantial testing requirement for fill changes. The > >> reason for that is we have had years of mostly good user experience > >> with the present fill algorithm so I feel it is important that > >> anybody that changes the fill algorithm in any further way needs to > >> demonstrate with substantial testing that their change does not > >> introduce fill regressions. > >> > >> I have alluded previously to automated fill regression testing (for > >> all our standard examples that directly or indirectly use fill and > >> all our file devices). The core of the idea is to compare old and > >> updated plot file results using imagemagick image differences. Do > >> you agree this general approach (supplemented by actually looking at the > >> "fill" > >> subset of our examples for each of our interactive devices) is the > >> way forward to insure that our further fill changes do not introduce > >> more issues than they fix? > > > > I think this is a good idea in general to avoid all sorts of > > regressions. > > Good. > > > Would it be easier to use the svg output and diff as the svg examples > > can be built on all systems? > > Presumably you are aware of this already, but it should be mentioned that one > issue with diff results is you cannot reliably compare results from two > different > floating-point (FP) platforms because FP errors propagate to rounded results > on > two such platforms in different ways. So it is essential to calculate both > the old and > revised fill result with exactly the same FP platform (i.e., you cannot store > plot > results from one FP platform to compare with plot results from other FP > platforms). > > Another issue with using diff even for the same FP platform is any significant > change in the fill code is likely to cause real differences, e.g., the > effective > boundaries of the filled regions will be slightly different. In fact, this > is a problem for > all fully automated methods I can think of to test for fill regressions; > there are going > to be large local changes (as boundaries change slightly) in results, but so > long as > the final result looks OK (i.e., no obvious holes in any fill region and no > significantly > overfilled regions) then the change does not count as a significant fill > regression. > > As a result of this concern, I am now thinking along the lines of an > interactive script > (i.e., not completely automated so it will be tiring to use unless we are > careful with > the selection of what images to compare). At the heart of the script, > imagemagick > would calculate the normalized difference of the old and modified image > results, and > then simultanously display old, modified, and difference image results to help > evaluate by visual means (as opposed to fully automated means) whether any > significant regression has occurred. (Of course, for those cases where the > normalized difference image is zero, the script could simply skip the visual > comparison to speed up the comparison). > > I have mentioned imagemagick here because I am reasonably familiar with it, > and it > is one of the primary collections of software that is used on Unix to > manipulate and > display images. However, you should also note that imagemagick is available > as a > binary download on Windows (see <http://www.imagemagick.org/script/binary- <http://www.imagemagick.org/script/binary-%0b>> releases.php>). > Furthermore, even though it appears not to be specifically packaged for Cygwin > such packaging has occurred for the MinGW-w64/MSYS2 platform so if the generic > windows binary download does not work, there is that other Windows platform > alternative to try as well. > > 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 > __________________________ DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
------------------------------------------------------------------------------
_______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
