plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Convenient submission of dashboards has now been enabled

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

On 2016-11-29 07:43-0000 Arjen Markus wrote:

> Hi Alan,

> I will have a look at this - it is a pretty lengthy email and I have
never used cdash before ;). It is probably not that complicated, but I
do want to get a clear idea about what it means.

Hi Arjen:

To be precise you are actually using ctest as a dashboard client to
send dashboards to our dashboard server (the PLplot_git "project" at
my.cdash.org).  The place where today's submitted dashboard
information is publicly displayed is
<http://my.cdash.org/index.php?project=PLplot_git>) with calendar
links to submissions on other days.  So you don't actually need to
know anything about the cdash software that runs that site other than
it provides a nice dashboard server.

As a first step, look carefully at the kinds of information displayed
at <http://my.cdash.org/index.php?project=PLplot_git> by clicking on
everything for a given dashboard.  For example, it turns out my
concerns about privacy were overblown since there is nothing there to
identify who submitted a dashboard and there is not even anything
there to identify who organized the "PLplot_git" project.  (It was me.
:-) ) So you end up knowing a lot about the computer that ran ctest
including its name, but nothing about who actually owns that computer.

As a second step instead of plunging right in by running ctest with
the "-D Experimental" option you may want to run
scripts/comprehensive_test.sh with the "--do_submit_dashboard yes"
option.  For a good example of this possibility please see the
Tested by: section of the commit message for commit 7e987c4.

Finally, read README.dashboard_submissions.  I have recently (commit
8cf972a) created that file to document our dashboard submission
capability.

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] Convenient submission of dashboards has now been enabled

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

Hi Alan,



