plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Space in full pathname issues

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

On 2017-05-09 07:00-0000 Arjen Markus wrote:

> Well, there is indeed a conundrum [for MSVC] - the diff executable. I have a solution in mind (using a temporary environment variable) to transfer the context from the shell script to CMake (this involves effectively going from one operating environment - MinGW-w64/MSYS2 - to another - "bare Windows") and I expect it to work, but I need to test it. And it may be there is a more elegant and robust way. Will keep you informed.

Hi Arjen:

The diff executable from the MinGW-w64/MSYS2 Unix tools should "just
work" if run from a bash script (as in comprehensive testing, ctest,
etc.) Is the issue simply that our build system is finding something
other than /usr/bin/diff.exe from the MinGW-w64/MSYS2 diffstat package?

If the issue is more complicated than that, please send me the
relevant report tarball.

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] Space in full pathname issues

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

Hi Alan,



I will be using this message to answer the other two as well ;).



See below.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, May 08, 2017 7:18 PM
> To: Arjen Markus
> Cc: Chris Marshall; PLplot development list
> Subject: RE: [Plplot-devel] Space in full pathname issues
>
> On 2017-05-08 08:03-0000 Arjen Markus wrote:
>
> > Hi Alan, Chris,
> >
> >
> >
> > I tried the same thing with MinGW-w64/MSYS2. This succeeded in so far, that:
> >
> > -        CMake produced a full report and makefiles
>
> Assuming the form I suggested on Cygwin
>
> cmake  .... "-CMAKE_INSTALL_PREFIX=d:/plplot-src/install with spaces"
>
> does work there, please check that same form (used by the comprehensive test
> script) works on this platform as well.
>
I have thought of that form too - it might do the trick indeed. I just hadn't expected the phenomenon I got - CMake in an infinite loop.

> >
> > -        make succeeded
> >
> > -        make install succeeded as well
>
> Congratulations.  This is all very encouraging.
>
> > -        making the examples worked, except for Java - the path to the Java
> compiler was not quoted
>
> Interesting.  According to <http://repo.msys2.org/mingw/x86_64/>,
> MinGW-w64/MSYS2 does not provide Java.  The conclusion that this is a non-
> platform version of Java also seems to be confirmed by the space in the Java
> compiler pathname since I assume this particular test was for an ordinary "non-
> space" installation of this platform.  If it is true this is a non-platform Java, I am
> pretty sure you are going to have ABI issues when attempting to use it on MinGW-
> w64/MSYS2 so you should take some measure to exclude Java there.  Brute force
> would be -DENABLE_java=OFF (with a big note in your submission script), but
> perhaps a better overall choice would be to adjust your PATH on this platform so
> CMake does not find non-platform software like this.
>
> That said, note if this version of Java is ABI compatible with the MSVC compilers,
> then it should be expected to work for your MSVC tests, and the case (4) issue you
> have found with our build system (Java compiler not quoted) will need to be
> addressed, and I look forward to your commit to that effect.

Sure, I think CMake found the "bare Windows" version of Java. I expect it will work, once the spaces issue is solved.

>
> And by the way, I thought you had solved some Tcl build system issue?
> If so, you should commit it before you lose it.
>
In theory I have, I just haven't had the opportunity yet to test it :). I didn't want to commit the changes beforehand.

>
> > -        running a C example didn't work, as the drivers are not installed
> > The latter is an omission in the installation procedure - I never noticed that before
> but I seldom use this full build procedure.
>
> I am virtually positive from your and Greg's previous comprehensive test successes
> on this platform that "make install" does install the drivers.  However, if you look at
> the comprehensive test script, special measures had to be used to put the installed
> driver location on the PATH.  But I hasten to add this PATH change should only be
> done when the install tree is being tested, and otherwise (e.g., when testing the
> build tree) the installation location for the drivers should be removed from the PATH
> (as you will see the comprehensive test script implements).
>
Argh, sorry for the noise - they are indeed installed, but under a different directory than I thought. Okay, that sorts out that issue.

>From your last message:

Hi Arjen:



It sounds like you are making good progress on this platform as well.

For all three Windows platforms I look forward to your commits solving the straightforward issues that you find and I assume the problem above is of that type.



However, if this or some other issue is tricky for you to solve, feel free to consult in detail with me using the normal report tarball method (which typically is required to give me all the details that I need to help you).

Well, there is indeed a conundrum - the diff executable. I have a solution in mind (using a temporary environment variable) to transfer the context from the shell script to CMake (this involves effectively going from one operating environment - MinGW-w64/MSYS2 - to another - "bare Windows") and I expect it to work, but I need to test it. And it may be there is a more elegant and robust way. Will keep you informed.

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] Space in full pathname issues

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

On 2017-05-08 13:40-0000 Arjen Markus wrote:

> Hi Alan, Chris,
>
>
>
> Just repeated the build experiment for "bare" Windows:
>
> -        CMake, make and make install all work with a destination directory whose name contains spaces
>
> -        However, nmake on the installed examples produces an error message:
>
>
>
> Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
>
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
>
>
>            cd c; "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\nmake.exe"
>
> The filename, directory name, or volume label syntax is incorrect.
>
> NMAKE : fatal error U1077: 'cd' : return code '0x1'
>
> Stop.
>
>
> The problem is probably in the combining of two commands via a semicolon. If I try "cd c; nmake" manually, I get the message "The system cannot find the path specified". It is not splitting up the line into two commands.
>
> Probably this has nothing to do with the spaces issue.

Hi Arjen:

It sounds like you are making good progress on this platform as well.
For all three Windows platforms I look forward to your commits solving the straightforward issues
that you find and I assume the problem above is of that type.

