plplot-devel — Technical discussion about PLplot development

[Plplot-devel] Welcome to António as our newest core PLplot developer!

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

It is my pleasure to announce publicly that António Rodrigues Tomé has
just become an official member of the PLplot core development team.
(For a list of all official members of that team, see
<https://sourceforge.net/p/plplot/_members/>.)  António's primary
development interest in PLplot is in that software's Qt5 related
components, and he plans further changes (if necessary) for PLplot to
make it compatible with Qt6 as well.  It's great to have that Qt
maintenance expertise on our core team because our Qt-related
components provide some of our best-looking plots.  However, I also
encourage António to work on more than just the Qt-related components
of PLplot if he spots anything else he would like to improve.

Welcome, António!

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
__________________________

Re: [Plplot-devel] plplot qt driver deprecated functions

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

On 2021-07-06 23:34+0100 António Rodrigues Tomé wrote:

> [... I built] all the examples and the patch i send you now seems to work
> very fine:

Same here so I pushed it.  See
<https://sourceforge.net/p/plplot/plplot/ci/cf04f2e6b555edab673a9703cea909d7239ce21b/>
for the substantially changed commit message that includes details of
the tests I ran.

Thanks very much for getting this revised version of your commit to work without generating
the segfaults produced by the prior version.

> P.s. Latter on I will try to understand how to deploy  pyqt5_example.

The missing Python library issue that was previously stopping you can
obviously be addressed by installing the right opensuse package.  But
finding the name of that needed package is more "an art rather than a science".

To help you with that "art" here are the equivalent details on my
Debian Stable platform.

# Find the names of all packages which include a partial filename "libplplot*.so$"
# where ".so" with nothing further added is important since it is that exact suffix the linker looks for.
irwin@merlin> apt-file search libpython |grep '\.so$' |less

There were 17 different possibilities, but one of those

libpython3.7-dev: /usr/lib/x86_64-linux-gnu/libpython3.7m.so

referred to the development version of libpython3 so I am sure
that is the library that is needed, and I do have that package
already installed.  So I think this
result for Debian Stable means you need to install the development
version of either the python3 or libpython3 package (depending on how
opensuse organizes its package names and designates the name of the
development version of those).  Of course, opensuse will not have
the apt-file application, but it should have something equivalent so
that you can associate filenames with the packages (either installed
or not installed) that include those files.

After a successful build I confirmed that /usr/lib/x86_64-linux-gnu/libpython3.7m.so name as follows:

# Find the exact name of that library (at least for Debian Stable after a successful build
of the python binding):

software@merlin> readelf -d bindings/python/_plplotc.so |grep -E 'PATH|NEEDED'
  0x0000000000000001 (NEEDED)             Shared library: [libplplot.so.17]
  0x0000000000000001 (NEEDED)             Shared library: [libpython3.7m.so.1.0]
  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
  0x000000000000001d (RUNPATH)            Library runpath: [/home/software/plplot/HEAD/build_dir/src:]

Hope this working Debian Stable example helps you figure out what to do for opensuse to gain
access to that distro's python3 library.

> also going to try to see how i can force plplot to build with qt6 and then
> one will know if this small patch is enough to deal with the next major
> version of the qt,

Good luck implementing these important Qt6-ready goals for PLplot.

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
__________________________

Re: [Plplot-devel] plplot qt driver deprecated functions

[António R. T. <ar...@gm...>]

Hi Alan,

unfortunately I couldn't test the pyqt5_example as I do not use python and
in spite having it installed I couldn't understand exactly what else to
install but  trying to build plplot
i get
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.13",
minimum required is "3")
-- Could NOT find PythonLibs (missing: PYTHON_LIBRARIES
PYTHON_INCLUDE_DIRS)

however I build all the examples and the patch i send you now seems to work
very fine:

cheers

P.s. Latter on I will try to understand how to deploy  pyqt5_example. I'm
also going to try to see how i can force plplot to build with qt6 and then
one will know if this small patch is enough to deal with the next major
version of the qt,





On Sun, Jun 6, 2021 at 10:33 PM Alan W. Irwin <Ala...@gm...>
wrote:

