plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Qt5 support, strange driver output

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

Hi Alan
this is indeed very strange.
here the result of uname -a
4.12.14-lp150.12.28-default #1 SMP Mon Dec 3 16:46:15 UTC 2018 (b91289f)
x86_64 x86_64 x86_64 GNU/Linux

My distribution is opensuse leap 15.0
and my qt is 5.12.0

(although i had exactly the same result with 5.11 as i've tested it a few
weeks ago)

just built again with your cmake suggestion and the results are exactly the
same as before.
I'l try to get an hand during next week on a computer with a different
linux distribution just for testing.

cheers,









On Fri, Dec 14, 2018 at 11:41 PM Alan W. Irwin <Ala...@gm...>
wrote:

> On 2018-12-12 15:24-0000 António Rodrigues Tomé wrote:
>
> > Hi Alan,
> > now that 5.14 is out I would like to be more useful in solving the qt5
> > driver problem. However I do not complete understand the driver system to
> > be of big help.However for me I found a work arround that seems to work
> > quite well. I send you 4 files, output of x01 example using qt driver,
> png
> > and pdf)  the ones with Realease in name were created by the actual qt
> > driver version 5.14 that I constructed with the command
> > cmake -DCMAKE_INSTALL_PREFIX=/home/artome/plplot/PLPLOTNEW/
> > -DDEFAULT_NO_CAIRO_DEVICES=ON  -DDEFAULT_NO_QT_DEVICES=OFF DENABLE_cxx=ON
> > -DPL_DOUBLE=ON -DPLPLOT_USE_QT5=ON DEFAULT_NO_BINDINGS=ON    ../ >&
> > cmake.out
>
> Hi António:
>
> Please keep this discussion thread on list.
>
> I think it would be better style (and also I think -DBUILD_TEST=ON is
> essential)
> to use instead
> cmake -DCMAKE_INSTALL_PREFIX=/home/artome/plplot/PLPLOTNEW/
> -DBUILD_TEST=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_cxx=ON -DENABLE_qt=ON
> -DPLPLOT_USE_QT5=ON -DDEFAULT_NO_CAIRO_DEVICES:BOOL=ON ../ >& cmake.out
>
> I just tried all those options here (except for your
> -DCMAKE_INSTALL_PREFIX), and they worked fine,
> i.e., eliminated all bindings other than cxx and qt, dropped the cairo
> devices, and included
> all qt devices (which happens by default if -DENABLE_qt=ON).
>
> What is your exact platform (I think it might still be opensuse, but what
> version?) and what are the results of the "uname -a" command on that
> platform?  Also, what is the version of Qt5 that you are using?
>
> The reason these details are important is I cannot replicate the text
> alignment issues you demonstrated with pdfqt and pngqt results for
> example one on your platform.  My platform is Debian Buster (with the
> Qt5 5.11.2 suite of libraries) installed on AMD64 hardware (Ryzen 7
> 1700).  I demonstrated that I cannot replicate your badly aligned
> results by configuring cmake in the way I described above and then
> executing the following commands:
>
> # Build the prerequisites for the specific examples below
> make -j16 test_c_pngqt
> make -j16 test_c_pdfqt
>
> # Build two specific examples
> examples/c/x01c -dev pngqt -o test.pngqt
> examples/c/x01c -dev pdfqt -o test.pdfqt
>
> I have attached those two result files so you can see for yourself that
> there are no text
> alignment issues.
>
> Also your suggested changes to plqt.cpp likely conflate two issues.  (i)
> alignment issues caused
> by your platform and not PLplot, and (ii) the size of the resulting
> characters (which I
> would prefer to put off discussing until later).  So to check those are
> two separate issues,
> what happens if you restore plqt.cpp to its original form except for this
> one line change:
>
> PLDLLIMPEXP_QT_DATA( int ) vectorize = 0;
> ==>
> PLDLLIMPEXP_QT_DATA( int ) vectorize = 1;
>
> ?  I am pretty sure that is the equivalent of the first part of your
> change where you
> are forcing the vectorize part of the code to be executed.
>
> If that one-line change is all you need to bypass your Qt5 platform
> issues, then I would be willing to test that simple change here to see
> if it also works on my platform.  But the vectorize = 1 code path has
> not been tested by anybody but you over the years and is just likely a
> workaround for your Qt5 platform issue so I likely won't push that
> one-line change in general.
>
> Also you do appear to be having text alignment troubles consistently
> over the years with your (opensuse?) Qt5 platforms so perhaps it is
> time to try other Qt5 platforms?  For example, you could build the
> upstream version of Qt5 yourself.  The very early versions of Qt5 did
> have character alignment difficulties in that upstream version, but my
> experiments showed they solved the alignment issues important to
> PLplot by 5.3.x so you will likely find the latest upstream Qt5 also
> does not have text alignment issues.  And if that is the case, then
> that experiment should be the basis of a bug report to your
> distribution.  Of course, if that bug report gets no response another
> possibility is to try Debian (which I know works well now with Qt5)
> some Debian derivative such as Ubuntu or Mint or some other rpm-based
> distribution such as Fedora.
>
> Good luck, and let me know how it goes.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________



-- 

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] Qt5 support, strange driver output

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

On 2018-12-12 15:24-0000 António Rodrigues Tomé wrote:

> Hi Alan,
> now that 5.14 is out I would like to be more useful in solving the qt5
> driver problem. However I do not complete understand the driver system to
> be of big help.However for me I found a work arround that seems to work
> quite well. I send you 4 files, output of x01 example using qt driver, png
> and pdf)  the ones with Realease in name were created by the actual qt
> driver version 5.14 that I constructed with the command
> cmake -DCMAKE_INSTALL_PREFIX=/home/artome/plplot/PLPLOTNEW/
> -DDEFAULT_NO_CAIRO_DEVICES=ON  -DDEFAULT_NO_QT_DEVICES=OFF DENABLE_cxx=ON
> -DPL_DOUBLE=ON -DPLPLOT_USE_QT5=ON DEFAULT_NO_BINDINGS=ON    ../ >&
> cmake.out

Hi António:

Please keep this discussion thread on list.

I think it would be better style (and also I think -DBUILD_TEST=ON is essential)
to use instead
cmake -DCMAKE_INSTALL_PREFIX=/home/artome/plplot/PLPLOTNEW/ -DBUILD_TEST=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_cxx=ON -DENABLE_qt=ON -DPLPLOT_USE_QT5=ON -DDEFAULT_NO_CAIRO_DEVICES:BOOL=ON ../ >& cmake.out

I just tried all those options here (except for your -DCMAKE_INSTALL_PREFIX), and they worked fine,
i.e., eliminated all bindings other than cxx and qt, dropped the cairo devices, and included
all qt devices (which happens by default if -DENABLE_qt=ON).

What is your exact platform (I think it might still be opensuse, but what version?) and what are the results of the "uname -a" command on that platform?  Also, what is the version of Qt5 that you are using?

The reason these details are important is I cannot replicate the text
alignment issues you demonstrated with pdfqt and pngqt results for
example one on your platform.  My platform is Debian Buster (with the
Qt5 5.11.2 suite of libraries) installed on AMD64 hardware (Ryzen 7
1700).  I demonstrated that I cannot replicate your badly aligned
results by configuring cmake in the way I described above and then
executing the following commands:

# Build the prerequisites for the specific examples below
make -j16 test_c_pngqt
make -j16 test_c_pdfqt

# Build two specific examples
examples/c/x01c -dev pngqt -o test.pngqt
examples/c/x01c -dev pdfqt -o test.pdfqt

I have attached those two result files so you can see for yourself that there are no text
alignment issues.

Also your suggested changes to plqt.cpp likely conflate two issues.  (i) alignment issues caused
by your platform and not PLplot, and (ii) the size of the resulting characters (which I
would prefer to put off discussing until later).  So to check those are two separate issues,
what happens if you restore plqt.cpp to its original form except for this one line change:

PLDLLIMPEXP_QT_DATA( int ) vectorize = 0;
==>
PLDLLIMPEXP_QT_DATA( int ) vectorize = 1;

?  I am pretty sure that is the equivalent of the first part of your change where you
are forcing the vectorize part of the code to be executed.

If that one-line change is all you need to bypass your Qt5 platform
issues, then I would be willing to test that simple change here to see
if it also works on my platform.  But the vectorize = 1 code path has
not been tested by anybody but you over the years and is just likely a
workaround for your Qt5 platform issue so I likely won't push that
one-line change in general.

Also you do appear to be having text alignment troubles consistently
over the years with your (opensuse?) Qt5 platforms so perhaps it is
time to try other Qt5 platforms?  For example, you could build the
upstream version of Qt5 yourself.  The very early versions of Qt5 did
have character alignment difficulties in that upstream version, but my
experiments showed they solved the alignment issues important to
PLplot by 5.3.x so you will likely find the latest upstream Qt5 also
does not have text alignment issues.  And if that is the case, then
that experiment should be the basis of a bug report to your
distribution.  Of course, if that bug report gets no response another
possibility is to try Debian (which I know works well now with Qt5)
some Debian derivative such as Ubuntu or Mint or some other rpm-based
distribution such as Fedora.

Good luck, and let me know how it goes.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] plplot-5.14.0 has been released

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