I will have a look at this - it is a pretty lengthy email and I have never used cdash before ;). It is probably not that complicated, but I do want to get a clear idea about what it means.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, November 29, 2016 3:39 AM
> To: PLplot development list
> Subject: [Plplot-devel] Convenient submission of dashboards has now been enabled
>
> To Arjen and Hazen:
>
> I have now enabled the convenient submission of a dashboard (defined as the
> collection of essentially all results from a run of ctest) to our cdash dartboard server,
> my.cdash.org, with results displayed at
> <http://my.cdash.org/index.php?project=PLplot_git>. This step was completely
> straightforward, i.e, it only required introduction of the 15-line file,
> CTestConfig.cmake that is actually provided by my.cmake.org when I created the
> PLplot_git project there. See the commit message for d7192bb for details.
>
> See also the commit messages for 9adf35e and e187a6c which implement opt-in
> dashboard submission for each ctest that is run by our comprehensive test script
> and which eliminates an annoying truncation problem that was occurring for my
> previously submitted dashboards.
>
> Will you both please try submitting dashboards to prove this process works well for
> you on the various platforms accessible to you?
>
> The whole submission process is straightforward and should work for any Unix
> platform (Cygwin, MinGW-w64/MSYS2, Mac OS X, and Linux should all qualify).
> Either you run scripts/comprehensive_test.sh with the "do_submit_dashboard yes"
> option or else you can configure PLplot with cmake as normal (using the -
> DBUILD_TEST=ON option), build the "all" target (as you likely do normally as well),
> and the only extra step required _after_ the "all"
> target is built is to execute
>
> ctest -D Experimental
>
> That command (also used in our comprehensive test script when "--
> do_submit_dashboard yes" runs all the ctest tests that are enabled by our build
> system as normal PLUS with that -D option, ctest collects the dashboard of those
> results and sends it off to my.cash.org as configured by CTestConfig.cmake.  And
> you can then review those results (and my previous ones) at
> <http://my.cdash.org/index.php?project=PLplot_git>.
>
> At first these results seem extremely terse (organized as one dashboard per line),
> but you soon realize that virtually every field for a given dashboard is a clickable link
> starting a hierarchy of further clickable links to make complete information on a
> given ctest run accessible in a very nicely organized way.
>
> The only slight concern I have with regard to these dashboard results is the false
> positive count of 14 warnings for the cmake run.
> Apparently, my use of "WARNING:" in many of the messages emitted by our build
> system is triggering this.  I think that is likely a ctest bug, and instead the dashboard
> should report a warning only when there is an official cmake warning message.
>
> Anyhow, the number of configuration warnings these dashboard summaries show
> should be taken with a large grain of salt.
>
> In sum, simply remember to configure, build, and then execute
>
> ctest -D Experimental
>
> whenever there is an interesting git commit you would like to test or whenever you
> would like to test your own work before a commit.  Then visit
> <http://my.cdash.org/index.php?project=PLplot_git> to look at those results in detail
> and to compare them with ctest results submitted by others.
>
> Now I have implemented this nice new facility for submitting dashboards, I have put
> together a table that compares this facility with the travis-ci capability recently
> implemented by Hazen.
>
> (N.B. "WLA" means whatever locally available.)
>
> Characteristic         dashboard         travis-ci
>
> Nicely formatted?      yes               no
>
> Git server allowed?    any               limited to GitHub
>
> Where tests are run?   locally           travis-ci server
>
> Compilers?             WLA               Many gcc suite versions, clang, etc.
>
> Platforms?             WLA               2.5 year-old Linux, Mac OS X
>
> The nicely formatted results (e.g., those at
> <http://my.cdash.org/index.php?project=PLplot_git> of the dashboard approach are
> a clear advantage for that approach, but I presume the travis-ci developers will get
> on top of this issue with their raw results at some point.
>
> The fact is lots of developers use GitHub so the extra freedom in this regard for the
> dashboard approach should be considered just a modest advantage for the
> dashboard approach.
>
> The biggest disadvantage of the dashboard approach from the user's perspective is
> ctest chews up lots of local cpu cycles while the advantage for the travis-ci
> approach from that same perspective is it chews up lots of cpu cycles on the travis-
> ci server.
>
> The variety of compilers and compiler versions supported by travis-ci is an
> advantage for that approach from the single-users perspective, but this advantage
> decreases considerably if you get many users of PLplot reporting dashboards for
> the wide variety of compilers and compiler versions available to them.
>
> The local platforms where this dashboard approach should work include essentially
> any platform that supports bash and other Unix commands which are needed by
> our tests.  Thus, our ctest results (and presumably dashboard submission as well)
> are known to work on Cygwin, MinGW-w64/MSYS2, Mac OS X, and Linux and
> should work on most other free and commercial Unices. Nobody has yet got ctest
> to work on "bare"
> Windows (e.g., MSVC) yet, although theoretically it should work if you used nmake
> and MSVC while putting e.g., the unix tools such as bash on the PATH from say,
> your MinGW-w64/MSYS2 platform.  Anyhow, even if this issue with ctest on "bare"
> Windows persists, I think there is a clear advantage with platform support here for
> the dashboard approach.
>
> Note, I have been in contact with the travis-ci support staff about that 2.5 year-old
> Linux limitation (which I consider to be a modest disadvantage now, but it is on the
> cusp of becoming a major disadvantage for our free software needs since we
> typically do not support extremely old versions of Linux libraries).  From the reply I
> got it appears the travis-ci developers have recently cleared up a bottleneck in their
> software which was making it difficult to update their Linux platforms available on
> their server so it is expected that limitation will be gone reasonably soon although
> there is no ETA yet.
>
> In sum, I think it is fair to say the two methods complement each other with
> advantages and disavantages for each as summarized 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
> __________________________
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

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] Convenient submission of dashboards has now been enabled

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

To Arjen and Hazen:

I have now enabled the convenient submission of a dashboard (defined as the
collection of essentially all results from a run of ctest) to our
cdash dartboard server, my.cdash.org, with results displayed at
<http://my.cdash.org/index.php?project=PLplot_git>. This step was
completely straightforward, i.e, it only required introduction of the
15-line file, CTestConfig.cmake that is actually provided by
my.cmake.org when I created the PLplot_git project there. See the
commit message for d7192bb for details.

See also the commit messages for 9adf35e and e187a6c which implement
opt-in dashboard submission for each ctest that is run by our
comprehensive test script and which eliminates an annoying truncation
problem that was occurring for my previously submitted dashboards.

Will you both please try submitting dashboards to prove this process
works well for you on the various platforms accessible to you?

The whole submission process is straightforward and should work for
any Unix platform (Cygwin, MinGW-w64/MSYS2, Mac OS X, and Linux should
all qualify).  Either you run scripts/comprehensive_test.sh with
the "do_submit_dashboard yes" option or else you
can configure PLplot with cmake as normal (using the
-DBUILD_TEST=ON option), build the "all" target (as you likely do
normally as well), and the only extra step required _after_ the "all"
target is built is to execute

ctest -D Experimental

That command (also used in our comprehensive test script when
"--do_submit_dashboard yes" runs all the ctest tests that are enabled
by our build system as normal PLUS with that -D option, ctest collects
the dashboard of those results and sends it off to my.cash.org as
configured by CTestConfig.cmake.  And you can then review those
results (and my previous ones) at
<http://my.cdash.org/index.php?project=PLplot_git>.

At first these results seem extremely terse (organized as one
dashboard per line), but you soon realize that virtually every field
for a given dashboard is a clickable link starting a hierarchy of
further clickable links to make complete information on a given ctest
run accessible in a very nicely organized way.

The only slight concern I have with regard to these dashboard results
is the false positive count of 14 warnings for the cmake run.
Apparently, my use of "WARNING:" in many of the messages emitted by
our build system is triggering this.  I think that is likely a ctest
bug, and instead the dashboard should report a warning only when there
is an official cmake warning message.

Anyhow, the number of configuration warnings these dashboard
summaries show should be taken with a large grain of salt.

In sum, simply remember to configure, build, and then execute

ctest -D Experimental

whenever there is an interesting git commit you would like to test or
whenever you would like to test your own work before a commit.  Then
visit <http://my.cdash.org/index.php?project=PLplot_git> to look at
those results in detail and to compare them with ctest results
submitted by others.

Now I have implemented this nice new facility for submitting
dashboards, I have put together a table that compares
this facility with the travis-ci capability recently
implemented by Hazen.

(N.B. "WLA" means whatever locally available.)

Characteristic         dashboard         travis-ci

Nicely formatted?      yes               no

Git server allowed?    any               limited to GitHub

Where tests are run?   locally           travis-ci server

Compilers?             WLA               Many gcc suite versions, clang, etc.

Platforms?             WLA               2.5 year-old Linux, Mac OS X

The nicely formatted results (e.g., those at
<http://my.cdash.org/index.php?project=PLplot_git> of the dashboard
approach are a clear advantage for that approach, but I presume
the travis-ci developers will get on top of this issue with
their raw results at some point.

The fact is lots of developers use GitHub so the extra freedom in this
regard for the dashboard approach should be considered just a modest
advantage for the dashboard approach.

The biggest disadvantage of the dashboard approach from the user's
perspective is ctest chews up lots of local cpu cycles while the
advantage for the travis-ci approach from that same perspective is it
chews up lots of cpu cycles on the travis-ci server.

The variety of compilers and compiler versions supported by travis-ci is
an advantage for that approach from the single-users perspective, but
this advantage decreases considerably if you get many users of PLplot
reporting dashboards for the wide variety of compilers and compiler
versions available to them.

The local platforms where this dashboard approach should work include
essentially any platform that supports bash and other Unix commands
which are needed by our tests.  Thus, our ctest results (and
presumably dashboard submission as well) are known to work on Cygwin,
MinGW-w64/MSYS2, Mac OS X, and Linux and should work on most other
free and commercial Unices. Nobody has yet got ctest to work on "bare"
Windows (e.g., MSVC) yet, although theoretically it should work if you
used nmake and MSVC while putting e.g., the unix tools such as bash on
the PATH from say, your MinGW-w64/MSYS2 platform.  Anyhow, even if
this issue with ctest on "bare" Windows persists, I think there is a
clear advantage with platform support here for the dashboard approach.

Note, I have been in contact with the travis-ci support staff about
that 2.5 year-old Linux limitation (which I consider to be a modest
disadvantage now, but it is on the cusp of becoming a major
disadvantage for our free software needs since we typically do not
support extremely old versions of Linux libraries).  From the reply I
got it appears the travis-ci developers have recently cleared up a
bottleneck in their software which was making it difficult to update
their Linux platforms available on their server so it is expected that
limitation will be gone reasonably soon although there is no ETA yet.

In sum, I think it is fair to say the two methods complement each
other with advantages and disavantages for each as summarized 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] Python3

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

On 2016-11-27 10:19-0500 Hazen Babcock wrote:

> On 11/27/2016 02:51 AM, Alan W. Irwin wrote:
>> 
>> P.S.  This further comment assumes that generating a python3 binding
>> is fairly trivial, i.e., nothing much more than using the -py3 option
>> to swig. If your experiments confirm that assumption holds, then I
>> suggest you should define a CMake option called PLPLOT_USE_PYTHON3. If
>> the user sets that to ON, the build system generates and uses a
>> python3 binding (using, e.g., that -py3 option to swig), and if OFF it
>> generates and uses a python2 binding (which we will likely want to
>> support indefinitely in any case).  With that either/or organization
>> between the two cases, the names of the modules we build will be
>> identical in the two cases, and the examples should just work
>> regardless of whether the binding is python2 or python3 (assuming you
>> can convert the syntax of the examples so that they work both with
>> python-2.7 and python-3.0).
>
> The bindings that swig generates are compatible with Python3 as well as 
> Python2 without the -py3 flag, so unless it turns out that we absolutely need 
> it I'm not going to use it. I also have no plans to add a special 
> PLPLOT_USE_PYTHON3 option. I'm reasonable confident we can be agnostic here 
> and it will not matter if the Python bindings are built in a Python2 
> environment and run in a Python3 environment or vice-versa.

It is good to hear it is likely going to be even easier than I thought.  I
guess that -py3 flag is needed for more complex Python bindings than ours.

>
> I would appreciate thoughts on:
>
> (1) In Python2 imp.find_module('_plplotc', ..) will find the shared library 
> _plplotcmodule.so, but this fails in Python3. I'm not sure why we chose to 
> have a file name that was different from the module name, but swig is not 
> generating the right calls for imp.find_module() and imp.load_module() to 
> work with this convention in Python3. For the time being I have just been 
> editing the generated plplotc.py file by hand to fix this. However, unless 
> there is some reason why the C library needs to be named _plplotcmodule.so I 
> would like to change its name to _plplotc.so, or alternatively change the 
> module name to _plplotcmodule. It looks like we are already doing this on 
> windows, the C library is called _plplotc.pyd and not _plplotcmodule.pyd.

I have looked at the naming conventions used in practice for
python-2.6 and python-2.7 on Debian, and even there the old-fashioned idea
of inserting a "module" suffix on the basename of the shared object
has mostly (but not completely) fallen out of favour.  So it is fine
with me if you drop the module part of the shared object name as well.

>
> (2) What is the command line to run a python example in the build tree 
> outside of ctest? Some of the examples are failing and debugging would be a 
> lot easier if I could run them by hand. Among other annoyances, ctest eats 
> any print() output breaking my preferred approach to debugging.

Try,

make test_python_psc

>From what you say, this will fail with python3, but the important
issue is it will build all python prerequisites and run each
python example up to the first that fails with python3.  Let's say
that first failure was for standard example 00.

Then, you can run that example individually
(_in the build tree_) as follows:

examples/python/x00 -dev psc -o test.psc

Then edit examples/python/xw00.py in the _source tree_ (to make sure
your changes are not lost), copy that changed version by hand to the
build tree (or else run "make test_python_psc" to do that) and try
again running it as above until you are satisfied with your source
tree change.  Then move to the second example that fails at run time
as revealed by "make test_python_psc", etc.

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] Python3

[Hazen B. <hba...@ma...>]

On 11/27/2016 02:51 AM, Alan W. Irwin wrote:
>
> P.S.  This further comment assumes that generating a python3 binding
> is fairly trivial, i.e., nothing much more than using the -py3 option
> to swig. If your experiments confirm that assumption holds, then I
> suggest you should define a CMake option called PLPLOT_USE_PYTHON3. If
> the user sets that to ON, the build system generates and uses a
> python3 binding (using, e.g., that -py3 option to swig), and if OFF it
> generates and uses a python2 binding (which we will likely want to
> support indefinitely in any case).  With that either/or organization
> between the two cases, the names of the modules we build will be
> identical in the two cases, and the examples should just work
> regardless of whether the binding is python2 or python3 (assuming you
> can convert the syntax of the examples so that they work both with
> python-2.7 and python-3.0).

The bindings that swig generates are compatible with Python3 as well as 
Python2 without the -py3 flag, so unless it turns out that we absolutely 
need it I'm not going to use it. I also have no plans to add a special 
PLPLOT_USE_PYTHON3 option. I'm reasonable confident we can be agnostic 
here and it will not matter if the Python bindings are built in a 
Python2 environment and run in a Python3 environment or vice-versa.

I would appreciate thoughts on:

(1) In Python2 imp.find_module('_plplotc', ..) will find the shared 
library _plplotcmodule.so, but this fails in Python3. I'm not sure why 
we chose to have a file name that was different from the module name, 
but swig is not generating the right calls for imp.find_module() and 
imp.load_module() to work with this convention in Python3. For the time 
being I have just been editing the generated plplotc.py file by hand to 
fix this. However, unless there is some reason why the C library needs 
to be named _plplotcmodule.so I would like to change its name to 
_plplotc.so, or alternatively change the module name to _plplotcmodule. 
It looks like we are already doing this on windows, the C library is 
called _plplotc.pyd and not _plplotcmodule.pyd.

(2) What is the command line to run a python example in the build tree 
outside of ctest? Some of the examples are failing and debugging would 
be a lot easier if I could run them by hand. Among other annoyances, 
ctest eats any print() output breaking my preferred approach to debugging.

-Hazen

Re: [Plplot-devel] Python3

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

Hi Hazen:

P.S.  This further comment assumes that generating a python3 binding
is fairly trivial, i.e., nothing much more than using the -py3 option
to swig. If your experiments confirm that assumption holds, then I
suggest you should define a CMake option called PLPLOT_USE_PYTHON3. If
the user sets that to ON, the build system generates and uses a
python3 binding (using, e.g., that -py3 option to swig), and if OFF it
generates and uses a python2 binding (which we will likely want to
support indefinitely in any case).  With that either/or organization
between the two cases, the names of the modules we build will be
identical in the two cases, and the examples should just work
regardless of whether the binding is python2 or python3 (assuming you
can convert the syntax of the examples so that they work both with
python-2.7 and python-3.0).

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] Python3

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