However, if this or some other issue is tricky for you to solve, feel
free to consult in detail with me using the normal report tarball
method (which typically is required to give me all the details that I
need to help you).

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] Space in full pathname issues

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

On 2017-05-08 08:03-0000 Arjen Markus wrote:

> Hi Alan, Chris,
>
>
>
> I tried the same thing with MinGW-w64/MSYS2. This succeeded in so far, that:
>
> -        CMake produced a full report and makefiles

Assuming the form I suggested on Cygwin

cmake  .... "-CMAKE_INSTALL_PREFIX=d:/plplot-src/install with spaces"

does work there, please check that same form (used by the
comprehensive test script) works on this platform as well.

>
> -        make succeeded
>
> -        make install succeeded as well

Congratulations.  This is all very encouraging.

> -        making the examples worked, except for Java - the path to the Java compiler was not quoted

Interesting.  According to <http://repo.msys2.org/mingw/x86_64/>,
MinGW-w64/MSYS2 does not provide Java.  The conclusion that this is a
non-platform version of Java also seems to be confirmed by the space
in the Java compiler pathname since I assume this particular test was
for an ordinary "non-space" installation of this platform.  If it is
true this is a non-platform Java, I am pretty sure you are going to
have ABI issues when attempting to use it on MinGW-w64/MSYS2 so you
should take some measure to exclude Java there.  Brute force would be
-DENABLE_java=OFF (with a big note in your submission script), but
perhaps a better overall choice would be to adjust your PATH on this
platform so CMake does not find non-platform software like this.

That said, note if this version of Java is ABI compatible with the
MSVC compilers, then it should be expected to work for your MSVC
tests, and the case (4) issue you have found with our build system
(Java compiler not quoted) will need to be addressed, and I look
forward to your commit to that effect.

And by the way, I thought you had solved some Tcl build system issue?
If so, you should commit it before you lose it.


> -        running a C example didn't work, as the drivers are not installed
> The latter is an omission in the installation procedure - I never noticed that before but I seldom use this full build procedure.

I am virtually positive from your and Greg's previous comprehensive
test successes on this platform that "make install" does install the
drivers.  However, if you look at the comprehensive test script,
special measures had to be used to put the installed driver location
on the PATH.  But I hasten to add this PATH change should only be done
when the install tree is being tested, and otherwise (e.g., when
testing the build tree) the installation location for the drivers
should be removed from the PATH (as you will see the comprehensive
test script implements).

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] Space in full pathname issues

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

On 2017-05-08 07:18-0000 Arjen Markus wrote:

> Hi Alan, Chris,
>
[...]
> My first step was to build in a directory whose name contains spaces, but nothing else. This worked smoothly for both Cygwin and MinGW-w64/MSYS2.

Hi Arjen:

Good to hear you had that initial promising result on both platforms.

>
> My next step was to build in that same directory and explicitly install in a (different) directory whose name contains spaces:
>
> cmake .... -DCMAKE_INSTALL_PREFIX="d:/plplot-src/install with spaces"
>
> (I simply added this option to the existing CMake invocation)
>
> This experiment was less successful: CMake started but never got beyond "configuration done" - no further output was produced, but according to the Task Manager it was writing a lot of data - after 15 minutes of CPU it had produced 52 MB of output. No idea though where this got to - the subdirectories of the build directory contain less than 10 MB. After that time I simply killed the program.

A slight variation of the above is a success on Linux with the
comprehensive test script under bash.  So what happens if you try the
comprehensive test form exactly, i.e.,

cmake  .... "-CMAKE_INSTALL_PREFIX=d:/plplot-src/install with spaces"

(with quotes around the whole option rather than just part of it)?

I am pretty sure you will have success with that variant because a lot
of experience has gone into that script so, for example, I am pretty
sure the form you tried above would not work on Linux.  For that same
reason when doing hand experiements like this, it is always a good
idea to follow the script (or just use it).

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] Space in full pathname issues

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

Hi Alan, Chris,



Just repeated the build experiment for "bare" Windows:

-        CMake, make and make install all work with a destination directory whose name contains spaces

-        However, nmake on the installed examples produces an error message:



Microsoft (R) Program Maintenance Utility Version 12.00.21005.1

Copyright (C) Microsoft Corporation.  All rights reserved.



            cd c; "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\nmake.exe"

The filename, directory name, or volume label syntax is incorrect.

NMAKE : fatal error U1077: 'cd' : return code '0x1'

Stop.


The problem is probably in the combining of two commands via a semicolon. If I try "cd c; nmake" manually, I get the message "The system cannot find the path specified". It is not splitting up the line into two commands.

Probably this has nothing to do with the spaces issue.

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] Space in full pathname issues

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

Hi Alan, Chris,



I tried the same thing with MinGW-w64/MSYS2. This succeeded in so far, that:

-        CMake produced a full report and makefiles

-        make succeeded

-        make install succeeded as well

-        making the examples worked, except for Java - the path to the Java compiler was not quoted

-        running a C example didn't work, as the drivers are not installed



The latter is an omission in the installation procedure - I never noticed that before but I seldom use this full build procedure.



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] Space in full pathname issues

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

Hi Alan, Chris,



Here are my first experiences with directories containing spaces in their names. See below in context.

Regards,

Arjen

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Friday, May 05, 2017 10:40 PM
> To: Arjen Markus; Chris Marshall; PLplot development list
> Subject: Re: [Plplot-devel] Space in full pathname issues
>
> To Arjen and Chris:
>
> @Arjen:
>
> I saw your remark that you were going to write off the Cygwin platform for case (4)
> testing, but please hold off on that decision until Chris clarifies what he said below:
>
> On 2017-05-05 08:24-0400 Chris Marshall wrote:
>
> > cygwin doesn't handle install directories with whitespace fully or at all.
>