On 2018-12-12 16:33+0100 Ole Streicher wrote:

> Hi Alan,
>
> "Alan W. Irwin" <Ala...@gm...> writes:
>> A comprehensive test and some additional specific tests of my fix for the
>> release critical bug went well, and as a result I have now released
>> 5.14.0.  See my forthcoming post to plplot-general for the details
>> concerning that release.
>
> thank you very much for preparing the new release! And congratulations
> for the success!

You are welcome.

>
> I am now preparing the Debian package, and for there, I have a few
> questions:
>
> * the soname (ABI version) of libplplot changed to 16, right? Any other
>  soname changes?

Yes.  Here is the transformed git diff results on soname changes:

software@merlin> git diff 5cac57603d^ 5cac57603d cmake |grep '^[+-]set' |grep 'SOVERSION ' |sort --key=1.2
-set(plplot_SOVERSION 15)
+set(plplot_SOVERSION 16)
-set(plplotada_SOVERSION 2)
+set(plplotada_SOVERSION 4)
-set(plplotcxx_SOVERSION 13)
+set(plplotcxx_SOVERSION 14)
-set(plplotdmd_SOVERSION 3)
+set(plplotdmd_SOVERSION 4)
-set(plplottcltk_SOVERSION 13)
+set(plplottcltk_SOVERSION 14)

I plan to put some variant of this command in README.Release_Manager_Cookbook for
next time since it makes obvious any typograpical errors in the library version updates
such as incrementing plplotada_SOVERSION by 2 rather than 1, above.  Sigh...

>
> * Is it now possible to build for more than one Python version? In
>  Debian, we would need to build it for all available Python 3 versions
>  (Python 3.6 and 3.7 in the moment), it would be nice if that would be
>  supported directly. Same is for the pyqt5 driver.

Sorry, we don't have direct support for building against multiple soft dependencies.
So to provide this capability I assume you have some combination of multiple builds for multiple
Python 3 versions.  But for the second and subsequent builds you can eliminate most
of the repeated stuff that you don't need to make the multiple builds quite efficient.

For example, if you use the CMake options

-DDEFAULT_NO_BINDINGS=ON -DENABLE_python -DENABLE_pyqt5 -DDEFAULT_NO_DEVICES=ON

you will end up not building any devices and no bindings other than python and pyqt5.  So
the only redundant builds left should be the small libraries in the lib directory
and the core C library itself that depends on those.

> * Given that Python 2 will die in 16 months, do you object when removing
>  the Python 2 (python-plplot and python-plplot-qt) packages?

A year or more ago I had direct advice from a Python developer that
bugs in Python 2 (i.e., a corruption I discovered back then in one of
my Python2-generated *.pyc files that was due to a Python2 race
condition) are rarely fixed any more.  So I haven't deprecated our
Python 2 capabilities yet, but it is "on my radar", and if you choose
to remove those capabilities for your Debian packages that is fine
with me.

[...]
> When I try to run the build time test, I get an error:
>
> ------------------------8<-----------------------------
> ctest  --extra-verbose
> UpdateCTestConfiguration  from :/build/plplot-5.14.0+dfsg/DartConfiguration.tcl
> UpdateCTestConfiguration  from :/build/plplot-5.14.0+dfsg/DartConfiguration.tcl
> Test project /build/plplot-5.14.0+dfsg
> Constructing a list of tests
> Updating test list for fixtures
> Added 0 tests to meet fixture requirements
> Checking test dependency graph...
> Checking test dependency graph end
> No tests were found!!!
> /usr/bin/make -C obj-* VERBOSE=1 test_diff_psc
> make[2]: Entering directory '/build/plplot-5.14.0+dfsg/obj-x86_64-linux-gnu'
> make[2]: *** No rule to make target 'test_diff_psc'.  Stop.
> ------------------------8<-----------------------------
>
> Should I do now something different than
>
> $ ctest  --extra-verbose
> $ make -C obj-* VERBOSE=1 test_diff_psc

You have to build the "all" target before you run ctest.  Otherwise, you will get
no tests as above.

I have never tried the -C option to make, but apparently it is a way to
short-circuit recursive invocations of make.  But I doubt that idea is robust
for all versions of cmake, and therefore I suggest you just drop
that option.  After all, running

make VERBOSE=1 test_diff_psc

is already quite fast and the time difference between using the -C option (when it works)
versus not has got to be negligible since that time is dominated by running all the C examples
for the psc device.

By the way, why are you building individual low-level test targets such as test_diff_psc?  Wouldn't it
be much more efficient to, say, build all low-level noninteractive tests in parallel, with, say
(assuming you have access to a computer with 16 threads)

make -j16 VERBOSE=1 test_noninteractive

?

Right now, when I do that here, I am getting time results equivalent to 4.5 threads, but
other compilation-only tests I have done show that efficiency statistic can rise to the equivalent
of about 15 threads (on my Ryzen 7 1700 system with 8 cpus and 16 hardware threads).  So
I think the reduced parallel efficiency of test_noninteractive is because those jobs
are generating so many files, i.e., the task is i/o dominated rather than cpu-dominated.
However, I have plans to try it out with an SSD (which should have much quicker i/o),
and it will be interesting in that case if I can get the equivalent thread number
up near 16 as well.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] plplot-5.14.0 has been released

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

Hi Alan,

"Alan W. Irwin" <Ala...@gm...> writes:
> A comprehensive test and some additional specific tests of my fix for the
> release critical bug went well, and as a result I have now released
> 5.14.0.  See my forthcoming post to plplot-general for the details
> concerning that release.

thank you very much for preparing the new release! And congratulations
for the success!

I am now preparing the Debian package, and for there, I have a few
questions:

* the soname (ABI version) of libplplot changed to 16, right? Any other
  soname changes?

* Is it now possible to build for more than one Python version? In
  Debian, we would need to build it for all available Python 3 versions
  (Python 3.6 and 3.7 in the moment), it would be nice if that would be
  supported directly. Same is for the pyqt5 driver. 

* Given that Python 2 will die in 16 months, do you object when removing
  the Python 2 (python-plplot and python-plplot-qt) packages? Supporting
  Python 2 and Python 3 in the same build is really a pain, since many
  of the paths (f.e. numpy) are different, and Python 2 will become
  obsolete within the life time of the next Debian version.

When I try to run the build time test, I get an error:

------------------------8<-----------------------------
ctest  --extra-verbose
UpdateCTestConfiguration  from :/build/plplot-5.14.0+dfsg/DartConfiguration.tcl
UpdateCTestConfiguration  from :/build/plplot-5.14.0+dfsg/DartConfiguration.tcl
Test project /build/plplot-5.14.0+dfsg
Constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
No tests were found!!!
/usr/bin/make -C obj-* VERBOSE=1 test_diff_psc
make[2]: Entering directory '/build/plplot-5.14.0+dfsg/obj-x86_64-linux-gnu'
make[2]: *** No rule to make target 'test_diff_psc'.  Stop.
------------------------8<-----------------------------

Should I do now something different than

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

for the build time test?

Best regards

Ole

[Plplot-devel] plplot-5.14.0 has been released

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

Dear PLplot developers:

A comprehensive test and some additional specific tests of my fix for the
release critical bug went well, and as a result I have now released
5.14.0.  See my forthcoming post to plplot-general for the details
concerning that release.

Here, I wish to thank Arjen Markus and Phil Rosenberg for their
direct contributions to this release, and many others here for their
indirect contributions via bug reports, using the git master tip
version to make sure it is always working for your particular needs,
participating in development discussions, etc.

Please take a critical look at plplot.org.  That site has been newly
reviewed, regenerated and uploaded as part of the recent release
process by me but other eyes on it will likely find more that needs
changing.

Of course, the soft freeze for pushing commits to SF is now over so
I encourage you to mature your git topic branches and push those
as well as push bug fixes as soon as possible in this new release cycle
to maximize the time we can test such changes during this current
release cycle which I currently plan will be something like 6 months
long.

My first priority for this release cycle is to make my Linux computer
stable so that lockups (and attempts to find the cause of those) that
occur on time scales of 1 day to 5 days are not distracting me near
the end of this release cycle.  But I also have a whole host of
quick bug fixes and small development topics on my ToDo list that I put
off near the end of the last release cycle, that I want to finish up
early in this release cycle.  Thus, if all goes well, you will see lots of
git activity from me in the coming weeks as I clear out that ToDo list.

Good luck with your own PLplot development and testing during this
release cycle!

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] 5.14.0 release status

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

On 2018-12-10 19:04-0800 Alan W. Irwin wrote:

> Hi Phil:
>
> This is mostly addressed to you because it turns out one of your
> commits is causing release-critical trouble with the plsori
> call in example 3 as well as any attempt to use a non-zero -ori
> option.
[...]
> I used the commands
>
> make -j16 x01c ; make -j16 cairo
> examples/c/x01c -dev xcairo -ori 0.001
>
> to help git bisect the issue.
[...]
> @Phil:
> This commit (or its reverse) is not intrusive at all so it should not
> be that difficult to figure out why this change had such a
> catastrophic effect on plsdiori.

Hi Phil (again):

After some investigation I decided to make the
following *local* change to the master tip version.

