plplot-devel — Technical discussion about PLplot development

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

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

On 2017-08-27 11:00+0200 Ole Streicher wrote:

> One point there however remains: I need to support all Python 3 versions
> we have in Debian; currently Python 3.5 and Python 3.6. The difference
> are just the shared library stubs, which are compiled using the specific
> header files (the package will contain both shared libs). Do you have an
> idea how I could simply do this?

Use multiple builds.

Also to make this easier for you I have now (commit e320210)
improved user control of the Python version.

So for one build you specify -DPLPLOT_PYTHON_EXACT_VERSION=3.5.0
and for the other you specify -DPLPLOT_PYTHON_EXACT_VERSION=3.6.0,
and it should "just work" according to my tests of the above
commit.

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

software@raven> find . -type f |grep -v .git |xargs grep -li gtk |less

found a large number of files where gtk is mentioned, but none of them
are relevant to python.  I dimly recall that we used to have a GTK
binding that also included a python interface, but that was superseded
by the pango/cairo related components of PLplot so is long gone now.
So I suspect this build dependency on python-gtk2 is an extremely
ancient artifact that you can just ignore from now on.

> And, a final point; I think we already shortly discussed that: Debian
> will drop Qt4 support at some point. Since I am doing a major
> restructuration of the Package structure anyway, it may be worth to use
> qt5 only in the plplot package as well; otherwise I would have to do
> that switching in a few months anyway. Would you agree here?

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

> Best regards, and already many thanks for the help!

You are welcome.

And thanks very much to you for taking on the responsibility of Debian
(and Debian-derived distribution) packaging of PLplot!  That job is
important because if you make the assumption that the fraction of
popularity contest statistics for PLplot represents the fraction of
Linux users who actually use PLplot on a monthly basis, then the
PLplot users who are using the binary versions of PLplot that you and
other packagers (such as Orion for Fedora) are creating far outnumber
the ~7000 users who download PLplot each year according to SF
statistics.

Best wishes,

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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

Linux-powered Science
__________________________

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

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

On 2017-08-26 14:36+0200 Ole Streicher wrote:

> On 26.08.2017 12:43, Alan W. Irwin wrote:
[...]
>> This simply means you need to install the python3-numpy package
>> (to be consistent with the above python3), and all should be well.
>
> Thanks With installing python3-numpy as well, it works. I didn't update
> the dependencies from plplot-12 (where we had  Python-2 bindings only).

Hi Ole:

I feel pretty strongly this discussion belongs on the PLplot development
list so I have put it back there again.

When you immediately posted that Python failure for plplot-5.13.0, I
was beginning to wonder if I would need to quickly release 5.13.1 to
fix whatever problem you had found.  So it is a big relief to me to
hear from you there is no plplot-5.13.0 issue in this regard and
installing the right version of the numpy package completely fixed the
issue.  :-)

>
> This opens however a new can of worms for me: If we are able to build
> Python-2 *and* Python-3 packages, it would be great to do so. Also, I'd
> like to build it for all supported Python minor versions (3.5 and 3.6
> for the moment, and Python 2.7) during the package build. Is there any
> way to configure or patch this? Supporting all Debian-supported versions
> is part of our Python policy.

That policy might need some adjustments, i.e., Python2 support should
be allowed, but I am pretty sure it should not be mandatory because
upstream Python developer support of Python2 is obviously not as active as
Python3 support, and that sometimes causes problems for Python2.

For an example of this, consider our examples/python/pytkdemo
interactive example that demonstrates use of our Tcl-based plframe
GUI under Python.  This is a complex beast with namespace issues
I have not yet been able to track down so to work around those I
do a double import of bindings/python/Plframe.py using

import Plframe
from Plframe import *

Such double imports to work around namespace issues are fairly common,
but from my python2 interactive testing experience this double import
would sometimes generate *.pyc corruption issues for the
bindings/python/Plframe.pyc file which should automatically be
generated by Python by that first import *only* if
bindings/python/Plframe.pyc does not exist or if
bindings/python/Plframe.py has been updated.

I consulted with a Python developer concerning this issue, and his
advice was to move to Python3 because there were known race conditions
that had been fixed in that latter case, but he wasn't sure if they
had been fixed for Python2, and he strongly implied that Python
developers tended to concentrate on Python3 for obvious reasons so
issues did slip through the cracks for Python2, and this corruption
issue was probably just one example of that.

So once (thanks to Hazen's efforts) PLplot was ready for Python3, I
started to use it almost exclusively to test it, and my tests showed
complete reliability and also no bindings/python/Plframe.pyc
corruption issue. So based on that demonstrated Python2 corruption
issue that Python3 solved, I updated our build system to make Python3
the preference if both Python3 and Python2 were available. And ever
since that change I have never run into that *.pyc corruption issue.
So my experience certainly jibes with what the Python developer said.

Now it could be that developer had some axe to grind, and he was
therefore too discouraging about the reliability of Python2.  So it is
possible that race condition for Python2 that seems to be the source
of this *.pyc corruption issue has been fixed in later Python2
versions than I currently have with Debian Jessie (2.7.9-2+deb8u1).
But my experience this Python developer's attitude toward Python2
should certainly give Debian developers some food for thought about
any mandatory Python2 requirements they may have in their Python
policy.

Those Debian policy issues aside, Plplot continues to work fine for
python2 aside from the relatively rare corruption issue for
bindings/python/Plframe.pyc which is straightforward (although
annoying) to work around by removing that corrupt file so that python
will regenerate it (typically in reliable fashion for quite a while).
Furthermore, this issue will likely go away once I figure out how to
move to a single name-spaced import of PLframe, and I suspect, in any
case, you likely don't bother to package the still somewhat
experimental examples/python/pytkdemo along with the special Plframe
module and Pltk_init extension module that are unique needs of that
example.

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

Alternatively, you might be able to trace through the
-DFORCE_PYTHON2=ON logic in cmake/modules/python.cmake, and provide a
patch to simultaneously support both Python2 and Python3 builds. But
that is a lot of work with a lot of chance to introduce build-system
errors/inconsistencies so I think the above multiple build approach
is much better.

>
> One solution could be to write a standard "setup.py", which would allow
> to run the Debian Python build machinery here. This automatically builds
> the Python modules for all supported versions, and installs them in the
> preferred path. Would you think it is problematic to write one? (I am
> not asking that you do it yourself; I just want to know if it is worth
> the effort).

Let's face it, the setup.py approach requires you to implement a
python-based build system and build systems are always tricky.  And
that is especially true when you are trying to simultaneously support
more than one version, see comment above.  So I think you are talking
about a considerable amount of implementation work, maintenance, and
potential errors.  In the distant past we used a setup.py approach for
our Python components but eventually abandoned it once we figured out
everything we needed to do with our autotools-based build system at
that time and we continued without using the setup.py approach when we
implemented the CMake-based build system that replaced that
autotools-based build system a decade ago.

In sum, that decision about implementing a setup.py approach is up to
you, but my advice is to not bother with that and instead use our
existing CMake-based build system to do what you want using the above
multiple build approach.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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

Linux-powered Science
__________________________

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

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

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

> On 2017-08-26 11:12+0200 Ole Streicher wrote:
>
>> Hi Alan,
>> 
>> "Alan W. Irwin" <ir...@be...> writes:
>>> The 5.13.0 release has now been completed.  (See my recent post to
>>> plplot-general for links to the details).
>>> 
>>> I encourage all of you to test the website (I already know of one dead
>>> external link there to Homebrew packaging of PLplot, but I hope none
>>> of you find any many more of those), and test this release tarball by
>>> downloading it, using gpg --verify on it, and building PLplot with it.
>> 
>> That is great news! We (in Debian) like to have a verified chain for the
>> source... I will enable this in my packaging.
>> 
>> I run into the first problem, concerning Python support:
>> 
>> During the cmake run, I get the following:
>> 
>> [...]
>> -- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.4", 
>> minimum required is "3")
>> -- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.4", 
>> minimum required is "2")
>> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found 
>> version "2.7.13+")
>> [...]
>> -- WARNING: ENABLE_python is OFF so setting ENABLE_pyqt4 to OFF.
>> [...]
>> ENABLE_python:          OFF
>> ENABLE_qt:              ON
>> ENABLE_pyqt4:           OFF
>> 
>> and consequently the pyqt4 bindings are not created. Explicitly using
>> -DENABLE_python does not help.
>> 
>> Any idea what to do?
>
> Hi Ole:
>
> I need more context to help me to figure out what is going wrong.
>
> Please send me the complete compressed output from cmake command and also
> the compressed CMakeCache.txt file.

