plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Missing pyqtconfig module issue should now be fixed

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

On 2017-09-06 06:47-0000 Arjen Markus wrote:

> [A]fter a bright moment and "pkgfile --help", I ran "pkgfile -v QtCoremod.sip" and got instead the more useful output below:
>
> mingw32/mingw-w64-i686-python2-pyqt4 4.11.4-2            /mingw32/share/sip/Py2-Qt4/QtCore/QtCoremod.sip
>
> mingw32/mingw-w64-i686-python2-pyqt5 5.8-1                 /mingw32/share/sip/Py2-Qt5/QtCore/QtCoremod.sip
>
> mingw32/mingw-w64-i686-python3-pyqt4 4.11.4-2              /mingw32/share/sip/PyQt4/QtCore/QtCoremod.sip
>
> mingw32/mingw-w64-i686-python3-pyqt5 5.8-1                 /mingw32/share/sip/PyQt5/QtCore/QtCoremod.sip
>
> mingw64/mingw-w64-x86_64-python2-pyqt4 4.11.4-2       /mingw64/share/sip/Py2-Qt4/QtCore/QtCoremod.sip
>
> mingw64/mingw-w64-x86_64-python2-pyqt5 5.8-1            /mingw64/share/sip/Py2-Qt5/QtCore/QtCoremod.sip
>
> mingw64/mingw-w64-x86_64-python3-pyqt4 4.11.4-2            /mingw64/share/sip/PyQt4/QtCore/QtCoremod.sip
>
> mingw64/mingw-w64-x86_64-python3-pyqt5 5.8-1               /mingw64/share/sip/PyQt5/QtCore/QtCoremod.sip

Thanks, Arjen.  I have now used the above information to update the
NAMES and HINTS used to discover PYQT_SIP_DIR.

Could you try the first stages again of the comprehensive test, but
this time without specifying PYQT_SIP_DIR?  Our build system should
now (commit e3e0f15) automatically be able to determine PYQT_SIP_DIR
on MinGW-w64/MSYS2 without you needing to specify it, and I hope the
above test will confirm that.

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
__________________________

Re: [Plplot-devel] Missing pyqtconfig module issue should now be fixed

[Arjen M. <Arj...@de...>]

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, September 05, 2017 8:07 PM

>
> > To settle this question of the various names for the various
> > combinations of Python2 versus Python3 and Qt4 versus Qt5, on
> > MinGW-w64/MSYS2 could you please give me the complete results for
> >
> > pkgfile QtCoremod.sip
> >
> > ? Once I have that information, I can update our HINTS so our users
> > don't have to specify PYQT_SIP_DIR on this platform regardless of what
> > combination of Python and Qt they try.
>
> Just to clarify, the remaining question above is not noise.  :-) That is, I am still
> interested in those pkgfile results.
>
Here is the output from that command - it does not tell you where the file is/will be installed though:

mingw32/mingw-w64-i686-python2-pyqt4

mingw32/mingw-w64-i686-python2-pyqt5

mingw32/mingw-w64-i686-python3-pyqt4

mingw32/mingw-w64-i686-python3-pyqt5

mingw64/mingw-w64-x86_64-python2-pyqt4

mingw64/mingw-w64-x86_64-python2-pyqt5

mingw64/mingw-w64-x86_64-python3-pyqt4

mingw64/mingw-w64-x86_64-python3-pyqt5

This is really all I got. Oh wait, after a bright moment and "pkgfile --help", I ran "pkgfile -v QtCoremod.sip" and got instead the more useful output below:

mingw32/mingw-w64-i686-python2-pyqt4 4.11.4-2            /mingw32/share/sip/Py2-Qt4/QtCore/QtCoremod.sip

mingw32/mingw-w64-i686-python2-pyqt5 5.8-1                 /mingw32/share/sip/Py2-Qt5/QtCore/QtCoremod.sip

mingw32/mingw-w64-i686-python3-pyqt4 4.11.4-2              /mingw32/share/sip/PyQt4/QtCore/QtCoremod.sip

mingw32/mingw-w64-i686-python3-pyqt5 5.8-1                 /mingw32/share/sip/PyQt5/QtCore/QtCoremod.sip

mingw64/mingw-w64-x86_64-python2-pyqt4 4.11.4-2       /mingw64/share/sip/Py2-Qt4/QtCore/QtCoremod.sip

mingw64/mingw-w64-x86_64-python2-pyqt5 5.8-1            /mingw64/share/sip/Py2-Qt5/QtCore/QtCoremod.sip

mingw64/mingw-w64-x86_64-python3-pyqt4 4.11.4-2            /mingw64/share/sip/PyQt4/QtCore/QtCoremod.sip

mingw64/mingw-w64-x86_64-python3-pyqt5 5.8-1               /mingw64/share/sip/PyQt5/QtCore/QtCoremod.sip



Regards,



Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Missing pyqtconfig module issue should now be fixed

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

On 2017-09-05 10:36-0700 Alan W. Irwin wrote:

> Did you forget to attach that tarball?  Anyhow, it did not make it
> here, and I am still most interested in those results.

Hi Arjen:

Sorry for that noise.  It turns out that tarball did make it here, and
the partial results (including a build of pyqt4) looked good.

> To settle this question of the various names for the various
> combinations of Python2 versus Python3 and Qt4 versus Qt5,
> on MinGW-w64/MSYS2 could you please give me the complete results for
>
> pkgfile QtCoremod.sip
>
> ? Once I have that information, I can update our HINTS so our users
> don't have to specify PYQT_SIP_DIR on this platform regardless
> of what combination of Python and Qt they try.

Just to clarify, the remaining question above is not noise.  :-) That
is, I am still interested in those pkgfile results.

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
__________________________

Re: [Plplot-devel] Missing pyqtconfig module issue should now be fixed

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

Hi Arjen:

On 2017-09-05 13:41-0000 Arjen Markus wrote:
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Sunday, September 03, 2017 4:47 AM
>> To: Arjen Markus; PLplot development list
>> Subject: Missing pyqtconfig module issue should now be fixed
>>
>> Hi Arjen:
>>
>>>
>> I am pretty sure this new pyqt-related CMake logic will work OK for you now on
>> MinGW-w64/MSYS2, but if not, please let me know what PYQT_SIP_DIR value
>> you needed to specify to work around this issue so I can improve those HINTS for
>> the PyQt4 case for finding that directory prefix on MinGW-w64/MSYS2.
>>
>

> Yes, it did work.

I am really happy to see this progress on the issue.

> I accidentally used the wrong MinGW-w64/MSYS2 installation and got
Python 2 instead of 3 and that revealed that for Python 2 the SIP
subdirectory is "Py2-Qt4" instead of "PyQt4", but after persuading
CMake to use that directory, it all worked fine. I had to kill the
comprehensive tests, as they were taking too long, but what I did have
was encouraging (see tar file).