On 2016-11-25 20:30-0500 Hazen Babcock wrote:

>
> Hello,
>
> I would like to fix PLplot so that it works with Python3. At a minimum
> it looks like this means fixing all the print statements, i.e.:
>
> print "asdf" -> print("asdf")
>
> I'll test against Python2.7. Do I also need to test against Python2.6?
> Or is that far enough in the past that we don't support it anymore?

Hi Hazen:

I thoroughly approve of your above goal.

The last release for 2.6.x was in 2013, but some of the key python3
syntax such as print(<string>) were backported to it so by accident it
might still work for us once you are done.  But I suggest for now you
concentrate on python-2.7 (which also includes the same backported
Python 3 syntax) and Python 3.x.

With regard to the bindings, have you seen
<http://www.swig.org/Doc1.3/Python.html#Python_python3support>?  It
appears a very tiny modification (using the -py3 command line option
for swig) of our present python bindings may be all you need to generate
python3 bindings.  So have fun experimenting with that option to
see how far you get!

With regard to the examples, they are really simple python code.
Apparently, there is a script that converts
python2 scripts to python-3 compatibility.  I presume most of what
that script would change would be print statements (to move from the
"print <string>" to "print(<string>)" form).  And with any luck at all,
those new results would work both with python 2.7 (which supports
"print(<string>)" and some other python-3 syntax) and python 3.x.

Good luck with this project!

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] Our Qt5 support has finally matured, but the Qt5 suite of libraries has not

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

Back in March 2014, I took the first tentative steps to change our
build system to support Qt5, and after delay due to (1) lack of access
to Qt5 that was resolved recently and (2) the completely different
nature of Qt4 versus Qt5 CMake support, I have finally matured that
project tonight (commit 34db4b3).  The result is perfect comprehensive
test results for both the Qt5 and Qt4 cases.

Note carefully (see the commit message for the details) the semantics
of PLPLOT_USE_QT5 have considerably changed, and most users will just
take the default -DPLPLOT_USE_QT5=OFF case here (which means our build
system will first look for Qt4, and if that fails look for Qt5).  But
if a user actively dislikes the Qt4 choice, then they can force the
build system to skip the stage looking for Qt4 by specifying
-DPLPLOT_USE_QT5=ON.

The reason why our build system makes Qt4 the first preference by
default is that library has no character misalignment issues or memory
management issues on my Debian Jessie system while Qt5 still shows
both kinds of errors. Furthermore, and this is a real killer for Qt5
until the Qt developers fix this significant inefficiency, our qt
devices (which use exactly the same Qt API regardless of whether our
build system finds Qt4 or Qt5) are a factor of two faster for Qt4 than
they are for Qt5! (For example, the comprehensive tests for the
present commit took 36 minutes for Qt4 and 71 minutes for Qt5.)

With Debian Jessie, I have demonstrated that "perfect" (i.e., no
character misalignment or memory management issues) Qt4 library suites
do exist but, as far as I know, nobody has yet found a "perfect" Qt5
library suite. Of course, it is still quite possible that various
software distros inadvertently screw up Qt4 so that it is actually
worse than Qt5 with regard to, e.g., memory management. Apparently
Hazen has found one such distribution so he might want to specify
-DPLPLOT_USE_QT5=ON for that particular distribution (or, better yet,
move to a distribution that supports Qt a lot better).  But unless the
good Qt4, mediocre Qt5 results on Debian Jessie are atypical, I plan
to keep the present Qt4 preference of our build system.

In sum, commit 34db4b3 is a major step in the march to the freeze date one
week from now and finishes my planned Qt-related activity, but I hope
to do a lot more on non-Qt topics before that date.

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] Testing with Docker

[Hazen B. <hba...@ma...>]

On 11/25/2016 09:46 AM, Hazen Babcock wrote:
>
> I think have this more or less working now. I created a git repository
> for this here:
> https://github.com/PLplot/plplot-docker
>
> And our docker images are here:
> https://hub.docker.com/u/plplot/
>
> Assuming that you have docker installed and running, then:
> docker run plplot/debian-stable 2>&1 | tee debian-stable.txt
>
> For example will pull the most recent version of PLplot, build and test
> it on debian stable.

I updated the docker images so that you can also test a local repository:

docker run -v /absolute/path/to/local/plplot:/plplot_repo 
plplot/debian-latest 2>&1 | tee debian-latest.txt

Or to test against all the images:

cd /path/to/plplot-docker
python test_all.py --plplot_repo /absolute/path/to/local/plplot

-Hazen

[Plplot-devel] Python3

[Hazen B. <hba...@ma...>]

Hello,

I would like to fix PLplot so that it works with Python3. At a minimum 
it looks like this means fixing all the print statements, i.e.:

print "asdf" -> print("asdf")

I'll test against Python2.7. Do I also need to test against Python2.6? 
Or is that far enough in the past that we don't support it anymore?

-Hazen

Re: [Plplot-devel] Testing with Docker

[Hazen B. <hba...@ma...>]

On 11/24/2016 01:15 AM, Alan W. Irwin wrote:
>
> I think for any Linux distro we choose, we should choose the latest
> version that has reasonable reliability for the tests. So generally
> that means the latest stable release on some but some have rolling
> releases that have a pretty good reputation for reliability as well.
> So my choices would be Debian Stretch (rolling), Ubuntu yakkety
> (latest stable since there is no Ubuntu rolling), OpenSUSE Tumbleweed
> (rolling), Arch Linux (only a rolling release), and Fedora 26 (latest
> stable).  I chose Fedora 26 over Rawhide (the Fedora rolling release)
> somewhat arbitrarily so others here with some 26 versus Rawhide
> reliability experience should help us finalize that decision.

I think have this more or less working now. I created a git repository 
for this here:
https://github.com/PLplot/plplot-docker

And our docker images are here:
https://hub.docker.com/u/plplot/

Assuming that you have docker installed and running, then:
docker run plplot/debian-stable 2>&1 | tee debian-stable.txt

For example will pull the most recent version of PLplot, build and test 
it on debian stable.

I'm still missing some dependencies in some of the distros.

This can also be done in travis-ci:
https://travis-ci.org/HazenBabcock/PLplot

I have attached testing results and also the test script that is being 
run in each image. I think the script outputs everything that we'd need 
to know, but it is easy to change.

-Hazen

Re: [Plplot-devel] Finding wxWidgets

[Pedro V. <ped...@sp...>]

Hi Alan

I tried to remove

-DwxWidgets_LIB_DIR:PATH=%WXWIN%/lib/vc_lib

in

cmake ".." -G "Visual Studio 
14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON -DCMAKE_CONFIGURATION_TYPES:STRING="Debug" 
 -DCMAKE_BUILD_TYPE:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF -DSTATIC_RUNTIME:BOOL=ON 
 -DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR:PATH=%WXWIN%  -DwxWidgets_CONFIGURATION=mswud 
 -DENABLE_MIX_CXX=ON -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF > 
cmake1.txt 2>&1

and I get an error

-- Performing Test WX_VERSION_LARGE_ENOUGH
CMake Error: Remove failed on file: 
P:/plplot-plplot/build/CMakeFiles/CMakeTmp/Debug/cmTC_54fb2.exe: System 
Error: No such file or directory


the output cmake1.txt is attached

adding

-DwxWidgets_LIB_DIR:PATH=%WXWIN%/lib/vc_lib

all is fine

the output is cmake2.txt


no big deal, just an extra flag

-Pedro


----- Original Message ----- 
From: "Alan W. Irwin" <ir...@be...>
To: "Pedro Vicente" <ped...@sp...>
Cc: "Phil Rosenberg" <p.d...@gm...>; "Laurent Berger" 
<lau...@un...>; <plp...@li...>
Sent: Tuesday, November 15, 2016 3:09 AM
Subject: Re: [Plplot-devel] Finding wxWidgets