Hi Ole:

The additional context you sent me off-list reads as follows:

-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.4", minimum required is "3") 
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.4", minimum required is "2") 
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version "2.7.13+") 
Traceback (most recent call last):
   File "<string>", line 1, in <module>
ImportError: No module named 'numpy'
-- WARNING: NumPy header not found. Disabling Python binding

This simply means you need to install the python3-numpy package
(to be consistent with the above python3), and all should be 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
__________________________

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

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

On 2017-08-26 11:12+0200 Ole Streicher wrote:

> Hi Alan,
>
> "Alan W. Irwin" <ir...@be...> writes:
>> The 5.13.0 release has now been completed.  (See my recent post to
>> plplot-general for links to the details).
>>
>> I encourage all of you to test the website (I already know of one dead
>> external link there to Homebrew packaging of PLplot, but I hope none
>> of you find any many more of those), and test this release tarball by
>> downloading it, using gpg --verify on it, and building PLplot with it.
>
> That is great news! We (in Debian) like to have a verified chain for the
> source... I will enable this in my packaging.
>
> I run into the first problem, concerning Python support:
>
> During the cmake run, I get the following:
>
> [...]
> -- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.4", minimum required is "3")
> -- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.4", minimum required is "2")
> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version "2.7.13+")
> [...]
> -- WARNING: ENABLE_python is OFF so setting ENABLE_pyqt4 to OFF.
> [...]
> ENABLE_python:          OFF
> ENABLE_qt:              ON
> ENABLE_pyqt4:           OFF
>
> and consequently the pyqt4 bindings are not created. Explicitly using
> -DENABLE_python does not help.
>
> Any idea what to do?

Hi Ole:

I need more context to help me to figure out what is going wrong.

Please send me the complete compressed output from cmake command and also
the compressed CMakeCache.txt file.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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

Linux-powered Science
__________________________

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

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

Hi Alan,

"Alan W. Irwin" <ir...@be...> writes:
> The 5.13.0 release has now been completed.  (See my recent post to
> plplot-general for links to the details).
>
> I encourage all of you to test the website (I already know of one dead
> external link there to Homebrew packaging of PLplot, but I hope none
> of you find any many more of those), and test this release tarball by
> downloading it, using gpg --verify on it, and building PLplot with it.

That is great news! We (in Debian) like to have a verified chain for the
source... I will enable this in my packaging.

I run into the first problem, concerning Python support:

During the cmake run, I get the following:

[...]
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.4", minimum required is "3") 
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.4", minimum required is "2") 
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version "2.7.13+") 
[...]
-- WARNING: ENABLE_python is OFF so setting ENABLE_pyqt4 to OFF.
[...]
ENABLE_python:          OFF
ENABLE_qt:              ON
ENABLE_pyqt4:           OFF

and consequently the pyqt4 bindings are not created. Explicitly using
-DENABLE_python does not help.

Any idea what to do?

Best regards

Ole

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

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

The 5.13.0 release has now been completed.  (See my recent post to
plplot-general for links to the details).

I encourage all of you to test the website (I already know of one dead
external link there to Homebrew packaging of PLplot, but I hope none
of you find any many more of those), and test this release tarball by
downloading it, using gpg --verify on it, and building PLplot with it.

And similarly with

git tag --verify plplot-5.13.0 
git checkout plplot-5.13.0

and building and testing that version.

The freeze on pushes to master is now rescinded, i.e., you are strongly
encouraged to push any private topic branches to master that you have
matured to your satisfaction.

I hope to continue the pace of a release every 6 months on average,
but 5.13.0 was 7 months after 5.12.0 so to make up for that I would
like to release in late January 2017, i.e., 5 months from now or a
year after 5.12.0 was released. That deadline is actually pretty soon,
so please start working on whatever interests you with PLplot now to
give the rest of us the maximum time to evaluate your work before the
next release.

Here are some development topics I am aware of that might make
it into the next release.

@Phil: Your private topic branch dealing with a setjmp/longjmp
implementation of C exceptions still needs a small amount of work in
my opinion to mature it (see my last suggestions to you about how to
mature that topic). Can we get this topic going again?

@Jim: I was reminded while writing up your work on the gdi device
driver in README.release, that this is "a first step to a
Unicode-aware driver that uses the GDI+ API (along with the Uniscribe
API to handle Unicode text)."  Are you willing to start that next step?

Arjen:

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

For my own part I have a massive ToDo list of all the minor issues
discovered during the last release cycle that I put off fixing until
later. Well "later" has arrived!  Therefore, during this release cycle
I hope to work steadily through at least a substantial fraction of
these issues.

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] Status of the 5.13.0 release process

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

Today I spent a lot of time looking at Arjen's MinGW-w64/MSYS2 plot
results and it turns out that in virtually all cases rendering is fine
on that platform. (See my previous post to this list for details about
the relatively few rendering issues (non of which are release
critical) that show up for this platform.)

The release process is still-ongoing and the hard freeze for pushing
of commits to our master branch continues.

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] Planning for the release of 5.13.0 -- Evaluation of rendering issues on MinGW-w64/MSYS2

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

On 2017-08-21 06:53-0000 Arjen Markus wrote:

> I have uploaded the full contents of the examples directory, as you requested.

I downloaded those plot results for the MinGW-w64/MSYS2 platform
successfully, and evaluated them for rendering issues.

The conclusion is that in the vast majority of cases, plot rendering
is fine on this platform so we can highly recommend this platform to
our Windows users.  However, there are a few exceptions to this good
rendering conclusion that are discussed in detail below, but none of
these issues are release critical.  Thus, the "NOTE:" remarks below
correspond to what I think we can do to fix some of these issues after
5.13.0 is released.

A. UTF-8 (i.e., human-readable format) results:

Here are the types of UTF-8 files and formats we are contending with

software@raven> file $(ls x00c* |grep -v txt) |grep -Ei 'postscript|svg|xfig'
x00c.ps:         PostScript document text conforming DSC level 2.0, type EPS
x00c.psc:        PostScript document text conforming DSC level 2.0, type EPS
x00c.pscairo:    PostScript document text conforming DSC level 3.0, Level 2
x00c01.epscairo: PostScript document text conforming DSC level 3.0, type EPS, Level 2
x00c01.epsqt:    PostScript document text conforming DSC level 1.0
x00c01.svg:      SVG Scalable Vector Graphics image
x00c01.svgcairo: SVG Scalable Vector Graphics image
x00c01.svgqt:    SVG Scalable Vector Graphics image
x00c01.xfig:     FIG image text, version 3.2, ASCII text, with very long lines
x00cxx.psc:      PostScript document text conforming DSC level 2.0, type EPS

I. Some of these UTF-8 results can be differenced with corresponding
Linux (Debian Jessie) results with few or any adjustments.  This
allows us to avoid having to look for rendering issues with these
particular device results).