> Hi António:
>
> On 2021-06-05 20:53+0100 António Rodrigues Tomé wrote:
>
> > Hi Alan,
> >
> > I hope you are well and managed to be free of the virus.
>
> So far so good.  And I hope that is true for everyone on this list
> and their close families!
>
> > new versions of QT5 produce some warnings about the use of  deprecated
> > functions in the driver.
> > The new qt6 will remove most of the obsolete functions,  unless one uses
> an
> > additional back compatibility module. Namely the  QLinkedList will no
> > longer be supported in qt6.
> >
> > So I send you a patch where I replace all the functions that (my qt5.15.2
> > versions) warns about.
> > I think that everything will work fine even with older qt versions,
> >
> > This was needed mainly because for qt6 it will be necessary.
>
> Thanks, António for making this effort to future-proof the PLplot qt
> component.
> You are very close to something I would be happy to push, but there is
> a regression in results that you need to fix in your patch.
>
> Here are the details concerning that regression.
>
> Your patch builds fine here on my Debian Buster = Stable with qt5.11.3
> platform and gives good run-time test results when I build the
> test_pyqt5_example (other than some deprecation warnings that eventually
> do need to be fixed), test_qt_example, and test_memqt_example targets
>
> However, it introduces a segfault regression when I attempt to build
> the test_c_qtwidget target.
>
> The previous (before your patch was applied) result for that target showed
> no warnings or errors for that target.  And there continue to be no
> warnings with this target when your patch is applied.  However,
> here is the error result for that case:
> Generate C results for qtwidget interactive device
> Testing subset of C examples for device qtwidget
> x01c
> x04c
> x08c
> x16c
> x24c
> x30c
> x14c
> /home/software/plplot/HEAD/build_dir/plplot_test/test_c_interactive.sh:
> line 47:  3746 Segmentation fault      $DEBUG_CMD "$cdir"/x${index}${lang}
> -dev $device $NP_OPTION 2> c_interactive_${device}_test.error >|
> "${OUTPUT_DIR}"/x${index}${lang}_${device}.txt
> make[3]: *** [examples/CMakeFiles/test_c_qtwidget.dir/build.make:58:
> examples/CMakeFiles/test_c_qtwidget] Error 1
> make[2]: *** [CMakeFiles/Makefile2:6635:
> examples/CMakeFiles/test_c_qtwidget.dir/all] Error 2
> make[1]: *** [CMakeFiles/Makefile2:6642:
> examples/CMakeFiles/test_c_qtwidget.dir/rule] Error 2
> make: *** [Makefile:2108: test_c_qtwidget] Error 2
>
> So it looks like all examples other than x14c work correctly with your
> patch, but
> x14c (which has quite special needs) apparently exposes an issue with your
> patch.
>
> In fact, after that test_c_qtwidget target was built (in order to build all
> necessary prerequisites) I could replicate the above segfault with
>
> software@merlin> examples/c/x14c -dev qtwidget
> Demo of multiple output streams via the qtwidget driver.
> Running with the second stream as slave to the first.
>
> Segmentation fault
>
> AND
>
> for a *fresh* configuration and build with
>
> software@merlin> printenv |grep FLAG
> FFLAGS=-g
> CXXFLAGS=-g
> CFLAGS=-g
>
> I confirmed the segfault (with these quite different compiler options)
> and also obtained the attached valgrind result determined
> from (after a build of the test_c_qtwidget target to build all
> prerequisites)
>
> valgrind --num-callers=400 examples/c/x14c -dev qtwidget 2>| valgrind.out
>
> Exactly the same test for the version of PLplot before your change
> produces the following results (if I keep hitting the enter key when
> the cursor was on the left-hand plot to proceed through the entire
> example successfully):
>
> software@merlin> valgrind --num-callers=400 examples/c/x14c -dev qtwidget
> ==9772== Memcheck, a memory error detector
> ==9772== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==9772== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
> ==9772== Command: examples/c/x14c -dev qtwidget
> ==9772==
> Demo of multiple output streams via the qtwidget driver.
> Running with the second stream as slave to the first.
>
> ==9772==
> ==9772== HEAP SUMMARY:
> ==9772==     in use at exit: 526,787 bytes in 6,853 blocks
> ==9772==   total heap usage: 216,516 allocs, 209,663 frees, 39,317,429
> bytes allocated
> ==9772==
> ==9772== LEAK SUMMARY:
> ==9772==    definitely lost: 6,888 bytes in 40 blocks
> ==9772==    indirectly lost: 5,109 bytes in 125 blocks
> ==9772==      possibly lost: 2,112 bytes in 6 blocks
> ==9772==    still reachable: 512,678 bytes in 6,682 blocks
> ==9772==         suppressed: 0 bytes in 0 blocks
> ==9772== Rerun with --leak-check=full to see details of leaked memory
> ==9772==
> ==9772== For counts of detected and suppressed errors, rerun with: -v
> ==9772== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
>
> So aside from some memory leaks (likely due to a Qt5-5.11.3 issue
> rather than a PLplot issue) the 14th standard example runs perfectly
> under valgrind before your patch.
>
> I hope the attached detailed valgrind results for the segfault case
> with your patch will help you to figure out how your patch needs to be
> changed to fix this regression for the special needs of our 14th
> standard example.
>
> Also, for your next version of the patch will you please try all the
> relevant
> test targets and then report those testing results in a "Tested by":
> stanza similar to the following?
>
> Tested by: António R. Tomé <ar...@gm...> on the <specify your
> platform details, e.g., Linux distribution name and version but also
> including your qt5.15.2 version> platform by configuring PLplot,
> building the test_pyqt5_example, test_qt_example, test_memqt_example,
> and test_c_qtwidget targets with no configuration, build, run-time, or
> GUI issues.
>
> Because our two Qt5 platforms are so different it is essential to test on
> both platforms.  So I plan to do these tests also and append my own
> "Tested by:" stanza to yours as
> follows (once those tests all succeed):
>
> Tested by: Alan W. Irwin <ai...@us...> on Linux
> (Debian Buster = Stable with qt5.11.3) by configuring PLplot, building
> the test_pyqt5_example, test_qt_example, test_memqt_example, and
> test_c_qtwidget targets with no configuration, build, run-time, or GUI
> issues.
>
> By the way, what I mean by no GUI issues above is that for the test targets
> that allow you to interact with a GUI (i.e., everything but
> test_c_qtwidget which because of the -np option for that test just
> runs through a critical subset of our standard examples automatically
> with no user intervention), you have exercised all possible actions
> (including exiting from the GUI which is always critical) to make sure
> all those GUI actions work).
>
> Also, if you have any trouble getting test_pyqt5_example to configure,
> remember you have to have the latest python3 and sip development
> packages installed for your platform.  Note I have included that
> possibility (if you have time to test it) because it already generates
> deprecated warnings here on my older platform, and it would be good to get
> our pyqt5 example future-proofed as well.
>
> For all those here wondering about the hiatus (for the last year now)
> in my PLplot development work, the reason for that is I am spending
> virtually 100 % of my current development time on FreeEOS with the
> goal of getting out a critical release for that software soon which
> will include all my work on modernizing that Fortran code (e.g., by
> using Fortran 2008 best practices) and by comprehensively testing that
> code's results.  So all that I have had time for from the PLplot
> perspective is to monitor other's PLplot development activities and
> help out where I can (as in the present segfault report to António).
>
> Of course, after that FreeEOS release is completed, I do hope to
> return to a more active PLplot development role starting with a fix to
> a pllegend issue (incorrect vertical line spacing when there are
> subscripts or superscripts in the legend text) that has been exposed
> by many of the FreeEOS research plots I have been producing using
> PLplot.  Of course, if you look back at the PLplot history, I first
> got active in PLplot development because of PLplot issues turned up by
> FreeEOS.  So it looks like my strong motivation for helping to develop
> PLplot will be continuing just like always!  :-)
>
> 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
> __________________________