> On 2016-11-14 23:39-0500 Pedro Vicente wrote:
>
>> all is fine
>>
>> so, the problem was that I was using git bash for Windows as shell (where 
>> back-slash forward-slash convention is different from Unix/Windows; as a 
>> software engineer I end up losing hours of my life fixing
>> different Unix/Windows path conventions. Thanks Microsoft).
>>
>> Using just a "normal" Windows shell , this works
>>
>> -DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib
>>
>> in
>>
>> cmake ".." -G "Visual Studio 
>> 14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON -DCMAKE_CONFIGURATION_TYPES:STRING="Debug" 
>>  -DCMAKE_BUILD_TYPE:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF -DSTATIC_RUNTIME:BOOL=ON 
>>  -DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR:PATH=%WXWIN% -DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib 
>>  -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF
>>
>>
>> sorry for all the false alarms
>
> Hi Pedro:
>
> No problem.  Been there done that (when I was playing with MinGW/MSYS
> under Wine years ago.)  In sum, I am glad you no longer encounter
> wxwidgets find issues.
>
>>
>> Just 2 last notes :-)
>>
>>
>> 1)
>>
>> If we specify the root of wxWidgets with
>>
>> -DwxWidgets_ROOT_DIR:PATH=%WXWIN%
>>
>> it seems that having to specify the library path could be eliminated
>>
>> -DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib
>>
>> I believe this path
>>
>> \lib\vc_lib
>>
>> is always the same for any Windows build? If not than my point is not 
>> valid
>
> I believe you are correct.  So try it and see.
>
>>
>> 2)
>>
>> After building with Visual Studio, all built ok
>>
>> ========== Rebuild All: 88 succeeded, 0 failed, 0 skipped ==========
>>
>> but in the last release there was an automatic run of the plot demo, that 
>> shows a plot window, that did not show up this time
>>
>> no big deal, but it's a nice feature that shows that all went fine
>
> If you are concerned about a test that is suddenly missing from (say)
> the test_interactive target, then you should look for WARNING messages in 
> the
> cmake output concerning test targets.  Those warnings typically end
> with a phrase similar to
>
> "... so it is temporarily excluded from being a dependency of other more
> general interactive test targets"
>
> We typically use such warnings for issues we can do nothing about except
> wait for external libraries to fix bugs.  So typically you can run
> such targets as an individual test, but you will encounter segfaults that 
> would
> ruin more comprehensive testing so we exclude these problematic test
> targets from being part of more comprehensive testing in the interest
> of allowing the comprehensive tests to finish under normal
> circumstances.
>
> For example, today I found two other such problematic tests under Qt5
> (test_qt_example and test_pyqt5_example).  I ascribe these to Qt5
> immaturity so the only thing we can do about these is wait for the
> bugs in Qt5 memory management to be fixed.  So those two tests are
> shortly going to be excluded from the test_interactive target (with a
> CMake WARNING similar to the above message to remind us to test the
> individual targets from time to time to see if the external library at
> fault has fixed its problems).
>
> 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] Testing with Docker

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

On 2016-11-23 23:29-0500 Hazen Babcock wrote:

>
> Going in a completely different direction from travis-ci.. I've been 
> experimenting with Docker:
>
> https://docs.docker.com/
>
> Quoting the web-site "Docker provides a way to run applications securely 
> isolated in a container, packaged with all its dependencies and libraries".
>
> What this means for us is that we can test just about any linux distro with 
> just about any set of libraries. For example, the attached will test the 
> current SF PLplot with a very limited number of dependencies on the 
> debian-latest distro. More interestingly, we can create images that have all 
> the dependencies and PLplot loaded. Then for updated test results all that 
> we'd have to do is pull the most recent version of PLplot, cmake, make and 
> ctest.
>
> So, thoughts about what 5 or so linux distros we want to be sure that PLplot 
> works on?

I think for any Linux distro we choose, we should choose the latest
version that has reasonable reliability for the tests. So generally
that means the latest stable release on some but some have rolling
releases that have a pretty good reputation for reliability as well.
So my choices would be Debian Stretch (rolling), Ubuntu yakkety
(latest stable since there is no Ubuntu rolling), OpenSUSE Tumbleweed
(rolling), Arch Linux (only a rolling release), and Fedora 26 (latest
stable).  I chose Fedora 26 over Rawhide (the Fedora rolling release)
somewhat arbitrarily so others here with some 26 versus Rawhide
reliability experience should help us finalize that decision.

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] Testing with Docker

[Hazen B. <hba...@ma...>]

Going in a completely different direction from travis-ci.. I've been 
experimenting with Docker:

https://docs.docker.com/

Quoting the web-site "Docker provides a way to run applications securely 
isolated in a container, packaged with all its dependencies and libraries".

What this means for us is that we can test just about any linux distro 
with just about any set of libraries. For example, the attached will 
test the current SF PLplot with a very limited number of dependencies on 
the debian-latest distro. More interestingly, we can create images that 
have all the dependencies and PLplot loaded. Then for updated test 
results all that we'd have to do is pull the most recent version of 
PLplot, cmake, make and ctest.

So, thoughts about what 5 or so linux distros we want to be sure that 
PLplot works on?

-Hazen

Re: [Plplot-devel] Continuous Integration

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

@Andrew: I have CC'd you because you are the maintainer for the
liblasi-dev Debian (and indirectly Ubuntu) package, and this e-mail
provides some background (scan below to the error involving freetype)
for a bug report I just made for that package at
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845497>. Also, note
comments below about an even worse issue for this package (it is based
on old buggy version where Hazen ran afoul of one of those bugs).

Hi Hazen:

I was glad to see most of my suggestions improved test completeness
right away.  I will respond below to the ones where there is still a
problem, but when you reply please post the exact URL of the relevant
report that failed (or succeeded) because they are tough to find
amongst all the many different build reports you are generating.

On 2016-11-23 12:23-0500 Hazen Babcock wrote:

> On 11/23/2016 06:08 AM, Alan W. Irwin wrote:
>
>> * -- WARNING: CMAKE_VERSION = 3.2.2 is in the range from 3.2 through
>>   3.3.1 which has a compromised find ability that was fixed in 3.3.2.
>>   Please upgrade to 3.3.2 or greater.
>
> I changed the builds to download and install cmake-3.7.0, which seems to be 
> working.

Excellent news.  Just out of curiosity, is cmake-3.7.0 actually provided
as an official package by travis-ci, is this the Linux binary version
supplied by Kitware, or do you build cmake-3.7.0 for each test?

>> * -- Looking for itcl.h - not found
>>   -- WARNING: Disabling Itcl interface code
>
> This is still failing with cmake-3.7.0 and the itcl3 and itcl3-dev packages.

That sounds like a Tcl find issue.  Short story, please try the cmake
option

-DTCL_INCLUDE_PATH:PATH=/usr/include/tcl8.5

to see if that solves the issue.

The (somewhat) longer story is as follows:

To analyze this situation further, if you look at
<http://packages.ubuntu.com/trusty/amd64/tcl-dev/filelist>, tcl.h
should be found at

/usr/include/tcl8.5/tcl.h,

and if you look at
<http://packages.ubuntu.com/trusty/amd64/itcl3-dev/filelist>, itcl.h
should be found at

/usr/include/tcl8.5/itcl.h

Yet your report says the tcl.h location (${TCL_INCLUDE_PATH}) is
/usr/include/tcl!  That would be OK if that was the result of some
Ubuntu consistent symlink /usr/include/tcl -> /usr/include/tcl8.5
since then itcl.h would still be found consistently in that same
symlinked directory.  But since itcl.h is not found, I assume the trouble is due
to some Ubuntu trusty symlink for tcl.h that is inconsistent with the
itcl.h location.  Thus, to achieve the required consistency, I suggest you
try setting TCL_INCLUDE_PATH as above.

>> Your detailed install messages for itcl3-dev seemed to successful
>> as noted above, but they did include the following warning message
>> about 110 packages that needed updating.
>> 
>> 0 upgraded, 2 newly installed, 0 to remove and 110 not upgraded.
>> 
>> To reduce that "not upgraded" number to 0, do the following:
>> 
>> sudo apt-get update
>> sudo apt-get dist-upgrade
>
> I suspect that you can't do that, but I have not actually tried.

It is definitely worthwhile on the Debian platform(or Debian
derivative platforms such as Ubuntu) to always do that standard
upgrade to get access to the latest bug fixes and security fixes.
Therefore, I do suggest you do give it a try, and if it works always
use it from then on in your tests.

>
>> On Debian Jessie, the package you need to install is called liblasi-dev.
>
> This causes the build to fail with:
>
> Scanning dependencies of target psttf
> [ 20%] Building CXX object drivers/CMakeFiles/psttf.dir/psttf.cc.o
> In file included from 
> /home/travis/build/HazenBabcock/PLplot/drivers/psttf.cc:44:0:
> /usr/include/LASi.h:14:30: fatal error: freetype/ftglyph.h: No such file or 
> directory
> compilation terminated.
> make[2]: *** [drivers/CMakeFiles/psttf.dir/psttf.cc.o] Error 1
> make[1]: *** [drivers/CMakeFiles/psttf.dir/all] Error 2
> make: *** [all] Error 2
>
> So I think we are still missing something, a freetype package perhaps?

@Andrew:
One aspect of the problem is a packaging bug for liblasi-dev which I have documented
at <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845497>.

Also, I have looked at the Release notes for lasi-1.1.2, and the
fundamental motivation for that release was to solve issues like the
above.  So I am pretty sure you put packaging lasi-1.1.2 on your ToDo
list at the time of that release, but never got around to it because
the Debian package is still for an outdated version, lasi-1.1.0.
Should I make an official bug report about this or is this reminder
enough?

@Hazen:
Solution of the above two liblasi-dev packaging bugs 
will likely solve this issue, but especially until that
second issue (old upstream version) is fixed there is
not much you can do so I suggest setting -DPLD_psttf=OFF
(with a comment about why because you will want to review
this once the above package fixes are made and the
results are propagated to travis-ci).

Also, I just noticed there continues to be a freetype issue that
is independent of -dev psttf (or -dev psttfc).  When you look
at this again, please give me the URL of the relevant report, but
from the old report I have been analyzing had the
following result for freetype:

-- Found Freetype: /usr/lib/x86_64-linux-gnu/libfreetype.so (found version "2.5.2") 
-- FREETYPE_CFLAGS = -I/usr/include/freetype2
-- FREETYPE_LIBRARIES = /usr/lib/x86_64-linux-gnu/libfreetype.so
Fonts not found - disabling freetype

