[Plplot-devel] Status of our octave binding and examples for version 4.4.0 of octave

[Alan W. I. <Ala...@gm...>]

To Orion and Arjen:

As of
<https://sourceforge.net/p/plplot/plplot/ci/d7310aa9864ce1676177f39323c9daf593ae0765/>
our octave binding and all examples/octave/x??c.m examples give a
perfect PostScript difference report for Octave 4.4.0 for Debian
Buster == Debian Testing.  Please do equivalent checks (i.e., by
simply building the test_noninteractive target in the build tree) for
Cygwin, MinGW-w64/MSYS2, and Fedora to check all is well on platforms
other than Debian Buster.  I emphasize build-tree checks because
install-tree checks currently won't work until I finish another
project that was half-completed when I discovered the octave-4 cell array
workaround described below.

The way I got the previously dropped octave examples 26 and 33 to work
was to use cell arrays at those points in the examples where Octave
non-cell arrays were not working due to an upstream bug in Octave 4.4
for the transformation method used to determine C strings from an
Octave non-cell array of strings.  For a long time I thought the issue
was UTF-8, but I discovered when testing the recent commit that pure
ascii strings could also cause issues.

Since that commit I have discovered (with my hex_print private test
project) the issue is a simple one which is the transformation method
that used to work fine for octave 3.8 no longer works for octave-4.4
*if* there are more than 15 bytes in the character strings in the
non-cell arrays.  (Of course, UTF-8 strings tend to have more bytes
which is why they tend to expose this upstream bug more than ascii
strings, but with hex_print I found in every case whether using the
ascii subset of UTF-8 or more general UTF-8 strings that short strings
worked, but when the number of bytes in the Octave string (excluding the NULL
byte) exceeded 15, the result was an invalid UTF-8 C string.

I have just submitted this issue to the upstream octave developers
(see <https://savannah.gnu.org/bugs/index.php?54415>).  That bug
report is based on the hex_print experience summarized above, and
since that experience proves there is now an explicit length limit of
15 imposed by the octave code, the issue should be easy to find and
fix (I hope).

But meanwhile, the cellstr workaround in the above commit for long
strings avoids this issue so with luck the PLplot testers lurking here
will now get perfect octave-4 results when building the
test_noninteractive target on all platforms of interest to them.

Also note in the subsequent commit 95f823ec0, I have changed our
octave detection method so that octave-4 is no longer a special case
with warnings attached.  Which finally (from the better late than
never department) answers Orion's question about those warnings from
long ago.  :-)

Alan
__________________________
Alan W. Irwin

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
__________________________