For such comparisons I usually did some variation on the command below
where files in the present directory correspond to MinGW-w64/MSYS2
platform results and files in ${DIR} correspond to Debian Jessie
results.  N is a string that corresponds to  "00" through "33" (with
"32" skipped.  The ls command
and grep -v command selects a certain subset of the
results (in this case, just selects the ps device driver results).
The -i 172 option for the cmp command ignores the date stamp in the
comparison.

for N in $(seq --format='%02.0f' 0 33|grep -vE '32'); do
   echo "Examples $N"
   for FILE in $(ls x${N}*.ps|grep -v txt); do
     echo $FILE
     cmp -i 172 $FILE "${DIR}/$FILE"
   done
done

__________________________________________________________________________________
1. The ps device results from the C standard examples were identical to the
corresponding Linux results.

2. The xfig device results from the C standard examples were identical to the
corresponding Linux results.

__________________________________________________________________________________
3. Your report tarball already shows that psc results for all the
bindings currently enabled for MinGW-w64/MSYS2 (i.e., c++, fortran, lua,
python, and tcl) are identical with the corresponding c results with
the exception of

lua
   Missing examples            :
   Differing graphical output  :  14a 19 23
   Missing stdout              :
   Differing stdout            :  31

A variation of the above "for N ..." set of commands showed all psc
device results from all examples were identical to the corresponding
Linux results except for the above Lua examples.  So the only Lua
differences we should be concerned about (post-release) are those in
the above summary.

As I believe you have already remarked, detailed diffs corresponding
to the above Lua examples show many trailing ".0" differences such as

-0.150 (0.0) SW
+0.150 (0) SW

NOTE: Apparently some Lua version difference is able to
affect whether trailing zeros are eliminated
by the -dev psc implementation that is written in C.
Actually, in the interest of saving space, the above line
should read

.15 (0) SW

so this is fundamentally a -dev psc formatting issue that we need to look at.

In addition when the above trailing zero issues were suppressed using
sed there are "real" differences
such as insertion of the following text in the Linux
version of these PostScript files:

+0.150 (0) SW
+(0) show

The trailing zero diffences have to be eliminated first before
we can look at the cause of the remaining "real" differences,
but that cause is likely to be due to some Lua version difference
between our two platforms.  So I may run into this same issue
once I update to Debian Stretch (which has a newer version of lua).

The above stdout differences (as opposed to the psc differences) are due to a trailing ".0" on some
of the numbers being output, but this is directly from Lua rather
than indirectly via -dev psc so it should be an entirely different
issue.

NOTE: I am pretty sure the cure for this lua stdout issue will be to specify exactly the same
stdout format in Lua and C standard examples 31 rather than default
format (which appears to have changed between our two Lua versions).
__________________________________________________________________________________
4. The svg device results from the C standard examples were identical to the
corresponding Linux results except that quantities formatted with an
"e" exponent had a leading 0 in the exponent. e.g.,

-      stroke-width="1.000000e+000"
+      stroke-width="1.000000e+00"

(i.e., if I adjusted one exponential form to the other using sed, there were
no differences left for all our standard examples).

NOTE: to address this issue we have to use explicit exponent
formatting in the -dev svg C implementation rather than the default used
by gcc (which apparently changes between the two gcc versions being
compared here).  This change should also protect us when
comparing between old and new gcc results on the same machine.
__________________________________________________________________________________

II. These remaining UTF-8 results have for unknown reasons large (and
therefore useless for further analysis) differences with the
corresponding Linux (Debian Jessie) results.  In all these cases I
fell back to the "display" method of visually looking for rendering
issues (see below).

1. The svgqt and svgcairo devices used different system fonts and also appeared
to use different SVG methods of scaling the results.

2. For the pscairo and epscairo results, "diff" showed
different fonts were used for the two platforms and also there were limited, but
still significant PostScript command differences.

3. For the epsqt device, "diff" showed different fonts were used for
the two platforms and also there were limited, but still significant
PostScript command differences.  One of those differences was the
bounding box for the MinGW-w64/MSYS2 result had X and Y limits swapped in error
(likely due to a Qt4 bug on the Windows platform).

B. Binary (i.e., non-UTF-8 format) results:

Here are the types of binary files and formats we are contending with

software@raven> file $(ls x00c* |grep -v txt) |grep -Eiv 'postscript|svg|xfig'
x00c.pdf:        PDF document, version 1.3
x00c.pdfcairo:   PDF document, version 1.5
x00c01.bmpqt:    PC bitmap, Windows 3.x format, 842 x 595 x 24
x00c01.jpgqt:    JPEG image data, JFIF standard 1.01, resolution (DPI), density 72x72, segment length 16, baseline, precision 8, 842x595, frames 3
x00c01.pdfqt:    PDF document, version 1.4
x00c01.pngcairo: PNG image data, 720 x 540, 8-bit/color RGB, non-interlaced
x00c01.pngqt:    PNG image data, 842 x 595, 8-bit/color RGB, non-interlaced
x00c01.ppmqt:    Netpbm PPM "rawbits" image data, size = 842 x 595
x00c01.tiffqt:   TIFF image data, little-endian

I. Binary files that are identical between the two platforms:

The appropriate variant of the above nested for loop commands shows
the *.pdf files are identical between the two platforms.

II. Binary files that are different between the two platforms:

diff x00c.pdfcairo "$DIR"

generates the message

Binary files x00c.pdfcairo and .... differ

and similarly for the remaining files in the above list other than
x00c.pdf.  In all these cases I fell back to the "display" method of
visually looking for rendering issues (see below).

C. The "display" method of visually looking for rendering issues.

I looked at all binary results that had differences between the
two platform and all UTF-8 results that had *major* differences
between the two platform as follows:

for N in $(seq --format='%02.0f' 0 31); do
   echo "Examples $N"
   for FILE in $(ls x${N}*|grep -vE '|grep -vE '(txt|ps|psc|xfig|pdf|svg)$'); do
     echo $FILE
     display $FILE
   done
done

I also did some displaying by hand of a sample of the x33 results.

The following were the MinGW-w64/MSYS2 rendering issues worth
mentioning that did not occur for the Linux case:

* As expected from the bounding box issue reported above, all epsqt
   results had parts of the plot missing.

* A similar issue occurs for pdfqt.

* All cairo devices had character sizes on the MinGW-w64/MSYS2
   platform that were ~50 per cent larger than the corresponding Linux
   results, but such was not the case for the qt devices.

* Example 23 shows a relatively small number of missing glyphs in the
   system fonts you have access to with MinGW-w64/MSYS2 for all the
   cairo and qt devices.  (As opposed to the Linux case where system
   fonts provide complete glyph coverage for example 23 for all cairo
   and qt devices.) I looked at the package names for MinGW-w64/MSYS2
   and the only package name with "font" in it is font-config.  So I am
   virtually positive that MinGW-w64/MSYS2 has chosen at this time
   (although it is possible later on they will provide all or part of
   the official fonts that are available to Linux users) to use just
   the same official system fonts that are accessible for "bare" Windows
   on your computer.

   If you haven't done so already, I would consult with the system guys
   in your company to make sure that you have all possible official
   system fonts installed on your computer.  However, I would recommend
   against installing unofficial Windows fonts to give you more unicode
   glyph coverage because my prejudice is there is likely to be more
   security and reliability issues with such unofficial software
   packages.

* The Arabic and Hebrew glyphs are missing from example 24 for all the
   cairo devices.  But this is not a system font issue because those
   glyphs are all available for the qt devices.

To summarize, I have evaluated rendering issues for the 
MinGW-w64/MSYS2 platform using all pages of your results of all our
standard examples (except for standard example 33 where I only sampled
the 100 pages of that example) of all our noninteractive devices that
you have been able to enable on this platform.  Three rendering issues
have been labelled above with "NOTE:" where I believe there is a
PLplot issues we can do something about after the 5.13.0 release.  The
rest of the rendering issues I noticed are discussed above, but in all
those cases I believe the issue is with external libraries on this
platform and not issues with PLplot.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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

Linux-powered Science
__________________________

[Plplot-devel] Status of the 5.13.0 release process

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

That process is still on-going, and so far there are no major
hiccups.

I plan to write one such "status" note per day until the release
occurs.  So hopefully this is the last such note, but it might not be.
:-)

The hard freeze for pushing of commits to our master branch continues.

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] Planning for the release of 5.13.0

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, August 21, 2017 9:04 PM
>
> By the way, we had absolutely clear weather this morning for looking at the partial
> solar eclipse that was visible from here and which reached ~90 per cent obscuration.
> It wasn't nearly as spectacular as the total eclipse experience that is occurring
> south of here on the totality path, but it was still pretty special because the solar
> crescent that was left at maximum obscuration was quite narrow. So I was glad I
> took some time out to look at it with my eclipse viewer, and even without the viewer
> it was obvious that the sunlight was a lot less than normal.
>
I envy you. The first time I saw it, a long time ago, the eclipse was partial, something like 40% (wild guess) and the second and last time, when there was the promise of something like 90% or more, the sky was clouded. I did notice a drop in light intensity and I had the radio at hand for a live report from France, but that is a poor surrogate ;).

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] Planning for the release of 5.13.0

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

