plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Fortran callback progress

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> Hi Arjen:
>
> This e-mail has a section concerning your Fortran-only Cygwin results and a section
> concerning your Fortran-only MinGW-w64/MSYS2 results.
>
> I.  Cygwin
>
> These Fortran-only results look good for Cygwin (no errors and no PostScript
> difference regressions).
>
Wonderful

>
> II. MinGW-w64/MSYS2
>
> These Fortran-only results look good for MinGW-w64/MSYS2 (no errors and no
> PostScript difference regressions).
>
> However, there are two issues that should be addressed.
>
> 1. ctest is dropped when it should not be.
>
> It appears there is some left over historical artifact from your comprehensive testing
> launch script that drops ctest testing by specifying "--ctest no".  Could you please
> not add that unnecessary constraint on this Fortran-only test (and also on all
> MinGW-w64/MSYS2 tests from now on).
>
> 2. Non-distribution executables.
>
> I also looked for applications that were found, but which did not belong to the
> MinGW-w64/MSYS2 distribution (i.e., did not have a prefix of C:/msys64) this way:
>
> grep '\.exe' shared/noninteractive/build_tree/CMakeCache.txt |grep -v 'C:/msys64'
>
> The answer was
>
> PERL_EXECUTABLE:FILEPATH=C:/cygwin64/bin/perl.exe
> CMAKE_COMMAND:INTERNAL=D:/cmake3.4.3/bin/cmake.exe
> CMAKE_CPACK_COMMAND:INTERNAL=D:/cmake3.4.3/bin/cpack.exe
> CMAKE_CTEST_COMMAND:INTERNAL=D:/cmake3.4.3/bin/ctest.exe
> CMAKE_EDIT_COMMAND:INTERNAL=D:/cmake3.4.3/bin/cmake-gui.exe
>
> This Cygwin perl version is probably OK since it should still likely produce correct
> results when our build system runs perl scripts.

The question is where that is coming from - CMake must be finding it by itself, because there is no Cygwin directory in the path. I just checked.

> However, these versions of cmake and friends are problematic because some
> distributions (e.g., Cygwin is known to do this) may massage those packages to
> deal with special issues for the distribution.  So there will always be a question mark
> concerning your MinGW-w64/MSYS2 results until you use that distribution's version
> of cmake and friends (and likely a very small question mark concerning the Cygwin
> version of perl as well).
>
Hm, I was unaware of CMake being distributed with MSYS2. Right, will update my installation and try again.

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] comprehensive testing results on Cygwin

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

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> The current results do look good, but I would like to review again the motivation for
> the following constraints on this comprehensive test because it has been a while
> since you last made a complete Cygwin report, and due to Cygwin or PLplot
> changes, some of these constraints should no longer be necessary.
>
All these options have a historical background. Like you say, it would be a good thing to check whether they are still required. More later today.

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] git blog

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

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, March 16, 2016 6:28 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: git blog
>
> On 2016-03-16 09:12-0000 Arjen Markus wrote:
>
> > Hi Alan,
> >
> >
> >
> >> -----Original Message-----
> >> From: Alan W. Irwin [mailto:ir...@be...]
> >> Sent: Wednesday, March 16, 2016 10:08 AM
> >> To: Arjen Markus
> >> Cc: PLplot development list
> >> Subject: git blog
> >>
> >> On 2016-03-16 08:04-0000 Arjen Markus wrote:
> >>
> >>> By the way, your most recent commits did not show up in the log. But
> >> when I did "git merge -ff-only origin/master" I did get the changes.
> >> Very odd.
> >>
> >> Probably not that odd.  "git log" generates the log _for the current
> >> branch_.  So if you had checked out master branch, and invoked "git
> >> log" it would not show the recent commits downloaded to origin/master
> >> by "git fetch".  In other words origin/master and master are two
> >> quite distinct branches; the first is populated by "git fetch", the
> >> second by fast forwarding (at least with our workflow) from some
> >> other local branch (such as origin/master or some topic branch) to master.  That
> is why master has no merge commits and therefore a very clean-looking history.
> >> Which allows you to "git push origin master" from that branch (which
> >> fast forwards to both origin/master and the master branch at SF) and propagate
> that linear history.
> >>
> >
> >
> > Hm, I never noticed that before and it probably means that our receipe is not
> quite correct or correctly described in terms of what you can expect:
> >
> > 2. Updating the master branch:
> >
> >   $ git checkout master
> >
> >   $ git fetch
> >
> >   (optional) review newly downloaded changes
> >
> >   $ git log origin/master
> >
> >   $ git merge --ff-only origin/master
> >
> >
> >
> > Using this receipe, I have always expected to see the latest commits (as retrieved
> by "git fetch") in the log.
>
> The above recipe is absolutely correct.
>
> However, if you specify the branch (e.g., "git log origin/master") it will show commits
> on that branch, but if you don't specify the branch (e.g., "git log") it will show
> commits on the branch that is checked out.  So my guess is you forgot to specify
> origin/master for the above git log command, i.e.,
>
Ah, that must have been it then, that sounds reasonable indeed.

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] Fortran callback progress

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

On 2016-03-16 08:18-0000 Arjen Markus wrote:

> Hi Alan,
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>>
>> Meanwhile, could you please run instead the simple test I requested, i.e.,
>>
>> scripts/comprehensive_test.sh --cmake_added_options "-
>> DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON  -
>> DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_test_interactive no
>>
>> on both Cygwin and MinGW-w64/MSYS2?  The point of those requested options is
>> to thoroughly test Fortran while at the same time automatically avoiding testing Tcl
>> or anything else that could go wrong.  For now, it's only these focussed Fortran test
>> reports I need from you now to help encourage others to try the above test.
>>
> See the attachments - Cygwin and MSYS2. Both 64-bits platforms.

Hi Arjen:

This e-mail has a section concerning your Fortran-only Cygwin results and 
a section concerning your Fortran-only MinGW-w64/MSYS2 results.

I.  Cygwin

These Fortran-only results look good for Cygwin (no errors and no
PostScript difference regressions).

I also looked for applications that were found, but which did not
belong to the Cygwin distribution (i.e., did not have a prefix of /usr
or /lib) this way:

grep '\.exe' shared/noninteractive/build_tree/CMakeCache.txt |grep -v /usr |grep -v /lib

The answer was there were no such applications which is the ideal
result.  For example, you are using the Cygwin version of cmake.exe
which is the correct thing to do.  (I just now did the same test for
the complete Cygwin results you recently sent me, and the results were
ideal for that case as well.)

I have updated the Fortran-only results table on our wiki accordingly
for Cygwin, (see
https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Fortran%20Testing%20Reports).

II. MinGW-w64/MSYS2

These Fortran-only results look good for MinGW-w64/MSYS2 (no errors and no
PostScript difference regressions).

However, there are two issues that should be addressed.

1. ctest is dropped when it should not be.

It appears there is some left over historical artifact from your
comprehensive testing launch script that drops ctest testing by
specifying "--ctest no".  Could you please not add that unnecessary constraint on
this Fortran-only test (and also on all MinGW-w64/MSYS2 tests from now
on).

2. Non-distribution executables.

I also looked for applications that were found, but which did not
belong to the MinGW-w64/MSYS2 distribution (i.e., did not have a
prefix of C:/msys64) this way:

grep '\.exe' shared/noninteractive/build_tree/CMakeCache.txt |grep -v 'C:/msys64'

The answer was