My first step was to build in a directory whose name contains spaces, but nothing else. This worked smoothly for both Cygwin and MinGW-w64/MSYS2.

My next step was to build in that same directory and explicitly install in a (different) directory whose name contains spaces:

cmake .... -DCMAKE_INSTALL_PREFIX="d:/plplot-src/install with spaces"

(I simply added this option to the existing CMake invocation)

This experiment was less successful: CMake started but never got beyond "configuration done" - no further output was produced, but according to the Task Manager it was writing a lot of data - after 15 minutes of CPU it had produced 52 MB of output. No idea though where this got to - the subdirectories of the build directory contain less than 10 MB. After that time I simply killed the program.

> @Chris:
>
> To clarify what you said, are you concerned that basic functionality (compilers,
> CMake, C, library, Unix tools like bash) just won't work at all on Cygwin if a
> "spaced" install prefix is used?  Or are you concerned that some libaries which are
> soft dependencies of PLplot but which are not fundamental to Cygwin's basic
> functionality won't work for this "spaced" case?  If the latter, I agree there are likely
> to be such cases (since free software has historically struggled with spaces in full
> pathnames just like PLplot is doing now), but that does not preclude us testing for
> case (4) issues for PLplot on Cygwin.
>

My Cygwin installation is in an ordinary directory, no spaces involved. Given the behaviour I saw, the first problem one would encounter is one in CMake itself.

CMake under Cygwin is version 3.6.2.

> @ Both:
>
> The argument is if a PLplot build with all bindings and devices that depend on
> external libraries disabled is a success for this "spaced"
> install prefix case, then that proves the basic functionality of Cygwin works for this
> case. And if you then follow up by removing all those constraints from the PLplot
> build, then you will likely encounter (as I stated above) some problems for certain
> PLplot components.  However, for these cases a quick visual check of "make
> VERBOSE=1" results should tell you whether the command that is failing has been
> set up properly by our build system so that the blanks are quoted or escaped
> properly.  And if we fix all such issues (or there are none) and the command still
> fails, then we will have to blacklist that component of PLplot (i.e., disable it) for
> "spaced" install prefixes until the external package sorts out its own problems for
> that scenario.
>
> Note, this argument is a general one so it also applies to both the
> MinGW-w64/MSYS2 and epa_build platforms.  If the platform fundamentals work
> for a "spaced" installation prefix (which is true almost by definition for at least the
> epa_build case) then sorting out whether the trouble for a given component of
> PLplot is due to an issue with our build system or the external software component
> for the platform should be completely straightforward.
>
Unfortunately, I am not getting this far.

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] Space in full pathname issues

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

To Arjen and Chris:

@Arjen:

I saw your remark that you were going to write off the Cygwin platform
for case (4) testing, but please hold off on that decision until
Chris clarifies what he said below:

On 2017-05-05 08:24-0400 Chris Marshall wrote:

> cygwin doesn't handle install directories with whitespace fully or at all.

@Chris:

To clarify what you said, are you concerned that basic functionality
(compilers, CMake, C, library, Unix tools like bash) just won't work
at all on Cygwin if a "spaced" install prefix is used?  Or are you
concerned that some libaries which are soft dependencies of PLplot but
which are not fundamental to Cygwin's basic functionality won't work
for this "spaced" case?  If the latter, I agree there are likely to be
such cases (since free software has historically struggled with spaces
in full pathnames just like PLplot is doing now), but that does not
preclude us testing for case (4) issues for PLplot on Cygwin.

@ Both:

The argument is if a PLplot build with all bindings and devices that
depend on external libraries disabled is a success for this "spaced"
install prefix case, then that proves the basic functionality of
Cygwin works for this case. And if you then follow up by removing all
those constraints from the PLplot build, then you will likely
encounter (as I stated above) some problems for certain PLplot
components.  However, for these cases a quick visual check of "make
VERBOSE=1" results should tell you whether the command that is failing
has been set up properly by our build system so that the blanks are
quoted or escaped properly.  And if we fix all such issues (or there
are none) and the command still fails, then we will have to blacklist
that component of PLplot (i.e., disable it) for "spaced" install
prefixes until the external package sorts out its own problems for
that scenario.

Note, this argument is a general one so it also applies to both the
MinGW-w64/MSYS2 and epa_build platforms.  If the platform fundamentals
work for a "spaced" installation prefix (which is true almost by
definition for at least the epa_build case) then sorting out whether
the trouble for a given component of PLplot is due to an issue with
our build system or the external software component for the platform
should be completely straightforward.

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] Space in full pathname issues

[Chris M. <dev...@gm...>]

You could still test the plplot space fixes, but you shouldn't install
cygwin into a location with whitespace in its pathname to do so.

On Fri, May 5, 2017 at 8:34 AM, Arjen Markus <Arj...@de...>
wrote:

> Hi Chris,
>
>
>
> Thanks for the warning – I will not try to test this feature on Cygwin
> then.
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>
>
> *From:* Chris Marshall [mailto:dev...@gm...]
> *Sent:* Friday, May 05, 2017 2:25 PM
> *To:* Arjen Markus
> *Cc:* PLplot development list
> *Subject:* Re: [Plplot-devel] Space in full pathname issues
>
>
>
> cygwin doesn't handle install directories with whitespace fully or at all.
>
>
> At any rate, you would not be able to determine if a failure was from
>
> a bad fix at the plplot level or the underlying cygwin and the white space.
>
> Cheers,
>
> Chris
>
>
>
> On Fri, May 5, 2017 at 2:41 AM, Arjen Markus <Arj...@de...>
> wrote:
>
> Hi Alan,
>
>
>
> > -----Original Message-----
> > From: Alan W. Irwin [mailto:ir...@be...
> <ir...@be...>]
> > Sent: Friday, May 05, 2017 5:09 AM
>
> > However, I have figured out two good alternatives for completely testing
> case (4)
> > which are for some tester with access to Windows to install either/both
> the Cygwin
> > and MinGW-w64/MSYS2 platforms using a installation prefix that has a
> blank in the
> > full pathname.  (Something we normally discourage, but we encourage it
> here for
> > this testing
> > purpose.) A PLplot build on either of such platforms would essentially
> provide a
> > complete test of case (4) instead of the piecemeal work you are doing at
> the
> > moment with only some of the external libraries and executables used by
> PLplot
> > having spaces in their full pathname.
> >
> Just a short update: I locally adjusted the diff commands in
> test_diff.sh.in, as these were causing trouble because of spaces in the
> path name. While doing that I found that CMake finds a “diff” program that
> is most probably not compliant with the Linux/POSIX/… conventions. So the
> report about the differences concerns all examples.
>
> The way around that is to force the use of the MinGW-w64/MSYS2 diff
> program. There may be more such surprises.
>
> And then there is the matter of the mysterious “D?” directory created by
> ctest. It is not the consequence of anything obvious that I could detect.
>
> Especially this latter issue hinders progress in the comprehensive tests,
> as it causes a premature end (find is not able to handle this directory and
> thus an error is thrown). So slow progress for the moment.
>
> 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.
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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] Space in full pathname issues

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

Hi Chris,



Thanks for the warning - I will not try to test this feature on Cygwin then.



Regards,



Arjen



From: Chris Marshall [mailto:dev...@gm...]
Sent: Friday, May 05, 2017 2:25 PM
To: Arjen Markus
Cc: PLplot development list
Subject: Re: [Plplot-devel] Space in full pathname issues

cygwin doesn't handle install directories with whitespace fully or at all.

At any rate, you would not be able to determine if a failure was from
a bad fix at the plplot level or the underlying cygwin and the white space.
Cheers,
Chris

On Fri, May 5, 2017 at 2:41 AM, Arjen Markus <Arj...@de...<mailto:Arj...@de...>> wrote:

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Friday, May 05, 2017 5:09 AM

> However, I have figured out two good alternatives for completely testing case (4)
> which are for some tester with access to Windows to install either/both the Cygwin
> and MinGW-w64/MSYS2 platforms using a installation prefix that has a blank in the
> full pathname.  (Something we normally discourage, but we encourage it here for
> this testing
> purpose.) A PLplot build on either of such platforms would essentially provide a
> complete test of case (4) instead of the piecemeal work you are doing at the
> moment with only some of the external libraries and executables used by PLplot
> having spaces in their full pathname.
>
Just a short update: I locally adjusted the diff commands in test_diff.sh.in<http://test_diff.sh.in>, as these were causing trouble because of spaces in the path name. While doing that I found that CMake finds a "diff" program that is most probably not compliant with the Linux/POSIX/... conventions. So the report about the differences concerns all examples.

The way around that is to force the use of the MinGW-w64/MSYS2 diff program. There may be more such surprises.

And then there is the matter of the mysterious "D?" directory created by ctest. It is not the consequence of anything obvious that I could detect.

Especially this latter issue hinders progress in the comprehensive tests, as it causes a premature end (find is not able to handle this directory and thus an error is thrown). So slow progress for the moment.

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.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Plplot-devel mailing list
Plp...@li...<mailto: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] Space in full pathname issues

[Chris M. <dev...@gm...>]

cygwin doesn't handle install directories with whitespace fully or at all.

At any rate, you would not be able to determine if a failure was from
a bad fix at the plplot level or the underlying cygwin and the white space.

Cheers,
Chris


On Fri, May 5, 2017 at 2:41 AM, Arjen Markus <Arj...@de...>
wrote:

> Hi Alan,
>
>
>
> > -----Original Message-----
> > From: Alan W. Irwin [mailto:ir...@be...
> <ir...@be...>]
> > Sent: Friday, May 05, 2017 5:09 AM
>
> > However, I have figured out two good alternatives for completely testing
> case (4)
> > which are for some tester with access to Windows to install either/both
> the Cygwin
> > and MinGW-w64/MSYS2 platforms using a installation prefix that has a
> blank in the
> > full pathname.  (Something we normally discourage, but we encourage it
> here for
> > this testing
> > purpose.) A PLplot build on either of such platforms would essentially
> provide a
> > complete test of case (4) instead of the piecemeal work you are doing at
> the
> > moment with only some of the external libraries and executables used by
> PLplot
> > having spaces in their full pathname.
> >
> Just a short update: I locally adjusted the diff commands in
> test_diff.sh.in, as these were causing trouble because of spaces in the
> path name. While doing that I found that CMake finds a “diff” program that
> is most probably not compliant with the Linux/POSIX/… conventions. So the
> report about the differences concerns all examples.
>
> The way around that is to force the use of the MinGW-w64/MSYS2 diff
> program. There may be more such surprises.
>
> And then there is the matter of the mysterious “D?” directory created by
> ctest. It is not the consequence of anything obvious that I could detect.
>
> Especially this latter issue hinders progress in the comprehensive tests,
> as it causes a premature end (find is not able to handle this directory and
> thus an error is thrown). So slow progress for the moment.
>
> 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.
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
>

Re: [Plplot-devel] Space in full pathname issues

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Friday, May 05, 2017 5:09 AM