Did you forget to attach that tarball?  Anyhow, it did not make it
here, and I am still most interested in those results.

The information you did state above was extremely helpful.  Greg
Jung's two-year-old patch for this issue (which I never applied)
included the names Py2-Qt4 and Py3-Qt4, but I wasn't sure whether
those were needed for this platform or another one.  But now you have
confirmed the Py2-Qt4 name above, that helps me understand the purpose
of Greg's patch a bit more.

To settle this question of the various names for the various
combinations of Python2 versus Python3 and Qt4 versus Qt5,
on MinGW-w64/MSYS2 could you please give me the complete results for

pkgfile QtCoremod.sip

? Once I have that information, I can update our HINTS so our users
don't have to specify PYQT_SIP_DIR on this platform regardless
of what combination of Python and Qt they try.

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
__________________________

Re: [Plplot-devel] Missing pyqtconfig module issue should now be fixed

[Arjen M. <Arj...@de...>]

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Sunday, September 03, 2017 4:47 AM
> To: Arjen Markus; PLplot development list
> Subject: Missing pyqtconfig module issue should now be fixed
>
> Hi Arjen:
>
> >
> I am pretty sure this new pyqt-related CMake logic will work OK for you now on
> MinGW-w64/MSYS2, but if not, please let me know what PYQT_SIP_DIR value
> you needed to specify to work around this issue so I can improve those HINTS for
> the PyQt4 case for finding that directory prefix on MinGW-w64/MSYS2.
>

Yes, it did work. I accidentally used the wrong MinGW-w64/MSYS2 installation and got Python 2 instead of 3 and that revealed that for Python 2 the SIP subdirectory is "Py2-Qt4" instead of "PyQt4", but after persuading CMake to use that directory, it all worked fine. I had to kill the comprehensive tests, as they were taking too long, but what I did have was encouraging (see tar file).

> Similarly, if on MSVC you have installed a third-party binary package that supplies
> PyQT4, then I think the present code is likely to work, but if not I would appreciate
> your PYQT_SIP_DIR feedback for that platform as well so I can improve our
> HINTS for the PyQt4 case.

Not done this yet.
>
> And similarly for PyQt5 on both platforms.
>
> For the Cygwin case I already know from using their file-location GUI that I have
> the correct HINTS for both PyQt4 and PyQt5.
>
My earlier problems with the SIP executable not being found were due to a missing package it seems - PyQt4 development stuff. With this I could build PLplot for this platform with PyQt4 support.

Regards,

Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Missing pyqtconfig module issue should now be fixed

[Arjen M. <Arj...@de...>]

Hi Alan,



See below.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Sunday, September 03, 2017 4:47 AM
> To: Arjen Markus; PLplot development list
> Subject: Missing pyqtconfig module issue should now be fixed
>
> Hi Arjen:
>
> You reported some time ago that the deprecated pyqtconfig module was not
> available on the MinGW-w64/MSYS2 platform.  Since that deficiency is obviously
> likely to spread to other platforms as well, I have now (commit b3ef719) updated
> our pyqt-related CMake logic to replace the pyqtconfig approach with our own
> approach for finding PYQT_SIP_DIR, the directory whose subdirectories contain all
> PyQT *.sip files.
>
> I am pretty sure this new pyqt-related CMake logic will work OK for you now on
> MinGW-w64/MSYS2, but if not, please let me know what PYQT_SIP_DIR value
> you needed to specify to work around this issue so I can improve those HINTS for
> the PyQt4 case for finding that directory prefix on MinGW-w64/MSYS2.
>

Okay, sounds interesting - I will give it a try tonight.

> Similarly, if on MSVC you have installed a third-party binary package that supplies
> PyQT4, then I think the present code is likely to work, but if not I would appreciate
> your PYQT_SIP_DIR feedback for that platform as well so I can improve our
> HINTS for the PyQt4 case.
>
> And similarly for PyQt5 on both platforms.
>
> For the Cygwin case I already know from using their file-location GUI that I have
> the correct HINTS for both PyQt4 and PyQt5.
>
I had some problems with Cygwin during the last round of comprehensive tests. I will have to see if this change solves the problem.

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

[Plplot-devel] Missing pyqtconfig module issue should now be fixed

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

Hi Arjen:

You reported some time ago that the deprecated pyqtconfig module
was not available on the MinGW-w64/MSYS2 platform.  Since
that deficiency is obviously likely to spread to other platforms
as well, I have now (commit b3ef719) updated our pyqt-related CMake logic
to replace the pyqtconfig approach with our own approach for
finding PYQT_SIP_DIR, the directory whose subdirectories contain
all PyQT *.sip files.

I am pretty sure this new pyqt-related CMake logic will work OK for
you now on MinGW-w64/MSYS2, but if not, please let me know what
PYQT_SIP_DIR value you needed to specify to work around this issue so
I can improve those HINTS for the PyQt4 case for finding that
directory prefix on MinGW-w64/MSYS2.

Similarly, if on MSVC you have installed a third-party binary package
that supplies PyQT4, then I think the present code is likely to
work, but if not I would appreciate your PYQT_SIP_DIR feedback for that
platform as well so I can improve our HINTS for the PyQt4 case.

And similarly for PyQt5 on both platforms.

For the Cygwin case I already know from using their file-location GUI
that I have the correct HINTS for both PyQt4 and PyQt5.

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
__________________________

Re: [Plplot-devel] Qt(5) problems

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

On 2017-08-30 16:17-0000 Schwartz, Steven J wrote:

> Hi Alan,
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: 28 August 2017 22:39
>> To: Ole Streicher <deb...@li...>
>> Cc: plp...@li...
>> Subject: Re: [Plplot-devel] Qt(5) problems
>>
>> On 2017-08-28 15:06+0200 Ole Streicher wrote:
>>
>>> [...] since Qt4 is going to be deprecated very soon in Debian [1]
>>
>> [...]
>>> [1]
>>> https://lists.debian.org/debian-devel-announce/2017/08/msg00006.html
>>
>> By the way, thanks very much for that link.  I had no idea that upstream Qt4
>> maintenance had completely shut down so that the demise of downstream
>> Qt4 on most Linux distributions is inevitable and likely soon even for non-
>> Debian distributions.  Let's just hope this focus of the upstream Qt
>> developers on Qt5 will soon make that suite of libraries as reliable as the Qt4
>> suite of libraries is now.
>>
>
> For Mac-related reasons we have been using Qt5 for some time now for our QSAS software, which as you know uses plplot as its graphics engine. Actually, we use our own qt driver rather than the official plplot versions for reasons I don't know but probably related to the way we bind it into our code and/or the way users have to interact with the plots. But we've kept the plplot core reasonably up-to-date.
>
> Our big issue with Qt5 is the placement of characters/symbols on the plot page which is rarely at exactly the right vertical location and varies from one output device to the next. I think that was one of the main issues which led you to revert to Qt4. Perhaps there are others.
>
> Do you have any updates (or optimism) on this issue?