PERL_EXECUTABLE:FILEPATH=C:/cygwin64/bin/perl.exe
CMAKE_COMMAND:INTERNAL=D:/cmake3.4.3/bin/cmake.exe
CMAKE_CPACK_COMMAND:INTERNAL=D:/cmake3.4.3/bin/cpack.exe
CMAKE_CTEST_COMMAND:INTERNAL=D:/cmake3.4.3/bin/ctest.exe
CMAKE_EDIT_COMMAND:INTERNAL=D:/cmake3.4.3/bin/cmake-gui.exe

This Cygwin perl version is probably OK since it should still likely
produce correct results when our build system runs perl scripts.
However, these versions of cmake and friends are problematic because
some distributions (e.g., Cygwin is known to do this) may massage
those packages to deal with special issues for the distribution.  So
there will always be a question mark concerning your MinGW-w64/MSYS2
results until you use that distribution's version of cmake and friends
(and likely a very small question mark concerning the Cygwin version
of perl as well).

To address these uncertainties, I suggest you install the
mingw-w64-x86_64-cmake and mingw-w64-x86_64-perl packages. (There are
also "msys" variants of these in the MSYS2 distribution, but I believe
those should be avoided.) A one-year-out-of date list of the
mingw-w64-x86_64 and msys packages provided by MSYS2 is given at
<https://sourceforge.net/p/msys2/wiki/Packages/>.  You should be able
to generate he equivalent up-to-date list by following the pacman
instructions at the top of that web page.

I cannot do that for myself because I don't have access to MSYS2 and
its pacman installer.  But please follow those directions for your own
use, and could you send me a compressed version of that up-to-date
list for my use as well?

For now, a different web resource
(<https://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64/>)
tells me that when you install mingw-w64-x86_64-cmake and
mingw-w64-x86_64-perl you will likely be installing cmake-3.3.2 and
perl-5.22.  The former satisfies PLplot's current requirement of a
minimum version of CMake-3.3.2 for all platforms other than Linux, and
that perl version should be fine as well.

I look forward to your next MinGW-w64/MSYS2 Fortran-only test
with issues 1 and 2 resolved.

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] comprehensive testing results on Cygwin

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

On 2016-03-16 11:45-0000 Arjen Markus wrote:

> In the attachment you'll find the results for the complete set of tests on Cygwin. It is looking quite good now.

Hi Arjen:

The current results do look good, but I would like to review again the
motivation for the following constraints on this comprehensive test
because it has been a while since you last made a complete Cygwin
report, and due to Cygwin or PLplot changes, some of these constraints
should no longer be necessary.

I. --cmake_added_options "-DENABLE_ada=OFF -DENABLE_octave=OFF"

Ia. disabling of Ada

Please do not disable Ada. I worked hard on that language support
during this release cycle (see 2.2 in README.release).  I am pretty
sure Greg participated in testing those results for Cygwin and
MinGW-w64/MSYS2. so it should "just work" on Cygwin.  In fact, if it
does not, then there is obviously more Ada work for me to do.

Ib. disabling octave

There has been no recent PLplot work on the octave binding so you may
have to keep that disabled.  It appears that the octave-devel-4.0.0-3
package is available for Cygwin.  Does that work or is there some
incompatiblity with that version of octave? I am virtually positive I
have asked this question before, but I don't remember the answer, and
hopefully you can just refer to notes to supply me with the answer
rather than having to run a special octave test.

II. --do_ctest no

This should be yes.

Here are some additional limitations I discovered by looking at
cmake.out.

1. -- WARNING: no working Java compiler so disabling Java binding and
examples (from cmake.out).

I think we are stuck with this limitation for 64-bit Cygwin for now.
My search using <http://cygwin.com/cgi-bin2/package-grep.cgi> for
"gcc-java" found two versions of that package on 32-bit Cygwin, but those
packages do not exist on 64-bit Cygwin. And if I recall correctly,
this has been a long-standing issue with 64-bit Cygwin.  I wonder what
the source of that 64-bit Cygwin packaging problem is?

2. "Application initialization failed: no display name and no $DISPLAY
environment variable
Error in startup script: couldn't load file "/usr/bin/tk85.dll" (from
cmake.out).

As I recall you have a standard way to address this issue.  Can you do
that in a script (say in the ~/.profile file when you login using the
bash shell) whenever you login to your Cygwin platform so you never
run into this again?

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

I can find no package for gdc (the GNU D compiler that we use on
Linux) on either 32-bit or 64-bit Cygwin.  So there is nothing
we can do here until someone packages gdc for Cygwin.

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

Please address this issue by installing shapelib-1.3.0-1 
(known to be available on 64-bit Cygwin).

5. -- WARNING: Setting PLD_pdf to OFF.

I can find no package for libharu or libhpdf (another name for
the same library) on 32-bit or 64-bit Cygwin. So there is nothing
we can do here until someone packages this library (see
<http://libharu.org/> for a description of it) for Cygwin.

6. -- WARNING:The camlidl application not found. Disabling OCaml binding

I can find no package for camlidl on 32-bit or 64-bit Cygwin. So there
is nothing we can do here until someone packages camlidl for Cygwin.
Note that Cygwin does have a package for ocaml-4.02.3-2 so you may
want to contact that packager to see why he hasn't taken one
additional critical step and also packaged camlidl which (as you can
see from <http://caml.inria.fr/pub/old_caml_site/camlidl/>) is
necessary to interface ocaml with a C library such as PLplot.

To summarize this, please follow the suggestions I have made in Ia,
II, 2, and 4 and re-run the test.  I will wait for those
as-complete-as-possible noninteractive Cygwin results before posting
them in our Wiki table that summarizes near-complete test results. I
would appreciate (soon if you have notes, but otherwise as a low
priority) your answers to the questions posed in Ib concerning octave.
As a low priority in the longer term you will likely want to agitate
on the Cygwin list concerning the missing gdc, libharu (or
libhpdf) and especially gcc-java and camlidl packages.

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] git blog

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

On 2016-03-16 09:12-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Wednesday, March 16, 2016 10:08 AM
>> To: Arjen Markus
>> Cc: PLplot development list
>> Subject: git blog
>>
>> On 2016-03-16 08:04-0000 Arjen Markus wrote:
>>
>>> By the way, your most recent commits did not show up in the log. But
>> when I did "git merge -ff-only origin/master" I did get the changes.
>> Very odd.
>>
>> Probably not that odd.  "git log" generates the log _for the current branch_.  So if
>> you had checked out master branch, and invoked "git log" it would not show the
>> recent commits downloaded to origin/master by "git fetch".  In other words
>> origin/master and master are two quite distinct branches; the first is populated by
>> "git fetch", the second by fast forwarding (at least with our workflow) from some
>> other local branch (such as origin/master or some topic branch) to master.  That is
>> why master has no merge commits and therefore a very clean-looking history.
>> Which allows you to "git push origin master" from that branch (which fast forwards
>> to both origin/master and the master branch at SF) and propagate that linear history.
>>
>
>
> Hm, I never noticed that before and it probably means that our receipe is not quite correct or correctly described in terms of what you can expect:
>
> 2. Updating the master branch:
>
>   $ git checkout master
>
>   $ git fetch
>
>   (optional) review newly downloaded changes
>
>   $ git log origin/master
>
>   $ git merge --ff-only origin/master
>
>
>
> Using this receipe, I have always expected to see the latest commits (as retrieved by "git fetch") in the log.

The above recipe is absolutely correct.

However, if you specify the branch (e.g., "git log origin/master") it
will show commits on that branch, but if you don't specify the branch
(e.g., "git log") it will show commits on the branch that is checked
out.  So my guess is you forgot to specify origin/master for the above
git log command, i.e.,

git checkout master
git fetch #updates origin/master branch from SF master
git log #shows non-updated master and not updated origin/master
git merge --ff-only origin/master #updates master

After the above, then either "git log" or "git log master" would show
the updated master branch, and if you had followed the original recipe
with "git log origin/master" any time after git fetch, it would have
shown the updated origin/master branch.

Anyhow, the next time you run

git checkout master
git fetch

then if the latter command output indicates something is being
downloaded from SF I suggest you experiment with "git log" versus "git
log origin/master" before the "git merge --ff-only origin/master" step
to confirm what I have said above.  During my first few months of
using git extensively I did such experiments myself which is why I am
confident that my mental model of what is going on with origin/master
versus master in the steps above is correct.

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] comprehensive testing results on Cygwin

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