On 2017-08-21 06:53-0000 Arjen Markus wrote:

> Anyway, I agree: the remaining issues with the various Windows-based
platforms can be examined after the release. They seem to be
relatively minor and solving them may take quite some time, if only
the complete test runs take a long time.

OK. Thanks for that clear response to my question.

Accordingly, I hope to get the release finished late today (Monday)
or early tomorrow.

I should have mentioned before that the freeze on pushes to master
should be considered rock hard (i.e., I would want to review all
pushes to master as release manager), until this release is completed.

By the way, we had absolutely clear weather this morning for looking
at the partial solar eclipse that was visible from here and which
reached ~90 per cent obscuration.  It wasn't nearly as spectacular as
the total eclipse experience that is occurring south of here on the
totality path, but it was still pretty special because the solar
crescent that was left at maximum obscuration was quite narrow. So I
was glad I took some time out to look at it with my eclipse viewer,
and even without the viewer it was obvious that the sunlight was a lot
less than normal.

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] Planning for the release of 5.13.0

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

Hi Alan,



I have uploaded the full contents of the examples directory, as you requested. It was your earlier estimate of 62 MB that prompted me to limit it to merely the PostScript files ;).



Anyway, I agree: the remaining issues with the various Windows-based platforms can be examined after the release. They seem to be relatively minor and solving them may take quite some time, if only the complete test runs take a long time.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Saturday, August 19, 2017 2:38 AM
>
> In sum, in the interest of getting this release done in a timely manner, I am fine with
> you putting off the above 3 comprehensive test efforts until later.  So assuming you
> agree, I am very much looking forward to releasing 5.13.0 on or before Tuesday,
> August 22nd 16:00 UTC.
>
> Thanks once again for all your testing and other help that has made the PLplot-
> 5.13.0 release so much better than it would have been otherwise.
>


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] Planning for the release of 5.13.0

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

Hi Arjen:

Here is the promised further discussion concerning the timing
of this release.

The current status is I have just completed both noninteractive and
interactive testing on Debian Jessie with no release-critical issues,
and that is probably enough right there to justify a release since
it is important we make the work done in this release cycle readily
available to our users, and this release is already at least a month
late.

So I plan to do everything in README.Release_Manager_Cookbook starting
tomorrow (Saturday) other than actually tagging the release and
uploading the tarball.  And that should put me in a good position to
release quickly (which is important to me for the above reason).  But
I am willing to wait for two or three days for you to finish off
noninteractive comprehensive testing on MinGW-w64/MSYS2 since you
appear to be so close to that goal thanks to your much-appreciated
efforts this week.

The status for MinGW-w64/MSYS2 is your noninteractive comprehensive
test report looks fine, but ideally I would like to follow up by
looking at detailed plot results for *all* noninteractive devices (not
just the psc ones) on that platform to make sure there are no major
rendering issues on that platform for any of those devices.  My last
post to you was about how to get those plot results to me. But if I
don't get access to those plot results by, say, Tuesday, August 22nd 
I will probably just go ahead and release early on that day my time
(i.e., about 16:00 UTC) without that ideal follow up.  But if you
contact me before that, I might be able to release even earlier than
that deadline.

Here are the remaining comprehensive tests that you should still
eventually complete beyond the noninteractive MinGW-w64/MSYS2 case
summarized above. The question about these tests is do you feel an
urgent need to finish any of them now before the release or are you
comfortable with doing them later?  If I don't hear from you on this
question by Tuesday 16:00 UTC, I will assume the answer is you are
comfortable with putting them off.

1. Finish your noninteractive comprehensive testing on Cygwin. As I
recall the status in this case, there are platform regressions you
need to sort out here relative to your successful comprehensive test
for this platform for 5.12.0.

2. Finish your noninteractive comprehensive testing on MSVC.
As I recall the script did not complete, but the partial result
looked promising so I asked you to run the script again with
one component disabled to see if you could get success that
way.

3. Finish interactive comprehensive testing on Cygwin, MinGW-w64/MSYS2
and MSVC for wxwidgets.

I recall that wxwidgets is currently problematic on Cygwin because of
find issues there that you still need to debug.

I recall you already had a certain amount of success with such tests
previously for both MinGW-w64/MSYS2 and MSVC, but that was before the
uninitialized variable fix in the wxwidgets code, and also I believe
one or both of those platform tests was too limited (e.g., only shared
library or maybe even only shared library/build tree).

In sum, in the interest of getting this release done in a timely
manner, I am fine with you putting off the above 3 comprehensive test
efforts until later.  So assuming you agree, I am very much looking
forward to releasing 5.13.0 on or before Tuesday, August 22nd 16:00
UTC.

Thanks once again for all your testing and other help that has made
the PLplot-5.13.0 release so much better than it would have been otherwise.

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] Planning for the release of 5.13.0

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

Hi Arjen:

Your report tarball looks good.  However, I want to have a look at the
plot files corresponding to that to make sure there are no remaining
issues that we need to fix for this platform before the release. (You
did put up on your ftp site complete -dev psc results which I downloaded
with no issues, but I need those results plus a lot more from the
rest of the noninteractive devices that you teste.)

So please follow the exact directions below.

On 2017-08-08 11:16-0700 Alan W. Irwin wrote:

> [...R]un this
> noninteractive comprehensive test again, but with these additional
> options:
>
> --do_clean_as_you_go no
> --do_nondynamic no
> --do_static no
> --do_ctest no
> --do_test_install_tree no
> --do_test_traditional_install_tree no
>
> These options keep all plplot results for a limited test case (only the 
> shared
> library build, only the build-tree, only the test_noninteractive target)
> which has 12 times less plot results than normal.

Then collect plot results as follows:

cd ../comprehensive_test_disposeable/shared/noninteractive/build_tree/examples

tar zcf test_examples_output_dir.tar.gz test_examples_output_dir

When I did exactly the above limited comprehensive test here and
collected the results as above, the result was 3GB (!) of files in
that directory (much more than just the -dev psc results) with the tarball
being 365MB in size.  (My previous estimate of a 62MB tarball was way
too small.  I am not sure how that happened.)  Your own
test_examples_output_dir.tar.gz tarball should be somewhat smaller than
365MB because the MinGW-w64/MSYS2 platform does not support as many
PLplot components as my Debian Jessie platform.  But it should be much
larger than 62MB.

Therefore, please place on that ftp site both the report tarball
corresponding to the above limited comprehensive test (in case I need
to check something for this exact run of the script) and that
test_examples_output_dir.tar.gz 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] Planning for the release of 5.13.0

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

Hi Alan,



Please find the latest test results for MinGW-w64/MSYS2 in the attachment.



A few remarks about your findings and suggestions:

-        The hash command under MinGW-w64/MSYS2 seems to look at /usr/bin only, whereas most packages are installed under /mingw64/bin. That makes it less useable than "which"

-        I had to rename the directory "C:\tcl" to make sure that CMake would find the correct version of tclsh, even though it is simply present in the path.

-        I have not looked into the perl and git issues - that is something for later, as is the issue with tclsh.