-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

Re: [Plplot-devel] What are the development priorities for the csironn library?

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

On 2021-07-04 01:16-0700 Alan W. Irwin wrote:

> [...* It "would be nice"] for libcsironn to change its dependence on libqhull to a
>  dependence on libqhull_r.

DONE (thanks mostly to Stefan).  See <https://sourceforge.net/p/plplot/plplot/ci/b6023bf465e9b024d3b161ba52ef01a1aff3e901/> for the details.

> * 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 would be happy to see patches or pushes implementing these development topics.  :-)

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
__________________________

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

[Rafael L. <ra...@la...>]

* Alan W. Irwin <Ala...@gm...> [2021-07-04 03:38]:

> A message on this thread from Atri Bhattacharya 
> <bad...@op...> bounced (presumably because he used a 
> non-subscription return address).  But as list administrator I saw 
> that bounced message which turned out to be of immediate interest.  So 
> I am reposting it here without asking Atri to resubmit with 
> subscription address == return address.
>
> Atri said: 
> _________________________________________
>
> For openSUSE's plplot package, we have a patch to build against 
> libqhull_r, kindly contributed by Stefan. Here is the bug reference 
> which has the patch as an attachment: 
> <https://sourceforge.net/p/plplot/bugs/196/>. Would be great to get 
> this checked into plplot upstream.
>
> Hope that helps. 
> _________________________________________
>
> Hi Atri:
>
> I don't know how I missed that PLplot bug report with a patch that 
> from its title likely implements the csironn library 
> development topic that I just discussed on this thread!
>
> Anyhow, thanks for drawing this patch to my attention, and I hope 
> I have time to take a close look at in in the coming week or so.

JFYI, I applied the patch indicated by Atri to the Debian package and 
released version 5.15.0+dfsg-21 to the experimental distribution : 
https://tracker.debian.org/news/1243929/accepted-plplot-5150dfsg-21-source-into-experimental/

Best,

Rafael

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

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

Hi Timo:

As a Debian user, I agreed with what you said all the way down the
line concerning how Debian is dealing with this transition from
libqhull to reentrant libqhull_r.

Furthermore, it looks like there is already a patch submitted to
upstream PLplot to solve this issue which I will be looking at fairly
soon.  If comprehensive testing works for that patch I will accept it
upstream, and in that case and assuming Rafael's tests work as well, I
assume Rafael will also accept that patch downstream in order to close
your bug#990397 against PLplot as fixed.

Best wishes for many more such quick fixes for this issue,

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
__________________________

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

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

A message on this thread from Atri Bhattacharya
<bad...@op...> bounced (presumably because he used a
non-subscription return address).  But as list administrator I saw
that bounced message which turned out to be of immediate interest.  So
I am reposting it here without asking Atri to resubmit with
subscription address == return address.

Atri said:
_________________________________________

For openSUSE's plplot package, we have a patch to build against
libqhull_r, kindly contributed by Stefan. Here is the bug reference
which has the patch as an attachment:
<https://sourceforge.net/p/plplot/bugs/196/>. Would be great to get
this checked into plplot upstream.

Hope that helps.
_________________________________________

Hi Atri:

I don't know how I missed that PLplot bug report with a patch that
from its title likely implements the csironn library
development topic that I just discussed on this thread!

Anyhow, thanks for drawing this patch to my attention, and I hope
I have time to take a close look at in in the coming week or so.

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
__________________________

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

Re: [Plplot-devel] Bug#990397: depends on deprecated qhull library

[Rafael L. <ra...@la...>]

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.

Best,

Rafael Laboissière

  [1] https://bugs.debian.org/990397
  [2] http://www.qhull.org/html/qh-code.htm#convert

* Timo Röhling <roe...@de...> [2021-06-28 10:47]:

> Package: src:plplot
> Version: 5.15.0+dfsg-19
> Severity: normal
> X-Debbugs-Cc: roe...@de...
>
> -----BEGIN PGP SIGNED MESSAGE----- 
> Hash: SHA512
>
> Dear Maintainer,
>
> 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.
>
> This bug is not release-critical for Bullseye, but you can expect the 
> severity to raise eventually when Qhull stops shipping with the 
> non-reentrant library.
>
> You can verify that your binary package links against the correct 
> library if it no longer depends on libqhull8.0 but libqhull-r8.0 
> instead.
>
> Cheers 
> Timo
>
>
> -----BEGIN PGP SIGNATURE-----
>
> iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmDZjJsACgkQ+C8H+466 
> LVn2yAv9EuiBJ5k+DcdH6K4sTxs6j/TFh4t8FrZRSjXV58k3yjTekmMIf9yrweVf 
> dEybLCuNAo+RHSLZLHpQevwarn5hu85ArQMrfbB59sS4ssQkvqg7YZYv7DHfRqdm 
> jC53VP2SWGtscBQfQK/MHFa2y6WK41jdt0dljdEAXzOXE11FFfr5/hZA/UCZ7GSl 
> mwfddlxespDvsGSs6rdi6eBYifJ6Ur7xt76V9eoNzacrvAZSy27w5EFyaOp8EasV 
> xxTTm7EfCi+nnw8sKy4e9l6qCVW+wKkuejbKPamCCUlxmXlAGPEw9+kelfQoITbz 
> Hno2/QIhGwXv0anc+TeJHbA7YtRuPqEZSVxFJ5fO/MUJcMojoqpVU9T0hdVndv3j 
> kVSwZdc357KaytihxLJogO/MjEGB7U5SyqThxAzXdTeuhdZ2eVYC33a5Ogc6jVXi 
> tcClKOSL8O3ACnWiGL1P+BC2nV5gFIVvHmWPUY4qTURVmTq9ycIt5jhDvbSTeK2F 
> stkABfQl 
> =GRsx 
> -----END PGP SIGNATURE-----
>
>