Hi Alan,



In the attachment you'll find the results for the complete set of tests on Cygwin. It is looking quite good now.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, March 14, 2016 10:58 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: comprehensive testing results on Cygwin
>
> On 2016-03-14 08:51-0000 Arjen Markus wrote:
>
> > I attach the tarball for Cygwin 64 bits - the test was unsuccessful, as pltcl crashed
> running example x00. The strange thing is: I can run it manually without any
> problem.
>
> Note it is not actually x00 that fails. If you look carefully at
> shared/noninteractive/output_tree/make_noninteractive.out you will find that the C
> version of x19 appears to work fine (albeit with messages about plmap missing
> functionality because shapelib is not installed ) but the Tcl version of x19 fails due
> to a segfault which virtually guarantees there is a memory management issue either
> in our C or Tcl version of the plmap functionality.  Note memory management
> issues are sometimes silent (i.e., will not produce a segfault in all cases). So Tcl
> example 19 could segfault but not C even if the memory management issue was in
> our core C library and not anything to do with our Tcl binding or examples.
>
> Anyhow, This is a perfect illustration of why we should do comprehensive testing
> during each release cycle for all platforms accessible to us, and my public thanks to
> you for doing that in this Cygwin case.
>
> I am going to follow up by trying some valgrind runs on Linux for example 19
> without shapelib and for both Tcl and C to see if valgrind can spot the fundamental
> memory management issue that is causing the segfault for your particular (Cygwin)
> combination of circumstances.
>


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] comprehensive testing results on Cygwin [POSSIBLE SOLUTION?]

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> Thanks for that explanation of the concise versus expanded error messages.  It still
> leaves two big question though which is why the artificial error in Tcl_GetMatrixPtr
> generated by my local one-line change never gave the expected message (in either
> direct or script mode)
>
> No matrix operator named...
>
> and why when there is a real Tcl_GetMatrixPtr error which should generate some
> variant of
>
> No matrix operator named...
>
> that message is completely suppressed in script mode as occurred recently before
> my fix to stop using GetEntries for the last argument (which is scalar) in
> plmaptexCmd.
>
Yes, that is a riddle. I will have to look into that.

Regards,

Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] comprehensive testing results on Cygwin [POSSIBLE SOLUTION?]

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

On 2016-03-16 08:04-0000 Arjen Markus wrote:

>> So for this case it appears there are consistent
>>
>> Matrix operator "x" already in use
>>
>> basic error messages between the two methods. but that basic error message is
>> not at all consistent with the above naive interpretation of what should happen due
>> to the above one-line change.  Also I don't understand at all why the scripted test
>> adds so much additional information to the basic error message while the direct test
>> does not do that!
>>

> This is a characteristic feature of the Tcl shell: in interactive
mode it produces a more concise error message than in "batch" mode,
i.e. when running a script. So there is nothing wrong there.

Thanks for that explanation of the concise versus expanded error
messages.  It still leaves two big question though
which is why the artificial error in Tcl_GetMatrixPtr generated
by my local one-line change never gave the expected
message (in either direct or script mode)

No matrix operator named...

and why when there is a real Tcl_GetMatrixPtr error which should
generate some variant of

No matrix operator named...

that message is completely suppressed in script mode as occurred
recently before my fix to stop using GetEntries for the last argument
(which is scalar) in plmaptexCmd.

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] git blog

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, March 16, 2016 10:08 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: git blog
>
> On 2016-03-16 08:04-0000 Arjen Markus wrote:
>
> > By the way, your most recent commits did not show up in the log. But
> when I did "git merge -ff-only origin/master" I did get the changes.
> Very odd.
>
> Probably not that odd.  "git log" generates the log _for the current branch_.  So if
> you had checked out master branch, and invoked "git log" it would not show the
> recent commits downloaded to origin/master by "git fetch".  In other words
> origin/master and master are two quite distinct branches; the first is populated by
> "git fetch", the second by fast forwarding (at least with our workflow) from some
> other local branch (such as origin/master or some topic branch) to master.  That is
> why master has no merge commits and therefore a very clean-looking history.
> Which allows you to "git push origin master" from that branch (which fast forwards
> to both origin/master and the master branch at SF) and propagate that linear history.
>


Hm, I never noticed that before and it probably means that our receipe is not quite correct or correctly described in terms of what you can expect:

2. Updating the master branch:

   $ git checkout master

   $ git fetch

   (optional) review newly downloaded changes

   $ git log origin/master

   $ git merge --ff-only origin/master



Using this receipe, I have always expected to see the latest commits (as retrieved by "git fetch") in the log.



Regards,



Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

[Plplot-devel] git blog

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

On 2016-03-16 08:04-0000 Arjen Markus wrote:

> By the way, your most recent commits did not show up in the log. But
when I did "git merge -ff-only origin/master" I did get the changes.
Very odd.

Probably not that odd.  "git log" generates the log _for the current
branch_.  So if you had checked out master branch, and invoked "git
log" it would not show the recent commits downloaded to origin/master
by "git fetch".  In other words origin/master and master are two quite
distinct branches; the first is populated by "git fetch", the second
by fast forwarding (at least with our workflow) from some other local
branch (such as origin/master or some topic branch) to master.  That
is why master has no merge commits and therefore a very clean-looking
history.  Which allows you to "git push origin master" from that
branch (which fast forwards to both origin/master and the master branch at SF) and
propagate that linear history.

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 callback progress

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

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> Meanwhile, could you please run instead the simple test I requested, i.e.,
>
> scripts/comprehensive_test.sh --cmake_added_options "-
> DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON  -
> DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_test_interactive no
>
> on both Cygwin and MinGW-w64/MSYS2?  The point of those requested options is
> to thoroughly test Fortran while at the same time automatically avoiding testing Tcl
> or anything else that could go wrong.  For now, it's only these focussed Fortran test
> reports I need from you now to help encourage others to try the above test.
>
See the attachments - Cygwin and MSYS2. Both 64-bits platforms.

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] comprehensive testing results on Cygwin [POSSIBLE SOLUTION?]

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
...