Hi Steve:

Yes to an update (see below), and because users like you and me are
sensitive to this issue, I was completely optimistic that Qt5 will
eventually be fixed in this regard (or that may have already happened
for the latest upstream version). However, from your experience it
sounds like that has not yet happened for the Mac OS X versions of Qt5
that you have tried so far, and my experience is mixed in this regard
for the Linux case (see below). My advice is to keep trying the latest
versions of Qt5 (e.g., an unpatched upstream version that you build
yourself) to see if/when this issue has finally been settled
completely.

Now here is my Linux experience concerning this issue.

Some years ago I designed an extremely sensitive test for character
alignment called examples/python/test_circle.py. The idea of this test
is to superimpose the same UTF-8 glyph at the same position for a wide
range of different character sizes.  If the font designers have
centred the glyph within the glyph box, then all those different sized
versions of the same glyph should line up exactly, but otherwise the
effective position changes with character size in a way that is
extremely sensitive to misalignment issues.  Of course, some glyphs
like an asterisk (which you can see from the example) are
fundamentally not centred by design, but in practice (at least for my
particular set of system fonts) I find the UTF-8 "heavy multiplication
x", "number sign", "four teardrop-spoked asterisk", and "8-spoked
asterisk" tend to be aligned consistently with each other, and
typically only tiny vertical adjustments (a small or zero fraction of
the character height) are needed to remove all misalignments for all
character heights for those particular glyphs.

The historical result for the above test was I found no vertical
alignment issues at all for Qt4 (zero offset adjustment needed), and
although an earlier Qt5 version (5.3.1?) that I built myself required
a large offset adjustment of -0.63 character heights I was able to
change that adjustment to zero and get good results for the above test
for an early version of Qt5 5.3.2 that was available for Debian
Jessie.  So I thought that Qt5 vertical alignment issue was settled
as of Qt version 5.3.2.

But I tested again just now to be sure of my answer to you, and the
ideal offset for Qt4 remains close to zero (I found best alignment
occurred if the offset adjustment was -0.035 character heights), but
for Qt5 it is now changed from zero to +0.46 (!) character heights for
most qt devices (with the exception of svgqt which appears to still
continue to need no offset correction).  Note this is still called Qt5
version 5.3.2, but I assume patches have been (incorrectly) applied to
it that have reintroduced the vertical alignment issue compared to the
earlier 5.3.2 version from Debian Jessie that I tested before.

Because this appears to be a Debian-specific issue for an outdated
Debian distribution and very likely not an upstream issue, I
ultimately decided to continue with no vertical adjustments for either
Qt4 or Qt5.  However, once I update to Debian Stretch (which provides
libqt5 version 5.7.1 (!)) I will look at this issue again, and I
remain optimistic no alignment fix will need to be made in that case
(since there appeared to already be a solution for at least one
variant of the 5.3.2 version of Qt5).

You may also want to look at this issue for yourself using the git
master branch version of PLplot and the above
examples/python/test_circle.py test.  But it appears from my Debian
Jessie experience that patches applied by packagers can screw up Qt5
vertical alignment quite easily so for that test I would suggest one
Qt5 version you should try is one you build yourself with source code
straight from the latest Qt5 upstream developers without any patches
applied at all.

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
__________________________

Re: [Plplot-devel] Qt(5) problems

[Schwartz, S. J <s.s...@im...>]

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: 28 August 2017 22:39
> To: Ole Streicher <deb...@li...>
> Cc: plp...@li...
> Subject: Re: [Plplot-devel] Qt(5) problems
> 
> On 2017-08-28 15:06+0200 Ole Streicher wrote:
> 
> > [...] since Qt4 is going to be deprecated very soon in Debian [1]
> 
> [...]
> > [1]
> > https://lists.debian.org/debian-devel-announce/2017/08/msg00006.html
> 
> By the way, thanks very much for that link.  I had no idea that upstream Qt4
> maintenance had completely shut down so that the demise of downstream
> Qt4 on most Linux distributions is inevitable and likely soon even for non-
> Debian distributions.  Let's just hope this focus of the upstream Qt
> developers on Qt5 will soon make that suite of libraries as reliable as the Qt4
> suite of libraries is now.
> 

For Mac-related reasons we have been using Qt5 for some time now for our QSAS software, which as you know uses plplot as its graphics engine. Actually, we use our own qt driver rather than the official plplot versions for reasons I don't know but probably related to the way we bind it into our code and/or the way users have to interact with the plots. But we've kept the plplot core reasonably up-to-date.

Our big issue with Qt5 is the placement of characters/symbols on the plot page which is rarely at exactly the right vertical location and varies from one output device to the next. I think that was one of the main issues which led you to revert to Qt4. Perhaps there are others.

Do you have any updates (or optimism) on this issue?

Best wishes
Steve

Re: [Plplot-devel] Is it time to remove our old fortran and our old Tcl bindings and examples?

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

On 2017-08-29 11:25-0000 Arjen Markus wrote:

> I agree - keeping the old stuff around (especially with the extra logic required for its support) is an unnecessary complication.

Thanks, Arjen, for your quick reply on these Fortran and Tcl cruft
removal issues.  I will follow up with an e-mail to plplot-general.

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
__________________________

Re: [Plplot-devel] This next release cycle should finish in early 2018

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

On 2017-08-29 11:44+0200 Ole Streicher wrote:

> Hi Alan,
>
> On 28.08.2017 00:13, Alan W. Irwin wrote:
>> On 2017-08-27 11:00+0200 Ole Streicher wrote:
>>> One point there however remains: I need to support all Python 3
>>> versions we have in Debian; currently Python 3.5 and Python 3.6.
>>> The difference are just the shared library stubs, which are
>>> compiled using the specific header files (the package will contain
>>> both shared libs). Do you have an idea how I could simply do this?
>>
>> Use multiple builds.
>>
>> Also to make this easier for you I have now (commit e320210) improved
>> user control of the Python version.
>>
>> So for one build you specify -DPLPLOT_PYTHON_EXACT_VERSION=3.5.0 and
>> for the other you specify -DPLPLOT_PYTHON_EXACT_VERSION=3.6.0, and it
>> should "just work" according to my tests of the above commit.
>
> Thank you for this; I am however still unsure: Multiple builds would
> mean to (currently) triple the whole build process (2.7, 3.5, 3.6),
> right? Or can I build the Python binding individually?

Mostly individually.  For example, if you used the cmake parameters
(-DFORCE_PYTHON2=ON -DDEFAULT_NO_DEVICES=ON -DPLD_extqt=ON
-DDEFAULT_NO_BINDINGS=ON -DENABLE_python=ON -DENABLE_qt=ON
-DENABLE_pyqt5=ON) to configure a build and install of just the
minimum PLplot components you need to support both python and pyqt5
under Python2, then that means there is a large saving in build cost
since few devices are built and few bindings are built.  Of course,
there is some duplication of build effort here, but it is tiny (just
the duplicate rebuild of the plplot C library and its small C library
dependencies, i.e., csironn, csirocsa, and qsastime) relative to what
a full PLplot build costs.

