[Plplot-devel] What are the development priorities for the csironn library? (was Bug#990397: depends on deprecated qhull library)

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

On 2021-07-02 10:38+0200 Rafael Laboissière wrote:

> Dear PLplot developers,
>
> I am hereby forwarding a bug report filed against the Debian plplot package 
> regarding the use of a deprecated Qhull library [1]. Conversion of the code 
> to the reentrant version of Qhull needs more changes than merely linking 
> against libqhull_r.so instead of libqhull.so and including 
> libqull_r/qhull_ra.h instead of libqull/qhull_a.h [2], and should be done by 
> the upstream authors.

Hi Rafael:

Since this email is primarily directed to the upstream Plplot
development list, I have generalized this discussion of how upstream
PLplot development should respond to Debian Bug#990397 to the new
subject line which is "What are the development priorities for the
csironn library?".  I would value your input into that general
discussion since you are a former PLplot developer who at that time
had a lot of interest in that library and its dependence on libqhull.

You likely know all this stuff already, but to set up this discussion
for the benefit of the others here, this is a quick review why the
plgriddata routine and therefore PLplot depends on our csironn library, and
that library in turn depends on the libqhull library.

The lib/nn/README file documents that question from the historical
(2003!)  viewpoint.  To add to that from my own current perspective,
the fundamental issue appears to be that Pavel Sakov's free nn-c
library throughout its history including [it's latest
version](https://github.com/sakov/nn-c) has depended on [the triangle
library](http://www.cs.cmu.edu/~quake/triangle.html) whose licensing
terms are as follows:

"Please note that although Triangle is freely available, it is
copyrighted by the author and may not be sold or included in
commercial products without a license."

You (and other Debian developers) know a lot more about licensing
legalities than I do so please let me know whether this license means
in Debian packaging terms Triangle is non-free as asserted in
lib/nn/README and therefore nn-c is "contrib" rather than "free" in
Debian packaging terms.

Anyhow, as a result of that perceived (and likely real, but that needs
confirmation) licensing issue Joao stripped the version of the nn-c
library available in 2003 to just what was needed by plgriddata, and
replaced all calls to triangle library routines in that stripped
version with the equivalent libqhull calls.  Anyhow it is that
stripped and triangle-replaced ancient version of nn-c that we call
csironn and that we have been maintaining (in a small way since 2003) as a free
(as opposed to contrib if the above licensing issue is confirmed) fork
of nn-c.

To help motivate further discussion of the subject-line topic would
you please briefly comment on the *potential* importance of the
csironn library in the free software world?  My guess is you will find
in practice it is not important (at least at present) because nobody
knows about this PLplot gem, e.g., you will likely discover that no
other Debian package depends on our csironn library.  However, do you agree
with me that situation is a real shame since the issue of
interpolating from non-gridded sample points to gridded sample points
is an important and fairly common issue that is nicely addressed by
our csironn library?

I would also appreciate your responses to the following comments and
questions concerning the new subject line topic:

* The original Debian Bug#990397 that started me thinking about this
   general topic states

   "your package builds and links against the non-reentrant version of
   Qhull, which has been deprecated by Qhull upstream and is likely to
   disappear soon."

   However, I quarrel with that "likely to disappear soon" phrase since
   on that subject the qhull developers say the following (from
   <http://www.qhull.org/html/qh-code.htm#reentrant>):

   "New code should be written with libqhull_r. Existing users of
   libqhull should consider converting to libqhull_r. Although *libqhull
   will be supported indefinitely* [emphasis mine], improvements may not be
   implemented."

   It is up to you, of course, but my feeling is you would be entirely
   justified in closing this bug report because of the "supported
   indefinitely" phrase above which completely contradicts the premise
   of the bug report!

   That said, from this language from the qhull developers I do agree use
   of libqhull is (very lightly) deprecated.  Therefore "it would be
   nice" for libcsironn to change its dependence on libqhull to a
   dependence on libqhull_r (as suggested by the libqhull developers and you)
   since rentrancy although not the same as thread-safe often is a step
   toward thread safety which is an extremely desirable library
   characteristic.  It does appear (from comments later in the above
   URL) this change would be straightforward so this should be a nice
   simple development topic for someone to implement.

* It "would be nice" to update our fork to the latest version of nn-c.
   The reason I suggest this as a worthwhile goal is I assume that
   Pavel's fairly constant development of nn-c since 2003 has found and
   fixed more bugs in the nn-c code than we have found and fixed in our
   fork of that code.  As a short-cut to make this development topic
   easier, our fork could continue to ignore everything in nn-c that is
   not relevant to the problem of interpolating from non-gridded sample
   points to gridded sample points, but see the next item below.  I haven't
   looked at what would be required by this development topic, but my
   guess is it could be implemented by simply replacing the
   csironn routines with the corresponding nn-c routines while keeping
   just the part of of the csironn routines that set up and call
   the libqhull routines and/or fix bugs in the nn-c version of these
   routines that are already in csironn and which have not already
   been fixed by Pavel.  So it might all end up as a glorious git conflict
   resolution.  :-)

* The above "would be nice" development topic should be done first,
   but in addition it "would be nice" to not strip nn-c at all. My
   guess is what was stripped was pretty minor stuff since the csironn
   ability to interpolate from non-gridded to gridded sample points
   captures all the essential functionality of nn-c.  But regardless of
   that question, the result should be that csironn should have all the
   functionality of modern nn-c (i.e., it passes all nn-c tests) with
   the only changes being conversion of *all* triangle library calls to
   the equivalent libqhull calls.

   I hasten to add I don't want to discuss this "vapour ware" with
   Pavel until it turns into "real ware".  However, if we accomplish
   that goal (i.e., if the updated csironn library passes all nn-c
   testing) I bet Pavel (who is a really approachable guy) would be
   willing to adopt our changes right into nn-c (likely as an option),
   and that would clear the way for that useful library to be packaged
   by Debian as "free" rather than "contrib" and would also allow us to
   abandon our fork (since it would have been merged back into
   mainstream nn-c development) which I think would be a highly desired
   outcome.

I have stated on this list before (but you may have missed that), I
work most efficiently on just one development topic at a time.  And my
current primary development topic is getting the next release of
FreeEOS out the door and my two topics following that are (i) getting
the next libLASi release out the door using recent PLplot to
comprehensively test it, and (ii) getting the PLplot release out the
door.

In sum, because of these other development commitments I don't plan
for now to contribute much toward any of the above three "would be
nice" development topics for libcsironn other than discussing them.
But if you or anyone else here that was interested in libcsironn were
inspired by this discussion to create a patch to implement any of
those topics (or any other libcsironn development topic that
interested you), I would be happy to comprehensively test that patch
in a timely manner and (assuming that was a success) push that commit
to make sure your work gets into the next release of PLplot.

Best wishes,

Alan
__________________________
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy,
University of Victoria, Victoria, BC, Canada.

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.org); 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
__________________________