> > [...]
> > *** PLPLOT WARNING ***
> > plmaptex is a no-op because shapelib is not available.
> > No matrix operator named "62"
> >
> > So from that last line I am pretty sure that the "62" in
> >
> > $w cmd plmaptex {} "ss/ss64ne_General_Text" 1.0 0.0 0.5
> > "Caffyns\nHeanton\nDown" $minx $maxx $miny $maxy 62
> >
> > in examples/tcl/x19.tcl is the cause of the above matrix operator
> > warning on Linux.
> >
> > That warning message comes from line 382 of bindings/tcl/tclMatrix.c.
> > I notice that for all other error conditions that are handled with
> > Tcl_AppendResult, the returned value is TCL_ERROR, but in this
> > particular case the returned value is NULL.  Is that difference in
> > pattern significant?
>
> Hi Arjen:
>
> Never mind.  That was a badly informed question.  This Tcl_GetMatrixPtr routine
> obviously returns a pointer to the specified matrix operator's data so the only way to
> signal error conditions is with a NULL pointer.
>
> That means every call to Tcl_GetMatrixPtr should be checked for that NULL error
> condition and return TCL_ERROR if that error condition is found.  It appears that
> bindings/tcl/tclgen.tcl does exactly that (and the generated file bindings/tcl/tclgen.c
> bears that out), but bindings/tcl/tclAPI.c is hand crafted so the potential was there
> for typographical errors in the error propagation for the call to Tcl_GetMatrixPtr.
> Accordingly as of commit 55f40c0 I have #defined and used the
> CHECK_Tcl_GetMatrixPtr macro to handle the error propagation in a uniform way.
>
> In that commit I also got rid of the bug that was emitting the message
>
> No matrix operator named "62"

This message shows up only if you run the example manually as you indicate below.

>
> for the case where example 19 was run exactly as follows:
>
> cd examples/tcl #(in the build tree)
> ../../bindings/tcl/pltcl -dev psc -o testt.psc
> pltcl> source x19.tcl
> pltcl> plinit
> pltcl> x19
> pltcl> plend
>
> So will you please check master tip (which has a style commit after commit 55f40c0)
> to see whether the segfault is now gone for Cygwin?
>
That segmentation fault was due to the wrapper for plmapline tryingto access argument 45 instead of 4.

> Even if that segfault is now gone, there is still an extremely important issue
> remaining which is that before commit 55f40c0 the
>
> No matrix operator named "62"
>
> message failed to appear for the following scripted version of the above test:
>
> ../../bindings/tcl/pltcl -f x19 -dev psc -o testt.psc
>
> The major concern here is error messages might be silently lost like this for other
> Tcl examples that we test by script rather than directly. (We rarely use the direct
> method for tests since it is so laborious.)  Therefore, I hope you are willing to use
> your Tcl expertise to pursue this issue further.  For example, I just now locally made
> the following modification:
>
...

> I would naively assume this change should generate a "No matrix operator
> named ..." message for the very first call to Tcl_GetMatrixPtr within the binding and
> then immediately exit.
>
> However, for the direct test above I get the following message instead:
>
> Matrix operator "x" already in use
>
> and for the scripted test above I get
>
> software@raven> ../../bindings/tcl/pltcl -f x19 -dev psc -o testt.psc Matrix operator
> "x" already in use
>      while executing
> "matrix x f 15"
>      invoked from within
> "$w cmd plmap mapform19 globe $minx $maxx $miny $maxy"
>      (procedure "x19" line 38)
>      invoked from within
> "x19"
>      (file "x19" line 16)
>
> So for this case it appears there are consistent
>
> Matrix operator "x" already in use
>
> basic error messages between the two methods. but that basic error message is
> not at all consistent with the above naive interpretation of what should happen due
> to the above one-line change.  Also I don't understand at all why the scripted test
> adds so much additional information to the basic error message while the direct test
> does not do that!
>
This is a characteristic feature of the Tcl shell: in interactive mode it produces a more concise error message than in "batch" mode, i.e. when running a script. So there is nothing wrong there. On the other hand I did see one or two error messages being printed to stderr directly. Most uses of fprintf() concern debug statements, but the ones that do not merit a closer look.

By the way, your most recent commits did not show up in the log. But when I did "git merge -ff-only origin/master" I did get the changes. Very odd.

Well, testing the "62" message ...

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] comprehensive testing results on Cygwin [POSSIBLE SOLUTION?]

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

On 2016-03-14 17:34-0700 Alan W. Irwin wrote:

> [...]
> *** PLPLOT WARNING ***
> plmaptex is a no-op because shapelib is not available.
> No matrix operator named "62"
>
> So from that last line I am pretty sure that the "62" in
>
> $w cmd plmaptex {} "ss/ss64ne_General_Text" 1.0 0.0 0.5 "Caffyns\nHeanton\nDown" $minx $maxx $miny $maxy 62
>
> in examples/tcl/x19.tcl is the cause of the above matrix operator
> warning on Linux.
>
> That warning message comes from line 382 of bindings/tcl/tclMatrix.c.
> I notice that for all other error conditions that are handled
> with Tcl_AppendResult, the returned value is TCL_ERROR, but in
> this particular case the returned value is NULL.  Is that difference
> in pattern significant?

Hi Arjen:

Never mind.  That was a badly informed question.  This Tcl_GetMatrixPtr
routine obviously returns a pointer to the specified matrix operator's data so
the only way to signal error conditions is with a NULL pointer.

That means every call to Tcl_GetMatrixPtr should be checked for that
NULL error condition and return TCL_ERROR if that error condition is
found.  It appears that bindings/tcl/tclgen.tcl does exactly that (and
the generated file bindings/tcl/tclgen.c bears that out), but
bindings/tcl/tclAPI.c is hand crafted so the potential was there
for typographical errors in the error propagation for the call
to Tcl_GetMatrixPtr.  Accordingly as of commit 55f40c0 I have
#defined and used the CHECK_Tcl_GetMatrixPtr macro to handle
the error propagation in a uniform way.

In that commit I also got rid of the bug that was emitting the
message

No matrix operator named "62"

for the case where example 19 was run exactly as follows:

cd examples/tcl #(in the build tree)
../../bindings/tcl/pltcl -dev psc -o testt.psc
pltcl> source x19.tcl
pltcl> plinit
pltcl> x19
pltcl> plend

So will you please check master tip (which has a style commit
after commit 55f40c0) to see whether the segfault is now gone
for Cygwin?

Even if that segfault is now gone, there is still an extremely
important issue remaining which is that before commit 55f40c0 the

No matrix operator named "62"

message failed to appear for the following scripted version
of the above test:

../../bindings/tcl/pltcl -f x19 -dev psc -o testt.psc

The major concern here is error messages might be
silently lost like this for other Tcl examples that we test by script
rather than directly. (We rarely use the direct method for tests since it
is so laborious.)  Therefore, I hope you are willing to use your Tcl expertise
to pursue this issue further.  For example, I just now locally made the
following modification:

software@raven> git diff --unified=10
diff --git a/bindings/tcl/tclMatrix.c b/bindings/tcl/tclMatrix.c
index f41e63c..25d0b26 100644
--- a/bindings/tcl/tclMatrix.c
+++ b/bindings/tcl/tclMatrix.c
@@ -370,20 +370,21 @@ Tcl_GetMatrixPtr( Tcl_Interp *interp, const char *matName )
      Tcl_HashEntry *hPtr;

      dbug_enter( "Tcl_GetMatrixPtr" );

      if ( !matTable_initted )
      {
          return NULL;
      }

      hPtr = Tcl_FindHashEntry( &matTable, matName );
+    hPtr = NULL;
      if ( hPtr == NULL )
      {
          Tcl_AppendResult( interp, "No matrix operator named \"",
              matName, "\"", (char *) NULL );
          return NULL;
      }
      return (tclMatrix *) Tcl_GetHashValue( hPtr );
  }

  //--------------------------------------------------------------------------

(I used the --unified=10 option to give more context for my one-line
change.)

I would naively assume this change should generate a "No matrix operator named ..." message for
the very first call to Tcl_GetMatrixPtr within the binding and then
immediately exit.

However, for the direct test above I get the following message instead:

Matrix operator "x" already in use

and for the scripted test above I get

software@raven> ../../bindings/tcl/pltcl -f x19 -dev psc -o testt.psc
Matrix operator "x" already in use
     while executing
"matrix x f 15"
     invoked from within