>> Our Qt-related components work extremely well with Qt4, and also
>> work pretty well (aside from small character alignment issues and a
>> segfault for pyqt5) with the Debian Jessie version of Qt5. But those
>> Qt5 issues are bound to go away as that library matures (and in fact
>> may have gone away already with the later versions of Qt5 that you
>> have access to with later Debian versions).  But I also don't think
>> you should throw away our superb Qt4 capabilities prematurely.  So I
>> suggest you use a multiple build approach here as well (one with
>> -DPLPLOT_USE_QT5=ON and one with the default value of that option
>> [-DPLPLOT_USE_QT5=OFF]).
>

[...]
> If we would split by the Qt
> version we would have:
>
> plplot-driver-qt4, plplot-driver-qt5,
> libplplotqt4-2, libplplotqt5-2,
> python-plplot-qt4, python-plplot-qt5,
> python3-plplot-qt4, python3-plplot-qt5
>
> so four more packages. For a library that is deprecated, this sounds a
> bit overkill, especially for a soon-to-be-removed package.

Having finally read the reference you gave concerning how soon Qt4 is
going to be removed from Debian, I now agree building Qt4-related
components of PLplot would be overkill (although the multiple build
cost would have been low since as in the python case above there is a
way to pare down the Plplot build to just the bare essentials
concerning its Qt-related components).

To summarize, I think you should do multiple builds for python 2.7,
3.5, and 3.6 (with relatively small extra build cost), but I agree you
should stick strictly to Qt5 for our Qt-related components because Qt4
is about to be removed from Debian.

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
__________________________

Re: [Plplot-devel] Qt(5) problems

[Ole S. <deb...@li...>]

Hi Alan,

"Alan W. Irwin" <ir...@be...> writes:
> Hi Ole:
>
> [...]
>
> To investigate this potential issue further, I have just now built and
> tested PLplot in an environment (Linux console mode) where no X server
> is running at all (although all the X headers, etc., were available).
> In response to the lack of an X server, our build system's
> wish-related part of the Tk configuration failed which in turn
> disabled tk.  However, this is the expected result from some Cygwin
> experiments Arjen has tried where he attempted to configure PLplot
> without the Cygwin X server running.  That was the only difference in
> that configuration compared to a more ordinary configuration with an X
> server running so all seemed well.  Furthermore, the subsequent build
> of the test_noninteractive target (the same one that intermittently
> failed due to an X server glitch above) had absolutely no issues with
> the lack of X server!  Furthermore, the combination of
>
> # Build all ctest dependencies:
> make -j4 all >& all.out
>
> ctest --extra-verbose -j4 >& ctest.out
>
> also showed no issues with the lack of X server (which makes sense
> since the "all" target builds no targets that do run-time testing, and
> ctest runs essentially the same noninteractive tests as the
> test_noninteractive target).  By the way, this was all done with
> Qt4, but I don't think Qt5 would be any different.

OK, I used here the standard tests (with "make test" or so) which
probably include interactive tests. Probably the glitches were from some
interaction between Qt and X11 (race conditions); I observed them on one
machine, but not on another (both with identical Debian "unstable"
installations).

Switching to "make VERBOSE=1 test_noninteractive" seems to run into
similar problems, however:

[...]
Generate C results for svgqt file device
cd /build/plplot-5.13.0+dfsg/obj-x86_64-linux-gnu/examples && env EXAMPLES_DIR=/build/plplot-5.13.0+dfsg/obj-x86_64-linux-gnu/examples SRC_EXAMPLES_DIR=/build/plplot-5.13.0+dfsg/examples OUTPUT_DIR=/build/plplot-5.13.0+dfsg/obj-x86_64-linux-gnu/examples/test_examples_output_dir /bin/bash /build/plplot-5.13.0+dfsg/obj-x86_64-linux-gnu/plplot_test/plplot-test.sh --verbose --front-end=c --device=svgqt
Testing front-end c
x00c
/build/plplot-5.13.0+dfsg/obj-x86_64-linux-gnu/plplot_test/test_c.sh: line 32: 31892 Aborted                 (core dumped) $DEBUG_CMD "$cdir"/x${index}${lang} -dev $device -o "${OUTPUT_DIR}"/x${index}${lang}%n.$dsuffix $options 2> test.error >| "${OUTPUT_DIR}"/x${index}${lang}_${dsuffix}.txt
QStandardPaths: XDG_RUNTIME_DIR points to non-existing path '/run/user/1000', please create it with 0700 permissions.
QXcbConnection: Could not connect to display 
examples/CMakeFiles/test_c_svgqt.dir/build.make:296: recipe for target 'examples/test_examples_output_dir/x00c01.svgqt' failed

What seems to work is

ctest --extra-verbose
make -C obj-* VERBOSE=1 test_diff_psc

(I thought that the non-interactive target just includes ctest and
test_diff_psc?)

> I hope this advice allows you to get through the rest of your
> noninteractive testing of PLplot without issues, and once that
> result is nailed down, it will be extremely interesting to see
> what is going on with your X server and interactive tests
> of PLplot.

The X server that is used here (Xvfb) is a bit special (no real display,
just a framebuffer), and is running "plain", without a window manager or
so. And we have no networking available during the build (test). I can
imagine that that there are implicit assumptions in Qt that are then not
fulfilled. Therefore, I would not too much effort in this; for built
time tests (on all the supported Architectures) and frequently run CI
tests this is IMO enough.

Best regards

Ole

Re: [Plplot-devel] Is it time to remove our old fortran and our old Tcl bindings and examples?

[Arjen M. <Arj...@de...>]

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, August 29, 2017 6:00 AM
> To: Arjen Markus; PLplot development list
> Subject: Is it time to remove our old fortran and our old Tcl bindings and examples?
>
> Hi Arjen:
>
> This e-mail concerns cruft removal for both the Fortran and Tcl cases.
>
> Fortran:
>
> We introduced the new Fortran binding and corresponding examples as of
> PLplot-5.12.0 (released on 2017-01-29), but as a safety measure supplied the old
> Fortran binding and examples if the user specified the CMake option -
> DPL_DEPRECATED_fortran=ON (which gave access to bindings/old_fortran and
> examples/old_fortran).
>
> Since that release I think we have gotten not even one complaint about the new
> fortran binding which introduced many backwards incompatible changes.  (There
> was one complaint about lack of Fortran support in CMake for a non-mainstream
> Fortran compiler, but that is a different issue that affects both our old and new
> fortran binding for that one user.) Furthermore, the next release is likely coming out
> in early 2018 or roughly one year later than PLplot-5.12.0.
> Therefore, I believe this release cycle is the right time to get rid of the cruft
> consisting of the -DPL_DEPRECATED_fortran=ON option and bindings/old_fortran
> and examples/old_fortran.
>
> If you agree with this timing, and assuming nobody on the plplot-general list objects
> (i.e., there is nobody there who is still actually using the old fortran binding), then I
> would plan to remove this cruft within a few days from now (just to make this
> change early in the release cycle so it gets maximum testing before the release in
> early 2018).