diff --git a/src/plcore.c b/src/plcore.c
index 8d82b5b0f..33c84eeb7 100644
--- a/src/plcore.c
+++ b/src/plcore.c
@@ -1965,10 +1965,10 @@ calc_didev( void )

  // Set clip limits to conform to new page size

-    plP_sclp( (PLINT) ( plsc->didxax * plsc->phyxmi + plsc->didxb ),
-        (PLINT) ( plsc->didxax * plsc->phyxma + plsc->didxb ),
-        (PLINT) ( plsc->didyay * plsc->phyymi + plsc->didyb ),
-        (PLINT) ( plsc->didyay * plsc->phyyma + plsc->didyb ) );
+    plsc->diclpxmi = (PLINT) ( plsc->didxax * plsc->phyxmi + plsc->didxb );
+    plsc->diclpxma = (PLINT) ( plsc->didxax * plsc->phyxma + plsc->didxb );
+    plsc->diclpymi = (PLINT) ( plsc->didyay * plsc->phyymi + plsc->didyb );
+    plsc->diclpyma = (PLINT) ( plsc->didyay * plsc->phyyma + plsc->didyb );
  }

This change reverses one part of your commit that is obviously incorrect (since
plP_sclp does not set plsc->diclpxmi et al and instead sets struct
elements with almost the same name (clpxmi rather than diclpxmi, etc.))

My quick tests of this change shows it restores proper functioning
of -ori and example 3 while also having good rendering results for

examples/c/x33c -dev wxwidgets

as well as -dev xwin, -dev xcairo, and -dev qtwidget.

So I am hugely relieved to have found this solution for this
regression so quickly. However, I haven't pushed this change yet
because I haven't comprehensively tested it yet.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] 5.14.0 release status

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

Hi Phil:

This is mostly addressed to you because it turns out one of your
commits is causing release-critical trouble with the plsori
call in example 3 as well as any attempt to use a non-zero -ori
option.

The current status of the PLplot-5.14.0 release process is as follows:

The PLplot development freeze that started on October 27th contines,
i.e., do not push any topics other than documentation updates or
well-tested bug fixes.

I had gotten to the stage in README.Release_Manager_Cookbook where I
was checking a locally generated version of our website when I
discovered all lines were missing from example 3 for pngcairo.
Further checking revealed that if plsori is called with a non-zero
value (example 3) or the -ori option is used with a non-zero value
(all other examples), then all graphical elements in the plot
disappear for all device drivers!

The plsori routine is simply a wrapper for plsdiori, and the -ori
command-line option calls plsdiori directly.  So this changed behaviour
for plsdiori since 5.13.0 is a substantial regression which
is therefore release critical.

I used the commands

make -j16 x01c ; make -j16 cairo
examples/c/x01c -dev xcairo -ori 0.001

to help git bisect the issue, and from that bisection the first commit
to cause missing graphics (i.e., missing lines) for that last command
(or the same command for any other device) was your commit
plplot-5.13.0-47-g124a0c3a2, with the subject line: "Set all clip
limit changes I could find to use plP_sclp and hence get recorded in
the buffer"

Furthermore, for a local topic branch based on master tip, if I
locally reverse that commit, the problem with missing graphics for the
above example is solved and similarly (note that example 3 contains
a call to plsori)

examples/c/x03c -dev xcairo

(or any other device) works fine (without missing graphics) as well.

With the reversed commit, one thing that does not work well is (as expected)

examples/c/x33c -dev wxwidgets

which has rendering issues (missing lines and other graphical items).
However, my test of that example with -dev xcairo, -dev qtwidget, and
-dev xwin do render well with this reversed commit.

@Phil:
This commit (or its reverse) is not intrusive at all so it should not
be that difficult to figure out why this change had such a
catastrophic effect on plsdiori.

N.B. Once I have that figured out, I will likely just go ahead and
reverse your commit so that -ori and calls to plsori continue to work
properly for our users just like they did for release 5.13.0.  Of
course, reversing your commit means that your attempt to record clip
limits in the buffer this way in order to fix "examples/c/x33c -dev wxwidgets"
will have to be addressed post-release
in a way that preserves the functionality of -ori and plsori, but
likely that will be far more intrusive than your commit
plplot-5.13.0-47-g124a0c3a2 so it very likely should be a post-release
change in any case.

In sum, if I don't hear back from you quickly, I will likely just go
ahead and reverse your commit tomorrow (Tuesday) and comprehensively
test that change in anticipation of making the release later
tomorrow.

More later.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Help needed for plplot runtime tests

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

On 2018-12-06 14:41+0100 Ole Streicher wrote:

> Hi Alan,
>
> sorry for the delay; I now managed to adjust and run the test suite on
> the installed package. I'll attach the full log; commands were
>
> $ cmake /usr/share/doc/plplot-doc/examples/
> $ make VERBOSE=1 test_noninteractive
>
> I needed to downgrade to cmake 3.12; see bug #191.

Hi Ole:

I am glad to hear you are so close to complete success.

My recent comprehensive test with 3.13.1 works perfectly here for
Debian Buster and the git master tip version of PLplot.  That master
tip version includes a fix for bug 191 so could you confirm that by
trying the master tip version (and then closing that bug if that
indeed fixes it)?

> The only remaining
> errors are now ADA errors:
>
> Building Ada object ada/CMakeFiles/xstandard16a.dir/xstandard16a.o
> make[3]: *** No rule to make target 'plplotada-NOTFOUND', needed by
> 'ada/xstandard16a'.

My recent comprehensive test using cmake-3.13.1 had no such Ada issue.
So very likely this issue is because your installation is missing the
plplotada *.so file or *.so.*.* file it links to, or this issue is an
artifact of the way Debian packaging software changes locations or
*.so names to some special Debian package naming scheme.

So to debug this final issue do the following:

* Make sure you are using the PLplot master tip version so we are on
   the same page with regard to bug fixes.  This is really important
   since many 5.13.0 bugs are fixed in master tip which is now very
   close to 5.14.0.  (I am now in the process of updating the release notes
   for that forthcoming release.)

* Make sure your Ada binary package or packages are installed, and in those you should find
   the full pathname of the plplotada *.so file that should be installed
   by that package.

* Check the Ada information in your installed and sed-transformed
   export files for consistency with that full pathname.

If there is an Ada install directory inconsistency, then adjustment of
the Ada install location you use for your core build should fix that.
If there is a name inconsistency, then you need to make that
consistent with some special Debian naming scheme for Ada *.so files by transforming
our export files with a sed script.  You told me of one such naming inconsistency
you discovered before for a python related *.so file, and this may be just one other instance
of the problem or all *.so files may have names that are inconsistent with the actual
install name.  In all cases if the *.so file name (without the path) does not match what is actually
installed, a sed script should correct that inconsistency.  Otherwise, it is "an accident
waiting to happen" as appears to be the case both for that *.so Python module and now
the Ada *.so file.

If those steps don't help you to completely resolve this matter,
please collect the following information and send it to me.  (i) The
complete list of files in your Ada binary packages (presumably some
rpm command will generate that), (ii) the output from the cmake
command you used *for the core build*, and (iii) the actual original
and sed-modified export files.  I am virtually positive that
information will be sufficient for me to figure out what is wrong.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] 5.14.0 release status

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

@All:

The current status of the PLplot-5.14.0 release process is as follows:

The PLplot development freeze that started on October 27th contines,
i.e., do not push any topics other than documentation updates or
well-tested bug fixes.

@Phil:
As part of the release process I added (commit
plplot-5.13.0-157-g6e7b51cae) a number of sections to README.release
discussing important improvements that were committed during this
release cycle.  There are more such sections to add, but I believe I
am finished with the sections that are already there.  However, I am
certainly capable of mistakes and/or bad writing so I would appreciate
you critically reading section 2.9 which summarizes your work on plmap
during this release cycle, and especially section 2.10 which
summarizes what I think are the current important wxwidgets issues.

While writing up the -DPL_WXWIDGETS_IPC3=OFF or ON discussion that is
part of section 2.10, I was reminded from my preliminary ChangeLog for
this release how hard you had worked during this release cycle on
fixing wxwidgets bugs.  So in light of all those changes I repeated
tests I had done earlier in the release cycle before your changes for
-DPL_WXWIDGETS_IPC3=OFF and ON for -locate mode for example 1.
Previously that interactive example had failed in two different ways
on Linux for those two cases as I reported to you back then.  With your fixes
(none of which directly affected our IPC code for either
-DPL_WXWIDGETS_IPC3=OFF or ON as far as I know) I continued to get the
same bad results as before (the display of the plot would not appear
until several mouse clicks had occurred on the blank plotting area of
the GUI) for the -DPL_WXWIDGETS_IPC3=OFF case.

However, the -DPL_WXWIDGETS_IPC3=ON test case result was a really good
surprise; it worked for the first time ever for that interactive
example!  So I am very happy about whatever non-IPC fix you did that
made that happen.  And I am left wondering if whether that example
will also work (e.g., without the deadlocks you noticed before) on
Windows now (i.e., after your seemingly unrelated fixes) for the
-DPL_WXWIDGETS_IPC3=ON case.  So I would appreciate you letting me
know about that so I can update section 2.10 accordingly.

@All:

The 5.14.0 release process will continue next with adding
several additional topics to README.release to finish preparation
of those release notes for 5.14.0.

More later.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] 5.14.0 release status

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