"$w cmd plmap mapform19 globe $minx $maxx $miny $maxy"
     (procedure "x19" line 38)
     invoked from within
"x19"
     (file "x19" line 16)

So for this case it appears there are consistent

Matrix operator "x" already in use

basic error messages between the two methods. but that basic error
message is not at all consistent with the above naive interpretation
of what should happen due to the above one-line change.  Also I
don't understand at all why the scripted test adds so much additional
information to the basic error message while the direct test does not
do that!

So my current conclusion is PLplot has one or more fundamental
problems in how it handles Tcl errors (at least on Linux), and I hope
you can figure out how to fix those problems.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Fortran callback progress

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, March 14, 2016 8:10 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: [Plplot-devel] Fortran callback progress
>
> On 2016-03-14 12:06-0000 Arjen Markus wrote:
>
> > [...]However, I do not see an
> overview of the differences (if any) in the reports produced so far.
>
> Here is an example of how I get access to those comprehensive PostScript
> difference reports.
>
> grep -B1 -A3 "Missing
> examples" ../comprehensive_test_disposeable/*/*/output_tree/*.out |less
>
> The -B1 -A3 options include the line before and 3 lines after the line that contains
> "Missing examples" in the *.out files i.e., all the PostScript difference report for any
> language where such report exists.
>
> I hope that Unix grep trick is also useful to you.
>
That is indeed useful to know, though under Windows I have a different tool at my disposal - I just needed the right keyword "missing examples" ;).

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] comprehensive testing of MSVC/ifort/nmake

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, March 14, 2016 10:23 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: comprehensive testing of MSVC/ifort/nmake
>
> On 2016-03-14 07:35-0000 Arjen Markus wrote:
>
> > Alas, I tried that [msvc/ifort comprehensive test] this weekend: somehow CMake
> gets confused. I have stared at the error messages, but I can make heads nor tails
> of the cause.
> >
> > Here is what I did:
> >
> > 1.     I added the directory containing MinGW-w64's sh.exe to the path, so that
> the shell script would be run properly
>
> From your comprehensive_test_env.out file, your PATH (as understood by
> bash.exe) was as follows:
>
> PATH=/d/cmake3.4.3/bin:/usr/bin:/c/Program Files (x86)/Intel/Composer XE
> 2015/bin/intel64:/c/Program Files (x86)/Intel/Composer XE
> 2015/redist/intel64/compiler:/c/Program Files (x86)/Microsoft Visual Studio
> 12.0/Common7/IDE/CommonExtensions/Microsoft/TestWindow:/c/Program Files
> (x86)/MSBuild/12.0/bin/amd64:/c/Program Files
> (x86)/MSBuild/12.0/bin/amd64:/c/Program Files (x86)/Microsoft Visual Studio
> 12.0/VC/BIN/amd64:/c/WINDOWS/Microsoft.NET/Framework64/v4.0.30319:/c/Pro
> gram Files (x86)/Microsoft Visual Studio 12.0/VC/VCPackages:/c/Program Files
> (x86)/Microsoft Visual Studio 12.0/Common7/IDE:/c/Program Files (x86)/Microsoft
> Visual Studio 12.0/Common7/Tools:/c/Program Files (x86)/HTML Help
> Workshop:/c/Program Files (x86)/HTML Help Workshop:/c/Program Files
> (x86)/Microsoft Visual Studio 12.0/Team Tools/Performance Tools/x64:/c/Program
> Files (x86)/Microsoft Visual Studio 12.0/Team Tools/Performance Tools:/c/Program
> Files (x86)/Windows Kits/8.1/bin/x64:/c/Program Files (x86)/Windows
> Kits/8.1/bin/x86:/c/Program Files (x86)/Microsoft SDKs/Windows/v8.1A/bin/NETFX
> 4.5.1 Tools/x64:/c/Program Files (x86)/Intel/Composer XE
> 2015/redist/intel64/mkl:/c/Program Files (x86)/Intel/Composer XE
> 2015/redist/intel64/compiler:/c/ProgramData/Oracle/Java/javapath:/d/CAF/bin:/c/GT
> K/bin:/c/Program Files (x86)/MATLAB/MATLAB Compiler
> Runtime/v82/runtime/win32:/c/Program Files
> (x86)/Skype/Phone:/c/windows/system32:/c/windows:/c/Python27:/c/Python27/DLL
> s:/c/Python27/Scripts:/c/Program Files (x86)/pythonxy/console:/c/Program Files
> (x86)/pythonxy/gettext/bin:/c/MinGW32-xy/bin:/c/Program Files
> (x86)/pythonxy/SciTE-3.3.2-3:/c/Program Files
> (x86)/pythonxy/swig:/c/tcl/bin:/c/windows/system32:/c/Program Files (x86)/MiKTeX
> 2.9/miktex/bin:/c/Program Files (x86)/Intel/Composer XE 2015/redist/intel64/mpirt
>
> That's an extraordinarily complicated PATH.  Is all that really necessary?
>

Quite possibly not, but in Windows these things tend to accumulate without an easy way to reduce it. (Yes, I know, I can go into the "Advanced System Properties" dialogue and the "Environment variables" bit, but the path is then presented as a long long string in a tiny entry control. I do not know which of these directories are really necessary, so that would require some experimenting.)

> From
>
> SH_EXECUTABLE:FILEPATH=C:/msys64/usr/bin/bash.exe
>
> in shared/noninteractive/build_tree/CMakeCache.txt it appears that somehow you
> have indeed found the MinGW-w64/MSYS2 version of bash.exe yet
> C:/msys64/usr/bin is not on your PATH.  For comprehensive testing you will likely
> need other things in C:/msys64/usr/bin so is there some issue with putting that
> PATH component last in your PATH?  (Not first since you want MinGW-
> w64/MSYS2 versions to be the last resort and not the first resort.)
>

Should well be possible - it is just my habit to put such things first.

> Also, I noticed from shared/noninteractive/build_tree/CMakeCache.txt
> you are using D:/cmake3.4.3/bin/cmake.exe.  Can you confirm that is indeed the
> ordinary Windows version of cmake that you should be using for MSVC/ifort/nmake
> that you can download from kitware rather than some MinGW-w64/MSYS2 version?


Yes, that is the version I use for building under MinGW-w64/MSYS2 as well (actually copied the path from the build script I use for that configuration).

>
> >
> > 2.     I invoked the script like this:
> >
> > ../plplot-git/scripts/comprehensive_test.sh --generator_string "NMake Makefiles" -
> -do_clean_as_you_go yes --do_test_interactive no --do_test_traditional_install_tree
> yes --cmake_added_options "-DTCL_INCLUDE_PATH=/usr/include" --
> cmake_added_options "-DENABLE_ada=OFF -DENABLE_octave=OFF" --do_ctest
> no --build_command "nmake" --cmake_added_options "-
> DCMAKE_Fortran_COMPILER=ifort"
> >
> > to make sure the Intel Fortran compiler is selected ("NMake Makefiles" was not
> enough). It took some experimenting ;).
>
> That invocation likely has two showstopper issues.
>
> 1.  The option --cmake_added_options was specified three times with different
> values. The result was (see comprehensive_test.sh.out)
>
> --cmake_added_options "-DCMAKE_Fortran_COMPILER=ifort"
>
> i.e., only the last specified value was honored.
>
> Instead you should use that option only once, e.g.,
>
> --cmake_added_options "-DTCL_INCLUDE_PATH=/usr/include -
> DENABLE_ada=OFF -DENABLE_octave=OFF"
>
> Note, in this example I have dropped -DCMAKE_Fortran_COMPILER=ifort because
> it is problematic, see 2.
>