I agree - keeping the old stuff around (especially with the extra logic required for its support) is an unnecessary complication.

>
> Tcl:
>
> There is a similar story with the redacted Tcl API introduced in PLplot-5.12.0.
> There have been no complaints about that large backwards incompatible change,
> and the next release will be roughly a year away from the release where this
> change was introduced.
> Therefore, I believe this release cycle is the right time to get rid of the cruft
> consisting of the -DUSE_NON_REDACTED_TCL_TK=ON option and the
> corresponding bindings/non_redacted_tcl, bindings/non_redacted_tk,
> bindings/non_redacted_tk-x-plat, examples/examples/non_redacted_tcl,
> and examples/non_redacted_tk.
>
> If you agree with this timing, and assuming nobody on the plplot-general list objects
> (i.e., nobody there is using the -DUSE_NON_REDACTED_TCL_TK=ON option),
> then I would plan to remove this cruft within a few days from now just as in the
> fortran cruft removal case and for similar reasons.
>
Here the same remark holds.

> General remarks about this cruft removal:
>
> I am pushing this cruft removal because keeping those old files around implies we
> should sometimes test the -DPL_DEPRECATED_fortran=ON and -
> DUSE_NON_REDACTED_TCL_TK=ON options (which I don't want to do) and also
> do minimal maintenance to the old versions of the files (which I also don't want to
> do).  For example, I am about to remove the long-deprecated plrgb, plrgb1, plhls,
> and plwid.  But some of those are assumed to be available (when -
> DPL_DEPRECATED=ON) in the old versions of the Fortran and Tcl bindings.
> Which implies I need to either maintain those old versions consistent with the
> removal of plrgb, plrgb1, plhls, and plwid or do the much simpler task of deleting
> those old versions.
>
I see that some of the source files for Tcl/Tk contain these macros. These can be simplified as well then.

Regards,

Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] This next release cycle should finish in early 2018

[Ole S. <deb...@li...>]

Hi Alan,

On 28.08.2017 00:13, Alan W. Irwin wrote:
> On 2017-08-27 11:00+0200 Ole Streicher wrote:
>> One point there however remains: I need to support all Python 3
>> versions we have in Debian; currently Python 3.5 and Python 3.6.
>> The difference are just the shared library stubs, which are
>> compiled using the specific header files (the package will contain
>> both shared libs). Do you have an idea how I could simply do this?
> 
> Use multiple builds.
> 
> Also to make this easier for you I have now (commit e320210) improved
> user control of the Python version.
> 
> So for one build you specify -DPLPLOT_PYTHON_EXACT_VERSION=3.5.0 and
> for the other you specify -DPLPLOT_PYTHON_EXACT_VERSION=3.6.0, and it
> should "just work" according to my tests of the above commit.

Thank you for this; I am however still unsure: Multiple builds would
mean to (currently) triple the whole build process (2.7, 3.5, 3.6),
right? Or can I build the Python binding individually?

>> The old (plplot-10) Debian package had a build dependency on
>> python-gtk2, a package that does not exist for Python 3. I would
>> suspect that it is not needed anymore?

> [...] So I suspect this build dependency on python-gtk2 is an
> extremely ancient artifact that you can just ignore from now on.

Thank you for the confirmation.

> Our Qt-related components work extremely well with Qt4, and also
> work pretty well (aside from small character alignment issues and a 
> segfault for pyqt5) with the Debian Jessie version of Qt5. But those 
> Qt5 issues are bound to go away as that library matures (and in fact 
> may have gone away already with the later versions of Qt5 that you 
> have access to with later Debian versions).  But I also don't think
> you should throw away our superb Qt4 capabilities prematurely.  So I 
> suggest you use a multiple build approach here as well (one with 
> -DPLPLOT_USE_QT5=ON and one with the default value of that option 
> [-DPLPLOT_USE_QT5=OFF]).

Here, I have the similar objection as above: it duplicates the number of
builds. And combined with the Python triple (for Python-plplot-qt) we
would need to compile the code six times.

Additionally, the number of packages would increase even more. pgplot
currently builds already 27 binary packages. If we would split by the Qt
version we would have:

plplot-driver-qt4, plplot-driver-qt5,
libplplotqt4-2, libplplotqt5-2,
python-plplot-qt4, python-plplot-qt5,
python3-plplot-qt4, python3-plplot-qt5

so four more packages. For a library that is deprecated, this sounds a
bit overkill, especially for a soon-to-be-removed package. I read the
deprecation message I mentioned in my other mail that they will write RC
bug reports quite soon, so Qt4 packages will not survive for more than a
few months. And the general package restructuring I do in the moment is
a good moment to drop it.

> You have already said that you decided to simplify your life by not
> trying the above approach to support Python2.  But PLplot (after the
> above commit) now works well both for Python2 and Python3, and it
> would be a shame if either Debian Python2 or Python3 users did not
> have access to PLplot. Furthermore, assuming you have since decided to
> support both Python-3.5 and Python-3.6 with two separate builds, then
> adding a third build as above to support Python2 should be
> straightforward for you.  So I hope you decide to go ahead and do
> that. 

Sure; if there is not much effort to support Python 2 aside of all
Python 3 versions, I will not remove the packages.

Best regards

Ole

[Plplot-devel] Is it time to remove our old fortran and our old Tcl bindings and examples?

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

Hi Arjen:

This e-mail concerns cruft removal for both the Fortran and Tcl cases.

Fortran:

We introduced the new Fortran binding and corresponding examples as of
PLplot-5.12.0 (released on 2017-01-29), but as a safety measure
supplied the old Fortran binding and examples if the user specified
the CMake option -DPL_DEPRECATED_fortran=ON (which gave access to
bindings/old_fortran and examples/old_fortran).

Since that release I think we have gotten not even one complaint about
the new fortran binding which introduced many backwards incompatible
changes.  (There was one complaint about lack of
Fortran support in CMake for a non-mainstream Fortran compiler, but
that is a different issue that affects both our old and new fortran
binding for that one user.) Furthermore, the next release is likely
coming out in early 2018 or roughly one year later than PLplot-5.12.0.
Therefore, I believe this release cycle is the right time to get rid
of the cruft consisting of the -DPL_DEPRECATED_fortran=ON option and
bindings/old_fortran and examples/old_fortran.

If you agree with this timing, and assuming nobody on the
plplot-general list objects (i.e., there is nobody there who is still
actually using the old fortran binding), then I would plan to remove
this cruft within a few days from now (just to make this change early
in the release cycle so it gets maximum testing before the release in
early 2018).