I suspect you have to install some truetype fonts to solve this issue.
There is a lot of choice available, but one TTF package I
install is fonts-freefont-ttf which contains a very large range
of TrueType glyphs, and it appears that that package
is also provided by Ubuntu trusty.

>
>> On Debian Jessie, the package you need to install is called
>> libwxgtk3.0-dev.
>
> This causes the build to fail with:
> [ 14%] Building CXX object 
> bindings/wxwidgets/CMakeFiles/plplotwxwidgets.dir/wxPLplotstream.cpp.o
> In file included from /usr/include/c++/5/type_traits:35:0,
>                 from /usr/include/wx-3.0/wx/strvararg.h:25,
>                 from /usr/include/wx-3.0/wx/string.h:46,
>                 from /usr/include/wx-3.0/wx/memory.h:15,
>                 from /usr/include/wx-3.0/wx/object.h:19,
>                 from /usr/include/wx-3.0/wx/wx.h:15,
>                 from 
> /home/travis/build/HazenBabcock/PLplot/bindings/wxwidgets/wxPLplotstream.cpp:22:
> /usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file 
> requires compiler and library support for the ISO C++ 2011 standard. This 
> support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
> #error This file requires compiler and library support \
>  ^
> In file included from /usr/include/wx-3.0/wx/string.h:46:0,
>                 from /usr/include/wx-3.0/wx/memory.h:15,
>                 from /usr/include/wx-3.0/wx/object.h:19,
>                 from /usr/include/wx-3.0/wx/wx.h:15,
>                 from 
> /home/travis/build/HazenBabcock/PLplot/bindings/wxwidgets/wxPLplotstream.cpp:22:
> /usr/include/wx-3.0/wx/strvararg.h:345:18: error: ‘is_enum’ in namespace 
> ‘std’ does not name a template type
>     typedef std::is_enum<T> is_enum;
>                  ^
> /usr/include/wx-3.0/wx/strvararg.h:349:54: error: ‘is_enum’ was not declared 
> in this scope
>     enum { value = wxFormatStringSpecifierNonPodType<is_enum::value>::value 
> };
>                                                      ^
> /usr/include/wx-3.0/wx/strvararg.h:349:68: error: template argument 1 is 
> invalid
>     enum { value = wxFormatStringSpecifierNonPodType<is_enum::value>::value 
> };
>                                                                    ^
> make[2]: *** 
> [bindings/wxwidgets/CMakeFiles/plplotwxwidgets.dir/wxPLplotstream.cpp.o] 
> Error 1
> make[1]: *** [bindings/wxwidgets/CMakeFiles/plplotwxwidgets.dir/all] Error 2
> make: *** [all] Error 2
>
> Not sure how to set compiler flags, I will have to investigate further. Or 
> maybe cmake should be doing this for us?

Try setting the environment variable CXXFLAGS as a workaround.  But I
don't need to do that here so I suspect the problem is a fundamental
mismatch between the old wxwidgets system libraries available to you
on Ubuntu trusty
and the (much newer) g++ compiler versions that are available to you
with travis-ci.  So I suspect that workaround won't help much, and
you will have to set -DPLD_wxwidgets=OFF (or drop installing the
wxwidgets development libraries) until travis-ci makes a newer set
of Linux libraries available.

>> * make[2]: Circular examples/python/x00 <- examples/python/x00
>> dependency dropped.
>> 
>> And many, many more such messages.
>
> Using cmake-3.7.0 seems to have fixed this.

Excellent.  I was quite concerned by that issue, but that good result
with cmake-3.7.0 confirms my prejudices against early versions of
CMake such as 3.1.x through 3.4.x.  The CMake developers actually
didn't introduce too many changes for 3.0.2 compared to 2.8.x so that
remains a reasonably reliable version outside of one known permission
issue I had to work around in the PLplot build system.  But there was
a flood of CMake changes for 3.1.x onwards so it took many subsequent
versions to wring out all the bugs that were introduced by those
changes.

>> Note, if travis-ci somehow precludes you from switching Ubuntu from
>> trusty to Ubuntu yakkety (admittedly a pretty drastic change) in
>> either of the two ways above, then that would force you to build
>> cmake-3.7.0 as part of each of your tests, and that would obviously be
>> slower than the above change to yakkety (if allowed by travis-ci).
>
> I used the cmake-3.7.0 binary so that I don't have to compile it. It would be 
> nice if they provided more recent distros but I'm not holding my breath..

Well, my opinion is CMake-3.7.0 + trusty is marginal rather than a disastrous
combination. So travis-ci will eventually have to move to something
newer, and it is beginning to get urgent.  So "eventually" may come
soon since they have supported precise and trusty (released in April
of 2012 and 2014) which are both LTS (long-term-support) Ubuntu
distributions.  The next LTS Ubuntu distribution was xenial (16.04LTS)
which from the numerical code was released in April this year.  So it
is disappointing that travis-ci has not yet moved to xenial in the 7
months since that release, but perhaps that will happen "real soon now"?

By the way, I also view my own platform, Debian stable = Jessie
(released in April 2015 so a year newer than trusty) as marginal
(i.e., on the edge of being too old).  So sometime in the next few
months I plan to switch to Debian stretch (the "testing" rolling
release).  Note stretch is in a freeze state now or soon will be in
preliminary preparation for releasing it as the next Debian stable
release some time in 2017. So Debian stretch should already be a
pretty reliable testing platform for 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] Fwd: Failed: HazenBabcock/PLplot#26 (master - ae56402)

[Hazen B. <hba...@ma...>]

Everything is passing now except for lasi, hdpf (harupdf?) and wxwidgets.

To make it easier to figure out which test was doing what I added a 
dummy variable to the environment, PLTEST, which shows up in the build 
jobs table.

Once everything is working I will likely combine most of the tests to 
reduce the load on the travis build servers.

I've attached my current .travis.yml file for those who are interested.

best,
-Hazen

-------- Forwarded Message --------
Subject: 	Failed: HazenBabcock/PLplot#26 (master - ae56402)
Date: 	Wed, 23 Nov 2016 18:27:44 +0000
From: 	Travis CI <bu...@tr...>
To: 	hba...@ma...



*HazenBabcock / PLplot <https://travis-ci.org/HazenBabcock/PLplot>* 
(master <https://github.com/HazenBabcock/PLplot/tree/master>)

	Build #26 failed. 
<https://travis-ci.org/HazenBabcock/PLplot/builds/178368681> 	
37 minutes and 50 seconds
	*Hazen Babcock* 	ae56402 
<https://github.com/HazenBabcock/PLplot/commit/ae56402e823575520597230fa9784c1ce0e75cd4> 
Changeset → 
<https://github.com/HazenBabcock/PLplot/compare/e7b1446e83aa...ae56402e8235> 

	Separate out the libhpdf test

*Want to know about upcoming build environment updates?*

Would you like to stay up-to-date with the upcoming Travis CI build 
environment updates? We set up a mailing list for you! Sign up here 
<http://eepurl.com/9OCsP>.

	Documentation <https://docs.travis-ci.com> about Travis CI
Need help? Mail support <mailto:su...@tr...>!
Choose who receives these build notification emails in your 
configuration file <https://docs.travis-ci.com/user/notifications>.

*Would you like to test your private code?*

Travis CI for Private Projects 
<https://travis-ci.com?utm_source=build_email_footer&utm_campaign=travis-ci.org&utm_medium=email> 
could be your new best friend!

Re: [Plplot-devel] Continuous Integration

[Hazen B. <hba...@ma...>]

On 11/23/2016 06:08 AM, Alan W. Irwin wrote:
>
> Sorry for the length of this, but I have a lot to say that should be a
> big help to you for testing purposes.

No problem, I appreciate your thoughts and help.

> * -- WARNING: CMAKE_VERSION = 3.2.2 is in the range from 3.2 through
>   3.3.1 which has a compromised find ability that was fixed in 3.3.2.
>   Please upgrade to 3.3.2 or greater.

I changed the builds to download and install cmake-3.7.0, which seems to 
be working.

> * Currently, your PLplot version is at least 3 commits behind.

That is true. Once I have gotten the .travis.yml file to a point where 
it is providing useful results for us I plan to commit it to the SF 
repo. Since (I believe) travis-ci only works off the master branch on 
Github I thought this was the easiest way to do the testing.

> From this cmake output message, it appears you don't have any X
> display available to you during testing. If you cannot fix that issue,
> I suggest you specifically disable Tk (-DENABLE_tk=OFF) to get rid of
> the above warning.

Done.

> * -- Looking for itcl.h - not found
>   -- WARNING: Disabling Itcl interface code

This is still failing with cmake-3.7.0 and the itcl3 and itcl3-dev packages.

> Your detailed install messages for itcl3-dev seemed to successful
> as noted above, but they did include the following warning message
> about 110 packages that needed updating.
>
> 0 upgraded, 2 newly installed, 0 to remove and 110 not upgraded.
>
> To reduce that "not upgraded" number to 0, do the following:
>
> sudo apt-get update
> sudo apt-get dist-upgrade

I suspect that you can't do that, but I have not actually tried. There 
are a number of issues on the travis github page basically complaining 
that the distros they provide are a bit old and why can't they provide 
something more modern.

> You need to install a package that contains the
> gnatmake command.  On Debian Jessie the name of that package is gnat-4.9.

Done.

> On Debian Jessie, the packages you need to install are called
> liblua5.2-dev (for the development version of the lua library) and lua5.2
> (for the lua executable).

Done.

> On Debian Jessie, the package you need to install is called gdc.

Done.

> On Debian Jessie, the package you need to install is called libshp-dev.

Done.

> On Debian Jessie, the package you need to install is called sip-dev.

Done, but it appears we are also missing the package that contains 
pyqt4. I should be able to fix this on my own :).