Re: [Plplot-devel] Port to SIP5

[Rafael L. <ra...@la...>]

Dear PLplot developers,

This is a followup for my message below, sent to plplot-devel in November 
2020.

I uploaded the version 5.15.0+dfsg-20 of the PLplot packages to the 
Debian experimental distribution [1]. This version contains a patch for 
allowing the compilation against SIP 5 and 6. The patch was provided by 
Dmitry Shachnev [2]. Dmitry told us that he posted the patch in the 
present mailing list in December 2020, but his message did not go 
through, apparently.

Best,

Rafael Laboissière

  [1] https://lists.debian.org/debian-experimental-changes/2021/06/msg00433.html
  [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964127#51

* Rafael Laboissière via Plplot-devel <plp...@li...> [2020-11-30 17:54]:

> Dear PLplot developers,
>
> [For more context regarding the request below, see https://bugs.debian.org/964127]
>
> Please, consider porting the Python-Qt build system to use SIP5 
> instead of SIP4.
>
> A completely new build system was introduced in SIP v5:
>
>    https://www.riverbankcomputing.com/static/Docs/sip/examples.html
>
> Here are two examples of projects that Dmitry Shachnev converted to 
> the new build system:
>
>    https://github.com/frescobaldi/python-poppler-qt5/pull/41
>    https://github.com/GauiStori/PyQt-Qwt/pull/14
>
> Best regards,
>
> Rafael Laboissière
>
>
> _______________________________________________ 
> Plplot-devel mailing list 
> Plp...@li... 
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] plplot qt driver deprecated functions

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

Hi António:

On 2021-06-05 20:53+0100 António Rodrigues Tomé wrote:

> Hi Alan,
>
> I hope you are well and managed to be free of the virus.

So far so good.  And I hope that is true for everyone on this list
and their close families!

> new versions of QT5 produce some warnings about the use of  deprecated
> functions in the driver.
> The new qt6 will remove most of the obsolete functions,  unless one uses an
> additional back compatibility module. Namely the  QLinkedList will no
> longer be supported in qt6.
>
> So I send you a patch where I replace all the functions that (my qt5.15.2
> versions) warns about.
> I think that everything will work fine even with older qt versions,
>
> This was needed mainly because for qt6 it will be necessary.

Thanks, António for making this effort to future-proof the PLplot qt component.
You are very close to something I would be happy to push, but there is
a regression in results that you need to fix in your patch.

Here are the details concerning that regression.

Your patch builds fine here on my Debian Buster = Stable with qt5.11.3
platform and gives good run-time test results when I build the
test_pyqt5_example (other than some deprecation warnings that eventually
do need to be fixed), test_qt_example, and test_memqt_example targets

However, it introduces a segfault regression when I attempt to build
the test_c_qtwidget target.

The previous (before your patch was applied) result for that target showed no warnings or errors for that target.  And there continue to be no warnings with this target when your patch is applied.  However,
here is the error result for that case:
Generate C results for qtwidget interactive device
Testing subset of C examples for device qtwidget
x01c
x04c
x08c
x16c
x24c
x30c
x14c
/home/software/plplot/HEAD/build_dir/plplot_test/test_c_interactive.sh: line 47:  3746 Segmentation fault      $DEBUG_CMD "$cdir"/x${index}${lang} -dev $device $NP_OPTION 2> c_interactive_${device}_test.error >| "${OUTPUT_DIR}"/x${index}${lang}_${device}.txt
make[3]: *** [examples/CMakeFiles/test_c_qtwidget.dir/build.make:58: examples/CMakeFiles/test_c_qtwidget] Error 1
make[2]: *** [CMakeFiles/Makefile2:6635: examples/CMakeFiles/test_c_qtwidget.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:6642: examples/CMakeFiles/test_c_qtwidget.dir/rule] Error 2
make: *** [Makefile:2108: test_c_qtwidget] Error 2

So it looks like all examples other than x14c work correctly with your patch, but
x14c (which has quite special needs) apparently exposes an issue with your patch.

In fact, after that test_c_qtwidget target was built (in order to build all
necessary prerequisites) I could replicate the above segfault with

software@merlin> examples/c/x14c -dev qtwidget
Demo of multiple output streams via the qtwidget driver.
Running with the second stream as slave to the first.

Segmentation fault

AND

for a *fresh* configuration and build with

software@merlin> printenv |grep FLAG
FFLAGS=-g
CXXFLAGS=-g
CFLAGS=-g

I confirmed the segfault (with these quite different compiler options)
and also obtained the attached valgrind result determined
from (after a build of the test_c_qtwidget target to build all prerequisites)

valgrind --num-callers=400 examples/c/x14c -dev qtwidget 2>| valgrind.out

Exactly the same test for the version of PLplot before your change
produces the following results (if I keep hitting the enter key when
the cursor was on the left-hand plot to proceed through the entire
example successfully):

software@merlin> valgrind --num-callers=400 examples/c/x14c -dev qtwidget
==9772== Memcheck, a memory error detector
==9772== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9772== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==9772== Command: examples/c/x14c -dev qtwidget
==9772== 
Demo of multiple output streams via the qtwidget driver.
Running with the second stream as slave to the first.

==9772== 
==9772== HEAP SUMMARY:
==9772==     in use at exit: 526,787 bytes in 6,853 blocks
==9772==   total heap usage: 216,516 allocs, 209,663 frees, 39,317,429 bytes allocated
==9772== 
==9772== LEAK SUMMARY:
==9772==    definitely lost: 6,888 bytes in 40 blocks
==9772==    indirectly lost: 5,109 bytes in 125 blocks
==9772==      possibly lost: 2,112 bytes in 6 blocks
==9772==    still reachable: 512,678 bytes in 6,682 blocks
==9772==         suppressed: 0 bytes in 0 blocks
==9772== Rerun with --leak-check=full to see details of leaked memory
==9772== 
==9772== For counts of detected and suppressed errors, rerun with: -v
==9772== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

So aside from some memory leaks (likely due to a Qt5-5.11.3 issue
rather than a PLplot issue) the 14th standard example runs perfectly
under valgrind before your patch.

I hope the attached detailed valgrind results for the segfault case
with your patch will help you to figure out how your patch needs to be
changed to fix this regression for the special needs of our 14th
standard example.

Also, for your next version of the patch will you please try all the relevant
test targets and then report those testing results in a "Tested by":
stanza similar to the following?

Tested by: António R. Tomé <ar...@gm...> on the <specify your
platform details, e.g., Linux distribution name and version but also
including your qt5.15.2 version> platform by configuring PLplot,
building the test_pyqt5_example, test_qt_example, test_memqt_example,
and test_c_qtwidget targets with no configuration, build, run-time, or
GUI issues.

Because our two Qt5 platforms are so different it is essential to test on
both platforms.  So I plan to do these tests also and append my own "Tested by:" stanza to yours as
follows (once those tests all succeed):

Tested by: Alan W. Irwin <ai...@us...> on Linux
(Debian Buster = Stable with qt5.11.3) by configuring PLplot, building
the test_pyqt5_example, test_qt_example, test_memqt_example, and
test_c_qtwidget targets with no configuration, build, run-time, or GUI
issues.

By the way, what I mean by no GUI issues above is that for the test targets
that allow you to interact with a GUI (i.e., everything but
test_c_qtwidget which because of the -np option for that test just
runs through a critical subset of our standard examples automatically
with no user intervention), you have exercised all possible actions
(including exiting from the GUI which is always critical) to make sure
all those GUI actions work).