-        With the prolonged timeout, the tests have run to completion.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Thursday, August 17, 2017 12:59 AM
>
> So please run this test again with the above platform install issues fixed (other than
> perl.exe and git.exe which I have presumed you want to put off dealing with until
> post-release) and using this latest commit.
>


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] <off topic> Solar eclipse coming for North America in 4 days!

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

I would add to Steve's points that although total solar eclipses
tracks often occur on the Earth those tracks are extremely narrow and
of relatively short duration so observing a total solar eclipse from a
fixed Earth location is a rare event (typically 3 times per thousand
years according to a pamphlet I have in front of me.) Despite the
improbability for one such event, Carbondale, Illinois will observe
two (!) total solar eclipses in the next 7 years (in 4 days when it
will be near the maximum totality point of the totality track that
occurs close to the middle of the longitude range of the track, and
also on April 08 2024 where again it will be close to the maximum
totality point).  There is a birthday paradox occurring here so you
have to be careful about getting too wild about improbability claims
for such double solar eclipes in 7 years or less for any fixed
location on Earth since all you need for such an event to occur is two
totality tracks crossing each other in 7 years or less.

I am sure somebody has made that calculation considering what is going
on for Carbondale in the next 7 years, and maybe narrowing it even
further by constraining the calculation so that the crossing occurs
near the maximum (say from the 45 per cent point to the 55 per cent
point of the track) of each totality track.  I haven't yet found such
a calculation, but I am sure such crossings near the totality maximum
for each don't occur very often. So Carbondale, Illinois is clearly
going to be "the" lucky total solar eclipse location for quite some
time before some other point on Earth inherits that designation.

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] <off topic> Solar eclipse coming for North America in 4 days!

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

On 2017-08-17 11:39-0000 Schwartz, Steven J wrote:

> Just to add a few cents' worth here, there are excellent resources at:
>
> http://www.eclipse2017.org/
>
> concerning where, when, what, how. While I would echo Alan's enthusiasm that being prepared and seeing a partial eclipse is better than missing it altogether, I'd also echo the comment on the above website under "The path of totality" which has a page "'Close' is not close enough!" I fought with my spouse to travel from the south of France to be on the French coast of the English channel for the 1999 eclipse over the question of "close". I won that fight and the instant we exited from totality she turned to me and asked "When's the next one?". Totality enables you to see the solar corona which is too faint against a 90 or 95% eclipsed Sun. And watch the animals respond.
>
> And by way of small correction, solar eclipses themselves are not rare, they occur every year or two. They're not always full eclipses and, as the planet is 75% covered by water, not often visible on land and certainly not cutting a swathe across North America.
>
> Under no circumstances look at the sun with the naked eye (or directly through a camera lens or binoculars) apart from during totality (this is one of those required health warnings). Alan's box will work well to watch the moon's advancement over the solar disc. Viewing glasses are quite cheap, but be careful as I'm told some being sold are fake.
>
> Happy viewing

All excellent points.

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] <off topic> Solar eclipse coming for North America in 4 days!

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

Just to add a few cents' worth here, there are excellent resources at:

http://www.eclipse2017.org/

concerning where, when, what, how. While I would echo Alan's enthusiasm that being prepared and seeing a partial eclipse is better than missing it altogether, I'd also echo the comment on the above website under "The path of totality" which has a page "'Close' is not close enough!" I fought with my spouse to travel from the south of France to be on the French coast of the English channel for the 1999 eclipse over the question of "close". I won that fight and the instant we exited from totality she turned to me and asked "When's the next one?". Totality enables you to see the solar corona which is too faint against a 90 or 95% eclipsed Sun. And watch the animals respond.

And by way of small correction, solar eclipses themselves are not rare, they occur every year or two. They're not always full eclipses and, as the planet is 75% covered by water, not often visible on land and certainly not cutting a swathe across North America.

Under no circumstances look at the sun with the naked eye (or directly through a camera lens or binoculars) apart from during totality (this is one of those required health warnings). Alan's box will work well to watch the moon's advancement over the solar disc. Viewing glasses are quite cheap, but be careful as I'm told some being sold are fake.

Happy viewing
Steve

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: 17 August 2017 12:08
> To: PLplot development list <Plp...@li...>
> Subject: [Plplot-devel] <off topic> Solar eclipse coming for North America in
> 4 days!
> 
> For those PLplot developers who are in North America on Monday, August
> 21st (4 days from now) there is going to be an exciting solar eclipse visible to
> all of you who have clear skies.  Most of you will only see a deep partial
> eclipse (e.g., 90 per cent of the sun will be obscured from here in Victoria)
> which is exciting enough (and even detectable in cloud) but the privileged
> few that live in or who visit the narrow total eclipse track from Oregon
> through southern Illinois (maximum totality near Carbondale) and then on to
> the Atlantic coast via S.
> Carolina will see a spectacular and rare event which is a total eclipse of the
> sun if you have good weather.
> 
> Barbara's sister (who lives near Carbondale) says they are now expecting
> something like 100 000 (!) vistors to Carbondale to view the total solar
> eclipse there which will likely completely overwhelm the resources of that
> small town.  Barbara and I won't join those Carbondale visitors because we
> don't travel much any more.
> Nevertheless, this is a pretty exciting astronomical event so I have built an
> eclipse viewer out of an old cardboard box following the instructions at
> <http://www.asc-csa.gc.ca/eng/multimedia/activities/eclipse-
> projector.asp>.
> It worked very well today to show me the round solar disk so it should be
> good to go on eclipse day to show us the thin crescent left when the moon is
> obscuring the sun at the 90 per cent level (assuming we have good weather
> that day).  Or if it is socked in that day we will throw away the eclipse viewer,
> but we should still be able to observe the eclipse effect since only the 10 per
> cent of the Sun's disk that is not obscured by the Moon will be providing our
> daylight.  And similarly for virtually everyone else in North America if they
> just evaluate the dimness of the daylight when looking out the window at the
> right time that day.
> 
> 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
> __________________________
> 
> ------------------------------------------------------------------------------
> 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

[Plplot-devel] <off topic> Solar eclipse coming for North America in 4 days!

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

For those PLplot developers who are in North America on Monday, August
21st (4 days from now) there is going to be an exciting solar eclipse
visible to all of you who have clear skies.  Most of you will only see
a deep partial eclipse (e.g., 90 per cent of the sun will be obscured
from here in Victoria) which is exciting enough (and even detectable
in cloud) but the privileged few that live in or who visit the narrow
total eclipse track from Oregon through southern Illinois (maximum
totality near Carbondale) and then on to the Atlantic coast via S.
Carolina will see a spectacular and rare event which is a total
eclipse of the sun if you have good weather.

Barbara's sister (who lives near Carbondale) says they are now
expecting something like 100 000 (!) vistors to Carbondale to view the
total solar eclipse there which will likely completely overwhelm the
resources of that small town.  Barbara and I won't join those
Carbondale visitors because we don't travel much any more.
Nevertheless, this is a pretty exciting astronomical event so I have
built an eclipse viewer out of an old cardboard box following the
instructions at
<http://www.asc-csa.gc.ca/eng/multimedia/activities/eclipse-projector.asp>.
It worked very well today to show me the round solar disk so it should
be good to go on eclipse day to show us the thin crescent left when
the moon is obscuring the sun at the 90 per cent level (assuming we
have good weather that day).  Or if it is socked in that day we will
throw away the eclipse viewer, but we should still be able to observe
the eclipse effect since only the 10 per cent of the Sun's disk that
is not obscured by the Moon will be providing our daylight.  And
similarly for virtually everyone else in North America if they just
evaluate the dimness of the daylight when looking out the window at
the right time that day.

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] A new interactive "iup" device based on the IUP library?

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

