To Phil and Pedro: Now that 5.12.0 has been released, I am writing a series of posts to our active developers with this subject line.
If either of you has any additional wxwidgets development in mind beyond what I discuss below, please let me know. For this release cycle I encourage both of you to continue your efforts to deal with obvious wxwidgets bugs (such as the unexpected black rather than expected white background color for the first page of example 16) to complement the work I plan to do deal with the last of the wxwidgets device driver efficiency issues on Linux. Your goal should be that each of our C examples with -dev wxwidgets should produce exactly the same results (except possibly for text size) as given at <http://plplot.sourceforge.net>/examples.php>. It would be great if one of you got the currently retired wxpng file device going again as an aid for such comparisons with other file-based plot results. But even better would be if you implemented a wxwidgets-based SVG device (see <https://wiki.wxwidgets.org/WxSVGFileDC>). The reason I particularly mention SVG as a file format is the generated results are written in XML and therefore are straightforward to interpret and debug by visual comparison of that XML result with other SVG (from -dev svg, -dev svgcairo, or -dev svgqt) results for the same standard example. @Phil: We were all agreed (see the February 2016 thread with the subject line "Error report system plus thread safety" that our current use of calls to exit() or the equivalent plexit whenever an error condition was encountered was an important issue for our users using interactive environments, i.e., one PLplot error ==> takes down entire interactive work without giving the user a chance to save anything ==> one less user interested in using PLplot! During that thread you were strongly recommending using a setjmp()/longjmp() C-based exception model because you are very comfortable with using exception handling in C++ and the amount of editing required to implement it would be much smaller than the return code method. Although Hazen had a substantially more cautious attitude, I was happy to go along with that C exception approach rather than the alternative return code method because of my knowledge of the extreme length of many of our call/caller graphs and the large amount of the work it would be for us to check _all_ calls of _all_ PLplot functions within our C library code for invalid return codes. <aside A google search for the search terms <c error handling longjmp setjmp> gives lots of hits. Phil, I would appreciate you looking at the top several and letting me know which you think is the best for learning about exception handling in C. </aside> The final upshot of that thread was you planned to make a proof of concept for us to look at (and help you propagate it to everywhere else in our C code during this release cycle if we liked that proof of concept). Anyhow, could you please implement that proof of concept now? 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 __________________________ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