Also, if you have any trouble getting test_pyqt5_example to configure,
remember you have to have the latest python3 and sip development
packages installed for your platform.  Note I have included that
possibility (if you have time to test it) because it already generates
deprecated warnings here on my older platform, and it would be good to get
our pyqt5 example future-proofed as well.

For all those here wondering about the hiatus (for the last year now)
in my PLplot development work, the reason for that is I am spending
virtually 100 % of my current development time on FreeEOS with the
goal of getting out a critical release for that software soon which
will include all my work on modernizing that Fortran code (e.g., by
using Fortran 2008 best practices) and by comprehensively testing that
code's results.  So all that I have had time for from the PLplot
perspective is to monitor other's PLplot development activities and
help out where I can (as in the present segfault report to António).

Of course, after that FreeEOS release is completed, I do hope to
return to a more active PLplot development role starting with a fix to
a pllegend issue (incorrect vertical line spacing when there are
subscripts or superscripts in the legend text) that has been exposed
by many of the FreeEOS research plots I have been producing using
PLplot.  Of course, if you look back at the PLplot history, I first
got active in PLplot development because of PLplot issues turned up by
FreeEOS.  So it looks like my strong motivation for helping to develop
PLplot will be continuing just like always!  :-)

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
__________________________

[Plplot-devel] CSA NaNs and Visual Studio 2019

[Phil R. <p.d...@gm...>]

I've just updated to using VS2019 and found a problem with csa/nan.h

Basically this file calls ymath.h when compiled on VS. According to this
forum post PLplot / Discussion / Open Discussion: Error compiling in
MSVC2019 (sourceforge.net)
<https://sourceforge.net/p/plplot/discussion/8606/thread/318f366398/?limit=25>
it's
due to VS mixing C and C++. I've never really heard of ymath.h, but a quick
google seems to hint that it is part of Microsoft's implementation of the
C++ Standard Template Library - so maybe it should never have been called
from C code in the first place.

The problem itself appears in plgridd.c where csa/nan.h is #included even
when we are not building with csa.

My feel is that plgridd.c should simply not use csa to get its NAN
implementation. So I'm about to commit a fix that defines PLFLT_NAN along
with PLFLT_HUGE_VAL, etc in plplot.h.

I'm posting to ask what (if anything) we should do with CSA?

>From what I understand CSA is external to PLPlot and was just pulled into
the repo some time ago. It is not code written by PLPlot devs. CSA is now
available on github at cameronbracken/csa
<https://github.com/cameronbracken/csa>, although it hasn't been updated
for around 9 years. Arjen - if you read this, it looks like it was you that
added the ymath.h code.

I've never used csa, so for now I won't change anything within the CSA
code. But I guess we can either revert to the non ymath.h code or do
something entirely different.

For now, my changes will mean when CSA is off PLPlot will still build.

[Plplot-devel] swig (and thus plplot) support for octave 6.1

[Orion P. <or...@nw...>]

PLplot folks -

I'm looking to update the octave package in Fedora to version 6.1. 
However swig 4.0.2 fails to build against it.  According to swig 
upstream here: https://github.com/swig/swig/issues/1893 the former 
swig-octave maintainer has stepped away, so support will have to come 
from the users of swig-octave.  Anyone here have some time and interest?

Thanks,

   Orion

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

[Plplot-devel] Show FreeType fonts founded at configuration time