The IUP library (see <http://webserver2.tecgraf.puc-rio.br/iup/> and
<https://en.wikipedia.org/wiki/IUP_(software)>) has recently been
discussed on the CMake developer's mailing list as a light-weight
replacement for the GUI needed for cmake-gui (which is currently Qt
based).

So I thought I should bring this library to the attention of device
driver developers here. The key characteristics of this library are it
is very small, it is MIT licensed, and it provides a uniform IUP GUI
API that wraps one of the following list of backend possibilities that are
available now:

UNIX (SunOS, IRIX, and AIX) using Motif 2.x
UNIX (FreeBSD and Linux) using GTK+ (since 3.0)
Microsoft Windows XP/2003/Vista/7 using the Win32 API

It appears there is a lot of developer interest in this library
because of the above characteristics so, for example, one of the
posters on the CMake developer's list mentioned he was writing a
CMake-based build system for IUP and also a IUP wrapper for the native
Mac OS X GUI (which would make this a truly cross-platform library).
Because of such developer enthusiasm, I also suspect it only a matter
of time until even more IUP backend graphical libraries are supported
such as Qt and wxWidgets.

Also, GTK+ and the Win32 API (when using GDI/GDI+/Uniscribe or
Direct2D/DirectWrite) (and Qt and wxWidgets) all support native unicode fonts and complex
text layout.  A google search for

unicode site:http://webserver2.tecgraf.puc-rio.br/iup/

shows 10 hits and what appears to be full cross-platform support for
the utf-8 encoding of unicode by the IUP library.

A similar search for the "complex text layout" or "CTL" terms found
nothing relevant, but complex text layout is completely in the
domain of the backend graphical libraries and nothing to
do with the IUP API so I suspect users of this potential device
would enjoy complete CTL support.

In sum, there is no deep urgency to create an IUP-based interactive
device driver for PLplot, but IUP is cross-platform (including Mac OS
X soon) and supports utf-8 and (likely) CTL just like our best device
drivers (i.e., svg, qt, cairo, wxwidgets) currently do.  Thus, the IUP
library provides a pretty interesting possibility for supporting a new
interactive device of extremely high quality. So if someone here is
interested in developing an "iup" device I would certainly encourage
that effort.

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] Planning for the release of 5.13.0

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

On 2017-08-16 06:19-0000 Arjen Markus wrote:

> [See] the attached tarball [...]

I analyzed your unpacked report tarball using the following commands:

# Check for any warning regressions in the cmake output.
less shared/noninteractive/output_tree/cmake.out

The only issue I found that was related to your platform installation
was a consistent version of itcl could not be found, see further
comment below about that.

# Check for any files that are not from MinGW-w64/MSYS2.  This is a 
# critical check for most of your comprehensive test results because 
# you have at least 3 platforms (MinGW-w64/MSYS2, Cygwin, and MSVC) 
# installed, and the first two of those should never use files from a
# different platform.  This is also true of the MSVC platform with the
# notable exception of just the Unix tools (but not the libraries) from
# MinGW-w64/MSYS2 that you need to test the MSVC platform.

grep -E '/|\\' shared/noninteractive/build_tree/CMakeCache.txt shared/noninteractive/output_tree/* \
|grep -Ev '//|mingw64-2|comprehensive_test_disposeable|CMakeFiles/|test_examples_output_dir|Test *#|plplot-svn/plplot-git|/dll/|test_dyndrivers_dir/|/plplot-test.sh|Output file name is' 
shared/noninteractive/build_tree/CMakeCache.txt:COMDLG32_LIBRARY:FILEPATH=C:/Windows/System32/comdlg32.dll
shared/noninteractive/build_tree/CMakeCache.txt:CYGWIN_INSTALL_PATH:PATH=C:/cygwin64
shared/noninteractive/build_tree/CMakeCache.txt:GDI32_LIBRARY:FILEPATH=C:/Windows/System32/gdi32.dll
shared/noninteractive/build_tree/CMakeCache.txt:PERL_EXECUTABLE:FILEPATH=C:/cygwin64/bin/perl.exe
shared/noninteractive/build_tree/CMakeCache.txt:PL_FREETYPE_FONT_PATH:PATH=c:/windows/fonts
shared/noninteractive/build_tree/CMakeCache.txt:TCL_INCLUDE_PATH:PATH=C:/Tcl/include
shared/noninteractive/build_tree/CMakeCache.txt:TCL_TCLSH:FILEPATH=C:/Tcl/bin/tclsh.exe
shared/noninteractive/build_tree/CMakeCache.txt:TK_INCLUDE_PATH:PATH=C:/Tcl/include
shared/noninteractive/build_tree/CMakeCache.txt:TK_WISH:FILEPATH=C:/Tcl/bin/wish.exe
shared/noninteractive/build_tree/CMakeCache.txt:TTK_STUB_LIBRARY:FILEPATH=C:/Tcl/lib/ttkstub.lib
shared/noninteractive/build_tree/CMakeCache.txt:WWW_DIR:STRING=/home/groups/p/pl/plplot/htdocs/docbook-manual
shared/noninteractive/build_tree/CMakeCache.txt:XML_DECL:STRING=/usr/share/xml/declaration/xml.dcl
shared/noninteractive/build_tree/CMakeCache.txt:FIND_PACKAGE_MESSAGE_DETAILS_Perl:INTERNAL=[C:/cygwin64/bin/perl.exe][v5.22.4()]
shared/noninteractive/build_tree/CMakeCache.txt:FIND_PACKAGE_MESSAGE_DETAILS_Tclsh:INTERNAL=[C:/Tcl/bin/tclsh.exe][v8.6()]
shared/noninteractive/output_tree/cmake.out:-- Looking for DIR symbol in sys/types.h;dirent.h
shared/noninteractive/output_tree/cmake.out:-- Looking for DIR symbol in sys/types.h;dirent.h - found
shared/noninteractive/output_tree/cmake.out:-- Found Perl: C:/cygwin64/bin/perl.exe (found version "5.22.4") 
shared/noninteractive/output_tree/cmake.out:-- Found Tclsh: C:/Tcl/bin/tclsh.exe (found version "8.6") 
shared/noninteractive/output_tree/cmake.out:-- TCL_INCLUDE_PATH = C:/Tcl/include
shared/noninteractive/output_tree/cmake.out:-- TCL_TCLSH = C:/Tcl/bin/tclsh.exe
shared/noninteractive/output_tree/cmake.out:-- TK_INCLUDE_PATH = C:/Tcl/include
shared/noninteractive/output_tree/cmake.out:-- TK_WISH = C:/Tcl/bin/wish.exe
shared/noninteractive/output_tree/cmake.out:-- TKLIB_COMPILE_FLAGS = -I"C:/Tcl/include"
shared/noninteractive/output_tree/cmake.out:-- ntk_COMPILE_FLAGS = -I"C:/Tcl/include" -I"C:/Tcl/include"
shared/noninteractive/output_tree/cmake.out:   and/or set the environment variable PKG_CONFIG_PATH appropriately.
shared/noninteractive/output_tree/cmake.out:-- WARNING: Perl modules XML::Parser and/or XML::DOM not available
shared/noninteractive/output_tree/installed_make_noninteractive.out:c/ext-cairo-test.exe -drvopt set_background=1
shared/noninteractive/output_tree/traditional_clean.out:rm -f *.psc *.pdfcairo *.pngcairo *.pscairo *.svgcairo \
shared/noninteractive/output_tree/traditional_clean.out:*.gif *.jpeg *.png *.psttfc *.svg *.xfig *.pstex* *.*qt *.cgm \
shared/noninteractive/output_tree/traditional_clean.out:*_*.txt test.error \
shared/noninteractive/output_tree/traditional_make_noninteractive.out:./test_diff.sh

The above initial grep search for either "/" or "\" searches for all
filenames in those files and the trailing grep -vE stanza above
eliminates all instances where these forms of filenames should be
expected for this platform.  So what is left is quite interesting!

>From these results there appears to be at least the following three issues:

* The package containing tclsh.exe needs to be found with pkgfile and
   installed (to avoid finding the non-MSYS2 version of tclsh.exe in
   C:/Tcl).  Or if this package is already installed, some adjustment
   of environment variables needs to be made (or C:Tcl has to be
   removed altogether) to avoid finding the "C:/Tcl" version of
   tclsh.exe.

* The package containing wish.exe probably needs to be installed
   (to avoid finding the "C:/Tcl" version).

* The package containing perl.exe needs to be installed (to avoid
   finding the non-MSYS2 Cygwin version).

The first issue is obviously critical.  So you need to solve it before
running this test again. This critical improvement will very likely
also solve another problematic issue that I noticed (above) which is
that a consistent version of itcl could not be found by our build
system with the (incorrect for this platform) "C:/Tcl" version of Tcl/Tk.

The second issue should be trivial to fix now that pkgfile is working
properly for you.  Of course, X is not present on this platform so our
build system drops all our Tk-related components other than ntk (our
only Tk component that is currently independent of X).  So I am not
sure how much PLplot actually uses wish.exe on this platform. 
Nevertheless, if pkgfile gives you a clear choice of package here, I
would advise installing that package.  The net result should be no
references to "C:/Tcl" anywhere.

The third of these issues is similar to the git one, i.e.,
it should be trivial to fix now that pkgfile is working properly for
you, but it is not a critical issue so it can be put off to
post-release if you so desire.

# Check for some non-standard warnings:
grep -i warning */*/output_tree/*.out \
|grep -vE 'cmake.out|ctest.out' \
|grep -vE 'PLPLOT WARNING|PRIVATE|deprecated|Resource leak|2 problems|Some graphical or stdout'

# Check for any ldd issues for the shared and nondynamic cases.
grep -iE 'found|symbol|undefined' */*/output_tree/*ldd.out

# Check for any PostScript or Text differences between all non-C languages
# and the corresponding C results.
grep -B1 -A3 "Missing examples" */*/output_tree/*.out |less

# Check for all errors:
grep -i error */*/output_tree/*.out

The previous checks were fine, but this last one yielded

static/noninteractive/output_tree/ctest.out:Errors while running CTest

which was due to a timeout error for the epsqt case which stopped
the static testing part of our test rather early in that part of
the comprehensive test.

To investigate this test error further, here is the summary for your
MinGW-w64/MSYS2 platform of the times taken by all the ctests for the
qt devices for our three major configurations (shared, nondynamic, and
static)

irwin@raven> grep 'Test #.*examples_.*qt' */*/output_tree/ctest.out
nondynamic/noninteractive/output_tree/ctest.out:12/24 Test #12: examples_epsqt ...................   Passed  278.76 sec
nondynamic/noninteractive/output_tree/ctest.out:13/24 Test #13: examples_pdfqt ...................   Passed  313.22 sec
nondynamic/noninteractive/output_tree/ctest.out:14/24 Test #14: examples_bmpqt ...................   Passed   87.16 sec
nondynamic/noninteractive/output_tree/ctest.out:15/24 Test #15: examples_jpgqt ...................   Passed  172.39 sec
nondynamic/noninteractive/output_tree/ctest.out:16/24 Test #16: examples_pngqt ...................   Passed   58.65 sec
nondynamic/noninteractive/output_tree/ctest.out:17/24 Test #17: examples_ppmqt ...................   Passed   87.78 sec
nondynamic/noninteractive/output_tree/ctest.out:18/24 Test #18: examples_tiffqt ..................   Passed   88.26 sec
nondynamic/noninteractive/output_tree/ctest.out:19/24 Test #19: examples_svgqt ...................   Passed  154.18 sec
shared/noninteractive/output_tree/ctest.out:12/24 Test #12: examples_epsqt ...................   Passed  339.58 sec
shared/noninteractive/output_tree/ctest.out:13/24 Test #13: examples_pdfqt ...................   Passed  338.77 sec
shared/noninteractive/output_tree/ctest.out:14/24 Test #14: examples_bmpqt ...................   Passed  129.30 sec
shared/noninteractive/output_tree/ctest.out:15/24 Test #15: examples_jpgqt ...................   Passed  215.66 sec
shared/noninteractive/output_tree/ctest.out:16/24 Test #16: examples_pngqt ...................   Passed  133.00 sec
shared/noninteractive/output_tree/ctest.out:17/24 Test #17: examples_ppmqt ...................   Passed  131.41 sec
shared/noninteractive/output_tree/ctest.out:18/24 Test #18: examples_tiffqt ..................   Passed  171.87 sec
shared/noninteractive/output_tree/ctest.out:19/24 Test #19: examples_svgqt ...................   Passed  155.59 sec
static/noninteractive/output_tree/ctest.out:10/22 Test #10: examples_epsqt ...................***Timeout 1500.12 sec
static/noninteractive/output_tree/ctest.out:11/22 Test #11: examples_pdfqt ...................   Passed  1437.34 sec
static/noninteractive/output_tree/ctest.out:12/22 Test #12: examples_bmpqt ...................   Passed   68.43 sec
static/noninteractive/output_tree/ctest.out:13/22 Test #13: examples_jpgqt ...................   Passed   48.88 sec
static/noninteractive/output_tree/ctest.out:14/22 Test #14: examples_pngqt ...................   Passed   54.99 sec
static/noninteractive/output_tree/ctest.out:15/22 Test #15: examples_ppmqt ...................   Passed   58.35 sec
static/noninteractive/output_tree/ctest.out:16/22 Test #16: examples_tiffqt ..................   Passed  101.99 sec
static/noninteractive/output_tree/ctest.out:17/22 Test #17: examples_svgqt ...................   Passed   90.05 sec