Oh dear, I completely overlooked that! One of those cases where one needs a fresh pair of eyes.

> 2. That added option -DCMAKE_Fortran_COMPILER=ifort is problematic since it
> does not get propagated properly to the soft landing workaround for Fortran.  So in
> that soft-landing workaround mode a non-intel compiler was checked (and was
> working).  Because of that success it then tried the Intel compiler for real which had
> a crash landing (cmake errored out).  To avoid this inconsistency issue between
> soft-landing mode and real mode I suggest you use the well-debugged environment
> variable method of specifying the compiler, i.e.,
>
> export FC=ifort
>
> which will test that compiler in soft-landing mode and only try it for real if the soft-
> landing mode has a success.  And if the soft-landing mode fails, then Fortran will be
> dropped from the real mode and at least the non-fortran part of the comprehensive
> test will continue.
>

Okay, that sounds like a better plan.

> [....]
> > I am particularly puzzled by the message from the linker
> that it knows no option "s" and what is more the Intel Fortran compiler is invoked
> with an option "-o name-of-executable", which is not the proper option to set the
> name of the executable (it should be -exe:name-of-executable).
>
> These showstopping ifort errors are indeed a puzzle since you have been having
> great success recently with configuring and testing PLplot by hand for the
> msvc/ifort/nmake platform.  So if that includes using -
> DCMAKE_Fortran_COMPILER=ifort rather than export FC=ifort, that is already
> proof that cmake should work fine with -DCMAKE_Fortran_COMPILER=ifort. So
> the fundamental question is how is the comprehensive test script invoking cmake
> differently than you do by hand?
>
> So I would look carefully at comprehensive_test_env.out to see if your PATH
> variable is way too complex compared to when you invoke cmake by hand
> (although MinGW-w64/MSYS2 should be on your PATH as a last resort, see
> above), and also look carefully at comprehensive_test.sh.out for the cmake options
> actually used (such as the --cmake_added_options issue I noted above) to see if
> they are different than what cmake options you use by hand.
>
> Also, you should try the usual trick to debug bash scripts, i.e., run it like this:
>
> export FC=ifort
> bash.exe -x ../plplot-git/scripts/comprehensive_test.sh --generator_string "NMake
> Makefiles" --do_clean_as_you_go yes --do_test_interactive no --
> do_test_traditional_install_tree yes --do_ctest no --build_command "nmake" --
> cmake_added_options "-DTCL_INCLUDE_PATH=/usr/include -
> DENABLE_ada=OFF -DENABLE_octave=OFF "
>
> which should print out a lot of intermediate values used in the script such as the
> complete invocation of the cmake command.  For example, when I try that bash
> trick here, I get the following result (buried deep in a lot of others)
>
> + cmake
> -
> DCMAKE_INSTALL_PREFIX=/home/software/plplot/HEAD/plplot.git/../comprehens
> ive_test_disposeable/shared/noninteractive/install_tree
> -DBUILD_TEST=ON -DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -
> DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON -DENABLE_tcl=ON -
> DBUILD_SHARED_LIBS=ON -G 'Unix Makefiles'
> /home/software/plplot/HEAD/plplot.git
>
> So this allows me to see exactly how cmake was invoked and absolutely confirms
> the script is getting it right in my case.  So if you do the equivalent there you should
> be able to quickly discover the error in how cmake is invoked by the script in your
> case.
>
> Note, also if ifort continues to be problematic with script results but not by hand
> even though you have proved by the above bash trick that the cmake invocations
> are identical for the two cases, then try the "by hand" result with exactly the same
> PATH as indicated in comprehensive_test_env.out just to check that putting
> MinGW-w64/MSYS2 bash.exe and sh.exe last on your PATH is not somehow
> interfering with CMake's tests of ifort.  If that possible interference turns out to be
> an issue for the "by hand" case, then you try putting Cygwin's bash.exe and sh.exe
> last on your PATH instead of the MinGW-w64/MSYS2 to see if there is also
> interference in that case.
>
> Let me know how it goes, and we can take it from there.
>
Okay, will do.

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] comprehensive testing results on Cygwin [POSSIBLE SOLUTION?]

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> And after a lot of complaints about shapelib being missing I ran into the following
> peculiar matrix operator message:
>
> [...]
> *** PLPLOT WARNING ***
> plmaptex is a no-op because shapelib is not available.
> No matrix operator named "62"
>
> So from that last line I am pretty sure that the "62" in
>
> $w cmd plmaptex {} "ss/ss64ne_General_Text" 1.0 0.0 0.5
> "Caffyns\nHeanton\nDown" $minx $maxx $miny $maxy 62
>
> in examples/tcl/x19.tcl is the cause of the above matrix operator warning on Linux.
>
> That warning message comes from line 382 of bindings/tcl/tclMatrix.c.
> I notice that for all other error conditions that are handled with Tcl_AppendResult,
> the returned value is TCL_ERROR, but in this particular case the returned value is
> NULL.  Is that difference in pattern significant?  In other words, if you changed that
> NULL to TCL_ERROR would that solve the segfault on Cygwin?
>
> In other words do we have two bugs here; one where some misuse of matrix is
> causing the
>
> No matrix operator named "62"
>
> warning message, and then a second bug in the way that issue is handled?
>
> Anyhow, I hope these speculations lead you to a definitive fix for both bugs if it
> turns out you agree with me that there are actually two bugs to deal with here, the
> NULL return value that likely should be changed to TCL_ERROR to get rid of the
> segfault on Cygwin, and also the actual condition that causes the above matrix
> operator message to be emitted.
>
Well, I did notice that a lot of PostScript files were created for the Tcl target - glad you found the real culprit example.

Tcl will complain and produce a runtime error when something is not right - in this case a non-existent matrix will cause it to abort immediately with a useful error message. A segfault is not part of the usual termination procedure so something below the level of the script may be wrong too. I will have a closer look at example x19 and the underlying API.

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] comprehensive testing results on Cygwin [POSSIBLE SOLUTION?]

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

On 2016-03-14 14:58-0700 Alan W. Irwin wrote:

> I am going to follow up by trying some valgrind runs on Linux for
> example 19 without shapelib and for both Tcl and C to see if valgrind
> can spot the fundamental memory management issue that is causing the
> segfault for your particular (Cygwin) combination of circumstances.

Hi Arjen:

In fact, for the -DHAVE_SHAPELIB:BOOL=OFF case where example 19
complains about shapelib being missing, if you build the test_c_psc and test_tcl_psc targets
on Linux (to build all required prerequisites) and then run

cd examples/tcl
env PATH=../../bindings/tcl:$PATH valgrind --num-callers=40 --trace-children=yes ./x19 -dev psc -o testt.psc

there are no memory management issues (0 errors) and some minor memory
leak issues.

Furthermore,

valgrind --num-callers=40 ../c/x19c -dev psc -o testc.psc

gives perfect valgrind results (0 errors, no leaks are possible) for
the C case, and the Tcl and C example PostScript results are identical for this
example.

So valgrind finds nothing seriously wrong with example 19 for
-DHAVE_SHAPELIB:BOOL=OFF for the Tcl and C cases on Linux.

However, I followed up further by mimicking what x19 does by hand.
That is, I ran the following:

../../bindings/tcl/pltcl -dev psc -o testt.psc

source x19.tcl
plinit
x19
plend

And after a lot of complaints about shapelib being missing I ran into
the following peculiar matrix operator message:

[...]
*** PLPLOT WARNING ***
plmaptex is a no-op because shapelib is not available.
No matrix operator named "62"

