[Plplot-devel] Planning for the release of 5.13.0

[Alan W. I. <ir...@be...>]

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
Plp...@li...
https://lists.sourceforge.net/lists/listinfo/plplot-devel