[Rafael L. <ra...@la...>]

Dear PLplot developers,

Please, find attached to this message a patch that is being currently 
applied to the Debian package for PLplot.  We got bitten by an 
auto-builder that did not have the fonts-freetype-ttf package installed 
and failed to build the libplplot17 package.  The proposed patch makes 
it easier to diagnose the problem.

Notice that I also changed the second check from "Symbol" into "Mono", 
since both PL_FREETYPE_SANS and PL_FREETYPE_SYMBOL point to FreeSans.ttf.

Best,

Rafael Laboissière

Re: [Plplot-devel] Port to SIP5?

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

On 2020-12-03 19:28+0300 Dmitry Shachnev wrote:

> H Alan!
>
> On Tue, Dec 01, 2020 at 01:34:50PM -0800, Alan W. Irwin wrote:
>> Hi Dmitry:
>>
>> From the PLplot bug discussion above, it appears Rafael was unable to
>> modify PLplot to use sip5 with two different methods which
>> are (1) to generalize our
>> present method for generating our pyqt5 binding so that method works for both sip4 and sip5 or
>> (2) adopting the completely new approach of using a sip5-based build system to generate our
>> pyqt5 binding.
>> I likely will also not be able to convert PLplot to use sip5
>> because my sip
>> expertise is not particularly good.  Also note we must
>> continue to support sip4 because many latest versions of distros
>> (including (!) Debian Unstable, see <https://packages.debian.org/sid/sip-dev>)
>> support that version of sip.  If you do provide a patch for this
>> issue, I would *far* prefer you to use method 1 that was described above.
>
> Let me try to convince you of the opposite.
>
> - SIP 5 was released in October 2019. It's not that much new.
> - SIP 5 is what users when they are installing PyQt5 from pypi.org (using pip
>  tool). So most people who are not relying on distros' package manager will
>  get it.
> - The upstream SIP developer writes [1]:
>  > SIP v4 has been deprecated for more than a year. *Nobody* should still be
>  > using it.
> - I am SIP maintainer in Debian. At the moment we support both 4 and 5.
>  The reason why I filed these bugs is that I *do* want to abandon SIP 4.
>  This won't happen in time for Debian 11 (Bullseye), but it will definitely
>  happen in Debian 12 (Bookworm). The same applies to Ubuntu, which gets SIP
>  synced from Debian.
>
> So at this point there are few reasons to care about SIP 4. Then, upstream
> is going to release SIP 6 soon (maybe in a few months). It will be *not*
> co-installable with SIP 5, so distros will probably have to ship either
> only SIP 6, or for some time SIP 4 and SIP 6 (but not SIP 5).
>
> If plplot keeps using the old sip/sip5 tool (approach 1), then it will work
> with SIP 4 and SIP 5, but will need changes when porting to SIP 6.
>
> If plplot starts using the new buildsystem (approach 2), then it will work
> with SIP 5 and SIP 6 without much changes.
>
> So I think approach 2 makes more sense than approach 1.

Hi Dmitry:

Thanks for sharing your knowledge of sip development and version status which I
was sorely lacking.  And armed with that knowledge the points you have made with regard to
moving to approach 2 seem pretty good to me.  Therefore,
if/when you send me a patch implementing approach 2, I would
be willing to modify it to keep the present pure sip4 approach as a
(deprecated) alternative until most modern versions of distros support
sip5 (if that is going to be an issue).

> I am not promising anything, but when I have time I may look at building
> plplot with SIP 5, regardless on what approach we decide on. This codebase
> is unknown to me, so it may take a while.

To help encourage that effort, here is what I would recommend for your first steps.

# Use the latest git version of PLplot following the directions at
# <https://sourceforge.net/p/plplot/plplot/ci/master/tree/>
git clone git://git.code.sf.net/p/plplot/plplot plplot.git

# Start configuration with a clean build directory that is located
# relative to the plplot.git directory.
cd plplot.git
mkdir ../build_dir
cd ../build_dir

# Configure a minimalist PLplot that still enables the pyqt5 binding
cmake -DDEFAULT_NO_BINDINGS=ON -DDEFAULT_NO_DEVICES=ON -DENABLE_python=ON -DENABLE_qt=ON -DENABLE_pyqt5=ON -DPLD_extqt=ON -DBUILD_TEST=ON ../plplot.git >& cmake.out)

# Test that configuration by building that binding and running an example that uses it.
make test_pyqt5_example

Note we currently also support Qt4 and pyqt4, but those are about to be removed so ignore that
part of our build system.

The files and directories within our source tree that are relevant to
our pyqt5 binding and the example that tests it are
cmake/modules/qt.cmake, bindings/qt_gui/pyqt5, examples, and
examples/python.

Good luck, and let me know how the above simple steps work for you to test
our present sip4 pyqt5 binding.

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
__________________________

Re: [Plplot-devel] Port to SIP5?

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

On 2020-11-30 17:54+0100 Rafael Laboissière via Plplot-devel wrote:

> Dear PLplot developers,
>
> [For more context regarding the request below, see 
> https://bugs.debian.org/964127]
>
> Please, consider porting the Python-Qt build system to use SIP5 instead of 
> SIP4.

Hi Dmitry:

>From the PLplot bug discussion above, it appears Rafael was unable to
modify PLplot to use sip5 with two different methods which
are (1) to generalize our
present method for generating our pyqt5 binding so that method works for both sip4 and sip5 or
(2) adopting the completely new approach of using a sip5-based build system to generate our
pyqt5 binding.
I likely will also not be able to convert PLplot to use sip5
because my sip
expertise is not particularly good.  Also note we must
continue to support sip4 because many latest versions of distros
(including (!) Debian Unstable, see <https://packages.debian.org/sid/sip-dev>)
support that version of sip.  If you do provide a patch for this
issue, I would *far* prefer you to use method 1 that was described above.

Of course, it is normally a good idea for PLplot to support new
versions of external software such as sip5 so long as support for
older versions that are still being used by most distros (e.g., sip4)
is not compromised.  However, unless you can find an easy way to
support both sip4 and sip5 (e.g., with method 1 above), we should
likely just stick with sip4 for quite some time to come.  After all,
sip4 is a mature and stable product that upstream sip
(riverbankcomputing) has continued to support this year via minor
feature and bug-fix releases, and it appears that Debian also has no
immediate plans to abandon sip4.

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
__________________________

[Plplot-devel] Port to SIP5

[Rafael L. <ra...@la...>]

Dear PLplot developers,

[For more context regarding the request below, see https://bugs.debian.org/964127]

Please, consider porting the Python-Qt build system to use SIP5 instead 
of SIP4.

A completely new build system was introduced in SIP v5:

     https://www.riverbankcomputing.com/static/Docs/sip/examples.html

Here are two examples of projects that Dmitry Shachnev converted to the 
new build system:

     https://github.com/frescobaldi/python-poppler-qt5/pull/41
     https://github.com/GauiStori/PyQt-Qwt/pull/14

Best regards,

Rafael Laboissière

Re: [Plplot-devel] Set the libplplotada_SOVERSION on the CMake command line

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

On 2020-11-17 03:25+0100 Rafael Laboissière wrote:

> I think it is a good idea to cache both *_SOVERSION and *_VERSION variants. 
> Even though we only need SOVERSION for now in Debian, this move will probably 
> cause no harm for the upstream development.

I have implemented this change, see my recent push of commit 28ffa1e84.

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
__________________________

Re: [Plplot-devel] Set the libplplotada_SOVERSION on the CMake command line

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

On 2020-11-15 07:36+0100 Rafael Laboissière wrote:

> Dear PLplot developers,
>
> Please find here attached a patch developed by Nicolas Boulenguez that we are 
> currently applying to the Debian package.  The patches regards the setting of 
> the libplplotada's shared object version.
>
> Here is the description of the patch, as written by Nicolas:
>
> “The SOVersion sometimes needs to evolve independently of the API (and thus, 
> is unrelated with semantic versioning), or even without knowledge by the 
> upstream author.  For example, a rebuild of the library with a different 
> compiler may break its ABI.
>
> This patch provides redistributors like Debian an easy way to set the 
> libplplotada_SOVERSION on the CMake command line, without patching CMake 
> files.
>
> This patch only affects the Ada library, but the suggestion applies to any 
> language allowing dynamic linking.
>
> As far as I know, the part added by _VERSION and the related symbolic links 
> are a complexity added by CMake (probably in order to follow the GNU libtool 
> conventions), but the linker only cares about the SOVERSION.”
>
> Please consider applying this patch to PLplot.

To Nicholas and Rafael:

I would be happy to cache *_SOVERSION variables for each of our
libraries to help packagers who are up against some ABI change for
their distribution.  However, packagers also would need to update the
*_VERSION variables as well if their distribution mandated some rule
for those such as semantic versioning (which is the set of library
SOVERSION/VERSION rules that libtool has adopted).  For example, if
*_VERSION remains uncached as now, then the VERSION result will
combine the packager's SOVERSION with a default suffix that is
consistent with the semantic versioning rules (e.g., the ".2.0" suffix
in ${plplotfortran_SOVERSION}.2.0) for the default SOVERSION supplied
by PLplot but *not* the SOVERSION supplied by the packager.  So I am
strongly leaning toward caching both *_SOVERSION and *_VERSION
variants of all library version variables.

@Nicholas:
Thanks for (indirectly) bringing this issue to our upstream attention.

@Rafael:

Historically (back in our autotools days) you were the PLplot guru on
library soversion/version issues.  So I would appreciate a comment
from you about whether you see any downside to my idea above to cache
both forms of library version variables to allow packagers to override
both.

@both:

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
__________________________

[Plplot-devel] Set the libplplotada_SOVERSION on the CMake command line

[Rafael L. <ra...@la...>]

Dear PLplot developers,

Please find here attached a patch developed by Nicolas Boulenguez that we 
are currently applying to the Debian package.  The patches regards the 
setting of the libplplotada's shared object version.

Here is the description of the patch, as written by Nicolas:

“The SOVersion sometimes needs to evolve independently of the API (and 
thus, is unrelated with semantic versioning), or even without 
knowledge by the upstream author.  For example, a rebuild of the 
library with a different compiler may break its ABI.

This patch provides redistributors like Debian an easy way to set the 
libplplotada_SOVERSION on the CMake command line, without patching 
CMake files.

This patch only affects the Ada library, but the suggestion applies 
to any language allowing dynamic linking.

As far as I know, the part added by _VERSION and the related symbolic 
links are a complexity added by CMake (probably in order to follow 
the GNU libtool conventions), but the linker only cares about the 
SOVERSION.”

Please consider applying this patch to PLplot.

Best regards,

Rafael Laboissière

Re: [Plplot-devel] Fix for Debian Sid sip file find problem

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

On 2020-10-06 19:21+0200 Rafael Laboissière wrote:

> Hello Alan and Ole,
>
> Commit 61e41ac6a from Alan worked fine for me.  I uploaded version 
> 5.15.0+dfsg-15 of plplot to Debian unstable: 
> https://tracker.debian.org/news/1181045/accepted-plplot-5150dfsg-15-source-into-unstable/
>
> The package built correctly on all architectures: 
> https://buildd.debian.org/status/package.php?p=plplot

Thanks, Rafael, for that test of my commit on Debian Sid, and the good news
concerning those results.

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
__________________________

[Plplot-devel] Fix for Debian Sid sip file find problem

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

To Ole and Rafael:

@Ole:

Rafael has contacted me off list concerning the sip file find problem
for Debian Sid that he feels is the cause of
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971215>.
Accordingly I have solved that find problem as part of a
larger rationalization of the CMake logic to find needed sip files
(see commit 61e41ac6a).  I am virtually positive this fix will work on
Debian Sid because I checked the file list there was consistent with
the PATHS and PATH_SUFFIXES I now use to help find the relevant sip
files.  However, I don't currently have convenient access to Debian
Sid so I could only test this commit introduced no regressions on
Debian Buster.

@Rafael:
Could you try that commit to confirm it works the same as your own
hackish patch to solve the issue?  Please report back those test
results to both Ole and me.

@Ole:
Please see whether commit 61e41ac6a solves Debian bug 971215.

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
__________________________

Re: [Plplot-devel] plplot build fails with Qt 5.15.1

[Orion P. <or...@nw...>]

On 9/13/20 1:42 PM, António Rodrigues Tomé wrote:
> hi orion
> this was solved in the  commit [2aa2e1]
> so you should use the development version.
> download it using
> git clone git://git.code.sf.net/p/plplot/plplot 
> <http://git.code.sf.net/p/plplot/plplot> plplot.git
> 
> cheers

António -

   Thanks for the reference.  That commit fixes the build.

Orion

> 
> On Sun, Sep 13, 2020 at 12:58 AM Orion Poplawski <or...@nw... 
> <mailto:or...@nw...>> wrote:
> 
>     Fedora rawhide just updated from Qt 5.14.2 to 5.15.1 and now the plplot
>     build fails with:
> 
>     [ 63%] Built target xstandard08a
>     /builddir/build/BUILD/plplot-5.15.0/bindings/qt_gui/plqt.cpp: In member
>     function 'void QtPLDriver::drawTextInPicture(QPainter*, const
>     QString&)':
>     /builddir/build/BUILD/plplot-5.15.0/bindings/qt_gui/plqt.cpp:222:22:
>     error: aggregate 'QPainterPath path' has incomplete type and cannot be
>     defined
>         222 |         QPainterPath path;
>             |                      ^~~~
> 
>     A quick google search of this error indicates that it has hit a number
>     of projects and there are some example fixes out there, e.g.:
> 
>     https://github.com/Nheko-Reborn/nheko/issues/214
> 
>     HTH,
> 
>         Orion
> 
>     -- 
>     Orion Poplawski
>     Manager of NWRA Technical Systems          720-772-5637
>     NWRA, Boulder/CoRA Office             FAX: 303-415-9702
>     3380 Mitchell Lane or...@nw... <mailto:or...@nw...>
>     Boulder, CO 80301 https://www.nwra.com/
> 
>     _______________________________________________
>     Plplot-devel mailing list
>     Plp...@li...
>     <mailto:Plp...@li...>
>     https://lists.sourceforge.net/lists/listinfo/plplot-devel
> 
> 
> 
> -- 
> 
> António Rodrigues Tomé
> Universidade da Beira Interior
> Instituto D. Luís (lab associado)
> email address:
> ar...@gm... <mailto:ar...@gm...>
> ar...@ub... <mailto:ar...@ub...>
> http://www.researcherid.com/rid/A-5681-2013
> 


-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

Re: [Plplot-devel] plplot build fails with Qt 5.15.1

[António R. T. <ar...@gm...>]

hi orion
this was solved in the  commit [2aa2e1]
so you should use the development version.
download it using
git clone git://git.code.sf.net/p/plplot/plplot plplot.git

cheers


On Sun, Sep 13, 2020 at 12:58 AM Orion Poplawski <or...@nw...> wrote:

> Fedora rawhide just updated from Qt 5.14.2 to 5.15.1 and now the plplot
> build fails with:
>
> [ 63%] Built target xstandard08a
> /builddir/build/BUILD/plplot-5.15.0/bindings/qt_gui/plqt.cpp: In member
> function 'void QtPLDriver::drawTextInPicture(QPainter*, const QString&)':
> /builddir/build/BUILD/plplot-5.15.0/bindings/qt_gui/plqt.cpp:222:22:
> error: aggregate 'QPainterPath path' has incomplete type and cannot be
> defined
>    222 |         QPainterPath path;
>        |                      ^~~~
>
> A quick google search of this error indicates that it has hit a number
> of projects and there are some example fixes out there, e.g.:
>
> https://github.com/Nheko-Reborn/nheko/issues/214
>
> HTH,
>
>    Orion
>
> --
> Orion Poplawski
> Manager of NWRA Technical Systems          720-772-5637
> NWRA, Boulder/CoRA Office             FAX: 303-415-9702
> 3380 Mitchell Lane                       or...@nw...
> Boulder, CO 80301                 https://www.nwra.com/
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>


-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

[Plplot-devel] plplot build fails with Qt 5.15.1

[Orion P. <or...@nw...>]

Fedora rawhide just updated from Qt 5.14.2 to 5.15.1 and now the plplot 
build fails with:

[ 63%] Built target xstandard08a
/builddir/build/BUILD/plplot-5.15.0/bindings/qt_gui/plqt.cpp: In member 
function 'void QtPLDriver::drawTextInPicture(QPainter*, const QString&)':
/builddir/build/BUILD/plplot-5.15.0/bindings/qt_gui/plqt.cpp:222:22: 
error: aggregate 'QPainterPath path' has incomplete type and cannot be 
defined
   222 |         QPainterPath path;
       |                      ^~~~

A quick google search of this error indicates that it has hit a number 
of projects and there are some example fixes out there, e.g.:

https://github.com/Nheko-Reborn/nheko/issues/214

HTH,

   Orion

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/