Tcl:

There is a similar story with the redacted Tcl API introduced in
PLplot-5.12.0.  There have been no complaints about that large
backwards incompatible change, and the next release will be roughly a
year away from the release where this change was introduced. 
Therefore, I believe this release cycle is the right time to get rid
of the cruft consisting of the -DUSE_NON_REDACTED_TCL_TK=ON option and
the corresponding bindings/non_redacted_tcl, bindings/non_redacted_tk,
bindings/non_redacted_tk-x-plat, examples/examples/non_redacted_tcl,
and examples/non_redacted_tk.

If you agree with this timing, and assuming nobody on the
plplot-general list objects (i.e., nobody there is using the
-DUSE_NON_REDACTED_TCL_TK=ON option), then I would plan to remove this
cruft within a few days from now just as in the fortran cruft removal
case and for similar reasons.

General remarks about this cruft removal:

I am pushing this cruft removal because keeping those old files around
implies we should sometimes test the -DPL_DEPRECATED_fortran=ON and
-DUSE_NON_REDACTED_TCL_TK=ON options (which I don't want to do) and
also do minimal maintenance to the old versions of the files (which I
also don't want to do).  For example, I am about to remove the
long-deprecated plrgb, plrgb1, plhls, and plwid.  But some of those
are assumed to be available (when -DPL_DEPRECATED=ON) in the old
versions of the Fortran and Tcl bindings.  Which implies I need to
either maintain those old versions consistent with the removal of
plrgb, plrgb1, plhls, and plwid or do the much simpler task of
deleting those old versions.

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
__________________________

[Plplot-devel] Removal of our file support (consisting mostly of test examples in examples/perl) for the external PDL::Graphics::PLplot project?

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

By historical accident Rafael (followed by other developers here)
helped out with Doug Hunt's
external PDL::Graphics::PLplot project by supplying test examples in
examples/perl to see how well that external project's results agreed
with our C examples (which was typically not very well). Also (see
examples/perl/README.perldemos), because of how PDL::Graphics::PLplot
is organized as an integrated project within PDL rather than an external
project that depends on PDL, it is a rather complex
procedure involving modification of system PDL files to actually use
our examples in perl examples to test that external project with a
recent PLplot build.  Because of that complexity, it has been quite a
few years since I have tried that procedure myself, and I have never
heard of anyone else trying it recently. Also, from the results of

git log --name-status examples/perl

it appears those standard examples are in minimum maintenance
mode, e.g., the most recent changes 
concern issues such as removing trailing whitespace rather than
adjusting to the major plot changes that have been accumulating
over the years for all the rest of our standard examples.

In sum, examples/perl is essentially never used or tested by us any
more, and its presence in our project is misleading (since those are
only support files for an external project and not a sign that we have,
for example, implemented our own perl/pdl binding).  Therefore, (if Doug is
interested) those files should be part of the PDL::Graphics::PLplot
project rather than our own project.

As a result of the above considerations, I would like to remove
examples/perl from PLplot, and this change would not preclude Doug
copying those files (entirely permitted under the LGPL license for
them) to his own PDL::Graphics::PLplot project from plplot-5.13.0
(either from the release tarball or from that tag on our master
branch) if he so desires.  Accordingly, I plan to make this move in a
couple of days unless I hear any strong objections here.

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
__________________________

Re: [Plplot-devel] Qt(5) problems

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

On 2017-08-28 15:06+0200 Ole Streicher wrote:

> [...] since Qt4 is going to be deprecated very soon in Debian [1]

[...]
> [1] https://lists.debian.org/debian-devel-announce/2017/08/msg00006.html

By the way, thanks very much for that link.  I had no idea that
upstream Qt4 maintenance had completely shut down so that the demise
of downstream Qt4 on most Linux distributions is inevitable and likely
soon even for non-Debian distributions.  Let's just hope this focus of
the upstream Qt developers on Qt5 will soon make that suite of libraries
as reliable as the Qt4 suite of libraries is now.

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
__________________________

Re: [Plplot-devel] Qt(5) problems

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

On 2017-08-28 15:06+0200 Ole Streicher wrote:

> Hi,
>
> on my path to get plplot compiled for Debian, I have a number of
> problems during the execution to the Qt tests. I first was trying to use
> Qt5, since Qt4 is going to be deprecated very soon in Debian [1], but I
> see the same problems with Qt4.
>
> Occasionally, I get now lots messages like
>
> Qt: Session management error: Could not open network socket
> Qt: Session management error: networkIdsList argument is NULL
> QXcbConnection: Could not connect to display :99
>
> The errors may be related to the specific environment that is used
> (xvfb-run); ":99" is the (automatically generated) DISPLAY for that
> case.
>

> Do you have an idea what happens here?

Hi Ole:

I did notice during my recent comprehensive testing with my usual 
X-terminal setup (using a local X server to display a remote desktop
where I was building and testing PLplot on a much more powerful
machine than my local one) that the *noninteractive* part of the tests
failed because of some temporary glitch in my local X server
In this case, I was in a last-minute rush with the
release, and the problem could not be reliably reproduced (the next
attempt of the noninteractive part of the comprehensive tests
succeeded without issues) so all I could do was note the issue and
move on at that time.  But it did seem peculiar to me that any
of our noninteractive tests were dependent on the X server working.

To investigate this potential issue further, I have just now built and
tested PLplot in an environment (Linux console mode) where no X server
is running at all (although all the X headers, etc., were available).
In response to the lack of an X server, our build system's
wish-related part of the Tk configuration failed which in turn
disabled tk.  However, this is the expected result from some Cygwin
experiments Arjen has tried where he attempted to configure PLplot
without the Cygwin X server running.  That was the only difference in
that configuration compared to a more ordinary configuration with an X
server running so all seemed well.  Furthermore, the subsequent build
of the test_noninteractive target (the same one that intermittently
failed due to an X server glitch above) had absolutely no issues with
the lack of X server!  Furthermore, the combination of

# Build all ctest dependencies:
make -j4 all >& all.out

ctest --extra-verbose -j4 >& ctest.out

also showed no issues with the lack of X server (which makes sense
since the "all" target builds no targets that do run-time testing, and
ctest runs essentially the same noninteractive tests as the
test_noninteractive target).  By the way, this was all done with
Qt4, but I don't think Qt5 would be any different.

Of course, in that environment any attempt at interactive testing will fail.  For
example, an attempt to build the test_c_qtwidget target failed as
follows

make VERBOSE=1 test_qtwidget
[...]
Testing subset of C examples for device qtwidget
x01c
/home/software/plplot/HEAD/build_dir/plplot_test/test_c_interactive.sh: line 46: 19881 Aborted                 $DEBUG_CMD "$cdir"/x${index}${lang} -dev $device $NP_OPTION 2> test.error >| "${OUTPUT_DIR}"/x${index}${lang}_${device}.txt
QWidget: Cannot create a QWidget when no GUI is being used
examples/CMakeFiles/test_c_qtwidget.dir/build.make:57: recipe for target 'examples/CMakeFiles/test_c_qtwidget' failed
make[3]: *** [examples/CMakeFiles/test_c_qtwidget] Error 1
make[3]: Leaving directory '/home/software/plplot/HEAD/build_dir'
CMakeFiles/Makefile2:7247: recipe for target 'examples/CMakeFiles/test_c_qtwidget.dir/all' failed
make[2]: *** [examples/CMakeFiles/test_c_qtwidget.dir/all] Error 2
make[2]: Leaving directory '/home/software/plplot/HEAD/build_dir'
CMakeFiles/Makefile2:7254: recipe for target 'examples/CMakeFiles/test_c_qtwidget.dir/rule' failed
make[1]: *** [examples/CMakeFiles/test_c_qtwidget.dir/rule] Error 2
make[1]: Leaving directory '/home/software/plplot/HEAD/build_dir'
Makefile:2106: recipe for target 'test_c_qtwidget' failed
make: *** [test_c_qtwidget] Error 2

So my conclusion is (a) our noninteractive tests are independent of
whether an X server is running or not (as they should be) and (b) the
above problem with the X server that killed "make test_noninteractive"
was likely due to the X server glitch affecting the overall KDE
desktop which in turn created a konsole command-line failure which
killed off that attempt to build the test_noninteractive target.
(Which, of course, has nothing to do with PLplot.)

> Is there a way to disable the Qt tests for a moment?

I would focus for now on making sure the test_noninteractive target
and ctest works, and those results should be independent of any X
server glitches unless such failures are affecting your entire desktop.

But let's assume later on you want to build the test_interactive target to test
the large subset of our interactive components which previous tests
have shown to be reliable which would include for the Qt5 case the test_c_qtwidget
target as well as the test_qt_example and test_pyqt5_example targets.

(By the way, use "make help |grep test | less" in the top of the build
tree to figure out what test targets are available to do run-time
testing.)

However, if that test shows one of the above qt test targets is
failing due to some X server issue, you can simply disable 
test_c_qtwidget, test_qt_example, and/or test_pyqt4_example targets
using respectively -DPLD_qtwidget=OFF, -DPLD_extqt=OFF, and/or
-DENABLE_pyqt5=OFF.

Or a more crude approach for such interactive testing without any
Qt-related components of PLplot would be to disable all such components
using the cmake options -DENABLE_qt=OFF and
-DDEFAULT_NO_QT_DEVICES=ON.

I hope this advice allows you to get through the rest of your
noninteractive testing of PLplot without issues, and once that
result is nailed down, it will be extremely interesting to see
what is going on with your X server and interactive tests
of PLplot.

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
__________________________

[Plplot-devel] Qt(5) problems

[Ole S. <deb...@li...>]

Hi,

on my path to get plplot compiled for Debian, I have a number of
problems during the execution to the Qt tests. I first was trying to use
Qt5, since Qt4 is going to be deprecated very soon in Debian [1], but I
see the same problems with Qt4.

Occasionally, I get now lots messages like

Qt: Session management error: Could not open network socket
Qt: Session management error: networkIdsList argument is NULL
QXcbConnection: Could not connect to display :99

The errors may be related to the specific environment that is used
(xvfb-run); ":99" is the (automatically generated) DISPLAY for that
case.

Do you have an idea what happens here? Is there a way to disable the Qt
tests for a moment?

Best regards

Ole

[1] https://lists.debian.org/debian-devel-announce/2017/08/msg00006.html

[Plplot-devel] git blog

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

Can some git guru here advise me what I need to do to publish a bug fix
release (in case during this release cycle some bug fix is so urgent
that we need to make a bug-fix 5.13.1 release to propagate that fix to
our users)?

I assume I would branch a private topic branch called "release" for this bug-fix
release at the plplot-5.13.0 tag (to minimize post-5.13.0 work that
goes into this "release" branch), and I would need to create a small
number of bug-fix commits on that topic branch (either by hand or with
git cherry pick) to complete all development for that private release
topic branch. But what is the best way to publish that work?

Here is a scenario I think might work.

Tag that last commit on that private "release" branch as (signed)
"plplot-5.13.1"

Propagate that tag to SF using

git push origin plplot-5.13.1

Is that sufficient?  i.e., will that propagate that tag (and
presumably its small number of parents back to plplot-5.13.0) to SF?
No new branches at SF would be ideal since development on
that "release" branch should not proceed past plplot-5.13.1

Or do I need to push the "release" branch to a new "release"
branch at SF, e.g., with

git push -u origin release

before pushing the tag, and then follow up with deleting the branch
(which should not delete the tag and its parents) which would allow me
to reuse the "release" branch name if I have to do this again and also
discourage anyone from attempting to use the "release" branch at SF
for further development.

Or if neither of these ideas end up with the plplot-5.13.1 tag and all
its parents being permanently stored and accessible at SF without a
corresponding branch, can someone advise me of a better procedure for
publishing my plplot-5.13.1 tag (and presumably its immediate parents)?

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
__________________________

[Plplot-devel] Deprecate plshade1?

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

Does anyone have any objections to me deprecating plshade1 for this
next release, to be followed up by removing it altogether in the
next release?

plshade1 differs from plshade only in the type of its first argument
(pointer to a contiguous block of memory that contains nx by ny matrix
values rather than the more general PLFLT_MATRIX type used for the
first argument of plshade.)  So my impression is plshade1 is not
too useful, and indeed it is not used in any examples other
than the C and Ada example 15, and those calls should be
straightforward to replace by the equivalent calls to plshade.

Therefore, unless one of you has a strong objection, I plan to remove
plshade1 entirely from Ada and deprecate its use in C
starting in a couple of days.

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
__________________________

Re: [Plplot-devel] On-going Windows testing, and our Wiki summary of it

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

Hi Arjen (off list):

There are at least three motivations why I would prefer you
to continue a slow but steady pace of testing right now rather than dropping it for
a while.

1. Continuing the testing effort you started before the 5.13.0 release
should be more efficient than dropping testing right now and
starting it up again later.  For example, slow but steady testing
will encourage you to make your package installs and test launch
procedures so automated, that you can start installation of a new
platform snapshot and/or start a comprehensive test in just a few
minutes, and in each case completely forget about it until it is
finished. So the goal should be that a pace of ~two tests per week or
one platform installation snapshot + a test per week should literally
require just a few minutes of your attention.

2. If the past is any guide, the ~3500 downloads that should occur for
this 5-month release cycle will occur throughout the cycle rather than
in a burst at the start of it.  So if you complete the rest of the
testing for Cygwin and MSVC in, say, the next 4 weeks (which should be
entirely possible even at the above slow pace), then most of the
5.13.0 users who pay attention to the release notes and its reference
to the wiki summary of tests should still be inspired by your test
results.  But if you wait to complete your Cygwin and MSVC tests until
late in this release cycle, then most 5.13.0 users won't even see your
test efforts.

3.  It would be good to establish testing benchmarks early in this
release cycle for Cygwin and MSVC (as has already been done for
MinGW-w64/MSYS2 and Linux) that should  be the basis of a comparison with
test results late in the release cycle to see whether the PLplot
changes have caused a regression in the test results.

On 2017-08-28 08:35-0000 Arjen Markus wrote:

> There are several other things besides PLplot that require my attention, I am afraid ;).

I am sympathetic concerning all these current calls on your time.  But
for the above reasons it would be better to complete your Cygwin and
MSVC testing sooner rather than later in this release cycle, and
indeed finishing up your current testing effort should allow you to take a
complete break from PLplot testing until late in this release cycle.
So ideally there should not be long gaps in your testing efforts right
now. Therefore, given the other calls on your time is a steady but
slow pace of testing (say ~two runs of the comprehensive test script
each week) to finish off testing on Cygwin and MSVC possible?  Or are
you in the unhappy position of being so rushed off your feet, that you
would prefer no distractions at all from PLplot testing at the moment?

If the latter, I will try to honor that by not saying much more about
testing until substantially later in this release cycle.  But I hope a
steady but slow testing pace is possible for you right now instead for
the reasons stated above.

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
__________________________

Re: [Plplot-devel] On-going Windows testing, and our Wiki summary of it

[Arjen M. <Arj...@de...>]

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, August 28, 2017 10:05 AM
> Hi Arjen:
>
> Could you please take a look at
> <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>
> where I have recently added a summary of your latest noninteractive
> comprehensive test for MinGW-w64/MSYS2?  In that summary I had to guess at
> the wxwidgets version number. If I guessed wrong, please update that version, and
> please also update any other thing in the
> MinGW-w64/MSYS2 summary which you feel I got wrong as well.
>

Sure, I will have a look.

> (By the way, my recent commit to change how we test for wxwidgets version
> number also outputs the wxwidgets version that has been found.  So I shouldn't
> have to guess any more about that from now on.)
>
That will definitely be useful - it was puzzling in the past.

> Now that you have essentially complete noninteractive comprehensive testing
> success with MinGW-w64/MSYS2, our wiki page
> <https://sourceforge.net/p/plplot/wiki/MinGW-w64-MSYS2/> needs to be updated
> from Greg's two-year-old experience to yours on this platform.
> Also, all the MSYS2 URL's on that page have to be updated to refer to the github
> version of the MSYS2 wiki, and the recommended list of MinGW-w64/MSYS2,
> packages needs updating. Would you be willing to take responsibiltiy for these
> updates to this wiki page?
>
I will take care of that, but not rightaway. There are several other things besides PLplot that require my attention, I am afraid ;).