> On Debian Jessie, the package you need to install is called liblasi-dev.

This causes the build to fail with:

Scanning dependencies of target psttf
[ 20%] Building CXX object drivers/CMakeFiles/psttf.dir/psttf.cc.o
In file included from 
/home/travis/build/HazenBabcock/PLplot/drivers/psttf.cc:44:0:
/usr/include/LASi.h:14:30: fatal error: freetype/ftglyph.h: No such file 
or directory
compilation terminated.
make[2]: *** [drivers/CMakeFiles/psttf.dir/psttf.cc.o] Error 1
make[1]: *** [drivers/CMakeFiles/psttf.dir/all] Error 2
make: *** [all] Error 2

So I think we are still missing something, a freetype package perhaps?

> On Debian Jessie, the package you need to install is called
> libwxgtk3.0-dev.

This causes the build to fail with:
[ 14%] Building CXX object 
bindings/wxwidgets/CMakeFiles/plplotwxwidgets.dir/wxPLplotstream.cpp.o
In file included from /usr/include/c++/5/type_traits:35:0,
                  from /usr/include/wx-3.0/wx/strvararg.h:25,
                  from /usr/include/wx-3.0/wx/string.h:46,
                  from /usr/include/wx-3.0/wx/memory.h:15,
                  from /usr/include/wx-3.0/wx/object.h:19,
                  from /usr/include/wx-3.0/wx/wx.h:15,
                  from 
/home/travis/build/HazenBabcock/PLplot/bindings/wxwidgets/wxPLplotstream.cpp:22:
/usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file 
requires compiler and library support for the ISO C++ 2011 standard. 
This support must be enabled with the -std=c++11 or -std=gnu++11 
compiler options.
  #error This file requires compiler and library support \
   ^
In file included from /usr/include/wx-3.0/wx/string.h:46:0,
                  from /usr/include/wx-3.0/wx/memory.h:15,
                  from /usr/include/wx-3.0/wx/object.h:19,
                  from /usr/include/wx-3.0/wx/wx.h:15,
                  from 
/home/travis/build/HazenBabcock/PLplot/bindings/wxwidgets/wxPLplotstream.cpp:22:
/usr/include/wx-3.0/wx/strvararg.h:345:18: error: ‘is_enum’ in namespace 
‘std’ does not name a template type
      typedef std::is_enum<T> is_enum;
                   ^
/usr/include/wx-3.0/wx/strvararg.h:349:54: error: ‘is_enum’ was not 
declared in this scope
      enum { value = 
wxFormatStringSpecifierNonPodType<is_enum::value>::value };
                                                       ^
/usr/include/wx-3.0/wx/strvararg.h:349:68: error: template argument 1 is 
invalid
      enum { value = 
wxFormatStringSpecifierNonPodType<is_enum::value>::value };
                                                                     ^
make[2]: *** 
[bindings/wxwidgets/CMakeFiles/plplotwxwidgets.dir/wxPLplotstream.cpp.o] 
Error 1
make[1]: *** [bindings/wxwidgets/CMakeFiles/plplotwxwidgets.dir/all] Error 2
make: *** [all] Error 2

Not sure how to set compiler flags, I will have to investigate further. 
Or maybe cmake should be doing this for us?

> On Debian Jessie, the package you need to install is called libhpdf-dev.

Sorry, missed this one, but I will test it soon.

> * -- WARNING: The ocamlc application not found. Disabling OCaml binding
>
> On Debian Jessie, I discovered by running
>
> apt-file search ocamlc

Done, I used both the ocaml and camlidl packages.

> * -- checking for module 'gtk+-x11-2.0'
>   --   package 'gtk+-x11-2.0' not found
>   -- WARNING: gtk+-x11-2.0 not found.  extXdrawable_demo not built.
>
> On Debian Jessie, the package you need to install is called
> libgtk2.0-dev.

Sorry, missed this one too.

> * make[2]: Circular examples/python/x00 <- examples/python/x00
> dependency dropped.
>
> And many, many more such messages.

Using cmake-3.7.0 seems to have fixed this.

> By the way, will there be a graphical summary somewhere of which
> ctests failed and which did not for your latest test results? (That
> sort of display is what you should soon find at my.cdash.org from my
> own nightly ctest-based testing results.)

I think we'd have to make our own, possibly by scraping the travis page. 
It looks like all they are going to tell you is whether or not all the 
executable "exited with 0".

> In any case, I suggest you specify "trusty" rather than the default
> "precise"
> because the latter is much too old and may include such old versions
> of PLplot dependencies that PLplot is no longer compatible with them.
> See
> <https://docs.travis-ci.com/user/trusty-ci-environment/#Image-differences-from-Precise>
>
> for how to switch from precise to trusty.

I am using trusty.

> Then follow up with the usual
> sudo apt-get update
> sudo apt-get dist-upgrade
>
> Note, if travis-ci somehow precludes you from switching Ubuntu from
> trusty to Ubuntu yakkety (admittedly a pretty drastic change) in
> either of the two ways above, then that would force you to build
> cmake-3.7.0 as part of each of your tests, and that would obviously be
> slower than the above change to yakkety (if allowed by travis-ci).

I used the cmake-3.7.0 binary so that I don't have to compile it. It 
would be nice if they provided more recent distros but I'm not holding 
my breath..

-Hazen

Re: [Plplot-devel] Continuous Integration

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> Hi Arjen:
>
> Just to interject, you have been tempted before to go down this road of attempting
> to support gfortran-4.8.  But I have always argued against that for the following
> reasons:
>
> We may never get that support to work properly.
>
> Adding such support introduces complexity into our new Fortran binding.
>
> gfortran-4.9 works beautifully, and modern Linux (and other) software distributions
> typically provide substantially higher versions than 4.9.  So I assume those who are
> stuck with gfortran-4.8 or lower are a small and rapidly shrinking fraction of our
> potential Fortran users.
>
> So from the above considerations I believe we should address this issue by simply
> stating in the release notes that gfortran-4.8 does not work (unless the user
> specifies our old binding and examples using
> -DPL_DEPRECATED_f95=ON) and therefore gfortran-4.9 is the minimum version
> we support in undeprecated fashion going forward.
>
> @Hazen:
>
> Just for fun with all this testing power at your fingertips, do you want to specify -
> DPL_DEPRECATED_f95=ON for your gfortran-4.8 test to really make sure that
> works like I claim above?
>
Yes, you are right - I was not quite sure which version of gfortran gets it right ;). Since it is only a minor version, we can simply state that you need 4.9 or later. Makes life a lot simpler.

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] Continuous Integration

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

On 2016-11-23 12:40-0000 Arjen Markus wrote:

> Hi Hazen,
>
>
>
> I see ... this is really a problem of the older version of gfortran. I tried the code below with version 5.4, just to make sure:
>
>
>
> module passing_c
>
>    use iso_c_binding
>
>
>
>    implicit none
>
> contains
>
> subroutine pass_array( array )
>
>    integer, dimension(:), target :: array
>
>
>
>    call pass_it( c_loc(array) )
>
> end subroutine pass_array
>
> end module passing_c
>
>
>
> and got no error messages or warnings at all.
>
>
>
> What happens if you add the bind(c) attribute, like:
>
>    integer, dimension(:), target, bind(c) :: array
>
>
> It is not the nicest solution, but maybe that will solve the problem.
>
> Regards,
>
> Arjen

Hi Arjen:

Just to interject, you have been tempted before to go down this road
of attempting to support
gfortran-4.8.  But I have always argued against that for the following
reasons:

We may never get that support to work properly.

Adding such support introduces complexity into our new
Fortran binding.

gfortran-4.9 works beautifully, and modern Linux (and other) software
distributions typically provide substantially higher versions than
4.9.  So I assume those who are stuck with gfortran-4.8 or lower are a
small and rapidly shrinking fraction of our potential Fortran users.

So from the above considerations I believe we should address this
issue by simply stating in the release notes that gfortran-4.8 does
not work (unless the user specifies our old binding and examples using
-DPL_DEPRECATED_f95=ON) and therefore gfortran-4.9 is the minimum
version we support in undeprecated fashion going forward.

@Hazen:

Just for fun with all this testing power at your fingertips, do
you want to specify -DPL_DEPRECATED_f95=ON for your gfortran-4.8 test
to really make sure that works like I claim 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] Continuous Integration

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

Hi Hazen,



I see ... this is really a problem of the older version of gfortran. I tried the code below with version 5.4, just to make sure:



module passing_c

    use iso_c_binding



    implicit none

contains

subroutine pass_array( array )

    integer, dimension(:), target :: array



    call pass_it( c_loc(array) )

