Re: [Plplot-devel] PLplot Fortran bindings

[Alan W. Irwin]

On 2016-04-28 06:35- Arjen Markus wrote:

> Hi Alan, Wadud,
>
>> -Original Message-
>> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
>> Sent: Wednesday, April 27, 2016 11:22 PM
>> To: Wadud Miah
>> Cc: Arjen Markus; plplot-devel@lists.sourceforge.net
>> Subject: RE: [Plplot-devel] PLplot Fortran bindings
>>
>> To Wadud and Arjen:
>>
>> @Arjen:
>> Since you have been unable to answer my quick question in a timely manner
>> concerning adopting selected_int_kind(9) rather than 4 for private_plint,
>> private_plbool, and private_plunicode, I have decided to just go ahead with 
>> that
>> change (commit 3442bac).
>>

> Yesterday was a national holiday here, so I paid little attention to
my inbox :). However, considering the portability of these two types,
why don't we use C_INT32_T from ISO_C_BINDING? This maps to C's
int32_t type (for the companion C compiler to be precise). Essentially
the same thing, except if the platform does not have 32 bits integers,
I'd say, but it conveys the one-to-one relation between the Fortran
and C side.

> This does not rely on the Fortran 2008 standard, only on the Fortran
2003 standard and we require that for the new binding anyway.

That argument sounds reasonable to me, but you are the expert here.  So
please implement this further change yourself.

>> @Arjen: Could you follow up with similar test results for the latest git 
>> master tip for
>> both your Cygwin and MinGW-w64/MSYS2 platforms?
>> That wiki table documents your previous (good) Cygwin Fortran result.
>> Previously you also sent me your good MinGW-w64/MSYS2 platform results for
>> Fortran, but I was holding off on posting that result to our wiki because 
>> that report
>> also revealed a MinGW-w64/MSYS2 installation update issue that requires you 
>> to
>> reinstall the MinGW-w64/MSYS2 platform to get access to the much more
>> convenient/reliable updating available for the latest version of that 
>> platform.
>>
> Will do. I should have time today to do that. That testing should cover the 
> other issue (the temporary files) as well.

I look forward to those comprehensive test results on both platforms.
You can constrain those tests to just test the Fortran, C, and the ps
device driver components of PLplot (with the script arguments I have indicated) 
for speed
because even that limited result should thoroughly test creating
temporary files.

I recommend you make that further change you outlined above before
these constrained comprehensive tests so you can summarize these tests
in the Tested by: paragraph in the commit message.  Once I see that
commit from you, I plan to follow up by redoing my own constrained
Fortran comprehensive test (since it only takes 7 minutes).

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
__

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLplot Fortran bindings

[Wadud Miah]

Hi Arjen/Alan,

I will build PLplot for Git late next week as I will busy the next few days. 
Let me know once you have made all the relevant changes for me to test with the 
NAG Fortran compiler.

I am actually running a workshop in the UK called "Fortran Modernisation 
Workshop" which covers PLplot:

http://www.nag.co.uk/market/training/fortran-modernisation-workshop

I've found PLplot the best visualisation libraries for Fortran 90 which I would 
like to thank you for :-)

Best regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: Thursday, April 28, 2016 9:55 AM
To: Alan W. Irwin 
Cc: Wadud Miah ; plplot-devel@lists.sourceforge.net
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Alan,



I made the small change I suggested and the results for Cygwin and MinGW64 look 
fine - see the attached files. The only platform I still need to test on is 
bare Windows (not as nicely packaged as the other two, unfortunately). When 
that turns out to be fine as well, I will do the commit.



Regards,



Arjen


> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Thursday, April 28, 2016 9:32 AM
> To: Arjen Markus
> Cc: Wadud Miah; plplot-devel@lists.sourceforge.net
> Subject: RE: [Plplot-devel] PLplot Fortran bindings
>
> On 2016-04-28 06:35- Arjen Markus wrote:
>
> > Hi Alan, Wadud,
> >
> >> -Original Message-
> >> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> >> Sent: Wednesday, April 27, 2016 11:22 PM
> >> To: Wadud Miah
> >> Cc: Arjen Markus; plplot-devel@lists.sourceforge.net
> >> Subject: RE: [Plplot-devel] PLplot Fortran bindings
> >>
> >> To Wadud and Arjen:
> >>
> >> @Arjen:
> >> Since you have been unable to answer my quick question in a timely
> >> manner concerning adopting selected_int_kind(9) rather than 4 for
> >> private_plint, private_plbool, and private_plunicode, I have decided
> >> to just go ahead with that change (commit 3442bac).
> >>
>
> > Yesterday was a national holiday here, so I paid little attention to
> my inbox :). However, considering the portability of these two types, why 
> don't we
> use C_INT32_T from ISO_C_BINDING? This maps to C's int32_t type (for the
> companion C compiler to be precise). Essentially the same thing, except if the
> platform does not have 32 bits integers, I'd say, but it conveys the 
> one-to-one
> relation between the Fortran and C side.
>
> > This does not rely on the Fortran 2008 standard, only on the Fortran
> 2003 standard and we require that for the new binding anyway.
>
> That argument sounds reasonable to me, but you are the expert here.  So please
> implement this further change yourself.
>
> >> @Arjen: Could you follow up with similar test results for the latest
> >> git master tip for both your Cygwin and MinGW-w64/MSYS2 platforms?
> >> That wiki table documents your previous (good) Cygwin Fortran result.
> >> Previously you also sent me your good MinGW-w64/MSYS2 platform
> >> results for Fortran, but I was holding off on posting that result to
> >> our wiki because that report also revealed a MinGW-w64/MSYS2
> >> installation update issue that requires you to reinstall the
> >> MinGW-w64/MSYS2 platform to get access to the much more
> convenient/reliable updating available for the latest version of that 
> platform.
> >>
> > Will do. I should have time today to do that. That testing should cover the 
> > other
> issue (the temporary files) as well.
>
> I look forward to those comprehensive test results on both platforms.
> You can constrain those tests to just test the Fortran, C, and the ps device 
> driver
> components of PLplot (with the script arguments I have indicated) for speed
> because even that limited result should thoroughly test creating temporary 
> files.
>
> I recommend you make that further change you outlined above before these
> constrained comprehensive tests so you can summarize these tests in the Tested
> by: paragraph in the commit message.  Once I see that commit from you, I plan 
> to
> follow up by redoing my own constrained Fortran comprehensive test (since it 
> only
> takes 7 minutes).
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state implementation for
> stellar interiors (freeeos.sf.net); the Time Ephemerides project 
> (timeephem.sf.net);
> PLplot scientific plotting software package (plplot.sf.net); the libLASi 
> project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the 
> Linux
> Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __
DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately

Re: [Plplot-devel] PLplot Fortran bindings

[Arjen Markus]

Hi Wadud,



The changes should be there now - I introduced ISO_C_BINDING's C_INT32_T kind 
to solve the portability issue. On the platforms I have available that works 
fine. See 
https://sourceforge.net/p/plplot/plplot/ci/f00ee2a0fb0293e118a359d6e6312b30804b3420/





Regards,



Arjen



From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Thursday, April 28, 2016 12:17 PM
To: Arjen Markus; Alan W. Irwin
Cc: plplot-devel@lists.sourceforge.net
Subject: RE: [Plplot-devel] PLplot Fortran bindings

Hi Arjen/Alan,

I will build PLplot for Git late next week as I will busy the next few days. 
Let me know once you have made all the relevant changes for me to test with the 
NAG Fortran compiler.

I am actually running a workshop in the UK called "Fortran Modernisation 
Workshop" which covers PLplot:

http://www.nag.co.uk/market/training/fortran-modernisation-workshop

I've found PLplot the best visualisation libraries for Fortran 90 which I would 
like to thank you for :-)

Best regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: Thursday, April 28, 2016 9:55 AM
To: Alan W. Irwin mailto:ir...@beluga.phys.uvic.ca>>
Cc: Wadud Miah mailto:wadud.m...@nag.co.uk>>; 
plplot-devel@lists.sourceforge.net
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Alan,



I made the small change I suggested and the results for Cygwin and MinGW64 look 
fine - see the attached files. The only platform I still need to test on is 
bare Windows (not as nicely packaged as the other two, unfortunately). When 
that turns out to be fine as well, I will do the commit.



Regards,



Arjen


> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Thursday, April 28, 2016 9:32 AM
> To: Arjen Markus
> Cc: Wadud Miah; 
> plplot-devel@lists.sourceforge.net
> Subject: RE: [Plplot-devel] PLplot Fortran bindings
>
> On 2016-04-28 06:35- Arjen Markus wrote:
>
> > Hi Alan, Wadud,
> >
> >> -Original Message-
> >> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> >> Sent: Wednesday, April 27, 2016 11:22 PM
> >> To: Wadud Miah
> >> Cc: Arjen Markus; 
> >> plplot-devel@lists.sourceforge.net
> >> Subject: RE: [Plplot-devel] PLplot Fortran bindings
> >>
> >> To Wadud and Arjen:
> >>
> >> @Arjen:
> >> Since you have been unable to answer my quick question in a timely
> >> manner concerning adopting selected_int_kind(9) rather than 4 for
> >> private_plint, private_plbool, and private_plunicode, I have decided
> >> to just go ahead with that change (commit 3442bac).
> >>
>
> > Yesterday was a national holiday here, so I paid little attention to
> my inbox :). However, considering the portability of these two types, why 
> don't we
> use C_INT32_T from ISO_C_BINDING? This maps to C's int32_t type (for the
> companion C compiler to be precise). Essentially the same thing, except if the
> platform does not have 32 bits integers, I'd say, but it conveys the 
> one-to-one
> relation between the Fortran and C side.
>
> > This does not rely on the Fortran 2008 standard, only on the Fortran
> 2003 standard and we require that for the new binding anyway.
>
> That argument sounds reasonable to me, but you are the expert here.  So please
> implement this further change yourself.
>
> >> @Arjen: Could you follow up with similar test results for the latest
> >> git master tip for both your Cygwin and MinGW-w64/MSYS2 platforms?
> >> That wiki table documents your previous (good) Cygwin Fortran result.
> >> Previously you also sent me your good MinGW-w64/MSYS2 platform
> >> results for Fortran, but I was holding off on posting that result to
> >> our wiki because that report also revealed a MinGW-w64/MSYS2
> >> installation update issue that requires you to reinstall the
> >> MinGW-w64/MSYS2 platform to get access to the much more
> convenient/reliable updating available for the latest version of that 
> platform.
> >>
> > Will do. I should have time today to do that. That testing should cover the 
> > other
> issue (the temporary files) as well.
>
> I look forward to those comprehensive test results on both platforms.
> You can constrain those tests to just test the Fortran, C, and the ps device 
> driver
> components of PLplot (with the script arguments I have indicated) for speed
> because even that limited result should thoroughly test creating temporary 
> files.
>
> I recommend you make that further change you outlined above before these
> constrained comprehensive tests so you can summarize these tests in the Tested
> by: paragraph in the commit message.  Once I see that commit from you, I plan 
> to
> follow up by redoing my own constrained Fortran comprehensive test (since it 
> only
> takes 7 minutes).
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of V

Re: [Plplot-devel] PLplot Fortran bindings

[Alan W. Irwin]

On 2016-04-28 10:19- Arjen Markus wrote:

> Hi Wadud,

> The changes should be there now - I introduced ISO_C_BINDING's
C_INT32_T kind to solve the portability issue. On the platforms I have
available that works fine. See
https://sourceforge.net/p/plplot/plplot/ci/f00ee2a0fb0293e118a359d6e6312b30804b3420/

Hi Arjen and Wadud:

@ Arjen:
I followed up (commit 4ec18f8) by doing a similar change for our
private Fortran types (using c_float and c_double rather than
kind(1.0) and kind(1.0d0)).

My Fortran-constrained comprehensive test on Debian jessie of that
change and Arjen's previous change gave perfect results.

As far as I know commit 4ec18f8 is our last Fortran change (other than
documentation) for our forthcoming release.

Now that you are all set up to do constrained Fortran tests on your
three Windows platforms, you will likely want to follow up by
repeating those tests for commit 4ec18f8.  But before running those
tests, please give me an hour or so to look at the report tarballs you
sent me recently for both the Cygwin and MinGW-w64/MSYS2 platforms in
case I spot some issue with the contents of those report tarballs.

> From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
> Sent: Thursday, April 28, 2016 12:17 PM
> To: Arjen Markus; Alan W. Irwin
> Cc: plplot-devel@lists.sourceforge.net
> Subject: RE: [Plplot-devel] PLplot Fortran bindings
>
> Hi Arjen/Alan,
>
[...]
> I've found PLplot the best visualisation libraries for Fortran 90 which I 
> would like to thank you for :-)

@Wadud:

On behalf of Arjen (who is the principal developer of both the old and
new Fortran bindings) and myself, thanks for those kind words about
our old Fortran binding.  I think you will like our new Fortran
binding even better, but if you find some issue with it, please let us
know, and we will attempt to fix it.

Alan
__
Alan W. Irwin

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

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

Linux-powered Science
__

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PLplot Fortran bindings

[Alan W. Irwin]

Hi Arjen:

On 2016-04-28 08:55- Arjen Markus wrote:

> I made the small change I suggested and the results for Cygwin and
MinGW64 look fine - see the attached files.

Thanks for those two test report tarballs.  Here is my analysis of
those results.

1. Cygwin

After unpacking your report tarball, I didn't spot anything unusual in
your comprehensive test script arguments except for

--build_command "make -j4"
--ctest_command "ctest -j4"

I believe you have sometimes found those parallel options to be
problematic for Cygwin in the past so I would drop them from
now on (even though they caused no issues for you for this particular
comprehensive test).

Furthermore,
comprehensive_test.sh.out showed no errors;

grep -i error */*/output_tree/*.out

and

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

gave perfect results; and there were no significant warnings in 
shared/noninteractive/output_tree/make_noninteractive.out or
shared/noninteractive/output_tree/cmake.out.

However, a final check

grep local shared/noninteractive/output_tree/cmake.out

yielded

-- FindShapelib: Found shapelib header directory, /usr/local/include, and 
library, /usr/lib/libshp.a.

indicating a potentially serious inconsistency between the Cygwin
location of /usr/lib/libshp.a and the headers of some local non-Cygwin
version of shapelib.  That inconsistency obviously caused no trouble
for your current tests, but it is an "accident waiting to happen"
which might occur any time you upgrade the Cygwin version of shapelib.

A Cygwin package search reveals there is no Cygwin package (at least
for up-to-date Cygwin) that includes libshp.a.  So I wonder if
/usr/lib/libshp.a above is from some older version of Cygwin?

Also, the relevant header file being searched for is called
shapefil.h, and that (and /usr/lib/libshp.dll.a which is the relevant
Cygwin shapefile library that you should have found above) should be
installed as part of the libshp-devel-1.3.0-1 package.

Anyhow, I suspect this issue will go away once you install the
libshp-devel-1.3.0-1 Cygwin package (which should automatically
get rid of the above /usr/lib/libshp.a if that is from some
previous version of Cygwin).

This may or may not be relevant to the above issue, but I notice in
comprehensive_env.out that your PATH variable includes /usr/local/bin
which significantly affects CMake find capabilities, i.e., in general,
if a PATH component is PREFIX/bin, CMake will search other standard
locations, (e.g., PREFIX/include) associated with that PREFIX for
include files (and similarly for libraries).  Anyhow, you only want to
depend on pure Cygwin software for these tests, so I suggest you
remove /usr/local/bin from your PATH for all subsequent Cygwin tests.

In sum, your Fortran test report is encouraging for this platform, but
I will wait for your next Cygwin test (of my latest Fortran commit)
with the parallel make and ctest options dropped, and this shapelib
and /usr/local/bin issue fixed before posting your Cygwin
Fortran-constrained comprehensive test reports to our Wiki.

2. MinGW-w64/MSYS2

After unpacking your report tarball, I didn't spot anything unusual in
your comprehensive test script arguments.  For example, there is no
parallel build or ctest option which is correct for this platform (and
also Cygwin, see above comment).

Furthermore,
comprehensive_test.sh.out showed no errors; and

grep -i error */*/output_tree/*.out

and

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

gave perfect results.

However, shared/noninteractive/output_tree/cmake.out showed that
libqhull was missing which adds some important core capabilities to
PLplot. If you look at the (dated) package list at
 MinGW-w64/MSYS2 does
include a qhull-related package.  So you should install the latest
version of that package to address this issue.  Also, I highly
recommend (if you haven't done so already) you reinstall
MinGW-w64/MSYS2 from scratch following the procedure given in
 to get
access to the latest much-simplified update procedure before
installing PLplot dependencies including the qhull-related package.

Furthermore,

grep local shared/noninteractive/output_tree/cmake.out

found no "local" issue, and no significant warnings appeared
in shared/noninteractive/output_tree/make_noninteractive.out other
than the expected warnings about libqhull-related functionality
being missing.

In sum, your Fortran test report is encouraging on this platform, but
I will wait for your next MinGW-w64/MSYS2 test (of my latest Fortran
commit) with reinstalled MinGW-w64/MSYS2 (if you haven't done that
already) and the qhull-related package installed, before posting your
MinGW-w64/MSYS2 Fortran-constrained comprehensive test reports to our
Wiki.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victo

Re: [Plplot-devel] PLplot Fortran bindings

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Thursday, April 28, 2016 11:33 PM
> To: Arjen Markus; PLplot development list
> Subject: RE: [Plplot-devel] PLplot Fortran bindings
>
> Hi Arjen:
>
> On 2016-04-28 08:55- Arjen Markus wrote:
>
> > I made the small change I suggested and the results for Cygwin and
> MinGW64 look fine - see the attached files.
>
> Thanks for those two test report tarballs.  Here is my analysis of those 
> results.
>
> 1. Cygwin
>
> After unpacking your report tarball, I didn't spot anything unusual in your
> comprehensive test script arguments except for
>
> --build_command "make -j4"
> --ctest_command "ctest -j4"
>
> I believe you have sometimes found those parallel options to be problematic 
> for
> Cygwin in the past so I would drop them from now on (even though they caused 
> no
> issues for you for this particular comprehensive test).

I guess this is because there was not all that much to be built: just the C 
library and the Fortran binding plus examples. I have had serious problems with 
parallel builds indeed. So my script to run the full test suite does set the 
build command to "make". Perhaps I should do that for the limited test script 
as well.

>
> Furthermore,
> comprehensive_test.sh.out showed no errors;
>
> grep -i error */*/output_tree/*.out
>
> and
>
> grep -B1 -A3 "Missing examples" */*/output_tree/*.out |less
>
> gave perfect results; and there were no significant warnings in
> shared/noninteractive/output_tree/make_noninteractive.out or
> shared/noninteractive/output_tree/cmake.out.
>
> However, a final check
>
> grep local shared/noninteractive/output_tree/cmake.out
>
> yielded
>
> -- FindShapelib: Found shapelib header directory, /usr/local/include, and 
> library,
> /usr/lib/libshp.a.
>
> indicating a potentially serious inconsistency between the Cygwin location of
> /usr/lib/libshp.a and the headers of some local non-Cygwin version of 
> shapelib.
> That inconsistency obviously caused no trouble for your current tests, but it 
> is an
> "accident waiting to happen"
> which might occur any time you upgrade the Cygwin version of shapelib.
>
> A Cygwin package search reveals there is no Cygwin package (at least for 
> up-to-
> date Cygwin) that includes libshp.a.  So I wonder if /usr/lib/libshp.a above 
> is from
> some older version of Cygwin?
>

No, I think it is the X shape extension, which allows for non-rectangular 
window shapes. Apparently CMake gets confused, but the build is done without 
issues.

> Also, the relevant header file being searched for is called shapefil.h, and 
> that (and
> /usr/lib/libshp.dll.a which is the relevant Cygwin shapefile library that you 
> should
> have found above) should be installed as part of the libshp-devel-1.3.0-1 
> package.
>
> Anyhow, I suspect this issue will go away once you install the
> libshp-devel-1.3.0-1 Cygwin package (which should automatically get rid of the
> above /usr/lib/libshp.a if that is from some previous version of Cygwin).
>
> This may or may not be relevant to the above issue, but I notice in
> comprehensive_env.out that your PATH variable includes /usr/local/bin which
> significantly affects CMake find capabilities, i.e., in general, if a PATH 
> component is
> PREFIX/bin, CMake will search other standard locations, (e.g., PREFIX/include)
> associated with that PREFIX for include files (and similarly for libraries).  
> Anyhow,
> you only want to depend on pure Cygwin software for these tests, so I suggest 
> you
> remove /usr/local/bin from your PATH for all subsequent Cygwin tests.
>

Right, this is part of the Cygwin shell. I will have to remove that segment 
from the PATH variable or else rename that directory.

> In sum, your Fortran test report is encouraging for this platform, but I will 
> wait for
> your next Cygwin test (of my latest Fortran commit) with the parallel make 
> and ctest
> options dropped, and this shapelib and /usr/local/bin issue fixed before 
> posting your
> Cygwin Fortran-constrained comprehensive test reports to our Wiki.
>

Good :)

> 2. MinGW-w64/MSYS2
>
> After unpacking your report tarball, I didn't spot anything unusual in your
> comprehensive test script arguments.  For example, there is no parallel build 
> or
> ctest option which is correct for this platform (and also Cygwin, see above
> comment).
>
> Furthermore,
> comprehensive_test.sh.out showed no errors; and
>
> grep -i error */*/output_tree/*.out
>
> and
>
> grep -B1 -A3 "Missing examples" */*/output_tree/*.out |less
>
> gave perfect results.
>
> However, shared/noninteractive/output_tree/cmake.out showed that libqhull was
> missing which adds some important core capabilities to PLplot. If you look at 
> the
> (dated) package list at  
> MinGW-
> w64/MSYS2 does include a qhull-related package.  So you should install the 
> latest
> version of that package to address this issue.  Also,