So from that last line I am pretty sure that the "62" in

$w cmd plmaptex {} "ss/ss64ne_General_Text" 1.0 0.0 0.5 "Caffyns\nHeanton\nDown" $minx $maxx $miny $maxy 62

in examples/tcl/x19.tcl is the cause of the above matrix operator
warning on Linux.

That warning message comes from line 382 of bindings/tcl/tclMatrix.c.
I notice that for all other error conditions that are handled
with Tcl_AppendResult, the returned value is TCL_ERROR, but in
this particular case the returned value is NULL.  Is that difference
in pattern significant?  In other words, if you changed that NULL
to TCL_ERROR would that solve the segfault on Cygwin?

In other words do we have two bugs here; one where some misuse of matrix
is causing the

No matrix operator named "62"

warning message, and then a second bug in the way that issue is handled?

Anyhow, I hope these speculations lead you to a definitive fix for
both bugs if it turns out you agree with me that there are actually
two bugs to deal with here, the NULL return value that likely should
be changed to TCL_ERROR to get rid of the segfault on Cygwin, and also
the actual condition that causes the above matrix operator message to
be emitted.

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] comprehensive testing results on Cygwin

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

On 2016-03-14 08:51-0000 Arjen Markus wrote:

> I attach the tarball for Cygwin 64 bits - the test was unsuccessful, as pltcl crashed running example x00. The strange thing is: I can run it manually without any problem.

Note it is not actually x00 that fails. If you look carefully at
shared/noninteractive/output_tree/make_noninteractive.out you will
find that the C version of x19 appears to work fine (albeit with
messages about plmap missing functionality because shapelib is not
installed ) but the Tcl version of x19 fails due to a segfault which
virtually guarantees there is a memory management issue either in our
C or Tcl version of the plmap functionality.  Note memory management
issues are sometimes silent (i.e., will not produce a segfault in all
cases). So Tcl example 19 could segfault but not C even if the memory
management issue was in our core C library and not anything to do with
our Tcl binding or examples.

Anyhow, This is a perfect illustration of why we should do
comprehensive testing during each release cycle for all platforms
accessible to us, and my public thanks to you for doing that in this
Cygwin case.

I am going to follow up by trying some valgrind runs on Linux for
example 19 without shapelib and for both Tcl and C to see if valgrind
can spot the fundamental memory management issue that is causing the
segfault for your particular (Cygwin) combination of circumstances.

More later.

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] comprehensive testing of MSVC/ifort/nmake

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

On 2016-03-14 07:35-0000 Arjen Markus wrote:

> Alas, I tried that [msvc/ifort comprehensive test] this weekend: somehow CMake gets confused. I have stared at the error messages, but I can make heads nor tails of the cause.
>
> Here is what I did:
>
> 1.     I added the directory containing MinGW-w64's sh.exe to the path, so that the shell script would be run properly

>From your comprehensive_test_env.out file, your PATH (as understood by
bash.exe) was as follows:

PATH=/d/cmake3.4.3/bin:/usr/bin:/c/Program Files (x86)/Intel/Composer XE 2015/bin/intel64:/c/Program Files (x86)/Intel/Composer XE 2015/redist/intel64/compiler:/c/Program Files (x86)/Microsoft Visual Studio 12.0/Common7/IDE/CommonExtensions/Microsoft/TestWindow:/c/Program Files (x86)/MSBuild/12.0/bin/amd64:/c/Program Files (x86)/MSBuild/12.0/bin/amd64:/c/Program Files (x86)/Microsoft Visual Studio 12.0/VC/BIN/amd64:/c/WINDOWS/Microsoft.NET/Framework64/v4.0.30319:/c/Program Files (x86)/Microsoft Visual Studio 12.0/VC/VCPackages:/c/Program Files (x86)/Microsoft Visual Studio 12.0/Common7/IDE:/c/Program Files (x86)/Microsoft Visual Studio 12.0/Common7/Tools:/c/Program Files (x86)/HTML Help Workshop:/c/Program Files (x86)/HTML Help Workshop:/c/Program Files (x86)/Microsoft Visual Studio 12.0/Team Tools/Performance Tools/x64:/c/Program Files (x86)/Microsoft Visual Studio 12.0/Team Tools/Performance Tools:/c/Program Files (x86)/Windows Kits/8.1/bin/x64:/c/Program Files (x86)/Windows Kits/8.1/bin/x86:/c/Program Files (x86)/Microsoft SDKs/Windows/v8.1A/bin/NETFX 4.5.1 Tools/x64:/c/Program Files (x86)/Intel/Composer XE 2015/redist/intel64/mkl:/c/Program Files (x86)/Intel/Composer XE 2015/redist/intel64/compiler:/c/ProgramData/Oracle/Java/javapath:/d/CAF/bin:/c/GTK/bin:/c/Program Files (x86)/MATLAB/MATLAB Compiler Runtime/v82/runtime/win32:/c/Program Files (x86)/Skype/Phone:/c/windows/system32:/c/windows:/c/Python27:/c/Python27/DLLs:/c/Python27/Scripts:/c/Program Files (x86)/pythonxy/console:/c/Program Files (x86)/pythonxy/gettext/bin:/c/MinGW32-xy/bin:/c/Program Files (x86)/pythonxy/SciTE-3.3.2-3:/c/Program Files (x86)/pythonxy/swig:/c/tcl/bin:/c/windows/system32:/c/Program Files (x86)/MiKTeX 2.9/miktex/bin:/c/Program Files (x86)/Intel/Composer XE 2015/redist/intel64/mpirt

That's an extraordinarily complicated PATH.  Is all that really
necessary?

From

SH_EXECUTABLE:FILEPATH=C:/msys64/usr/bin/bash.exe

in shared/noninteractive/build_tree/CMakeCache.txt it appears
that somehow you have indeed found the MinGW-w64/MSYS2 version of bash.exe
yet C:/msys64/usr/bin is not on your PATH.  For comprehensive testing
you will likely need other things in C:/msys64/usr/bin so is
there some issue with putting that PATH component last in your
PATH?  (Not first since you want MinGW-w64/MSYS2 versions to
be the last resort and not the first resort.)

Also, I noticed from shared/noninteractive/build_tree/CMakeCache.txt
you are using D:/cmake3.4.3/bin/cmake.exe.  Can you confirm that is
indeed the ordinary Windows version of cmake that you should be using
for MSVC/ifort/nmake that you can download
from kitware rather than some MinGW-w64/MSYS2 version?

>
> 2.     I invoked the script like this:
>
> ../plplot-git/scripts/comprehensive_test.sh --generator_string "NMake Makefiles" --do_clean_as_you_go yes --do_test_interactive no --do_test_traditional_install_tree yes --cmake_added_options "-DTCL_INCLUDE_PATH=/usr/include" --cmake_added_options "-DENABLE_ada=OFF -DENABLE_octave=OFF" --do_ctest no --build_command "nmake" --cmake_added_options "-DCMAKE_Fortran_COMPILER=ifort"
>
> to make sure the Intel Fortran compiler is selected ("NMake Makefiles" was not enough). It took some experimenting ;).

That invocation likely has two showstopper issues.

1.  The option --cmake_added_options was specified three times with
different values. The result was (see comprehensive_test.sh.out)

--cmake_added_options "-DCMAKE_Fortran_COMPILER=ifort"

i.e., only the last specified value was honored.

Instead you should use that option only once, e.g.,

--cmake_added_options "-DTCL_INCLUDE_PATH=/usr/include -DENABLE_ada=OFF -DENABLE_octave=OFF"