end subroutine pass_array

end module passing_c



and got no error messages or warnings at all.



What happens if you add the bind(c) attribute, like:

    integer, dimension(:), target, bind(c) :: array


It is not the nicest solution, but maybe that will solve the problem.

Regards,

Arjen


> -----Original Message-----
> From: Hazen Babcock [mailto:hba...@ma...]
> Sent: Wednesday, November 23, 2016 1:11 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] Continuous Integration
>
>
>
> On 11/23/2016 02:52 AM, Arjen Markus wrote:
> >
> > Nevertheless, do you have an error report for gfortran 4.8? We have
> > seen a few issues when we started on this, but I do not remember
> > whether they were serious and with the newer version they have
> > disappeared. (The NAG compiler is rather picky about not following the
> standard ;)).
>
> It looks like 4.8.5? If you go to the Travis page you can see the logs for all of the
> builds that I tried (click on "Build History"). Here is one example of a build that failed
> because of fortran95:
>
> https://travis-ci.org/HazenBabcock/PLplot/jobs/178182917
>
> All the error messages are some form of:
>
> included_plplot_real_interfaces.f90:2502.25:
>
>      Included at
> /home/travis/build/HazenBabcock/PLplot/bindings/f95/plplot_double.f90:117:
>
>                     c_loc(plotentries), size(plotentries,
> kind=private_plint) )
>
>                           1
>
> Error: Assumed-shape array 'plotentries' at (1) cannot be an argument to the
> procedure 'c_loc' because it is not C interoperable
>
> -Hazen

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] Continuous Integration

[Hazen B. <hba...@ma...>]

On 11/23/2016 02:52 AM, Arjen Markus wrote:
>
> Nevertheless, do you have an error report for gfortran 4.8? We have seen
> a few issues when we started on this, but I do not remember whether they
> were serious and with the newer version they have disappeared. (The NAG
> compiler is rather picky about not following the standard ;)).

It looks like 4.8.5? If you go to the Travis page you can see the logs 
for all of the builds that I tried (click on "Build History"). Here is 
one example of a build that failed because of fortran95:

https://travis-ci.org/HazenBabcock/PLplot/jobs/178182917

All the error messages are some form of:

included_plplot_real_interfaces.f90:2502.25:

     Included at 
/home/travis/build/HazenBabcock/PLplot/bindings/f95/plplot_double.f90:117:

                    c_loc(plotentries), size(plotentries, 
kind=private_plint) )

                          1

Error: Assumed-shape array 'plotentries' at (1) cannot be an argument to 
the procedure 'c_loc' because it is not C interoperable

-Hazen

Re: [Plplot-devel] Soft freeze on December 3rd and release on December17th?

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

On 2016-11-22 20:21-0500 Pedro Vicente wrote:

> Hi Alan
> Those dates look good to me, and I will investigate my 3 thread issues 
> (wxWidgets, Qt, error messages ) well before the freezing date

Hi Pedro:

Glad those dates work out for you.

If as a result of your investigations you have a PLplot change you
would like to suggest, then an ordinary compressed patch (which can be
generated by "git diff" and "gzip") is an OK way for you to communicate
that change to us (as an attachment to your post to this mailing list), but
ideally to give you credit for the actual commit we suggest you use
"git format-patch" (and "gzip") instead.

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] Continuous Integration

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

On 2016-11-22 23:07-0500 Hazen Babcock wrote:

>
> On 11/20/2016 01:12 PM, Tom Schoonjans wrote:
>> That’s exactly how I do it though: trial and error :-)
>
> I think I have at least sort of figured out travis-vi. To make it easier
> I've been doing all the experiments on a personal copy of the PLplot
> repo. It is pretty cool to be able to build 5 different versions at the
> same time :).
>
> If anyone is interested, you can see the results of all the tests here:
> https://travis-ci.org/HazenBabcock/PLplot/builds
>
> So far I have learned the new fortran95 bindings fail with gfortran4.8
> (and presumably lower). I also had trouble with ada, wxwidgets, lua and
> ocaml, but I'm not sure whether these are dependency issues.

Hi Hazen:

Sorry for the length of this, but I have a lot to say that should be a
big help to you for testing purposes.

Indeed those raw testing reports are certainly quite interesting to
me, and here are some suggestions for improvements based on looking in
detail at the results from one of those raw reports
(<https://travis-ci.org/HazenBabcock/PLplot/jobs/178182918>).

* -- WARNING: CMAKE_VERSION = 3.2.2 is in the range from 3.2 through
   3.3.1 which has a compromised find ability that was fixed in 3.3.2.
   Please upgrade to 3.3.2 or greater.

In other words, the cmake version (supplied by your distro?) is not
recommended at all, and I suggest you build and use the latest CMake
release (currently 3.7.0) instead, but note you should be able to
build into your testing scripts a check of recent tags for the git
version of the master branch for CMake to figure out whenever they
release another version.  I plan to automate that process myself for
the cmake script I am putting together to collect ctest results and
publish them at my.cdash.org because otherwise I will forget to do
that update and end up testing latest PLplot against some older
version of cmake that nobody uses any more.  For that cmake script I
actually plan not only to run the PLplot build and ctest against the
latest CMake version and also some fixed CMake versions such as CMake
version 3.7.0 (once that is different from latest CMake version and
currently required for users of rolling software releases such as
Debian testing and MinGW-w64/MSYS2 unless they are willing to
build their own CMake version from scratch), CMake version 3.6.2 (currently
required by Cygwin users unless ...), and CMake version 3.0.2 (currently required
by Debian stable users unless ...).

* Currently, your PLplot version is at least 3 commits behind. (I can
tell that from the form of the cmake output which probably means I
should get a life other than testing and developing PLplot.  :-) )

I assume you are deliberately not upgrading PLplot until you are ready
to merge into SF master the files you need to support these tests. But
when you are ready to test the latest PLplot, you could do the git
fetch, etc., from our SF repository by hand, but that would become a
pretty tough maintenance issue since you would likely have to remember
to do that PLplot upgrade on a daily basis. Therefore, I advise you to
automate your PLplot update process (which is what I plan to do for
the script I referred to above.)

* application-specific initialization failed: no display name and no
   $DISPLAY environment variable

   Error in startup script: no display name and no $DISPLAY environment
   variable
   [....]
   -- Looking for Tk version with wish - not found
   -- WARNING: setting ENABLE_tk to OFF

>From this cmake output message, it appears you don't have any X
display available to you during testing. If you cannot fix that issue,
I suggest you specifically disable Tk (-DENABLE_tk=OFF) to get rid of
the above warning.

* -- Looking for itcl.h - not found
   -- WARNING: Disabling Itcl interface code

On Debian Jessie, the package you need to install is called itcl3-dev
and I presume that the package names I mention for that distro will
also be relevant for Ubuntu as well since that is based on Debian. But
it turns out from your raw test results that you _did_ install
itcl3-dev.  I looked carefully at the Ubuntu install messages for that
package and except for one system update issue, (see below) all seems
to be well there so itcl.h was very likely installed fine, but cmake
is just plain not finding it.  Therefore, I am virtually positive this
problem is an example of one of the many known find problems with your
version of CMake.  So you should address that issue by building and
using the latest CMake (see the remarks about that above), and I am
pretty sure once you do that, this issue with finding itcl.h will
"magically" disappear.

* Updating your Ubuntu distro to make it self-consistent (and a lot more
secure)

Your detailed install messages for itcl3-dev seemed to successful
as noted above, but they did include the following warning message
about 110 packages that needed updating.

0 upgraded, 2 newly installed, 0 to remove and 110 not upgraded.

To reduce that "not upgraded" number to 0, do the following:

sudo apt-get update
sudo apt-get dist-upgrade

The first of those commands updates the lists of _potential_ packages
you should upgrade, and the second of those commands actually does
those updates.  I suspect as a result of the first command, there will
be far more than the 110 packages mentioned above that need updating
to bring your system into self-consistency and to also make it much
more secure because many of those updates are related to security. 
But the second of those commands does those necessary updates and
should bring the "not upgraded" count to 0.  (Note as a matter of
standard maintenance of your Ubuntu system I would reccommend doing
the two sudo commands above at least a couple of times a month, and
depending on the pace of upgrading packages by the Ubuntu packagers,
you might want to do those two commands much more often than that.)

* -- WARNING: no working Ada compiler so disabling Ada binding and
examples.

You need to install a package that contains the
gnatmake command.  On Debian Jessie the name of that package is gnat-4.9.


* -- Could NOT find Lua (missing:  LUA_EXECUTABLE LUA_VERSION
LUA_LIBRARIES LUA_INCLUDE_DIR)
   -- WARNING: Lua library and/or header not found. Disabling Lua binding

On Debian Jessie, the packages you need to install are called
liblua5.2-dev (for the development version of the lua library) and lua5.2
(for the lua executable).

* -- WARNING: no working D compiler so disabling D binding and examples.

On Debian Jessie, the package you need to install is called gdc.

* -- WARNING: SHAPELIB not found.  Setting HAVE_SHAPELIB to OFF.

On Debian Jessie, the package you need to install is called libshp-dev.