> Note, I haven't bothered in the above table of reports to summarize your latest
> Cygwin and MSVC noninteractive tests because I don't view those as complete yet,
> see my quoted question to you above about the next comprehensive test you plan
> to do.
>
There is indeed a whole bunch of smallish things that need to be sorted out, for the three Windows-based platforms in fact.

Regards,

Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

[Plplot-devel] On-going Windows testing, and our Wiki summary of it

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

On 2017-08-25 23:34-0700 Alan W. Irwin wrote:

> Arjen:
>
> Your comprehensive tests on MinGW-w64/MSYS2, Cygwin, and MSVC (+ Unix
> tools to help with testing) are really important since they are
> fundamental to improving our build system for those platforms. Nevertheless, 
> because 5.13.0 was late we jointly decided to make the
> compromise of putting off some of your planned comprehensive testing
> until after 5.13.0 was released.  So now that that post-release time
> has arrived what is the next test you have planned here?

Hi Arjen:

Could you please take a look at
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>
where I have recently added a summary of your latest noninteractive
comprehensive test for MinGW-w64/MSYS2?  In that summary I had to
guess at the wxwidgets version number. If I guessed wrong, please
update that version, and please also update any other thing in the
MinGW-w64/MSYS2 summary which you feel I got wrong as well.

(By the way, my recent commit to change how we test for wxwidgets
version number also outputs the wxwidgets version that has been found.  So
I shouldn't have to guess any more about that from now on.)

Now that you have essentially complete noninteractive comprehensive
testing success with MinGW-w64/MSYS2, our wiki page
<https://sourceforge.net/p/plplot/wiki/MinGW-w64-MSYS2/> needs to be
updated from Greg's two-year-old experience to yours on this platform.
Also, all the MSYS2 URL's on that page have to be updated to refer to
the github version of the MSYS2 wiki, and the recommended list of
MinGW-w64/MSYS2, packages needs updating. Would you be willing to take
responsibiltiy for these updates to this wiki page?

Note, I haven't bothered in the above table of reports to summarize
your latest Cygwin and MSVC noninteractive tests because I
don't view those as complete yet, see my quoted question to you
above about the next comprehensive test you plan to do.

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
__________________________

Re: [Plplot-devel] This next release cycle should finish in early 2018

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

On 2017-08-26 13:15-0700 Alan W. Irwin wrote:

[...]
> Plplot continues to work fine for
> python2 aside from the relatively rare corruption issue for
> bindings/python/Plframe.pyc [... which will likely go away once I figure out how to
> move to a single name-spaced import of PLframe.

Hi Ole:

That turned out to be an easy fix (see commit 1b93965) so I assume
that corruption issue (that only occurred intermittently for Python2)
is now gone.

> So I suggest if you still want to build a python2 package for PLplot,
> that you do that in a separate build where both python2 and
> python-numpy are available and you use the cmake option
> -DFORCE_PYTHON2=ON.  In that case and assuming that Python2 and
> python-numpy are installed, our build system will do the right thing
> with regard to building the Python2 plplot module using consistent
> Python2 library and numpy versions, and also use the correct install
> location for the resulting Python2 plplot module.  Also, this extra
> build does not need to cost you very much since you can use
> (-DFORCE_PYTHON2=ON -DDEFAULT_NO_DEVICES=ON -DPLD_extqt=ON
> -DDEFAULT_NO_BINDINGS=ON -DENABLE_python=ON -DENABLE_qt=ON
> -DENABLE_pyqt4=ON) to, for example, configure a build and install of
> just the minimum PLplot components you need to support both python and
> pyqt4 under Python2.

You have already said that you decided to simplify your life by not
trying the above approach to support Python2.  But PLplot (after the
above commit) now works well both for Python2 and Python3, and it
would be a shame if either Debian Python2 or Python3 users did not
have access to PLplot. Furthermore, assuming you have since decided to
support both Python-3.5 and Python-3.6 with two separate builds, then
adding a third build as above to support Python2 should be
straightforward for you.  So I hope you decide to go ahead and do
that.

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
__________________________