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 __________________________ ------------------------------------------------------------------------------ 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