> However, I have figured out two good alternatives for completely testing case (4)
> which are for some tester with access to Windows to install either/both the Cygwin
> and MinGW-w64/MSYS2 platforms using a installation prefix that has a blank in the
> full pathname.  (Something we normally discourage, but we encourage it here for
> this testing
> purpose.) A PLplot build on either of such platforms would essentially provide a
> complete test of case (4) instead of the piecemeal work you are doing at the
> moment with only some of the external libraries and executables used by PLplot
> having spaces in their full pathname.
>
Just a short update: I locally adjusted the diff commands in test_diff.sh.in, as these were causing trouble because of spaces in the path name. While doing that I found that CMake finds a "diff" program that is most probably not compliant with the Linux/POSIX/... conventions. So the report about the differences concerns all examples.

The way around that is to force the use of the MinGW-w64/MSYS2 diff program. There may be more such surprises.

And then there is the matter of the mysterious "D?" directory created by ctest. It is not the consequence of anything obvious that I could detect.

Especially this latter issue hinders progress in the comprehensive tests, as it causes a premature end (find is not able to handle this directory and thus an error is thrown). So slow progress for the moment.

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] Space in full pathname issues

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

On 2017-05-03 20:29-0700 Alan W. Irwin wrote:

> On 2017-05-03 00:42-0700 Alan W. Irwin wrote:
>
>> [....]It turns out there
>> are 4 kinds of these type of issues where the spaces(s) occur in the
>> full pathname of (1) the source tree, (2), the build tree, (3), the
>> install tree, and (4) the system libraries and executables that PLplot
>> uses.

[...]
> I expect I will have additional fixes (likely all non-Tcl) soon for
> case (2) and case (3) so I appreciate your expressed willingness to
> keep plugging away on any case (4) issues you encounter (which are
> fairly common on Windows).  Eventually, I plan to do a Linux epa_build
> with install prefix containing spaces to test for case (4) issues as well.

Hi Arjen:

I have rethought that epa_build idea.  That whole mini-project has
fallen way behind and therefore needs lots of maintenance which I
don't have time to provide right now.  For example, part of that
needed maintenance is to finish the project (e.g., provide epa_builds
of some needed external libraries such as open-ssh used by CMake which
have rather obscure instructions for their builds which I have not yet
been able to translate into epa_build instructions).

However, I have figured out two good alternatives for completely
testing case (4) which are for some tester with access to Windows to
install either/both the Cygwin and MinGW-w64/MSYS2 platforms using a
installation prefix that has a blank in the full pathname.  (Something
we normally discourage, but we encourage it here for this testing
purpose.) A PLplot build on either of such platforms would essentially
provide a complete test of case (4) instead of the piecemeal work you
are doing at the moment with only some of the external libraries and
executables used by PLplot having spaces in their full pathname.

There is also case (5) (basic system libraries such as the C library
with a blank in their full pathname that are used, e.g., by MSVC and
at least MinGW-w64/MSYS2).  But I suspect that case has already been
heavily tested on the Windows platform.

As of commit 4295d9b, I have completed a number of fixes for cases
(1), (2), (3) and done a successful comprehensive test of those
combined 3 cases of most of the PLplot components.  So this is a really
encouraging result!

However, there are some important caveats (see the commit message)
concerning the completeness of that comprehensive test.

That means there is still more for me to do to complete comprehensive
tests of cases (1), (2), and (3). which is the following:

* Deal with the known (according to my recent tests on Linux) Ada, D,
   and OCaml "space in full pathname" issues in PLplot's CMake language
   support for those three languages.

* Comprehensive noninteractive test of just those components to finish
   that test for cases (1), (2), and (3).

* Comprehensive interactive test to check for (and fix) any additional
   issues in the interactive components of PLplot for cases (1), (2),
   and (3).

This will complete the successful comprehensive test of all components
of PLplot that are available on Linux and will terminate my planned
work on this topic other than encouraging you or anyone else here with
access to either/both Cygwin or MinGW-w64/MSYS2 to deal with case (4)
in the way I have described 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] Space in full pathname issues

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

On 2017-05-03 00:42-0700 Alan W. Irwin wrote:

> [....]It turns out there
> are 4 kinds of these type of issues where the spaces(s) occur in the
> full pathname of (1) the source tree, (2), the build tree, (3), the
> install tree, and (4) the system libraries and executables that PLplot
> uses.
>

> More later once I make some significant progress on (1), (2), and
(3)

Hi Arjen:

I am putting this thread on the plplot-devel mailing list because these changes
should impact all our advanced Windows users (and also POSIX users who
are in the habit of putting spaces in the full path names that they use).

See commits d9fffdda and f432893 for what I have done on this topic so
far.  For the first of those my fix passed a comprehensive test for
case (1) (except for Ada, D, and OCaml language support issues for
this case that I will attempt to fix later).

When I looked at case (2), more issues showed up. The first of those
was for the test_tcl_psc target which I fixed in the last commit
above.  Since the file I changed is the same one that you have worked
on recently I expected I might encounter a conflict, but it turned out
you had delayed committing your work so that was not a problem for me.
On the other hand, you might have a conflict to resolve (by using the
well-known git method to choose my code change or yours or a
combination of the two if our changes impacted the same lines of the
file).  But whatever further changes (if any) you make to my changes,
please test the result by building the test_tcl_psc target and running
ctest on MinGW-w64/MSYS2, Cygwin, and MSVC.

I expect I will have additional fixes (likely all non-Tcl) soon for
case (2) and case (3) so I appreciate your expressed willingness to
keep plugging away on any case (4) issues you encounter (which are
fairly common on Windows).  Eventually, I plan to do a Linux epa_build
with install prefix containing spaces to test for case (4) issues as well.

