Re: [Plplot-devel] Testing with Docker

2016-11-23 Thread Alan W. Irwin 
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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Testing with Docker

2016-11-23 Thread Hazen Babcock 


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
# Distro
FROM debian:latest
MAINTAINER Hazen Babcock 

# Update sources
RUN apt update

# Get dependencies, these are in alphabetical order
RUN apt --yes install camlidl
RUN apt --yes install cmake
RUN apt --yes install gcc
#RUN apt --yes install gdc
RUN apt --yes install gfortran
RUN apt --yes install git
#RUN apt --yes install gnat
RUN apt --yes install g++
#RUN apt --yes install default-jdk
#RUN apt --yes install default-jre
#RUN apt --yes install itcl3
#RUN apt --yes install itcl3-dev
#RUN apt --yes install libcairo-dev
#RUN apt --yes install libgtk2.0-dev
#RUN apt --yes install libhpdf-dev
#RUN apt --yes install liblasi-dev
#RUN apt --yes install liblua5.2-dev
#RUN apt --yes install libpango1.0-dev
#RUN apt --yes install libqhull-dev
#RUN apt --yes install libshp-dev
#RUN apt --yes install libxml-dom-perl
#RUN apt --yes install libxml-parser-perl
#RUN apt --yes install libwxgtk3.0-dev
#RUN apt --yes install lua5.2
RUN apt --yes install ocaml
#RUN apt --yes install octave
#RUN apt --yes install pdl
#RUN apt --yes install python-dev
#RUN apt --yes install python-numpy
#RUN apt --yes install python-qt4
#RUN apt --yes install python-qt4-dev
#RUN apt --yes install sip-dev
#RUN apt --yes install swig

# Get PLplot, configure, build and test.
RUN cd tmp && git clone git://git.code.sf.net/p/plplot/plplot plplot
RUN cd tmp && mkdir plplot-build
RUN cd tmp/plplot-build && cmake ../plplot -DBUILD_TEST=ON -DENABLE_tk=OFF
RUN cd tmp/plplot-build && make
RUN cd tmp/plplot-build && ctest --verbose
--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Continuous Integration

2016-11-23 Thread Alan W. Irwin 
@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
. 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
, tcl.h
should be found at

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

and if you look at
, 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 .

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 i

[Plplot-devel] Fwd: Failed: HazenBabcock/PLplot#26 (master - ae56402)

2016-11-23 Thread Hazen Babcock 


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 +
From:   Travis CI 
To: hbabc...@mac.com



*HazenBabcock / PLplot * 
(master )


	Build #26 failed. 
 	

37 minutes and 50 seconds
	*Hazen Babcock* 	ae56402 
 
Changeset → 
 


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 
.


Documentation  about Travis CI
Need help? Mail support !
Choose who receives these build notification emails in your 
configuration file .


*Would you like to test your private code?*

Travis CI for Private Projects 
 
could be your new best friend!





.travis.yml
Description: application/yaml
--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Continuous Integration

2016-11-23 Thread Hazen Babcock 
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 is_enum;
   ^
/usr/include/wx-3.0/wx/strvararg.h:349:54: error: ‘is_enum’ was not 
declared in this scope
  enum { value = 
wxFormatStringSpecifierNonPodType::value };
   ^
/usr/include/wx-3.0/wx/strvararg.h:349:68: error: template argument 1 is 
invalid
  enum { value = 
wxFormatStringSpecifierNonPodType::value };

Re: [Plplot-devel] Continuous Integration

2016-11-23 Thread Arjen Markus 
Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
>
> 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.
--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Continuous Integration

2016-11-23 Thread Alan W. Irwin 
On 2016-11-23 12:40- 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
__

--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Continuous Integration

2016-11-23 Thread Arjen Markus 
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:hbabc...@mac.com]
> 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.
--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Continuous Integration

2016-11-23 Thread Hazen Babcock 


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

--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

2016-11-23 Thread Alan W. Irwin 
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
__

--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Continuous Integration

2016-11-23 Thread Alan W. Irwin 
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
().

* -- 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