On 2018-12-01 18:35-0800 Alan W. Irwin wrote:

The current status of the PLplot-5.14.0 release process is as follows:

The PLplot development freeze that started on October 27th contines,
i.e., do not push any topics other than documentation updates or
well-tested bug fixes.

As part of the release process I have summarized (commit
plplot-5.13.0-156-g39a15ae66) my recent comprehensive test reports for
Debian Buster as the first two entries in the table at
<https://sourceforge.net/p/plplot/wiki/Testing_Reports/>.

The late October test was with cmake-3.7.2 (our minimum allowed
version of CMake).  Those results were perfect except that I forgot to
install the haru software package so -dev pdf did not get tested.  I
corrected that oversight for my latest comprehensive test which I
performed using cmake-3.13.1 (the latest release of CMake).  Those
results were perfect except for a run-time regression against the
October results where the installed versions of qt_example and
pyqt5_example.py both segfaulted.

So for the final run of the comprehensive test script (which was
perfect) I had to drop those tests using -DPLD_extqt=OFF.  I don't
think this issue is release critical so I am going to continue with
the rest of the release process in README.Release_Manager_Cookbook
with no code changes or further comprehensive tests.

However, I have since discovered that for one combination (cmake 3.7.2
+ shared libraries/dynamic devices + build tree), valgrind shows no
memory management errors (i.e, segfaults were impossible for that
combination) so a detailed valgrind comparison of all combinations
possible (for all combinations tested by the comprehensive test script
where only qt_example is tested for both cmake-3.7.2 and cmake-3.13.1)
should easily find the specific PLplot or external cause of these
segfaults, and if it is a PLplot issue I hope to make the fix soon
after 5.14.0 is released.

The 5.14.0 release process continues....

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] 5.14.0 release status

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

Hi Alan

-----Original Message-----
From: Alan W. Irwin <Ala...@gm...>
Sent: zondag 2 december 2018 03:35
To: Arjen Markus <Arj...@de...>; PLplot development list <Plp...@li...>
Subject: Re: [Plplot-devel] 5.14.0 release status

The current status of the PLplot-5.14.0 release process is as follows:

The PLplot development freeze that started on October 27th contines, i.e., do not push any topics other than documentation updates or well-tested bug fixes.

As part of the release process I have summarized (commit
plplot-5.13.0-153-g0d50e2a2a) Arjen's recent Cygwin and
MinGW-w64/MSYS2 comprehensive test reports as the first two entries in the table at <https://sourceforge.net/p/plplot/wiki/Testing_Reports/>.

@Arjen:

Could you please review those table entries to make sure my summaries of your comprehensive tests are correct?

My next planned step is to update that table again with my own recent comprehensive test reports, and then continue with the remaining parts of README.Release_Manager_Cookbook to finish the 5.14.0 release.


--
AM: Sure, I will do that - I have been looking at the "comprehensive testing"page and I have a few suggestions. I will combine that.

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] 5.14.0 release status

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

The current status of the PLplot-5.14.0 release process is as follows:

The PLplot development freeze that started on October 27th contines,
i.e., do not push any topics other than documentation updates or
well-tested bug fixes.

As part of the release process I have summarized (commit
plplot-5.13.0-153-g0d50e2a2a) Arjen's recent Cygwin and
MinGW-w64/MSYS2 comprehensive test reports as the first two entries in
the table at <https://sourceforge.net/p/plplot/wiki/Testing_Reports/>.

@Arjen:

Could you please review those table entries to make sure my summaries
of your comprehensive tests are correct?

My next planned step is to update that table again with my own recent
comprehensive test reports, and then continue with the remaining parts
of README.Release_Manager_Cookbook to finish the 5.14.0 release.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Rewrite of our Testing_PLplot wiki entry and new method of updating our wiki pages

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

On 2018-11-29 07:45-0000 Arjen Markus wrote:

> Hi Alan,
>
> I will read this page on my way home, but for now my main critique is that it does not show up on the front page of the Wiki, whereas the first sentence is:
> "We encourage those who build PLplot to test both their build-tree and installed-examples-tree versions on any Linux, Windows, or Mac OS X platform."
>
> Currently, you have to know the page exists to find it 😉.

Thanks for this good suggestion which I have just implemented (commit plplot-5.13.0-151-g38f41b6bf
and <https://sourceforge.net/p/plplot/wiki/Home/>.

<git blog aside>
I am trying to develop the habit of using "git describe" to describe
all commits as above.  For those who don't know about "describe"
results yet, "plplot-5.13.0-151" says the commit is the 151st since
plplot-5.13.0, and "g38f41b6bf" says the git commit id is 38f41b6bf
(i.e. drop the "g" which I assume stands for git, but it is easy to
remember to drop it in any case since "g" is not hexadecimal).
</git blog aside>

By the way, this change fitted in well with the current organization
of that Home page which I like.  So I believe the only real issue with
our wiki at that stage is too many of the pages are severely outdated.
To illustrate this point, here are the current results adapted from
<https://sourceforge.net/p/plplot/wiki/browse_tags/>

2006	Configure_PLplot_for_Borland_CXX_5.5_(free_command_line_tools)
2007	Configure_PLplot_for_Borland_Turbo_C++_Explorer_Edition_(free_IDE_and_compiler)
2008	Additional_notes_for_ifort_users; Aquaterm; Debugging_code; Documenting_the_undocumented; List_of_Debian_Ubuntu_packages; Mac_OSX; Qhull; Setup_watcom
2009	Apply_a_patch; Configuration_of_wxWidgets_driver; Freetype; Frequently_Asked_Questions; Lua; OCaml_tutorial; Qt; Setup_mingw; Submit_a_patch; Swig; Using_PLplot; WxWidgets
2010	Cairo_pango; Configure_PLplot_for_MinGW_CLI; Git_miscellanea; Install_3rd_party_libraries; Install_Lua; Install_MinGW_MSYS; Install_Octave; Install_SWIG; Install_Tcl; Libgd; Third-party_libraries
2011	Building_PLplot_with_a_cross-compiler; Mac_OSX_Status; Todo_List
2012	Configure_PLplot_for_Visual_CXX_CLI
2013	Install_Python; Setup_Visual_Studio_Express; Setup_visualc; Specifics_for_various_platforms
2014	Building_PLplot; Configure_PLplot_for_the_Visual_Studio_IDE; General_CMake_documentation_links
2015	CMake_options_for_PLplot; Configure_PLplot_for_cygwin; Linux; Setup_cygwin
2017	Overview_of_the_status_on_Windows
2018	Home; MinGW-w64-MSYS2; Testing_PLplot; Testing_Reports

>From this list only 9 of our 54 pages have been updated since 2014!

To all those here who would like to help out with our wiki.  Please
pick one of the topics above and update the corresponding markdown
format file in doc/wiki_source, and commit that change to a local
topic branch of your git repository.

Those here who are not core developers should send us your suggested
change in "git format-patch" form.  After applying your commit on our
own local topic branch, we will review your suggested change, cut and
paste it to the SF GUI editor for the wiki page in question, test the
resulting changed wiki page (e.g., check the history GUI to make sure
there were no cut and paste failures, check the new links, check the
rendering of the markdown format looks good), amend your commit if
necessary, and push your (amended) commit following the directions in
README.developers.

Core developers here can skip the "git format-patch" command, but
otherwise do everything else in the paragraph above (just like I did
for Home) to update wiki pages that are important to you.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Help needed for plplot runtime tests

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

On 2018-11-29 13:33+0100 Ole Streicher wrote:

[...]
> Now, all C examples pass.

Excellent!

> For ADA, I now however get
>
> [ 11%] Built target test_c_psc
> Scanning dependencies of target xstandard16a
> [ 11%] Building Ada object ada/CMakeFiles/xstandard16a.dir/xstandard16a.o
> make[3]: *** Keine Regel vorhanden, um das Ziel „plplotada-NOTFOUND“,
>  benötigt von „ada/xstandard16a“, zu erstellen.  Schluss.
> make[2]: *** [CMakeFiles/Makefile2:5655:
> ada/CMakeFiles/xstandard16a.dir/all] Fehler 2
> make[1]: *** [CMakeFiles/Makefile2:387:
> CMakeFiles/test_noninteractive.dir/rule] Fehler 2
>

The build of xstandard* examples is configured by the CMake logic in
examples/ada/CMakeLists.txt.

I am pretty sure the relevant CMake logic lines to build the Ada examples in that file for this case where it is not the CORE_BUILD are

set(adalinkflags "\"-aI${CMAKE_CURRENT_SOURCE_DIR}\" \"-aI${ADA_INCLUDE_DIR}\" \"-aL${ADA_LIB_DIR}\"")
[...]
      set_target_properties(${TARGET_NAME} PROPERTIES LINK_FLAGS ${adalinkflags})
      target_link_libraries(${TARGET_NAME} PLPLOT::plplotada PLPLOT::plplot)

So are the install locations ${ADA_INCLUDE_DIR} and ${ADA_LIB_DIR} set
where your Debian package actually installs Ada files?  And if you
look in the PLplot export file, is the PLPLOT::plplotada location
property set there consistent with the full pathname of the plplotada
library that is installed by your debian package?

If those hints don't solve it or if they do solve it but another error
is encountered, please use a clean start (i.e., an initially empty
build tree), and send me the the complete cmake output and also the
complete results of

make VERBOSE=1 test_noninteractive >& test_noninteractive.out

(i.e., without any parallel build options).

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-devel] git blog

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