@Others here:

All our "test_*" targets such as test_tcl_psc are custom targets that
typically execute a bash script to do the heavy lifting for a given
test.  (These same test bash scripts are executed by the ctest command
that we have configured.) Of course, the normal Unix commands such as
cd, cp, mv, rm, etc. are used within those test bash scripts.

I was able to add MSVC to the above list of platforms I asked Arjen to
test in this semi-automatic way because he has gotten our test targets
to execute correctly on MSVC, and he plans to follow up with ctest
results as well as soon as one overall ctest issue he encountered is
fixed. He made all this work by putting the location of the
MinGW-w64/MSYS2 Unix tools last on the PATH.  The bash.exe application
can be run from a CMD environment so what happens is CMake-generated
nmake build rules which are implemented strictly using the CMD
environment invoke bash.exe to execute the bash scripts that are used
for testing all the ordinary build targets (e.g., bindings and
examples) that have been created by nmake using the ordinary CMD
environment.

So although this testing concept is somewhat complex, it does
fundamentally work, and the result is MSVC is much more convenient to
test in this semi-automatic way since our entire bash-related test
infrastructure is now available for that purpose on that platform
without impacting the ordinary MSVC build targets. Of course, we
expect tests done in this new way are likely to find a number of
build-system issues on MSVC, but cleaning those up should make PLplot
more much reliable on the vanilla MSVC platform (i.e., without the
Unix tools on the PATH that were put there just for these testing
purposes).

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 2017-04-22 17:55-0400 Hazen Babcock wrote:

> On 04/21/2017 03:42 AM, Alan W. Irwin wrote:
>> 
>> Hi Hazen:
>> 
>> Could you please test commit 578b028?

[...]

> It works for me with Python3 and pyqt5.

Hi Hazen:

That positive test result on your Linux platform is a big relief to
me.  I looked through your previous e-mails, and from one you wrote
last November you were using at that time

Distributor ID: Ubuntu
Description:    Ubuntu 16.04.1 LTS
Release:        16.04
Codename:       xenial

Is that still the case for this test?  If so, that should be
almost exactly a year more modern than my current Debian Jessie
platform (released almost exactly two years ago), and if you have
now moved to a later Ubuntu release that is an even larger disparity
in time of release.

> My understanding is that error 
> messages like you are seeing mean that the C library was built for the wrong 
> version of Python.

That seems like a plausible explanation which I can address by
updating to Debian Stretch (not quite yet ready for official release,
but likely that official release will occur later this year and
Stretch is likely already quite stable enough on my particular hardware
platform, x86_64). Anyhow, I will put that update to Stretch on my
agenda in the intermediate term (within a month or two) even if it
isn't completely polished into an official release by then.

> I've attached my CMakeCache.txt file.

That's somewhat useful information, but capturing the combined stdout
and stderr output from your cmake command, e.g.,

cmake <CMake options> <Top directory for PLplot source tree> >& cmake.out

is even more useful.  That captured output gives the sip (since commit
7f1f5ce earlier today), Python, Qt, and pyqt detailed version numbers.

Also, since the above works for you I have changed (commit 7653e24
today) our default Python version to Python 3 (if it is available) and
Python 2 otherwise.  The Python 3 find is now only skipped if the user
specifies -DFORCE_PYTHON2=ON, but normally they would not want to do
that since Python 3 is likely less buggy than Python 2.  For example,
the Python developer I talked to implied I was very much less likely
to experience the python-generated Plframe.pyc corruption issue that
was showing up for me fairly regularly for Python 2, if I switched to
Python 3, and that expectation has been born out so far in fairly
limited Python 3 testing by me.

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] [ANNOUNCEMENT] The minumum version of CMake we accept on Linux is now bumped from 3.0.2 to 3.6.2

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