Note, in this example I have dropped -DCMAKE_Fortran_COMPILER=ifort
because it is problematic, see 2.

2. That added option -DCMAKE_Fortran_COMPILER=ifort is problematic
since it does not get propagated properly to the soft landing
workaround for Fortran.  So in that soft-landing workaround mode a
non-intel compiler was checked (and was working).  Because of that
success it then tried the Intel compiler for real which had a crash
landing (cmake errored out).  To avoid this inconsistency issue
between soft-landing mode and real mode I suggest you use the
well-debugged environment variable method of specifying the compiler,
i.e.,

export FC=ifort

which will test that compiler in soft-landing mode and only try it for
real if the soft-landing mode has a success.  And if the soft-landing
mode fails, then Fortran will be dropped from the real mode and at
least the non-fortran part of the comprehensive test will continue.

[....]
> I am particularly puzzled by the message from the linker
that it knows no option "s" and what is more the Intel Fortran
compiler is invoked with an option "-o name-of-executable", which is
not the proper option to set the name of the executable (it should be
-exe:name-of-executable).

These showstopping ifort errors are indeed a puzzle since you have
been having great success recently with configuring and testing PLplot
by hand for the msvc/ifort/nmake platform.  So if that includes using
-DCMAKE_Fortran_COMPILER=ifort rather than export FC=ifort, that is
already proof that cmake should work fine with
-DCMAKE_Fortran_COMPILER=ifort. So the fundamental question is how is
the comprehensive test script invoking cmake differently than you do
by hand?

So I would look carefully at comprehensive_test_env.out to see if your
PATH variable is way too complex compared to when you invoke cmake by
hand (although MinGW-w64/MSYS2 should be on your PATH as a last
resort, see above), and also look carefully at
comprehensive_test.sh.out for the cmake options actually used (such as
the --cmake_added_options issue I noted above) to see if they are
different than what cmake options you use by hand.

Also, you should try the usual trick to debug bash scripts, i.e.,
run it like this:

export FC=ifort
bash.exe -x ../plplot-git/scripts/comprehensive_test.sh --generator_string "NMake Makefiles" --do_clean_as_you_go yes --do_test_interactive no --do_test_traditional_install_tree yes --do_ctest no --build_command "nmake" --cmake_added_options "-DTCL_INCLUDE_PATH=/usr/include -DENABLE_ada=OFF -DENABLE_octave=OFF "

which should print out a lot of intermediate values used in the script
such as the complete invocation of the cmake command.  For example,
when I try that bash trick here, I get the following result (buried
deep in a lot of others)

+ cmake
-DCMAKE_INSTALL_PREFIX=/home/software/plplot/HEAD/plplot.git/../comprehensive_test_disposeable/shared/noninteractive/install_tree
-DBUILD_TEST=ON -DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON
-DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON -DENABLE_tcl=ON
-DBUILD_SHARED_LIBS=ON -G 'Unix Makefiles'
/home/software/plplot/HEAD/plplot.git

So this allows me to see exactly how cmake was invoked and absolutely
confirms the script is getting it right in my case.  So if you do the
equivalent there you should be able to quickly discover the error
in how cmake is invoked by the script in your case.

Note, also if ifort continues to be problematic with script results
but not by hand even though you have proved by the above bash trick
that the cmake invocations are identical for the two cases, then try
the "by hand" result with exactly the same PATH as indicated in
comprehensive_test_env.out just to check that putting MinGW-w64/MSYS2
bash.exe and sh.exe last on your PATH is not somehow interfering with
CMake's tests of ifort.  If that possible interference turns out to be
an issue for the "by hand" case, then you try putting Cygwin's
bash.exe and sh.exe last on your PATH instead of the MinGW-w64/MSYS2
to see if there is also interference in that case.

Let me know how it goes, and we can take it from there.

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 callback progress

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

On 2016-03-14 12:06-0000 Arjen Markus wrote:

> [...]However, I do not see an
overview of the differences (if any) in the reports produced so far.

Here is an example of how I get access to those comprehensive
PostScript difference reports.

grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable/*/*/output_tree/*.out |less

The -B1 -A3 options include the line before and 3 lines after the line
that contains "Missing examples" in the *.out files i.e., all the
PostScript difference report for any language where such report exists.

I hope that Unix grep trick is also useful to 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] Fortran callback progress

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

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, March 14, 2016 1:03 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: [Plplot-devel] Fortran callback progress
>
> On 2016-03-14 09:50-0000 Arjen Markus wrote:
>
> > I will try again with Cygwin - it could have been some strange hiccup.
>
> Just a thought.... I don't have the time to look at this myself at the moment, but I
> suggest you look carefully at the cmake.out results in the report tarball to see
> whether the Tcl issue is due to some non-Cygwin form of Tcl being found for all or
> part of the configured Tcl results.
>
Hm, worth a try indeed. Meanwhile the tests are running fine now that I have excluded the Tcl binding. However, I do not see an overview of the differences (if any) in the reports produced so far. More to investigate.

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] Fortran callback progress

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

On 2016-03-14 09:50-0000 Arjen Markus wrote:

> I will try again with Cygwin - it could have been some strange hiccup.

Just a thought.... I don't have the time to look at this myself at the
moment, but I suggest you look carefully at the cmake.out results in
the report tarball to see whether the Tcl issue is due to some
non-Cygwin form of Tcl being found for all or part of the configured
Tcl results.

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 callback progress

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

On 2016-03-14 08:51-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Monday, March 14, 2016 9:23 AM
>> To: Arjen Markus
>> Cc: PLplot development list
>> Subject: RE: [Plplot-devel] Fortran callback progress
>>
>>
>> I also just asked you in another e-mail for similar report tarballs for the pure Cygwin
>> and pure MinGW-w64/MSYS2 platforms.  You may have already run the desired
>> simple comprehensive Fortran test on those platforms, but I need to see the report
>> tarball in each case as well.
>>

> I attach the tarball for Cygwin 64 bits - the test was unsuccessful, as pltcl crashed running example x00. The strange thing is: I can run it manually without any problem.

Hi Arjen:

Thanks for this report tarball and also for your report tarball for
MSVC/ifort/nmake which you sent in a different e-mail.  I hope to
respond on the different errors you found in each case within a day or
two.

Meanwhile, could you please run instead the simple test I requested,
i.e.,

scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON  -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_test_interactive no

on both Cygwin and MinGW-w64/MSYS2?  The point of those requested
options is to thoroughly test Fortran while at the same time
automatically avoiding testing Tcl or anything else that could go
wrong.  For now, it's only these focussed Fortran test reports I need
from you now to help encourage others to try the above test.

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 callback progress

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

Hi Alan,



As you can see from the attached tarball, the tests for MinGW-w64/MSYS2 were quite satisfactory, even though with my current set-up I test only three of the language bindings.



I will try again with Cygwin - it could have been some strange hiccup.



Regards,



Arjen



From: Arjen Markus [mailto:Arj...@de...]
Sent: Monday, March 14, 2016 9:52 AM
To: Alan W. Irwin
Cc: PLplot development list
Subject: Re: [Plplot-devel] Fortran callback progress


Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, March 14, 2016 9:23 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: [Plplot-devel] Fortran callback progress
>
>
> I also just asked you in another e-mail for similar report tarballs for the pure Cygwin
> and pure MinGW-w64/MSYS2 platforms.  You may have already run the desired
> simple comprehensive Fortran test on those platforms, but I need to see the report
> tarball in each case as well.
>
I attach the tarball for Cygwin 64 bits - the test was unsuccessful, as pltcl crashed running example x00. The strange thing is: I can run it manually without any problem.

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