I just discovered the --word-diff option to "git diff" command.  That
option has proven to be essential for evaluation of my recent commits
concerning markdown format files (which all have extraordinarily long
lines which makes "git diff" output without the --word-diff option
essentially impossible to interpret).

To show how useful this option is, compare results from

git diff 7bedc70ad0^ 7bedc70ad0

and

git diff --word-diff 7bedc70ad0^ 7bedc70ad0

The former result is essentially impossible to interpret because of
the very long lines while the latter clearly shows the small tweaks I
performed on those long lines for commit 7bedc70ad0.

I am happy we are using git because I keep finding such cool
functionality (as above).  :-)

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Help needed for plplot runtime tests

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

On 2018-11-27 13:44+0100 Ole Streicher wrote:

> Hi Alan,
>
> thanks for the help so far!

Hi Ole:
You are welcome.

>
> On 26.11.18 19:52, Alan W. Irwin wrote:
>> On 2018-11-26 16:46+0100 Ole Streicher wrote:
>> It appears that CMake hard codes the filename on export.  For example,
>>
>> software@merlin> grep _Pltk_init.so export_plplot-noconfig.cmake
>>   IMPORTED_LOCATION_NOCONFIG
>> "/home/software/plplot/HEAD/comprehensive_test_disposeable
>> blank/shared/noninteractive/install_tree/lib/python3.6/site-packages/_Pltk_init.so"
>>
>> list(APPEND _IMPORT_CHECK_FILES_FOR_PLPLOT::_Pltk_init
>> "/home/software/plplot/HEAD/comprehensive_test_disposeable
>> blank/shared/noninteractive/install_tree/lib/python3.6/site-packages/_Pltk_init.so"
>> )
>>
>> where export_plplot-noconfig.cmake is (on my system) installed in the
>> $prefix/lib/cmake/plplot directory.  And you will find similar
>> hard-coded filenames for all other libraries and shared objects
>> (dll's) in that file.
>
> I now just remove the checks via sed:
>
> sed
> '/\/_Pltk_init.so/d;/\/_plplotc.so/d;/\/plplot_pyqt5_/d;/\/libplplotada.so/d'
> \
> -i /usr/lib/*/cmake/plplot/export_plplot-none.cmake
>
> And I also removed them from the dependencies in CMakeList.txt of the
> examples subdir.

This is not a good idea.  I haven't checked deeply, but our build and
test system for the installed examples may use the location property
of the imported PLPLOT::_Pltk_init target which you have removed with
the above step.  Or we may make such a change later. So if this is not
an issue now, it is "an accident waiting to happen".  So I strongly
suggest instead you fix this properly by using your sed command to
replace (not remove) _Pltk_init.so with the correct Debianized name
for that installed file.

> Then, cmake runs fine But the "make" command gives errors after 8%
> completion:
>
> --------------------------8<-----------------------------------------
> x19c
>
> *** PLPLOT ERROR, ABORTING OPERATION ***
> Could not find ss/ss64ne_Landform_Area file., aborting operation
> [... repeating the same warning for different files]
>
> *** PLPLOT ERROR, ABORTING OPERATION ***
> Could not find ss/ss64ne_General_Text file., aborting operation
> make[3]: *** [CMakeFiles/test_c_svgqt.dir/build.make:294:
> test_examples_output_dir/x00c01.svgqt] Fehler 1
> --------------------------8<-----------------------------------------

A recent install of mine has the following shapelib data files installed in
$prefix/share/plplot$version/ss
os_open_conditions.txt    ss64ne_Height_Contours.dbf  ss64ne_Landform_Line.prj    ss64ne_Water_Area.shp
ss64ne_Building_Area.dbf  ss64ne_Height_Contours.prj  ss64ne_Landform_Line.shp    ss64ne_Water_Area.shx
ss64ne_Building_Area.prj  ss64ne_Height_Contours.shp  ss64ne_Landform_Line.shx    ss64ne_Water_Line.dbf
ss64ne_Building_Area.shp  ss64ne_Height_Contours.shx  ss64ne_Road_Centreline.dbf  ss64ne_Water_Line.prj
ss64ne_Building_Area.shx  ss64ne_Landform_Area.dbf    ss64ne_Road_Centreline.prj  ss64ne_Water_Line.shp
ss64ne_General_Text.dbf   ss64ne_Landform_Area.prj    ss64ne_Road_Centreline.shp  ss64ne_Water_Line.shx
ss64ne_General_Text.prj   ss64ne_Landform_Area.shp    ss64ne_Road_Centreline.shx
ss64ne_General_Text.shp   ss64ne_Landform_Area.shx    ss64ne_Water_Area.dbf
ss64ne_General_Text.shx   ss64ne_Landform_Line.dbf    ss64ne_Water_Area.prj

Example 19 depends on these map data so these files are absolutely
necessary for example 19 to work.  Also, I believe we have had some
discussion in the past on the licensing of these files, and I am
positive you were satisfied on that issue.  An apt-file search for
these files here tells me they have not been included in the past in
Debian PLplot packages (likely because of unclear licensing concerns
which we have addressed), but once you address that issue, the above
errors should go away.  And that change (and the sed command change I
recommended above) might be all you need to do to have a complete test
success since the above error occurring for example 19 means almost
half the standard examples work fine for you now.  And, yes, I am a
"glass half full" rather than "glass half empty" kind of guy.  :-)

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] 5.14.0 release status

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

The current status of the PLplot-5.14.0 release process is as follows:

The PLplot development freeze that started on October 27th contines,
i.e., do not push any topics other than documentation updates or
well-tested bug fixes.

I have just finished pushing a rewrite of the Testing_PLplot wiki page, and I
plan to follow up with

1. Updating the new wiki page, Testing_Reports, with recent comprehensive test results.

2. Doing all the usual steps documented in README.Release_Manager_Cookbook to finish
    up this release.

So even though the computer instability I mentioned before is still
something of a distraction, I have developed some temporary
workarounds for the issue that should allow me to get through the
above steps without too many more delays.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-devel] Rewrite of our Testing_PLplot wiki entry and new method of updating our wiki pages

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

Hi Arjen:

I have just (the series of commits leading up to f7bedc70a) pushed a
much-needed documentation update for
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot> where the test
reports (so far not updated) have been separated out into their own
wiki area <https://sourceforge.net/p/plplot/wiki/Testing_Reports>.

Since you also use our test system a lot, I would appreciate your
critical review of this updated documentation.  As my next step, I
intend to update the Testing_Reports page with results from your
recent good comprehensive tests on your Cygwin and MinGW-w64/MSYS2
platforms and my own recent good comprehensive tests on my Linux
(Debian Buster) platform.

N.B. I seriously do not like the really weird markdown editor that is
available at SourceForge for our wiki pages.  As far as I am concerned
that GUI editor is mostly good for the extremely old-fashioned version
(with ctrl-c, ctrl-v, and delete) of cut and paste and that is about
it.  And I am also not happy with the SF methods to allow us to only
backup those markdown files in non-standard JSON format that no JSON
converter can convert back to markdown!  Therefore, as part of the
preliminaries to updating Testing_PLplot, I have put all the markdown
source for our SF wiki pages under git control in the PLplot source
tree.  So from now on, updating a wiki page such as Testing_PLplot
means you should edit the definitive markdown source for that wiki
page in our source tree (at doc/wiki_source/Testing_PLplot for this
particular example) using your favorite editor, check the results by
cutting and pasting those changes to the wiki edit GUI (available at
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/> for this
particular example), exit that SF GUI editor (which allows you to view
the revised SF wiki entry generated by that GUI edit session), and if
happy with that result, git commit the updated markdown file in our
source tree.  Or if you really like that GUI editor you can use it
to edit our wiki at SF so long as you remember to cut and paste
(that revised result directly from that GUI editor (not the SF page that
links to that editor!) to the appropriate file in doc/wiki_source in
our source tree and git commit that revised result.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Help needed for plplot runtime tests

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

On 2018-11-26 16:46+0100 Ole Streicher wrote:

> Hmm, no. It installs the file on the expected place, but *after* this
> (just before the files are put into the package), its name is changed
> to_Pltk_init.x86_64-linux-gnu.so (so, the architecture triple is added).
> Similarly for _plplotc.so (to _plplotc.x86_64-linux-gnu.so) and for the
> Python 3 shared libs (there, the name contains the Python version as well).
>
> So, it is not an inconsistent location, but a different file name.

It appears that CMake hard codes the filename on export.  For example,

software@merlin> grep _Pltk_init.so export_plplot-noconfig.cmake
   IMPORTED_LOCATION_NOCONFIG "/home/software/plplot/HEAD/comprehensive_test_disposeable blank/shared/noninteractive/install_tree/lib/python3.6/site-packages/_Pltk_init.so"
list(APPEND _IMPORT_CHECK_FILES_FOR_PLPLOT::_Pltk_init "/home/software/plplot/HEAD/comprehensive_test_disposeable blank/shared/noninteractive/install_tree/lib/python3.6/site-packages/_Pltk_init.so" )

where export_plplot-noconfig.cmake is (on my system) installed in the
$prefix/lib/cmake/plplot directory.  And you will find similar
hard-coded filenames for all other libraries and shared objects
(dll's) in that file.

To solve this I suggest you simply use a sed script to add the
architecture triple expected by Debian for the relevant filenames in
the above file.

Good luck with that suggested change and let me know how it goes.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Help needed for plplot runtime tests

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

Hi Alan,

On 23.11.18 22:17, Alan W. Irwin wrote:
> On 2018-11-23 08:28+0100 Ole Streicher wrote:
>> -- Could NOT find Qt5Svg (missing: Qt5Svg_DIR)
>> CMake Warning at
>> /usr/lib/x86_64-linux-gnu/cmake/plplot/plplotConfig.cmake:5
>> (find_package):
>>  Found package configuration file:
>>
>>    /usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake
>>
>>  but it set Qt5_FOUND to FALSE so package "Qt5" is considered to be NOT
>>  FOUND.  Reason given by package:

That was actually my fault; I didn't install all plplot packages.

>> CMake Error at
>> /usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot.cmake:279 (message):
>>  The imported target "_Pltk_init2.7" references the file
>>
>>     "/usr/lib/python2.7/dist-packages/_Pltk_init.so"
>>
>>  but this file does not exist.  Possible reasons include:

This however remains.

> II. The second problem above starts with the message
> 
> CMake Error at
> /usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot.cmake:279 (message)
> 
> I am virtually positive what is going on is that PLplot installs the
> files corresponding to the exported target PLPLOT::_Pltk_init.so in
> one location, e.g., "/usr/lib/python2.7/dist-packages/_Pltk_init.so"
> and your Debian packaging automatically changes that location to
> something else creating an inconsistency between the location expected
> by the exported target, and the location where the file was installed.

Hmm, no. It installs the file on the expected place, but *after* this
(just before the files are put into the package), its name is changed
to_Pltk_init.x86_64-linux-gnu.so (so, the architecture triple is added).
Similarly for _plplotc.so (to _plplotc.x86_64-linux-gnu.so) and for the
Python 3 shared libs (there, the name contains the Python version as well).

So, it is not an inconsistent location, but a different file name.

> Please look at your core build (not the build of the installed
> examples you were testing above) cmake output for instructions about
> how to get PLplot to modify installation locations.  For example, here
> is the relevant part of my cmake output:
> 
> -----------------------------------------------8<-------------------------------------
> 
> CMAKE_INSTALL_PREFIX: /home/software/plplot/installcmake
> CMAKE_INSTALL_EXEC_PREFIX: /home/software/plplot/installcmake
> CMAKE_INSTALL_BINDIR: /home/software/plplot/installcmake/bin
> CMAKE_INSTALL_DATADIR: /home/software/plplot/installcmake/share
> CMAKE_INSTALL_LIBDIR: /home/software/plplot/installcmake/lib
> CMAKE_INSTALL_INCLUDEDIR: /home/software/plplot/installcmake/include
> CMAKE_INSTALL_INFODIR: /home/software/plplot/installcmake/share/info
> CMAKE_INSTALL_MANDIR: /home/software/plplot/installcmake/share/man
> CMAKE_INSTALL_PKG_CONFIG_DIR:
> /home/software/plplot/installcmake/lib/pkgconfig
> DATA_DIR: /home/software/plplot/installcmake/share/plplot5.13.0
> LIB_DIR: /home/software/plplot/installcmake/lib
> INCLUDE_DIR: /home/software/plplot/installcmake/include/plplot
> BIN_DIR: /home/software/plplot/installcmake/bin
> DRV_DIR: /home/software/plplot/installcmake/lib/plplot5.13.0/drivers
> DOC_DIR: /home/software/plplot/installcmake/share/doc/plplot
> INFO_DIR: /home/software/plplot/installcmake/share/info
> MAN_DIR: /home/software/plplot/installcmake/share/man
> PKG_CONFIG_DIR: /home/software/plplot/installcmake/lib/pkgconfig
> FORTRAN_MOD_DIR:
> /home/software/plplot/installcmake/lib/fortran/modules/plplot
> JAR_DIR: /home/software/plplot/installcmake/share/java
> JAVAWRAPPER_DIR: /home/software/plplot/installcmake/lib/jni
> PYTHON_INSTDIR:
> /home/software/plplot/installcmake/lib/python3.6/site-packages
> PLPLOT_OCTAVE_DIR: /home/software/plplot/installcmake/share/plplot_octave
> OCTAVE_M_DIR: /home/software/plplot/installcmake/share/octave/site/m/PLplot
> OCTAVE_OCT_DIR: /home/software/plplot/installcmake/lib/octave
> TCL_DIR: /home/software/plplot/installcmake/share/plplot5.13.0/tcl
> ADA_INCLUDE_DIR:
> /home/software/plplot/installcmake/share/ada/adainclude/plplotada
> ADA_LIB_DIR: /home/software/plplot/installcmake/lib/ada/adalib/plplotada
> LUA_DIR: /home/software/plplot/installcmake/lib/lua/plplot
> OCAML_INSTALL_DIR: /home/software/plplot/installcmake/lib/ocaml
> -----------------------------------------------8<-------------------------------------

That looks reasonable, see f.e.
https://buildd.debian.org/status/fetch.php?pkg=plplot&arch=amd64&ver=5.13.0%2Bdfsg-9&stamp=1538607430&raw=0

-----------------------------------------------8<-------------------------------------
CMAKE_INSTALL_PREFIX: /usr
CMAKE_INSTALL_EXEC_PREFIX: /usr
CMAKE_INSTALL_BINDIR: /usr/bin
CMAKE_INSTALL_DATADIR: /usr/share
CMAKE_INSTALL_LIBDIR: /usr/lib/x86_64-linux-gnu
CMAKE_INSTALL_INCLUDEDIR: /usr/include
CMAKE_INSTALL_INFODIR: /usr/share/info
CMAKE_INSTALL_MANDIR: /usr/share/man
CMAKE_INSTALL_PKG_CONFIG_DIR: /usr/lib/x86_64-linux-gnu/pkgconfig
DATA_DIR: /usr/share/plplot5.13.0
LIB_DIR: /usr/lib/x86_64-linux-gnu
INCLUDE_DIR: /usr/include/plplot
BIN_DIR: /usr/bin
DRV_DIR: /usr/lib/x86_64-linux-gnu/plplot5.13.0/drivers
DOC_DIR: /usr/share/doc/plplot
INFO_DIR: /usr/share/info
MAN_DIR: /usr/share/man
PKG_CONFIG_DIR: /usr/lib/x86_64-linux-gnu/pkgconfig
FORTRAN_MOD_DIR: /usr/lib/x86_64-linux-gnu/fortran/modules/plplot
JAR_DIR: /usr/share/java
JAVAWRAPPER_DIR: /usr/lib/x86_64-linux-gnu/jni
PYTHON_INSTDIR: /usr/lib/python3/dist-packages
PLPLOT_OCTAVE_DIR: /usr/share/plplot_octave
OCTAVE_M_DIR: /usr/share/octave/site/m/PLplot
OCTAVE_OCT_DIR:
/usr/lib/x86_64-linux-gnu/octave/site/oct/api-v52/x86_64-pc-linux-gnu
TCL_DIR: /usr/share/plplot5.13.0/tcl
ADA_INCLUDE_DIR: /usr/share/ada/adainclude/plplotada
ADA_LIB_DIR: /usr/lib/x86_64-linux-gnu/ada/adalib/plplotada
LUA_DIR: /usr/lib/x86_64-linux-gnu/lua/5.1/plplot
OCAML_INSTALL_DIR: /usr/lib/ocaml
-----------------------------------------------8<-------------------------------------

(The Python install dir is patched, since I build both Python 2 and 3
packages)

Best

Ole

Re: [Plplot-devel] Help needed for plplot runtime tests

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

On 2018-11-24 19:06-0700 Orion Poplawski wrote:

> On 11/24/18 11:55 AM, Alan W. Irwin wrote:
>> Hi Orion:
>> 
>> This thread has previously been directed mostly at Ole, but
>> I am including you now because I think it will interest you.  It concerns 
>> the
>> problems (one of them upstream which I plan to fix soon by factoring
>> the export files [as I promised you long ago, but it got lost on the
>> stack until Ole ran into this problem again!]) that Ole has been having
>> with Debian to get testing working properly for the installed
>> examples.
>> 
>> I would appreciate you contributing to this thread.  For example, if
>> all Fedora binary packages are installed (which works around the above
>> factoring problem until I can get it fixed) do the following tests of the
>> CMake-based and legacy-based installed examples work?
>> 
>> # CMake-based build system for the installed examples
>> # Move to initially empty build tree first.
>> rm -rf /tmp/plplot_cmake_test
>> mkdir /tmp/plplot_cmake_test
>> cd /tmp/plplot_cmake_test
>> cmake $prefix/share/plplot$plplot_version/examples
>> make -j<parallel_build_number> test_noninteractive >& 
>> test_noninteractive.out
>> 
>> # Legacy-based build system for the installed examples
>> # Keep the install-tree clean by copying the installed examples elsewhere
>> cp -a $prefix/share/plplot$plplot_version/examples /tmp
>> cd /tmp/examples
>> make -j<parallel_build_number> test_noninteractive >& 
>> test_noninteractive.out
>> 
>> If the above tests work on Fedora that proves that the Fedora
>> PLplot installation has correctly configured CMake export
>> and pkg-config *.pc files for the final Fedora installation locations.
>> 
>> Currently such tests fail for Ole's Debian packages, but I think some
>> attention to the details of PLplot installation locations will solve this
>> issue.  And similarly in your case if those tests fail for Fedora.
>> 
>> Alan
>
> It mostly seems to work fine.  The one strange error for cmake is:
>
> Generate C results for bmpqt file device
> /usr/share/plplot5.13.0/examples/test_lua.sh: line 50: lua_svg_test.error: 
> Permission denied
> [ 92%] Built target xtraditional16a
> cat: lua_svg_test.error: No such file or directory
> make[3]: *** [CMakeFiles/test_lua_svg.dir/build.make:374: 
> test_examples_output_dir/x00lua01.svg] Error 1
>
> and for make/pkgconfig:
>
> Generate Octave results for svg device
> ./plplot-test.sh --verbose --front-end=octave --device=svg
> /usr/bin/bash: ./plplot-test.sh: Permission denied
> make: *** [Makefile:126: x01o01.svg] Error 126
>
> which is due to my removing the executable bit for the example script to 
> avoid issues with automatic dependencies.

Hi Orion:

I am glad to hear you appear to have what appear to be only two minor
issues flawing complete success with the above tests.

N.B. I regret now specifying the /tmp directory for both tests since that might get overflowed
by the ~3GB of files that are produced by each of these tests when they are successful.
So modify my instructions above to create an initially empty build directory under your home
directory for the CMake-based case, and cp the installed example tree to an initially empty
examples directory under your home directory.

Here are my comments on those two issues.

I.  For CMake-based build system for the installed examples, issue with lua_svg_test.error: Permission denied.

Just to remind you, official Debian lua version 5.3.3 (but not Fedora Lua 5.3.5) has a really bad bug
that can only be avoided by using a home-built 5.3.5 (which I use for my testing).
So in my results the lua location will look quite different than yours.

Line 50 of the configured  test.lua.sh file in my case is

/home/software/lua/install-5.3.5/bin/lua x${index}.${lang} -dev $device -o "${results}"/x${index}${lang}%n.$dsuffix \
             $options 2> lua_${device}_test.error >| "${results}"/x${index}${lang}_${dsuffix}.txt

So my guess is in your case the equivalent lua command is having trouble gaining permissions to write
to /tmp. To check that try running

lua test.lua 2> test.stderr >| test.stdout

in /tmp and also your home directory where
test.lua simply writes separate test strings to stderr and stdout.

Of course, if /tmp was overflowing doing the same test under your home directory might cure the
issue.

II. For legacy build system for the installed examples, issue with ./plplot-test.sh: Permission denied

The configured and installed (in <prefix>/share/plplot5.13.0/examples)
test scripts in my case have the following permissions

software@merlin> ls -lt *.sh
-rwxr-xr-x 1 software software 14080 Oct 27 12:16 plplot-test-interactive.sh*
-rwxr-xr-x 1 software software 13782 Oct 27 12:16 plplot-test.sh*
-rwxr-xr-x 1 software software  2211 Oct 27 12:16 test_ada.sh*
-rwxr-xr-x 1 software software  2326 Oct 27 12:16 test_c.sh*
-rwxr-xr-x 1 software software  2981 Oct 27 12:16 test_c_interactive.sh*
-rwxr-xr-x 1 software software  2802 Oct 27 12:16 test_cxx.sh*
-rwxr-xr-x 1 software software  2427 Oct 27 12:16 test_d.sh*
-rwxr-xr-x 1 software software  7150 Oct 27 12:16 test_diff.sh*
-rwxr-xr-x 1 software software  2965 Oct 27 12:16 test_fortran.sh*
-rwxr-xr-x 1 software software  2898 Oct 27 12:16 test_java.sh*
-rwxr-xr-x 1 software software  2645 Oct 27 12:16 test_lua.sh*
-rwxr-xr-x 1 software software  2176 Oct 27 12:16 test_ocaml.sh*
-rwxr-xr-x 1 software software  3662 Oct 27 12:16 test_octave.sh*
-rwxr-xr-x 1 software software  4221 Oct 27 12:16 test_octave_interactive.sh*
-rwxr-xr-x 1 software software  2337 Oct 27 12:16 test_python.sh*
-rwxr-xr-x 1 software software  4556 Oct 27 12:16 test_tcl.sh*

Yours should as well since that executable permission bit is essential for all of
them to work.  So I hope you have a cunning scheme in mind to work
around your package dependency issue another way rather then removing
any/all of these essential executable bits.

And, in this case also, this test should be done in your home directory and
not /tmp.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Help needed for plplot runtime tests

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

On 11/24/18 11:55 AM, Alan W. Irwin wrote:
> Hi Orion:
> 
> This thread has previously been directed mostly at Ole, but
> I am including you now because I think it will interest you.  It 
> concerns the
> problems (one of them upstream which I plan to fix soon by factoring
> the export files [as I promised you long ago, but it got lost on the
> stack until Ole ran into this problem again!]) that Ole has been having
> with Debian to get testing working properly for the installed
> examples.
> 
> I would appreciate you contributing to this thread.  For example, if
> all Fedora binary packages are installed (which works around the above
> factoring problem until I can get it fixed) do the following tests of the
> CMake-based and legacy-based installed examples work?
> 
> # CMake-based build system for the installed examples
> # Move to initially empty build tree first.
> rm -rf /tmp/plplot_cmake_test
> mkdir /tmp/plplot_cmake_test
> cd /tmp/plplot_cmake_test
> cmake $prefix/share/plplot$plplot_version/examples
> make -j<parallel_build_number> test_noninteractive >& 
> test_noninteractive.out
> 
> # Legacy-based build system for the installed examples
> # Keep the install-tree clean by copying the installed examples elsewhere
> cp -a $prefix/share/plplot$plplot_version/examples /tmp
> cd /tmp/examples
> make -j<parallel_build_number> test_noninteractive >& 
> test_noninteractive.out
> 
> If the above tests work on Fedora that proves that the Fedora
> PLplot installation has correctly configured CMake export
> and pkg-config *.pc files for the final Fedora installation locations.
> 
> Currently such tests fail for Ole's Debian packages, but I think some
> attention to the details of PLplot installation locations will solve this
> issue.  And similarly in your case if those tests fail for Fedora.
> 
> Alan

It mostly seems to work fine.  The one strange error for cmake is:

Generate C results for bmpqt file device
/usr/share/plplot5.13.0/examples/test_lua.sh: line 50: 
lua_svg_test.error: Permission denied
[ 92%] Built target xtraditional16a
cat: lua_svg_test.error: No such file or directory
make[3]: *** [CMakeFiles/test_lua_svg.dir/build.make:374: 
test_examples_output_dir/x00lua01.svg] Error 1

and for make/pkgconfig:

Generate Octave results for svg device
./plplot-test.sh --verbose --front-end=octave --device=svg
/usr/bin/bash: ./plplot-test.sh: Permission denied
make: *** [Makefile:126: x01o01.svg] Error 126

which is due to my removing the executable bit for the example script to 
avoid issues with automatic dependencies.


-- 
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] Help needed for plplot runtime tests

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

Hi Orion:

This thread has previously been directed mostly at Ole, but
I am including you now because I think it will interest you.  It concerns the
problems (one of them upstream which I plan to fix soon by factoring
the export files [as I promised you long ago, but it got lost on the
stack until Ole ran into this problem again!]) that Ole has been having
with Debian to get testing working properly for the installed
examples.

I would appreciate you contributing to this thread.  For example, if
all Fedora binary packages are installed (which works around the above
factoring problem until I can get it fixed) do the following tests of the
CMake-based and legacy-based installed examples work?

# CMake-based build system for the installed examples
# Move to initially empty build tree first.
rm -rf /tmp/plplot_cmake_test
mkdir /tmp/plplot_cmake_test
cd /tmp/plplot_cmake_test
cmake $prefix/share/plplot$plplot_version/examples
make -j<parallel_build_number> test_noninteractive >& test_noninteractive.out

# Legacy-based build system for the installed examples
# Keep the install-tree clean by copying the installed examples elsewhere
cp -a $prefix/share/plplot$plplot_version/examples /tmp
cd /tmp/examples
make -j<parallel_build_number> test_noninteractive >& test_noninteractive.out

If the above tests work on Fedora that proves that the Fedora
PLplot installation has correctly configured CMake export
and pkg-config *.pc files for the final Fedora installation locations.

Currently such tests fail for Ole's Debian packages, but I think some
attention to the details of PLplot installation locations will solve this
issue.  And similarly in your case if those tests fail for Fedora.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] FW: Exponential labels - custom position

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

On 2018-11-23 12:11-0000 Allen, Anthony J wrote:

> Alan,
>
> just to confirm, QSAS does not use your colour bar code, nor does it
> use label_box_custom(). Alban wrote his own colour bar using plbox().
>
> This means any change we made to label_box_custom is historical and nugatory, and only the
> changes to plbox() are relevant ( the else{  } ).
>
> In fact we do not include pllegend.c in our version of plplot at all, which is why I did
> not see label_box_custom() being called.

Hi Tony:

Of course, upstream does use both label_box and label_box_custom.  So
from that upstream perspective, I believe the plan should be to (1)
implement the test case I suggested (a simple example that plots both
a box and a color bar where both require exponential labels with
different custom locations for each); and (2) assuming that simple
example demonstrates the bug you discovered, then fix the bug in a
consistent way for both label_box and label_box_custom.

I have put this plan on my ToDo list and will keep you informed of my
progress once I start working on this topic (likely early in 2019).
However, if you decide to work along the lines of that upstream
plan yourself before I can get to it, please keep me informed of your
progress as well.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Help needed for plplot runtime tests

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

On 2018-11-23 08:28+0100 Ole Streicher wrote:

[...]
> It is the cmake command. When I start with an empty dir, and then do
>
> $ cmake /usr/share/doc/plplot-doc/examples/
>
> I get the following output:
>
> --------------------------------8<----------------------------------------
> -- The C compiler identification is GNU 8.2.0
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- CMake version = 3.12.3
> -- CMAKE_SYSTEM_NAME = Linux
> -- CMAKE_PLATFORM_INFO_DIR = /home/ole/Projects/2011/debian/plplot/x/CMakeFiles/3.12.3
> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29")
> -- Looking for pkg-config - found
> -- cxx_compiler_library_pathname_list =
> -- A test cmake run with language = Ada enabled failed.
> -- Specify -DENABLE_compiler_diagnostics=ON to see full CMake diagnostics concerning this failure.
> -- WARNING: no working Ada compiler so disabling ada examples.
> -- The CXX compiler identification is GNU 8.2.0
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- The Fortran compiler identification is GNU 8.2.0
> -- Check for working Fortran compiler: /usr/bin/gfortran
> -- Check for working Fortran compiler: /usr/bin/gfortran  -- works
> -- Detecting Fortran compiler ABI info
> -- Detecting Fortran compiler ABI info - done
> -- Checking whether /usr/bin/gfortran supports Fortran 90
> -- Checking whether /usr/bin/gfortran supports Fortran 90 -- yes
> -- Found JNI: /usr/lib/jvm/default-java/lib/libjawt.so
> -- Could NOT find Qt5Svg (missing: Qt5Svg_DIR)
> CMake Warning at /usr/lib/x86_64-linux-gnu/cmake/plplot/plplotConfig.cmake:5 (find_package):
>  Found package configuration file:
>
>    /usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake
>
>  but it set Qt5_FOUND to FALSE so package "Qt5" is considered to be NOT
>  FOUND.  Reason given by package:
>
>  Failed to find Qt5 component "Svg" config file at
>  "/usr/lib/x86_64-linux-gnu/cmake/Qt5Svg/Qt5SvgConfig.cmake"
>
>
>
> Call Stack (most recent call first):
>  CMakeLists.txt:471 (find_package)
>
>
> -- CORE_Qt5_FOUND = ON
> -- CORE_Qt5_VERSION_MAJOR = 5
> -- CORE_Qt5_VERSION_MINOR = 11
> -- CORE_Qt5_VERSION_PATCH = 2
> -- Qt5_FOUND = 0
> -- Qt5_VERSION_MAJOR = 5
> -- Qt5_VERSION_MINOR = 11
> -- Qt5_VERSION_PATCH = 2
> -- WARNING: Qt5 core build-tree and install-tree inconsistency
> CMake Error at /usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot.cmake:279 (message):
>  The imported target "_Pltk_init2.7" references the file
>
>     "/usr/lib/python2.7/dist-packages/_Pltk_init.so"
>
>  but this file does not exist.  Possible reasons include:
>
>  * The file was deleted, renamed, or moved to another location.
>
>  * An install or uninstall procedure did not complete successfully.
>
>  * The installation package was faulty and contained
>
>     "/usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot.cmake"
>
>  but not all the files it references.
>
> Call Stack (most recent call first):
>  /usr/lib/x86_64-linux-gnu/cmake/plplot/plplotConfig.cmake:20 (include)
>  CMakeLists.txt:471 (find_package)
>
>
> -- Configuring incomplete, errors occurred!
>
> --------------------------------8<----------------------------------------
>
> A Makefile is not produced then. The produced logfile is attached.
>
> Any idea?

Hi Ole:

I think there are at least two issues above.

I.  Missing package

Everything above leading up to

-- WARNING: Qt5 core build-tree and install-tree inconsistency

indicates there is an inconsistency between the environment you used to build
and install PLplot and the environment you are using to test the installed examples
tree.  From the first set of messages, especially,

Failed to find Qt5 component "Svg" config file at
"/usr/lib/x86_64-linux-gnu/cmake/Qt5Svg/Qt5SvgConfig.cmake"

I think the solution is you must install
libqt5svg5-dev which apt-file tells me contains
/usr/lib/x86_64-linux-gnu/cmake/Qt5Svg/Qt5SvgConfig.cmake.

II. The second problem above starts with the message

CMake Error at /usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot.cmake:279 (message)

I am virtually positive what is going on is that PLplot installs the
files corresponding to the exported target PLPLOT::_Pltk_init.so in
one location, e.g., "/usr/lib/python2.7/dist-packages/_Pltk_init.so"
and your Debian packaging automatically changes that location to
something else creating an inconsistency between the location expected
by the exported target, and the location where the file was installed.
To avoid such exported target inconsistent location issues, it is
imperative that you change the *PLplot* installation locations to the
locations expected by Debian.

Please look at your core build (not the build of the installed
examples you were testing above) cmake output for instructions about
how to get PLplot to modify installation locations.  For example, here
is the relevant part of my cmake output:

-----------------------------------------------8<-------------------------------------
Summary of CMake build system results for PLplot

Install location variables which can be set by the user.  N.B. These
variables are ordered by decreasing degree of generality, with the
_default_ values of the later ones in the list determined by the
values of variables earlier in the list.  So, for example, it is
usually sufficient in the vast majority of cases to just set
CMAKE_INSTALL_PREFIX, and the rest of these variables are adjusted
accordingly (at least for a fresh configuration), and it is rare
indeed that is is necessary for a user to set any variable here whose
name does not start with "CMAKE_INSTALL_".

CMAKE_INSTALL_PREFIX: /home/software/plplot/installcmake
CMAKE_INSTALL_EXEC_PREFIX: /home/software/plplot/installcmake
CMAKE_INSTALL_BINDIR: /home/software/plplot/installcmake/bin
CMAKE_INSTALL_DATADIR: /home/software/plplot/installcmake/share
CMAKE_INSTALL_LIBDIR: /home/software/plplot/installcmake/lib
CMAKE_INSTALL_INCLUDEDIR: /home/software/plplot/installcmake/include
CMAKE_INSTALL_INFODIR: /home/software/plplot/installcmake/share/info
CMAKE_INSTALL_MANDIR: /home/software/plplot/installcmake/share/man
CMAKE_INSTALL_PKG_CONFIG_DIR: /home/software/plplot/installcmake/lib/pkgconfig
DATA_DIR: /home/software/plplot/installcmake/share/plplot5.13.0
LIB_DIR: /home/software/plplot/installcmake/lib
INCLUDE_DIR: /home/software/plplot/installcmake/include/plplot
BIN_DIR: /home/software/plplot/installcmake/bin
DRV_DIR: /home/software/plplot/installcmake/lib/plplot5.13.0/drivers
DOC_DIR: /home/software/plplot/installcmake/share/doc/plplot
INFO_DIR: /home/software/plplot/installcmake/share/info
MAN_DIR: /home/software/plplot/installcmake/share/man
PKG_CONFIG_DIR: /home/software/plplot/installcmake/lib/pkgconfig
FORTRAN_MOD_DIR: /home/software/plplot/installcmake/lib/fortran/modules/plplot
JAR_DIR: /home/software/plplot/installcmake/share/java
JAVAWRAPPER_DIR: /home/software/plplot/installcmake/lib/jni
PYTHON_INSTDIR: /home/software/plplot/installcmake/lib/python3.6/site-packages
PLPLOT_OCTAVE_DIR: /home/software/plplot/installcmake/share/plplot_octave
OCTAVE_M_DIR: /home/software/plplot/installcmake/share/octave/site/m/PLplot
OCTAVE_OCT_DIR: /home/software/plplot/installcmake/lib/octave
TCL_DIR: /home/software/plplot/installcmake/share/plplot5.13.0/tcl
ADA_INCLUDE_DIR: /home/software/plplot/installcmake/share/ada/adainclude/plplotada
ADA_LIB_DIR: /home/software/plplot/installcmake/lib/ada/adalib/plplotada
LUA_DIR: /home/software/plplot/installcmake/lib/lua/plplot
OCAML_INSTALL_DIR: /home/software/plplot/installcmake/lib/ocaml
-----------------------------------------------8<-------------------------------------

Of course, your own list of install locations will be quite different
(since I am using a a completely different installation prefix than
you), but your should modify your list (e.g., by setting
-DCMAKE_INSTALL_LIBDIR=<Debian library install location>
-DPYTHON_INSTDIR=<Debian Python install location) in your core build so that your Debian
packager does not have to change *any* file location installed by
PLplot which then forces the exported targets for the install to have the
correct file locations.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________