I prefer to support only recent CMake versions and latest CMake
policies to keep the PLplot build system as simple and as bug free as
possible.  For this reason I have recently bumped (see
<https://sourceforge.net/p/plplot/plplot/ci/f0610cdf5879ce2d7727f8d865d4523ebc501c78/>)
the minimum version of CMake we accept on Linux to 3.6.2, and and we may similarly
bump that version and also the minimum version we accept on non-Linux
platforms to 3.7.2 later on this year.

This current bump will only affect Linux users of our current git
version (and also our next release) on the relatively small number of
Linux distributions that do not yet provide CMake-3.6.2 or later.  So
the number of affected users should be relatively small and decreasing
because Linux distributions generally do a good job of keeping up with
the latest CMake versions.  However, if you are one of these users
that is temporarily affected by this issue, you will have to build the
latest CMake (currently 3.8.0 which builds PLplot without
difficulties) before building the git version of PLplot.  So the
purpose of this announcement is to warn users about this uncommon
possibility.

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 04/21/2017 03:42 AM, Alan W. Irwin wrote:
>
> Hi Hazen:
>
> Could you please test commit 578b028?  For that commit I made some
> modest progress with Python 3 for both pyqt4 and pyqt5, but I have hit
> a roadblock with a run-time error saying the plplot_pyqt[45] extension
> modules are not initialized properly when the script tries to import
> one of those modules.  The sip, pyqt[45], and python3 software
> packages are all supposed to work well together for their latest
> versions according to my google search results, but it is possible the
> Debian Jessie versions of these software packages are too old and
> buggy which is why I am asking you to test this commit by attempting
> to build the test_pyqt[45]_example target (depending on whether your
> build system finds Qt4 or Qt5) for both the python2 and python3 cases
> (where the former builds and runs plplot_pyqt[45] without issues here,
> but the latter case only builds these extension modules without
> obvious issues but runs into initialization errors at run time).
>
> The test_pyqt4_example target build all
> prerequisites with success but fails the final run-time test.
>
> Here is the relevant error message if I attempt to do the
> run-time test by hand:
>
> software@raven> python3 examples/python/pyqt4_example.py Traceback (most
> recent call last):
>   File "examples/python/pyqt4_example.py", line 33, in <module>
>     import plplot_pyqt4
> ImportError: dynamic module does not define init function
> (PyInit_plplot_pyqt4)
>
> Do you get a similar error there or success?

It works for me with Python3 and pyqt5. My understanding is that error 
messages like you are seeing mean that the C library was built for the 
wrong version of Python.

I've attached my CMakeCache.txt file.

-Hazen

[Plplot-devel] Python3

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

On 2017-04-17 16:30-0700 Alan W. Irwin wrote:

> Note also that there are additional non-standard Python examples in
> the examples/python subdirectory so those should all be checked to
> make sure they work with both Python 2 and Python 3.  And similarly
> for the pyqt4 and pyqt5 standard examples.

Hi Hazen:

Could you please test commit 578b028?  For that commit I made some
modest progress with Python 3 for both pyqt4 and pyqt5, but I have hit
a roadblock with a run-time error saying the plplot_pyqt[45] extension
modules are not initialized properly when the script tries to import
one of those modules.  The sip, pyqt[45], and python3 software
packages are all supposed to work well together for their latest
versions according to my google search results, but it is possible the
Debian Jessie versions of these software packages are too old and
buggy which is why I am asking you to test this commit by attempting
to build the test_pyqt[45]_example target (depending on whether your
build system finds Qt4 or Qt5) for both the python2 and python3 cases
(where the former builds and runs plplot_pyqt[45] without issues here,
but the latter case only builds these extension modules without
obvious issues but runs into initialization errors at run time).

The test_pyqt4_example target build all
prerequisites with success but fails the final run-time test.

Here is the relevant error message if I attempt to do the
run-time test by hand:

software@raven> python3 examples/python/pyqt4_example.py 
Traceback (most recent call last):
   File "examples/python/pyqt4_example.py", line 33, in <module>
     import plplot_pyqt4
ImportError: dynamic module does not define init function (PyInit_plplot_pyqt4)

Do you get a similar error there or success?

For the record here is the complete list of python3-related packages
I have installed on Debian Jessie.  If you think I am missing anything
please let me know.

software@raven> dpkg --list |grep python3 |cut --delimiter=" " --fields=3
libpython3-dev:amd64
libpython3-stdlib:amd64
libpython3.4:amd64
libpython3.4-dev:amd64
libpython3.4-minimal:amd64
libpython3.4-stdlib:amd64
python3
python3-apt
python3-chardet
python3-checkbox-ng-doc
python3-debian
python3-dev
python3-dugong
python3-magic
python3-minimal
python3-numpy
python3-pkg-resources
python3-pyqt4
python3-pyqt5
python3-sip
python3-sip-dev
python3-six
python3-tk
python3-uno
python3.4
python3.4-dev
python3.4-minimal

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] Replace "f95" and "F95" by "fortran" and "Fortran"

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

On 2017-04-19 14:50-0700 Alan W. Irwin wrote:

> DONE as of commit e233697.  I did a lot of testing of this large and
> intrusive change (see details in the commit message) on my Debian Jessie
> platform but additional testing is requested on other platforms as
> well.

By the way, I forgot to check these (mostly automated via sed) changes
with regard to our website, but I just now did that by generating that
website locally (without issues), and looking carefully at those
results.  A search of the PDF form of our revised documentation for
"95" only found one instance where that reference was Fortran related,
but it should be there for that case because that sentence says
essentially our Fortran code is Fortran 2003 now rather than Fortran
95.  Spot checks of the examples showed the source code had been
properly copied from examples/fortran (rather than examples/f95) and
it was referred to as the "Fortran" version of our standard examples
rather than the "F95" version of our standard examples. So my mostly
automatic editing seems to have been a success even in this regard.

Of course, if anyone spots any remaining references to f95, F95,
Fortran 95, 95, etc., anywhere in our source tree that shouldn't be
there or any regressions due to this large change, please let me know
so I can address the issue.

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] Replace "f95" and "F95" by "fortran" and "Fortran"

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

On 2017-04-18 12:19-0700 Alan W. Irwin wrote:

> On 2017-04-18 07:05-0000 Arjen Markus wrote:
>
>> [...] I agree, as per your later post (got caught by the spam filter for
> reasons best known to itself), that "f95" is not the correct keyword
> anymore. So that is indeed another thing to do.
>
> Hi Arjen:
>
> Thanks for giving your above agreement to this change.  I have decided
> to move ahead with it by replacing "f95" and "F95" _everywhere_ in the
> source tree by "fortran" and "Fortran". The use of "git mv" to rename
> files; find and grep to find all files that contain f95 or F95; and
> "sed -i" to automatically make the change to those files (other than
> historical ones such as the ChangeLog) has made this large change tractable
> in just a few hours.  I started this last night, and I am almost done
> now, but I need to follow up with a comprehensive test (both
> interactive and active) and several other tests of this intrusive
> change I have in mind before I make the commit and push it.  Thus,
> because the tests will take a lot of time, you will probably only see
> that push much later today or early tomorrow.

DONE as of commit e233697.  I did a lot of testing of this large and
intrusive change (see details in the commit message) on my Debian Jessie
platform but additional testing is requested on other platforms as
well.

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] Replace "f95" and "F95" by "fortran" and "Fortran"

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

On 2017-04-18 07:05-0000 Arjen Markus wrote:

> [...] I agree, as per your later post (got caught by the spam filter for
reasons best known to itself), that "f95" is not the correct keyword
anymore. So that is indeed another thing to do.

Hi Arjen:

Thanks for giving your above agreement to this change.  I have decided
to move ahead with it by replacing "f95" and "F95" _everywhere_ in the
source tree by "fortran" and "Fortran". The use of "git mv" to rename
files; find and grep to find all files that contain f95 or F95; and
"sed -i" to automatically make the change to those files (other than
historical ones such as the ChangeLog) has made this large change tractable
in just a few hours.  I started this last night, and I am almost done
now, but I need to follow up with a comprehensive test (both
interactive and active) and several other tests of this intrusive
change I have in mind before I make the commit and push it.  Thus,
because the tests will take a lot of time, you will probably only see
that push much later today or early tomorrow.

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] Fortran standard compliance checking does not work for gfortran

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

Hi Alan,



Hm, I will have to look into this a bit closer - this week is a trifle crowded though, so it will take me some time to get around to it. I agree, as per your later post (got caught by the spam filter for reasons best known to itself), that "f95" is not the correct keyword anymore. So that is indeed another thing to do. Perhaps I should consult the gfortran mailing list about the details.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Saturday, April 15, 2017 5:55 AM
> To: Arjen Markus; PLplot development list
> Subject: Fortran standard compliance checking does not work for gfortran
>
> Hi Arjen:
>
> I had to rework (commit 58dc757) the suggestion in README.developers about the
> recommended gfortran compiler options because the prior suggestion
>
> export FFLAGS='-std=f95 -O3 -fall-intrinsics -fvisibility=hidden -pedantic -Wall -
> Wextra'
>
> did not work with our new fortran binding.
>
> (As an aside, in my tests I dropped -fvisibility=hidden because I believe that makes
> no sense for Fortran code.  I also dropped -fall-intrinsics since I prefer using
> Wintrinsics-std which is automatically deployed with -Wall if -fall-intrinsics is not
> specified.) So here are the actual flags I tried.
>
> 1. export FFLAGS='-O3 -std=f95 -pedantic -Wall -Wextra'
>
> Those options generated a build error (as expected) because the Fortran 95
> standard does not include support for the ISO_C_BINDING module that we use to
> implement the new fortran binding.
>
> 2. export FFLAGS='-O3 -std=f2003 -pedantic -Wall -Wextra'
>
> Those options generated the following type of build error:
>
> included_plplot_real_interfaces.f90:2601.25:
>      Included at
> /home/software/plplot/HEAD/plplot.git/bindings/f95/plplot_double.f90:117:
>
>                     c_loc(plotentries), size(plotentries, kind=private_plint) )
>                           1
> Error: Fortran 2008: Array of interoperable type at (1) to C_LOC which is
> nonallocatable and neither assumed size nor explicit size
>
> for what I consider to be a spurious reason (see the revised README.developers
> for further discussion).
>
> 3. export FFLAGS='-O3 -std=f2008 -pedantic -Wall -Wextra'
>
> got rid of the above type of error message, but also generated a whole new set of
> build errors.
>
> 4. export FFLAGS='-O3 -Wall -Wextra'
>
> does work without any build errors so this is now what I recommend in
> README.developers.
>
> To summarize, if you discovered a standards-compliant change to our new Fortran
> binding implementation that would allow use of
>
> export FFLAGS='-O3 -std=f2003 -pedantic -Wall -Wextra'
>
> with gfortran, then that would allow our users/developers to at least do minimal
> standards compliance checking with gfortran. But if you feel that is too much trouble
> and/or the fix would obfuscate our fortran binding code too much simply to quiet a
> gfortran build error that is likely spurious, then I am content with the current
> recommendation
>
> export FFLAGS='-O3 -Wall -Wextra'
>
> Of course, the (significant) downside of the current recommendation is it means our
> users/developers cannot check Fortran standards compliance with gfortran and
> must rely on NAG instead for such checking.
>
> 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
> __________________________

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] A mysterious pyc file corruption issue

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

On 2017-04-17 16:30-0700 Alan W. Irwin wrote:

> I feel it is important to get back to Python 2 PostScript difference
> perfection and to also achieve that perfection for Python 3.

I now (commit 9185cce) have achieved perfect PostScript difference
reports for both Python 2 and Python 3.  I had never heard of floor
division before, but that turned out to be the answer for the Python 3
versus Python 2 numerical differences we still had after my previous
commit.  See the commit 9185cce message for details concerning floor
division.

> Note also that there are additional non-standard Python examples in
> the examples/python subdirectory so those should all be checked to
> make sure they work with both Python 2 and Python 3.  And similarly
> for the pyqt4 and pyqt5 standard examples.

This part still needs to be done, but getting the standard examples
working perfectly for both Python 2 and Python 3 is a big step in the
right direction.

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] A mysterious pyc file corruption issue

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

On 2017-04-17 16:30-0700 Alan W. Irwin wrote:

> [T]here are now PostScript consistency issues _both_ for Python 2 and
> Python 3 results that were not there before for Python 2 before your
> push.
>
> python (2)
>   Missing examples            :
>   Differing graphical output  :  33
>   Missing stdout              :
>   Differing stdout            :  23
>
> python (3)
>   Missing examples            :
>   Differing graphical output  :  02 09 11 14a 15 16
>   Missing stdout              :
>   Differing stdout            :

I have now (commit 2bbdcb0) fixed the above two Python 2 issues. Those
fixes did not affect the above Python 3 issues which I plan to tackle
(likely quite slowly because of my current unfamiliarity with Python
3) in ascending order.

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
__________________________