For comparison purposes here are the equivalent times taken here for the same
ctests on my Debian Jessie platform:

software@raven> grep 'Test #.*examples_.*qt' */*/output_tree/ctest.out
nondynamic/noninteractive/output_tree/ctest.out:17/31 Test #19: examples_bmpqt ...................   Passed   50.79 sec
nondynamic/noninteractive/output_tree/ctest.out:18/31 Test #18: examples_pdfqt ...................   Passed   57.25 sec
nondynamic/noninteractive/output_tree/ctest.out:19/31 Test #20: examples_jpgqt ...................   Passed   49.61 sec
nondynamic/noninteractive/output_tree/ctest.out:20/31 Test #17: examples_epsqt ...................   Passed   81.75 sec
nondynamic/noninteractive/output_tree/ctest.out:21/31 Test #22: examples_ppmqt ...................   Passed   47.97 sec
nondynamic/noninteractive/output_tree/ctest.out:22/31 Test #23: examples_tiffqt ..................   Passed   50.18 sec
nondynamic/noninteractive/output_tree/ctest.out:23/31 Test #21: examples_pngqt ...................   Passed   54.98 sec
nondynamic/noninteractive/output_tree/ctest.out:28/31 Test #24: examples_svgqt ...................   Passed   80.66 sec
shared/noninteractive/output_tree/ctest.out:17/31 Test #19: examples_bmpqt ...................   Passed   48.96 sec
shared/noninteractive/output_tree/ctest.out:18/31 Test #20: examples_jpgqt ...................   Passed   48.34 sec
shared/noninteractive/output_tree/ctest.out:19/31 Test #18: examples_pdfqt ...................   Passed   56.96 sec
shared/noninteractive/output_tree/ctest.out:20/31 Test #17: examples_epsqt ...................   Passed   80.28 sec
shared/noninteractive/output_tree/ctest.out:21/31 Test #21: examples_pngqt ...................   Passed   51.80 sec
shared/noninteractive/output_tree/ctest.out:22/31 Test #23: examples_tiffqt ..................   Passed   48.90 sec
shared/noninteractive/output_tree/ctest.out:23/31 Test #22: examples_ppmqt ...................   Passed   48.90 sec
shared/noninteractive/output_tree/ctest.out:28/31 Test #24: examples_svgqt ...................   Passed   76.18 sec
static/noninteractive/output_tree/ctest.out:13/27 Test #15: examples_bmpqt ...................   Passed   62.59 sec
static/noninteractive/output_tree/ctest.out:14/27 Test #16: examples_jpgqt ...................   Passed   58.59 sec
static/noninteractive/output_tree/ctest.out:15/27 Test #14: examples_pdfqt ...................   Passed   70.07 sec
static/noninteractive/output_tree/ctest.out:16/27 Test #13: examples_epsqt ...................   Passed   97.40 sec
static/noninteractive/output_tree/ctest.out:17/27 Test #18: examples_ppmqt ...................   Passed   57.96 sec
static/noninteractive/output_tree/ctest.out:18/27 Test #19: examples_tiffqt ..................   Passed   60.73 sec
static/noninteractive/output_tree/ctest.out:19/27 Test #17: examples_pngqt ...................   Passed   68.72 sec
static/noninteractive/output_tree/ctest.out:24/27 Test #20: examples_svgqt ...................   Passed   93.94 sec

So for some unknown reason on the MinGW-w64/MSYS2 platform the ctests
for both pdfqt and epsqt dramatically slow down for the static case
(compared to an actual speed up on that platform for the static case
for all other qt devices).  And in the epsqt case (which the details
show almost completed) that slowdown was sufficiently large that it
ran into the default timeout limit of 1500 sec on tests done by ctest
and therefore errored out.  I am virtually certain this static
inefficiency for these two devices for MinGW-w64/MSYS2 is a platform
issue (probably for the upstream Qt4 suite of libraries) that someone
will notice and fix eventually, but meanwhile we have to deal with the
fact that some ctests take longer than 1500 seconds on this platform.

So to work around this static library inefficiency issue for epsqt and
pdfqt for this platform (and also to allow our users who happen to
have really slow computers like the raspberry Pi to complete these
tests) I have changed (commit ac3473f) the default ctest timeout from
1500 seconds to 15000 seconds.

So please run this test again with the above platform install
issues fixed (other than perl.exe and git.exe which I have presumed
you want to put off dealing with until post-release) and using this
latest commit.

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] Planning for the release of 5.13.0

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, August 15, 2017 9:23 PM
>
> Oops.  That above key qualifying phrase should have read
>
> "when your current test **without** git completes"
>
Phew, that is a relieve - see the attached tarball :).

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] Planning for the release of 5.13.0

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

On 2017-08-15 12:19-0700 Alan W. Irwin wrote:

> On 2017-08-15 11:03-0000 Arjen Markus wrote:
>
>>> -----Original Message-----
>>> From: Alan W. Irwin [mailto:ir...@be...]
>>> Sent: Tuesday, August 15, 2017 12:42 PM
>>> To: Arjen Markus
>>> Cc: PLplot development list
>>> Subject: RE: [Plplot-devel] Planning for the release of 5.13.0
>>> 
>>> On 2017-08-15 08:03-0000 Arjen Markus wrote:
>>> 
>>>> I expand the path to get access to git in the comprehensive tests, but 
>>>> then
>>> CMake fails:
>>> 
>>> Hi Arjen:
>>> 
>>> How do you expand the PATH?  If you mean put /usr/bin on it, doesn't that 
>>> already
>>> happen automatically when you set the appropriate shell for 
>>> MinGW-w64/MSYS2?
>>> 
>
>> Oh, don't worry: when you start a MinGW-w64/MSYS2 shell or a Cygwin
> shell for that matter, you get a dedicated path variable. In fact much
> cleaner than the one a DOS-box starts with, as that accumulates a lot
> of junk :(. I had to expand it to get access to git - it resides in
> "c:\program files\git" and that is not part of the initial path.
>
>> Meanwhile, leaving out "git" has allowed CMake to continue without
> much ado - CMake encounters a wxWidgets directory within the git
> installation, but without the header files and then chokes, it seems.
>
>> For now I run the tests without git.
>
> That sounds like absolutely the correct approach since from its
> location the above version of git is obviously not part of the
> MinGW-w64/MSYS2 platform (which is a big strike against that version
> of git right from the start), and you further discovered including
> "c:\program files\git" on your PATH brings additional problematic
> baggage.
>
> In fact, in the interest of getting these tests done as quickly and
> easily as possible, let's forget about git on MinGW-w64/MSYS2 entirely
> until after this release, i.e., when your current test with git
> completes, please send me that report tarball, and with luck (no
> showstopper issues revealed) that should be the last noninteractive
> test you need to do for this platform before the 5.13.0 release.

Oops.  That above key qualifying phrase should have read

"when your current test **without** git completes"

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] Planning for the release of 5.13.0

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

On 2017-08-15 11:03-0000 Arjen Markus wrote:

>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Tuesday, August 15, 2017 12:42 PM
>> To: Arjen Markus
>> Cc: PLplot development list
>> Subject: RE: [Plplot-devel] Planning for the release of 5.13.0
>>
>> On 2017-08-15 08:03-0000 Arjen Markus wrote:
>>
>>> I expand the path to get access to git in the comprehensive tests, but then
>> CMake fails:
>>
>> Hi Arjen:
>>
>> How do you expand the PATH?  If you mean put /usr/bin on it, doesn't that already
>> happen automatically when you set the appropriate shell for MinGW-w64/MSYS2?
>>

> Oh, don't worry: when you start a MinGW-w64/MSYS2 shell or a Cygwin
shell for that matter, you get a dedicated path variable. In fact much
cleaner than the one a DOS-box starts with, as that accumulates a lot
of junk :(. I had to expand it to get access to git - it resides in
"c:\program files\git" and that is not part of the initial path.

> Meanwhile, leaving out "git" has allowed CMake to continue without
much ado - CMake encounters a wxWidgets directory within the git
installation, but without the header files and then chokes, it seems.

> For now I run the tests without git.

That sounds like absolutely the correct approach since from its
location the above version of git is obviously not part of the
MinGW-w64/MSYS2 platform (which is a big strike against that version
of git right from the start), and you further discovered including
"c:\program files\git" on your PATH brings additional problematic
baggage.

In fact, in the interest of getting these tests done as quickly and
easily as possible, let's forget about git on MinGW-w64/MSYS2 entirely
until after this release, i.e., when your current test with git
completes, please send me that report tarball, and with luck (no
showstopper issues revealed) that should be the last noninteractive
test you need to do for this platform before the 5.13.0 release.

But please also copy the following ideas to your post-release ToDo list
for MinGW-w64/MSYS2.

Try using the

pkgfile git.exe

command to discover the names of the installed and uninstalled
MinGW-w64/MSYS2 packages that contain git.exe.  Assuming that works
(and you have previously assured me your tests show that pkgfile does
work to reliably search installed and uninstalled packages for filenames), then
I am virtually positive that one of those package names will be "git"
without a prefix, i.e., it is part of the "msys2" repository rather
than the "mingw64" repository.  Then according to
<https://wiki.archlinux.org/index.php/Pkgfile>
you should be able to use

pkgfile -l <package name>

e.g.,

pkgfile -l git

to list all files in the git package.  One of those should be
/usr/bin/git.exe so after you install the git package, then

hash git; hast -t git

should respond with /usr/bin/git.exe, and that should finish off this
distracting subtopic of which git version to use for the
MinGW-w64/MSYS2 platform.

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] Planning for the release of 5.13.0

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, August 15, 2017 12:42 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: [Plplot-devel] Planning for the release of 5.13.0
>
> On 2017-08-15 08:03-0000 Arjen Markus wrote:
>
> > I expand the path to get access to git in the comprehensive tests, but then
> CMake fails:
>
> Hi Arjen:
>
> How do you expand the PATH?  If you mean put /usr/bin on it, doesn't that already
> happen automatically when you set the appropriate shell for MinGW-w64/MSYS2?
>
Oh, don't worry: when you start a MinGW-w64/MSYS2 shell or a Cygwin shell for that matter, you get a dedicated path variable. In fact much cleaner than the one a DOS-box starts with, as that accumulates a lot of junk :(. I had to expand it to get access to git - it resides in "c:\program files\git" and that is not part of the initial path.

Meanwhile, leaving out "git" has allowed CMake to continue without much ado - CMake encounters a wxWidgets directory within the git installation, but without the header files and then chokes, it seems. For now I run the tests without git.

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.