Re: [Plplot-devel] PLplot Debian package

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

On 2017-07-14 14:48-0600 Orion Poplawski wrote:

>> @Orion:
>>
>> Can you confirm that PLplot now works well with Octave-4.2 on Fedora
>> or is there additional issues to deal with?
>
> Well, it compiles.  There are longstanding test failures though:
>
> 5:
> 5: *** PLPLOT ERROR, ABORTING OPERATION ***
> 5: UTF-8 string is malformed: ???M??????, aborting operation
>
> Check out a build log from:
> https://apps.fedoraproject.org/koschei/package/plplot?collection=f27

Hi Orion:

Just before sending this off, I looked in detail at the above error
log but could not find the above error there.  So it may be solved,
it may be obscured by another issue now, or I may have misread
the above build log.

Anyhow, the rest of this post assumes the above error is still an
issue for octave-4.2.x, but it would be interesting for Ole to confirm
that as well (once he gets the swig issue sorted out).

The PLplot core library assumes all user-supplied strings are encoded
in UTF-8, and then it converts those to UCS4 for internal use.  And
the above error message is a result of that converter tool detecting
some user input that is not encoded in UTF-8.

That process works fine for octave-3.8.2.  UTF-8 user strings are
passed from octave to our dynamically loaded octave binding shared
object which then passes those on to our own PLplot
library to do the conversion to UCS4 with success.

So I suspect that a backwards incompatibility was introduced into
octave-4.x.y (or perhaps octave-4.2.x if 4.0.x worked fine for Fedora)
so that it molests UTF-8 strings in some way so that whenever these
molested strings are transmitted to our octave binding shared
object/core PLplot library that latter library detects an invalid
UTF-8 input string (as above).

I have had troubles before with octave and UTF-8 (see
<http://octave.1599824.n4.nabble.com/utf8-does-not-appear-to-work-for-function-documentation-strings-generated-with-texinfo-td4663317.html>)
That issue was (eventually) satisfactorily resolved, but I was
surprised at how little Octave developers knew about UTF-8 back then
(3 years ago). For example, some of them felt you must use wide
characters to store UTF-8 which is completely incorrect; it is
designed to be stored as a string of 8-bit bytes.  Also, their
documentation translation teams seemed unaware of UTF-8.  For example,
they felt they had to be dependent on wide characters for their
translation of their English documentation strings into other human
languages.

Anyhow, if you and Ole don't want to mess with this issue, I will take it
up myself once I get my hands on octave-4 (i.e., post-release).  And
hopefully this time I will find octave developers who are more aware
of the power of UTF-8.

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
__________________________