* -- pyqt: SIP_EXECUTABLE = SIP_EXECUTABLE-NOTFOUND
   -- WARNING: sip not found so setting ENABLE_pyqt4 / ENABLE_pyqt5 to OFF.

On Debian Jessie, the package you need to install is called sip-dev.

* --   package 'lasi' not found
        [...]
   -- WARNING: pango, pangoft2, or lasi not found with pkg-config.

    Setting PLD_psttf to OFF.  Please install all of these packages

       and/or set the environment variable PKG_CONFIG_PATH appropriately.

On Debian Jessie, the package you need to install is called liblasi-dev.

* -- wxWidgets_FOUND           : FALSE
   -- wxWidgets_INCLUDE_DIRS    :
   -- wxWidgets_LIBRARY_DIRS    :
   -- wxWidgets_LIBRARIES       :
   -- wxWidgets_CXX_FLAGS       :
   -- wxWidgets_USE_FILE        : UsewxWidgets
   -- WARNING: wxWidgets or its libraries not found so setting all wxwidgets devices to OFF.
   -- WARNING: PLD_wxwidgets is OFF so setting ENABLE_wxwidgets to OFF.
   -- WARNING: ENABLE_wxwidgets is OFF so setting all wxwidgets devices to OFF.

On Debian Jessie, the package you need to install is called 
libwxgtk3.0-dev.

* -- Looking for haru pdf header and library
   -- Looking for haru pdf header and library - not found
   -- WARNING: Setting PLD_pdf to OFF.

On Debian Jessie, the package you need to install is called libhpdf-dev.

* -- WARNING: The ocamlc application not found. Disabling OCaml binding

On Debian Jessie, I discovered by running

apt-file search ocamlc

that the package ocaml-nox contains that needed executable.  However,
I happen to know that ocaml-nox is a dependency of the "ocaml" package
which advertises itself as providing everything you need for ocaml
development so I would recommend you install ocaml (which
automatically installs its dependency, ocaml-nox as well) instead of
just ocaml-nox alone.

There may be additional ocaml-related executables or libraries, you
need once our build system finds ocamlc installed on your platform,
but look in the raw output from the cmake command for any relevant
WARNING messages about that. Such messages will likely include what
executable is still missing, and in that case the apt-file command
should help you to figure out what additional packages you need to
install to support our ocaml bindind and examples.

* -- checking for module 'gtk+-x11-2.0'
   --   package 'gtk+-x11-2.0' not found
   -- WARNING: gtk+-x11-2.0 not found.  extXdrawable_demo not built.

On Debian Jessie, the package you need to install is called
libgtk2.0-dev.

* make[2]: Circular examples/python/x00 <- examples/python/x00
dependency dropped.

And many, many more such messages.

I don't have a clue whether that is a CI analysis error or your
old version of CMake actually produces bad Makefiles as claimed,
but it will be interesting to see if this issue dissapears once
you move to modern cmake.

N.B. All my comments above are relevant to testing the latest PLplot,
testing all components of PLplot whose dependencies should be readily
accessible on Ubuntu, and preparing your Ubuntu system to be
consistent and secure.  So once you address all the above issues all
the cmake WARNINGS I mentioned above should be gone (i.e., the
WARNINGS that remain should never refer to missing components), and
your PLplot testing environment should become as powerful as mine.

But despite these temporary limitations of your current tests, I want
to congratulate you on at least one test result you have produced
which is already useful to me because it definitely confirms my
previous suspicion (from problematic results for gfortran-4.8 when
Arjen first started implementing this new Fortran binding) that
gfortran-4.8 does not support the iso_c_binding module (first
introduced for Fortran 2003) well enough to build the new binding.  So
as a result of your current tests, I can now state in the release
notes that gfortran-4.9 (which works well for you there and which also
works well for me here with Debian Jessie) is the minimum version of
gfortran that can be used with the new binding.

Anyhow, thanks very much for the interesting testing results you have
already generated, and I look forward to more of those with the above
issues addressed.

By the way, will there be a graphical summary somewhere of which
ctests failed and which did not for your latest test results? (That
sort of display is what you should soon find at my.cdash.org from my
own nightly ctest-based testing results.)

Also, after writing the above I have now read a bit more about the
<https://en.wikipedia.org/wiki/Travis_CI> continuous integration
available for free to gitHub users and also followed up by reading
<https://docs.travis-ci.com/user/customizing-the-build/#Customizing-the-Build-Step>
The "apt-get update" and apt-get install commands are specifically
mentioned in that latter document so I presume "apt-get dist-upgrade"
is also available, and I highly recommend including that.
I also find from
<https://docs.travis-ci.com/user/ci-environment/#Virtualization-environments>
that both Ubuntu 12.04 LTS (precise) and  14.04 LTS (trusty) with
both the 64-bit Server Edition.

>From looking at
<http://packages.ubuntu.com/search?keywords=cmake&searchon=names&suite=all&section=all>
no offical version of Ubuntu supplies the version (3.2.2) that you get
from Travis.  I assume that is because precise was released more than 4 years
ago, and trusty was released more than two years ago so neither of them
provides access to modern CMake-3.

In any case, I suggest you specify "trusty" rather than the default "precise"
because the latter is much too old and may include such old versions
of PLplot dependencies that PLplot is no longer compatible with them.
See
<https://docs.travis-ci.com/user/trusty-ci-environment/#Image-differences-from-Precise>
for how to switch from precise to trusty.

I am now wondering whether it is possible to use the same simple
method to get access to the latest officially released Ubuntu which is
called yakkety and which gives you access to CMake-3.5.2 and many
other recent versions of the PLplot dependencies so that would be a
really powerful and interesting test environment.

Also, note that travis-ci gives you a fresh system for every test
which implies it might be possible to change that system anyway you
like since they are no consequences other than possibly a temporarily
broken system and therefore a broken test result.  So assuming the
above idea for getting access to yakkety does not work, the
possibility exists that if you follow the ideas in
<https://www.howtoforge.com/tutorial/ubuntu-rolling-release/> (an
article about how to change Ubuntu to a rolling release, but the same
idea can be used to change from one official version to another) you
can change Ubuntu versions with just 3 key commands (if you don't
count the two extra cat commands to figure out whether the key sed
command actually worked properly or not)

sudo cat /etc/apt/sources.list
sudo sed -i 's/trusty/yakkety/g' /etc/apt/sources.list
sudo cat /etc/apt/sources.list

Those cat commands are not necessary, but they should tell you what is
going on with the key /etc/apt/sources.list file before and after the
sed command changed that system file.

Then follow up with the usual
sudo apt-get update
sudo apt-get dist-upgrade

Note, if travis-ci somehow precludes you from switching Ubuntu from
trusty to Ubuntu yakkety (admittedly a pretty drastic change) in
either of the two ways above, then that would force you to build
cmake-3.7.0 as part of each of your tests, and that would obviously be
slower than the above change to yakkety (if allowed by travis-ci).

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] Continuous Integration

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

Hi Hazen,



Gfortran 4.8.0 was released in march 2013, the last version of that series was 4.8.5, released in june 2015. The current development version is 7.x. Version 5 has seen four releases since the first one in april 2015. While I can imagine there are problems with the new binding if you use this rather old version of gfortran, note that we have been testing this with three unrelated compilers (gfortran 5.x, Intel Fortran 15 and NAG Fortran). I may actually be able to test it with a fourth one, Oracle Fortran, before the freeze date. So I am pretty sure that a recent enough version of any Fortran compiler will be useable.

Nevertheless, do you have an error report for gfortran 4.8? We have seen a few issues when we started on this, but I do not remember whether they were serious and with the newer version they have disappeared. (The NAG compiler is rather picky about not following the standard ;)).

Regards,

Arjen



> -----Original Message-----
> From: Hazen Babcock [mailto:hba...@ma...]
> Sent: Wednesday, November 23, 2016 5:07 AM
> To: Tom Schoonjans
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] Continuous Integration
>
>
> On 11/20/2016 01:12 PM, Tom Schoonjans wrote:
> > That's exactly how I do it though: trial and error :-)
>
> I think I have at least sort of figured out travis-vi. To make it easier I've been doing
> all the experiments on a personal copy of the PLplot repo. It is pretty cool to be able
> to build 5 different versions at the same time :).
>
> If anyone is interested, you can see the results of all the tests here:
> https://travis-ci.org/HazenBabcock/PLplot/builds
>
> So far I have learned the new fortran95 bindings fail with gfortran4.8 (and
> presumably lower). I also had trouble with ada, wxwidgets, lua and ocaml, but I'm
> not sure whether these are dependency issues.
>
> -Hazen
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

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] Continuous Integration

[Hazen B. <hba...@ma...>]

On 11/20/2016 01:12 PM, Tom Schoonjans wrote:
> That’s exactly how I do it though: trial and error :-)

I think I have at least sort of figured out travis-vi. To make it easier 
I've been doing all the experiments on a personal copy of the PLplot 
repo. It is pretty cool to be able to build 5 different versions at the 
same time :).

If anyone is interested, you can see the results of all the tests here:
https://travis-ci.org/HazenBabcock/PLplot/builds

So far I have learned the new fortran95 bindings fail with gfortran4.8 
(and presumably lower). I also had trouble with ada, wxwidgets, lua and 
ocaml, but I'm not sure whether these are dependency issues.

-Hazen