We have made lots of progress (see our git log) since the release of 5.12.0 so I am looking forward to releasing 5.13.0 in the near future (i.e., in early or late August depending on how much time Arjen has for PLplot testing in the remainder of this month, and how soon we can debug the issues he has found with his preliminary Windows platform testing.
I am now declaring a soft code freeze for this release (which means large documentation upgrades are still fine, but no actual code changes should be merged to the master branch that will be the basis of this release other than bug fixes). Right now, this code freeze is quite soft, but as we approach closer to the release it will harden almost completely (i.e., only the simplest and most trivial bug fixes will be accepted). The point of this rapidly hardening policy is those of us that test need some largely quiet time with regard to actual code changes for a week or so just before the release to finalize our testing results. N.B. this code freeze does not preclude me continuing to work with Phil on his private topic branch concerning implementing and using C exceptions to handle all our C errors. The projects that we need to finish before this release are the following with all three of these release-critical in my view. * Completely debug the Windows variant of the 3-semaphores approach to IPC between -dev wxwidgets and wxPLViewer. The status of this project is Arjen and I have gone through a number of iterations of code changes and Linux comprehensive wxwidgets tests on my part and similar comprehensive tests of wxwidgets on Windows platforms on Arjen's part. My comprehensive test on Linux was fine (except for subscript rendering issues, see below) and Arjen also got a promising preliminary result (confined to just the shared library build tree) on MinGW-w64/MSYS2 that he needs to extend to the nondynamic, static, and install tree cases. In addition Arjen's tests with the MSVC compiler discovered an uninitialized variable in the superfix/subfix rendering code for wxwidgets. I am the last developer to have touched that complicated code so it is up to me to fix it. But the reason I touched it before was it was not rendering correctly at all. The superscript rendering was a lot better after I modified that code to fix some obvious issues AND to introduce some semiempirical corrections to the vertical spacing for superscripts, but there was still an egregious subscript rendering issue (subscripts were being rendered exactly like superscripts). I expect the uninitialized variable explains why I was having so much trouble debugging that code, but I am virtually positive there is more work to do there than that. Although I have not been able to work on this recently because of other interesting PLplot developments, I do plan to dig deep into that code and finally make it work properly starting tomorrow. Of course, such bug fixes are allowed and positively encouraged during the soft part of the code freeze so if anyone else wants to deal with a bug that has been bothering you (other than the well-known plfill bug where there are some deep issues I want to deal with myself, and now likely post-release again), I strongly encourage you to do that now. * Comprehensive tests on the Linux and non-interactive comprehensive tests on MinGW-w64/MSYS2, MSVC, Cygwin, and Mac OS X platforms with fixes for all obvious issues discovered with these tests (or if the fix is not obvious or is complex, dropped components of PLplot for the platform in question). The status of this project is as follows: The comprehensive test success that I got last month on Linux has now recently been confirmed again (actually for a case where once again the prefixes for the source, build, and install trees all contained a space). That Debian Jessie platform has all possible PLplot soft dependencies installed (albeit for rather old versions of software). As a result essentially all Linux-relevant components of PLplot were tested, and the tests were done for both noninteractive and interactive components of PLplot. Thus, we are in good shape on Linux outside of the PLplot soft dependency version issues brought up recently by Ole such as Octave 4 which only works for pure ascii examples versus Octave-3 on Debian Jessie that works for both ascii and non-ascii UTF-8 examples. (This octave-4 non-ascii UTF-8 issue is something I plan to deal with post-release once I have had a chance to install Debian stable = Stretch, testing, and unstable following Ole's suggestion.) Arjen had completed a successful comprehensive test of all relevant noninteractive components of Cygwin much earlier in this release cycle so I thought we were in good noninteractive shape on that platform, but for some reason that same test is now erroring out so that issue needs a lot further investigation by Arjen to discover the cause of that peculiar noninteractive regression on Cygwin. For example, it has some symptoms that are consistent with it being a hardware failure, but there is no proof of that until he gets the classic inconsistent results for exactly the same test that are typically associated with some sort of hardware failure (e.g., errors in the memory hardware). Furthermore, Arjen's first test of an almost fully loaded (except for Qt) MinGW-w64/MSYS2 platform on the same box errored out so this is a regression against the good Greg Jung results we had for a fully loaded earlier version of this platform ~2 years ago. So this MinGW-w64/MSYS2 platform regression needs a lot further investigation by Arjen as well. My understanding is Arjen also plans a comprehensive noninteractive MSVC (+ Unix tools on PATH) test with one PLplot component removed that did not work the last time he tried this test on that platform. If some volunteer steps forward to do a comprehensive test of the latest PLplot on Mac OS X, that would be nice, but I don't view that as release critical. * The typedef project The status of that project is my old plan (explained in the release notes for 5.12.0) to change most PLplot generic pointers to have the const attribute is a bad way to create const correctness because that imposes a long-term burden on users of these argument types to never pass back information using the generic pointers in their callbacks. So I have already (a couple of weeks ago) backed away from that plan and have gone back to what we had in 5.11.1 which was all our generic pointers in our API have the type PLPointer which is typedefed to void *. The generic pointers PL_NC_GENERIC_POINTER and PL_GENERIC_POINTER (both of which were introduced in 5.12.0 by typedefing them to void *, but there _were_ big plans to change PL_GENERIC_POINTER to const void * and use that const type for the majority of our generic pointer API) will continue to be typedefed as void *. However, they are now officially deprecated in favor of the PLPointer alternative which PLplot users have been using for years. So currently PL_NC_GENERIC_POINTER and PL_GENERIC_POINTER are typedef'd in include/plplot.h, but they have both been replaced by PLpointer everywhere in our code (other than that file) and also in our documentation. So the current result of the above work is the set of typedefs we use in our DocBook documentation is consistent with the non-deprecated typedefs specified in include/plplot.h. So that is an excellent start! However, there is obviously lots more to do here such as to propagate the use of our non-deprecated typedefs (many first defined in 5.12.0) to all our C and C++ code in our bindings (e.g., our C++ binding itself as well as the swig-generated Python, Java, Octave, and Lua bindings that are implemented using swig-generated C and C++ source code) and our drivers and examples that are written in either C or C++. Finally I would also like to make all our C and C++ code const correct. However, I have run out of time in this release cycle so I will put off these typedef propagation efforts and updating our code to improve const correctness until after the release. For the same reason, I plan to put off working on the plfill bug and OCaml PostScript difference issues until after this release as well. So where we stand is the first topic above is relatively close to being done, and the last topic is done. However, the second topic will have a large degree of uncertainty with regard to when it will be resolved until Arjen's further tests determine the source of those peculiar noninteractive regressions on those two Windows platforms. So we are clearly getting much closer to the release because we have made a lot of progress in the last few weeks and we are now at the stage where I feel comfortable about declaring the soft freeze. Also, I am pretty sure the release will be in August, but I cannot be more definite than that right now until Arjen figures out the causes of those two testing regressions. 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 ------------------------------------------------------------------------------ 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
