plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] PLplot Fortran bindings

[Wadud M. <wad...@na...>]

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:Arj...@de...]
Sent: Thursday, April 28, 2016 9:55 AM
To: Alan W. Irwin <ir...@be...>
Cc: Wadud Miah <wad...@na...>; plp...@li...
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...@be...]
> Sent: Thursday, April 28, 2016 9:32 AM
> To: Arjen Markus
> Cc: Wadud Miah; plp...@li...
> Subject: RE: [Plplot-devel] PLplot Fortran bindings
>
> On 2016-04-28 06:35-0000 Arjen Markus wrote:
>
> > Hi Alan, Wadud,
> >
> >> -----Original Message-----
> >> From: Alan W. Irwin [mailto:ir...@be...]
> >> Sent: Wednesday, April 27, 2016 11:22 PM
> >> To: Wadud Miah
> >> Cc: Arjen Markus; plp...@li...
> >> 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 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.
________________________________________________________________________
This e-mail has been scanned for all viruses by Star.
________________________________________________________________________
________________________________

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is:

Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.



This e-mail has been scanned for all viruses by Microsoft Office 365.

________________________________

Re: [Plplot-devel] PLplot Fortran bindings

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

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...@be...]
> Sent: Thursday, April 28, 2016 9:32 AM
> To: Arjen Markus
> Cc: Wadud Miah; plp...@li...
> Subject: RE: [Plplot-devel] PLplot Fortran bindings
>
> On 2016-04-28 06:35-0000 Arjen Markus wrote:
>
> > Hi Alan, Wadud,
> >
> >> -----Original Message-----
> >> From: Alan W. Irwin [mailto:ir...@be...]
> >> Sent: Wednesday, April 27, 2016 11:22 PM
> >> To: Wadud Miah
> >> Cc: Arjen Markus; plp...@li...
> >> 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 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] PLplot Fortran bindings

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

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

> Hi Alan, Wadud,
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Wednesday, April 27, 2016 11:22 PM
>> To: Wadud Miah
>> Cc: Arjen Markus; plp...@li...
>> 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
__________________________

Re: [Plplot-devel] PLplot Fortran bindings

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

Hi Alan, Wadud,

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, April 27, 2016 11:22 PM
> To: Wadud Miah
> Cc: Arjen Markus; plp...@li...
> 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.

>
> @Arjen and Wadud: I suspect the kind=4 logic we were using before only worked
> by a historical accident that that particular kind value corresponded for most Fortran
> compilers to the 4-byte integers we desired for these private types.  So I am much
> more comfortable with the present selected_int_kind(9) fix for that situation, but that
> fix does need testing on more than just my (Debian jessie) platform.
>
Quite possibly, something like unit 5 in Fortran being attached to the keyboard and unit 6 to the console. Nothing that is 100% guaranteerd, but so likely that you begin to think it is guaranteed.

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

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] C example 8 changes, and which parts of our API should be propagated to other languages?

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

On 2016-04-27 18:03-0700 Alan W. Irwin wrote:

> [...] gained useful generalized capability for processing 2D arrays in any
> format that is accessible to C (regardless of whether that format is
> efficent or not).  Note that each of our supported languages typically
> has a preferred efficient native method of representing 2D arrays,
> e.g., row-major order in C and row-column order in Fortran (see
> <https://en.wikipedia.org/wiki/Row-major_order> for further details).
> So the above functions can be quite useful in _the implementation_ of
> each of our language bindings to help translate from one implementation
> to another.                                               ^^^^

Ugh. That last "implementation" obscures the whole meaning of the
paragraph.  What I meant to write instead of that particular word was
"2D array representation" which I hope clarifies my meaning.

The problem obviously is that Fortran is my first language instead of
English.  :-)

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] C example 8 changes, and which parts of our API should be propagated to other languages?

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

@Jerry:

This is the heads-up you requested for this commit
(<https://sourceforge.net/p/plplot/plplot/ci/314bae717aff3e1af3cd11cbf650f18c0a33a3ce/>)
concerning C example 8 and use of plsurf3d rather than plfsurf3d there.

@Everybody

Those of you who have been doing recent testing of PLplot should have
noticed that the PostScript differences between Ada
(thick and thin) examples and corresponding C examples are now perfect,
e.g.,

ada
   Missing examples            :
   Differing graphical output  :
   Missing stdout              :
   Differing stdout            : 
adathick
   Missing examples            :
   Differing graphical output  :
   Missing stdout              :
   Differing stdout            :

This satisfying result is thanks to Jerry's recent Ada changes.

During that effort, Jerry effectively asked the question why should
there be plfsurf3d calls in C example 8 but not in example 8 for any
of the other languages? That is known as a "good question".  :-)

Please see the commit message at the above URL for my opinion
concerning that question.

However, there is a larger question here which is relevant because of
David McMahon's patch that I applied in 2010.  As a result of that
change the C functions

plfgriddata,
plfmesh,
plfmeshc,
plfplot3d,
plfplot3dc,
plfplot3dcl,
plfshades,
plfshade1,
plfimagefr,
plfimage,
plfsurf3d, and
plfsurf3dl

gained useful generalized capability for processing 2D arrays in any
format that is accessible to C (regardless of whether that format is
efficent or not).  Note that each of our supported languages typically
has a preferred efficient native method of representing 2D arrays,
e.g., row-major order in C and row-column order in Fortran (see
<https://en.wikipedia.org/wiki/Row-major_order> for further details).
So the above functions can be quite useful in _the implementation_ of
each of our language bindings to help translate from one implementation
to another.

That said, I am strongly of the opinion that we should only support
the preferred efficient native method of representing 2D arrays for
each of our languages other than C.  That is, none of the above
functions should be propagated to our non-C languages and should not
be used in any of our non-C examples.  When I surveyed our C examples,
the only direct use of the above API was in example 8 (i.e., use of
plfsurf3d there) which served as the motivation for the current commit
which (unless the user specifies the C-only -if_plfsurf3d option)
replaces all those calls by the equivalent plsurf3d calls to help give
better guidance as to what part of the C API should be propagated to
our non-C languages.

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] PLplot Fortran bindings

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

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

On 2016-04-27 09:11-0000 Wadud Miah wrote:
[out of original order]
> Using INT32 does require a 2008 compiler and gfortran 4.5 and above
(https://gcc.gnu.org/wiki/GFortran/News#gfortran_4.5), so it makes
sense to use the intrinsic function selected_int_kind instead for now
until Fortran compilers provide the iso_fortran_env intrinsic module.

@Arjen and Wadud: I suspect the kind=4 logic we were using before only
worked by a historical accident that that particular kind value
corresponded for most Fortran compilers to the 4-byte integers we
desired for these private types.  So I am much more comfortable with
the present selected_int_kind(9) fix for that situation, but that fix
does need testing on more than just my (Debian jessie) platform.

> I'm more than happy to try out the latest release of PLplot, but I
am only using a very small subset of the library. I'm using it just
for 2D line graphs.  I can also build PLplot using the NAG compiler
which is one of the most standards conforming compilers available to
ensure PLplot is truly portable to different compilers.

@Wadud:

Your willingness to test our Fortran binding is much appreciated.

Here is the simple cookbook for doing that which internally tests
essentially all our Fortran API against the corresponding C API using
our standard sets of Fortran and C examples.

1. Select the desired C and Fortran compilers and options for those
compilers that you want to test by setting the CC and FC
environment variables, e.g.,

export CC='gcc -O3 -fvisibility=hidden -Wuninitialized'
export FC='gfortran -O3 -Wuninitialized -Wunused'

2. Clone the repository, e.g.,

git clone git://git.code.sf.net/p/plplot/plplot plplot.git

where I assume the name you are going to use for the top-level
directory of the working tree for the repository is "plplot.git".
(Select any name for that directory that you like so long as it doesn't
correspond to any current directory that you have.)  If you have
already cloned the repository, follow the directions in
plplot.git/README.developers for updating your local repository
to the latest master tip version at SourceForge.

3. Run the comprehensive Fortran test:

cd plplot.git
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

4. Evaluate those results:

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

That first grep command should only find

../comprehensive_test_disposeable/nondynamic/noninteractive/output_tree/traditional_clean.out:*_*.txt test.error \
../comprehensive_test_disposeable/shared/noninteractive/output_tree/traditional_clean.out:*_*.txt test.error \
../comprehensive_test_disposeable/static/noninteractive/output_tree/traditional_clean.out:*_*.txt test.error \

and the second grep command should find the 12 instances (for various
build configurations) of the summary of tests to compare PostScript results from our
Fortran examples with corresponding C results.  A perfect result for
such test summaries is

f95
   Missing examples            :
   Differing graphical output  :
   Missing stdout              :
   Differing stdout            :

which indicates in order that there are no missing Fortran examples,
the PostScript results for those examples are identical (except for
the date stamp) with the corresponding C results, and the stdout
exists from the Fortran results and is identical with the
corresponding C stdout result.

5. Send a complete summary of your test to me.  That summary is collected
by the script into the report tarball whose name is

../comprehensive_test_disposeable/comprehensive_test.tar.gz

That report tarball gets overwritten each time you run the script (say
for different Fortran compiler choices) so remember to rename it to
something else to preserve those report results if you are going to
run the script more than once.

If you look at the commit message
<https://sourceforge.net/p/plplot/plplot/ci/3442bac79bf5a5c63a79bcc45cf0de51420dd8a5/>
you will see in the Tested by: paragraphs I followed the above
directions for invoking the script and got perfect results from that. 
That script completed for me in only 7 minutes so running that script
with the same arguments should take a similar amount of time for your
case.

I then summarized my testing results at
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Fortran%20Testing%20Reports>.

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

@Wadud: I would be very happy to post your comprehensive Fortran
testing results in the same place in our Wiki once you sent the report
tarball(s) to me that are generated by setting the CC and FC environment
variables and running the above script with exactly those arguments.

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] PLplot Fortran bindings

[Wadud M. <wad...@na...>]

Hello Alan,

I'm more than happy to try out the latest release of PLplot, but I am only using a very small subset of the library. I'm using it just for 2D line graphs.
I can also build PLplot using the NAG compiler which is one of the most standards conforming compilers available to ensure PLplot is truly portable to different compilers.

Using INT32 does require a 2008 compiler and gfortran 4.5 and above (https://gcc.gnu.org/wiki/GFortran/News#gfortran_4.5), so it makes sense to use the intrinsic function selected_int_kind instead for now until Fortran compilers provide the iso_fortran_env intrinsic module.

There is a good guide on the features of Fortran compilers which is reasonably up to date:

http://www.fortranplus.co.uk/resources/fortran_2003_2008_compiler_support.pdf

It's good that you are dropping the PLINT kind as I personally didn't see a need. I'm sure you are aware, but I would really use the Fortran standard as much as possible to ensure the greatest portability.

Best regards,
Wadud.

-----Original Message-----
From: Alan W. Irwin [mailto:ir...@be...]
Sent: 26 April 2016 18:32
To: Wadud Miah <wad...@na...>; Arjen Markus <arj...@de...>
Cc: plp...@li...
Subject: Re: [Plplot-devel] PLplot Fortran bindings

On 2016-04-26 14:47-0000 Wadud Miah wrote:

> Hello,
>
> I tried building the PLplot library with the NAG Fortran compiler and noticed something unusual in the Fortran code. In plplot_types.f90 the kind constants are declared as:
>
>
>
>   integer, parameter :: plint  = 4
>
>   integer, parameter :: plunicode  = 4
>
>
>
> These are not portable and neither are part of the standard. To make it portable and adhere to the Fortran standard, use:
>
>
>
>  integer, parameter :: plint = selected_int_kind(9)
>
>  integer, parameter :: plunicode = selected_int_kind(9)
>
>
>
> Or even better:
>
>
>
>  use, intrinsic :: iso_fortran_env
>
>
>
>  integer, parameter :: plint = INT32
>
>  integer, parameter :: plunicode = INT32
>

Hi Wadud:

For your information, Arjen and I have finished a major rewrite of our
fortran binding, and we are quite pleased with the result which is
much more powerful than our old binding and passes all of the tests we
have been able to throw at it.  However, it isn't quite ready for
naive PLplot Fortran users to try until I have finished updating the
relevant documentation.  But once I am finished with that task, I will
be asking those PLplot users who are interested in Fortran to give
that new Fortran binding a try to make sure there are no obvious
problems with it before we make it part of our forthcoming release. If
you want to try out that binding early, then git clone our master
branch, and pay attention to the Fortran bits of our (forthcoming)
release notes, README.release which documents the changes from our old
binding.

I just looked at that new binding, and the same kind=4 issue you noted
for the old binding occurs for private_plint, private_plunicode, and
private_plbool for the new binding as well.  Note, however, the
semantics are different.  These private types are all designed to
match the C types reasonably well for internal purposes, but they are
not types that are available to users who just need to use the default
integer type for arguments equivalent to the C types PLINIT, and
PLUNICODE, and the default logical type for arguments equivalent to the
C type PLBOOL.

Defining private_plint, private_plunicode, and private_plbool to 4 is
a leftover from the days when Fortran compilers tended to not be
compliant with modern Fortran standards, and the web advice then was
to use kind=4 rather than something more complex because of that issue. And
it appears that crude approach still works. However, I would be happy
to change to something more standards compliant, _IF_ we could be
assured it was supported by most/all Fortran compilers.

@Arjen: Do you agree we should move to using selected_int_kind(9) in
the new binding for private_plint, private_plunicode, and
private_plbool in conformity with Wuhad's first idea?  According to
the gfortran documentation, that function was first introduced with
the Fortran 95 standard so surely by now (20 years later!) most
Fortran compilers support that function by default (i.e., without
requiring any special Fortran compiler options).

@Wuhad:

Your second idea of using INT32 rather than selected_int_kind(9) is
likely a good one for the future, but for now I don't think we should
use it since according to
<http://fortranwiki.org/fortran/show/iso_fortran_env> INT32 was only
introduced in the Fortran 2008 standard, and we would like to stick to
Fortran 2003 in our new Fortran binding as much as possible to enhance
our chances that the PLplot Fortran binding will work with most
Fortran compilers.

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
__________________________

________________________________________________________________________
This e-mail has been scanned for all viruses by Star.
________________________________________________________________________
________________________________


The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is:

Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.



This e-mail has been scanned for all viruses by Microsoft Office 365.

________________________________

[Plplot-devel] Substantial changes to pl_create_tempfile and pl_create_tempfifo

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

A windows user "DrO" has recently discovered issues with the
pl_create_tempfile function.  (See the discussion in support request
#39 "Otherwise working PLPlot examples dont work on Win7/64").

I have tried to address those issues (after I got the OK for my ideas
from Andrew who was the originator of this code ) with commit 62b5e52
which constitutes a fairly substantial rewrite of both
pl_create_tempfile and pl_create_tempfifo (that latter function is
required by the tk device). PLplot doesn't work at all unless
pl_create_tempfile works so I used pretty extensive testing with
valgrind for both the svg and tk devices to validate my commit (for
details of that testing see the commit message). However, this testing
has a major limitation in that it has only been done on my particular
Linux platform (Debian jessie) at this time.

@Arjen, Phil, Hazen, and Greg:
I would very much appreciate further testing of this commit on the
MSVC, Cygwin, and MinGW-w64/MSYS2 Windows platforms that are available
to you to make sure I haven't introduced any issues for those
platforms.

@Others here:
Further testing on Linux and Mac OS X would also be appropriate.

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] PLplot Fortran bindings

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

On 2016-04-26 14:47-0000 Wadud Miah wrote:

> Hello,
>
> I tried building the PLplot library with the NAG Fortran compiler and noticed something unusual in the Fortran code. In plplot_types.f90 the kind constants are declared as:
>
>
>
>   integer, parameter :: plint  = 4
>
>   integer, parameter :: plunicode  = 4
>
>
>
> These are not portable and neither are part of the standard. To make it portable and adhere to the Fortran standard, use:
>
>
>
>  integer, parameter :: plint = selected_int_kind(9)
>
>  integer, parameter :: plunicode = selected_int_kind(9)
>
>
>
> Or even better:
>
>
>
>  use, intrinsic :: iso_fortran_env
>
>
>
>  integer, parameter :: plint = INT32
>
>  integer, parameter :: plunicode = INT32
>

Hi Wadud:

For your information, Arjen and I have finished a major rewrite of our
fortran binding, and we are quite pleased with the result which is
much more powerful than our old binding and passes all of the tests we
have been able to throw at it.  However, it isn't quite ready for
naive PLplot Fortran users to try until I have finished updating the
relevant documentation.  But once I am finished with that task, I will
be asking those PLplot users who are interested in Fortran to give
that new Fortran binding a try to make sure there are no obvious
problems with it before we make it part of our forthcoming release. If
you want to try out that binding early, then git clone our master
branch, and pay attention to the Fortran bits of our (forthcoming)
release notes, README.release which documents the changes from our old
binding.

I just looked at that new binding, and the same kind=4 issue you noted
for the old binding occurs for private_plint, private_plunicode, and
private_plbool for the new binding as well.  Note, however, the
semantics are different.  These private types are all designed to
match the C types reasonably well for internal purposes, but they are
not types that are available to users who just need to use the default
integer type for arguments equivalent to the C types PLINIT, and
PLUNICODE, and the default logical type for arguments equivalent to the
C type PLBOOL.

Defining private_plint, private_plunicode, and private_plbool to 4 is
a leftover from the days when Fortran compilers tended to not be
compliant with modern Fortran standards, and the web advice then was
to use kind=4 rather than something more complex because of that issue. And
it appears that crude approach still works. However, I would be happy
to change to something more standards compliant, _IF_ we could be
assured it was supported by most/all Fortran compilers.

@Arjen: Do you agree we should move to using selected_int_kind(9) in
the new binding for private_plint, private_plunicode, and
private_plbool in conformity with Wuhad's first idea?  According to
the gfortran documentation, that function was first introduced with
the Fortran 95 standard so surely by now (20 years later!) most
Fortran compilers support that function by default (i.e., without
requiring any special Fortran compiler options).

@Wuhad:

Your second idea of using INT32 rather than selected_int_kind(9) is
likely a good one for the future, but for now I don't think we should
use it since according to
<http://fortranwiki.org/fortran/show/iso_fortran_env> INT32 was only
introduced in the Fortran 2008 standard, and we would like to stick to
Fortran 2003 in our new Fortran binding as much as possible to enhance
our chances that the PLplot Fortran binding will work with most
Fortran compilers.

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] PLplot Fortran bindings

[Wadud M. <wad...@na...>]

Hello,

I tried building the PLplot library with the NAG Fortran compiler and noticed something unusual in the Fortran code. In plplot_types.f90 the kind constants are declared as:



   integer, parameter :: plint  = 4

   integer, parameter :: plunicode  = 4



These are not portable and neither are part of the standard. To make it portable and adhere to the Fortran standard, use:



  integer, parameter :: plint = selected_int_kind(9)

  integer, parameter :: plunicode = selected_int_kind(9)



Or even better:



  use, intrinsic :: iso_fortran_env



  integer, parameter :: plint = INT32

  integer, parameter :: plunicode = INT32



Best regards,
Wadud.

-----------------------------------
Dr. Wadud Miah
Computational Scientist
Numerical Algorithms Group
01865 518035


________________________________

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is:

Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.



This e-mail has been scanned for all viruses by Microsoft Office 365.

________________________________

[Plplot-devel] 1st Call For Papers - 23rd Annual Tcl/Tk Conference (Tcl'2016)

[<aku...@sh...>]

Hello plplot-devel, fyi ...

23rd Annual Tcl/Tk Conference (Tcl'2016)
http://www.tcl.tk/community/tcl2016/

November 14 - 18, 2016
Crowne Plaza Houston River Oaks
2712 Southwest Freeway, 77098
Houston, Texas, USA

Important Dates:

Abstracts and proposals due   September 12, 2016
Notification to authors       September 19, 2016
WIP and BOF reservations open August 22, 2016
Author materials due          October 24, 2016
Tutorials Start               November 14, 2016
Conference starts             November 16, 2016

Email Contact:                tcl...@go...

Submission of Summaries

Tcl/Tk 2016 will be held in Houston, Texas, USA from November 14, 2016 to November 18, 2016.

The program committee is asking for papers and presentation proposals
from anyone using or developing with Tcl/Tk (and extensions). Past
conferences have seen submissions covering a wide variety of topics
including:

* Scientific and engineering applications
* Industrial controls
* Distributed applications and Network Managment
* Object oriented extensions to Tcl/Tk
* New widgets for Tk
* Simulation and application steering with Tcl/Tk
* Tcl/Tk-centric operating environments
* Tcl/Tk on small and embedded devices
* Medical applications and visualization
* Use of different programming paradigms in Tcl/Tk and proposals for new
  directions.
* New areas of exploration for the Tcl/Tk language

Submissions should consist of an abstract of about 100 words and a
summary of not more than two pages, and should be sent as plain text
to tcl...@go... no later than September 12, 2016. Authors of accepted
abstracts will have until October 24, 2016 to submit their final
paper for the inclusion in the conference proceedings. The proceedings
will be made available on digital media, so extra materials such as
presentation slides, code examples, code for extensions etc. are
encouraged.

Printed proceedings will be produced as an on-demand book at lulu.com

The authors will have 30 minutes to present their paper at
the conference.

The program committee will review and evaluate papers according to the
following criteria:

* Quantity and quality of novel content
* Relevance and interest to the Tcl/Tk community
* Suitability of content for presentation at the conference

Proposals may report on commercial or non-commercial systems, but
those with only blatant marketing content will not be accepted.

Application and experience papers need to strike a balance between
background on the application domain and the relevance of Tcl/Tk to
the application. Application and experience papers should clearly
explain how the application or experience illustrates a novel use of
Tcl/Tk, and what lessons the Tcl/Tk community can derive from the
application or experience to apply to their own development efforts.

Papers accompanied by non-disclosure agreements will be returned to
the author(s) unread. All submissions are held in the highest
confidentiality prior to publication in the Proceedings, both as a
matter of policy and in accord with the U. S. Copyright Act of 1976.

The primary author for each accepted paper will receive registration
to the Technical Sessions portion of the conference at a reduced rate.

Other Forms of Participation

The program committee also welcomes proposals for panel discussions of
up to 90 minutes. Proposals should include a list of confirmed
panelists, a title and format, and a panel description with position
statements from each panelist. Panels should have no more than four
speakers, including the panel moderator, and should allow time for
substantial interaction with attendees. Panels are not presentations
of related research papers.

Slots for Works-in-Progress (WIP) presentations and Birds-of-a-Feather
sessions (BOFs) are available on a first-come, first-served basis
starting in August 22, 2016. Specific instructions for reserving WIP
and BOF time slots will be provided in the registration information
available in August 22, 2016. Some WIP and BOF time slots will be held open
for on-site reservation. All attendees with an interesting work in
progress should consider reserving a WIP slot.

Registration Information

More information on the conference is available the conference Web
site (http://www.tcl.tk/community/tcl2016/) and will be published on
various Tcl/Tk-related information channels.

To keep in touch with news regarding the conference and Tcl events in
general, subscribe to the tcl-announce list. See:
http://code.activestate.com/lists/tcl-announce to subscribe to the
tcl-announce mailing list.


Conference Committee

   * Andreas Kupries Hewlett Packard Enterprise
   * Arjen Markus    Deltares
   * Brian Griffin   Mentor Graphics
   * Clif Flynt      Noumena Corp
   * Gerald Lester   KnG Consulting LLC
   * Joe Mistachkin  Mistachkin Systems
   * Ronald Fox      CAEN Technologies
                     NSCL @ Michigan State University

Contact Information     tcl...@go...

Tcl'2016 would like to thank those who are sponsoring the conference:

   * Mentor Graphics
   * Tcl Community Association

Re: [Plplot-devel] Discussion about building PLplot on Windows - comp.lang.fortran

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

Hi everyone,



FYI, Walt Brainerd (the Fortran Company) published an announcement of their Fortran tools 6.0, which now contains the PLplot libraries - https://groups.google.com/forum/?hl=nl#!topic/comp.lang.fortran/A9Zy3DpqXkI.



Regards,



Arjen



From: Arjen Markus
Sent: Tuesday, March 29, 2016 4:45 PM
To: PLplot development list
Subject: Discussion about building PLplot on Windows - comp.lang.fortran


Hi everyone,



I am currently involved in a discussion about building PLplot for Fortran programs under Windows. It may be that we need to clarify things a lot more.



See: https://groups.google.com/forum/?hl=nl#!topic/comp.lang.fortran/NIJssR9Axj8



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 Fortran on MinGW-w64

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> The openwalnut project
> <http://www.openwalnut.org/projects/openwalnut/wiki/InstallMSYS2>
> uses the form
>
> pacman -S mingw64-w64-x86_64-qhull-git
>
> so I would always stick with that form for packages in that particular repository.
>
> But since that form is not working, I wonder if you carefully followed the detailed
> install directions at
> <https://sourceforge.net/p/msys2/wiki/MSYS2 installation/<https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/>> concerning the update-
> core script?  That URL does seem to imply that if you do not use that script, that
> subsequent installation of packages using "pacman -S" is going to fail.  Anyhow, if
> there is any question that you have not been using update-core, I think you
> probably need to reinstall.
>
That is the first time I heard/read about update-core. I will have to look into this (will be several days before I have the opportunity, I am afraid)

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 Fortran on MinGW-w64

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

On 2016-03-29 09:58-0000 Arjen Markus wrote:

> Hi Alan,
>
> Alas, ctest failed and the script got stuck, so I had to kill it. The problem is presumably that the tests are run in parallel (-j4) and I have had serious problems with parallel make on Cygwin and MinGW. See the attached output file.
>
> I will retry with ctest in a serial mode.
>
> ---
> Indeed, setting the ctest command to "ctest" did the trick, see the attached tarball.

Hi Arjen:

This latest result is quite encouraging. Everything looks good (no
configuration, build, run-time, or PostScript difference issues) in
that report except for your current problem with installing the
mingw-w64-x86_64-qhull-git package. See my previous post for a
suggestion (complete reinstall following the detailed instructions
given at https://sourceforge.net/p/msys2/wiki/MSYS2 installation/ and
continuing to follow those instructions especially with regard to
running the update-core script) for dealing with that issue.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] comprehensive testing results Fortran on MinGW-w64

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

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

>> 3. From shared/noninteractive/output_tree/cmake.out (which you should always
>> check for WARNING messages to see if anything critical is missing), there is a
>> WARNING concerning not finding libqhull.  That issue severely limits the plgriddata
>> algorithm possibilities. I suggest you install mingw64/mingw-w64-x86_64-qhull-git
>> (taken from the last package list you sent me) to attempt to address this issue.
>>
>> I would appreciate you running one more Fortran-only comprehensive test on your
>> MinGW-w64/MSYS2 platform with these 3 issues addressed.
>>
> Well, that has failed. Qhull is listed (pacman -Ss shows two packages, one for MinGW32 and one for MinGW64), but installing it via any of the following failed - "target not found":
>
> pacman -S qhull
>
> pacman -S mingw64-w64-x86_64-qhull-git
>
> pacman -S qhull-git
>
> pacman -S mingw64/mingw64-w64-x86_64-qhull-git

The openwalnut project 
<http://www.openwalnut.org/projects/openwalnut/wiki/InstallMSYS2>
uses the form

pacman -S mingw64-w64-x86_64-qhull-git

so I would always stick with that form for packages in that particular
repository.

But since that form is not working, I wonder if you carefully followed
the detailed install directions at
<https://sourceforge.net/p/msys2/wiki/MSYS2 installation/> concerning
the update-core script?  That URL does seem to imply that if you do
not use that script, that subsequent installation of packages using
"pacman -S" is going to fail.  Anyhow, if there is any question that
you have not been using update-core, I think you probably need to
reinstall.

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 Fortran on MinGW-w64

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

On 2016-03-29 09:58-0000 Arjen Markus wrote:

> Hi Alan,
>
> Alas, ctest failed and the script got stuck, so I had to kill it. The problem is presumably that the tests are run in parallel (-j4) and I have had serious problems with parallel make on Cygwin and MinGW. See the attached output file.
>
> I will retry with ctest in a serial mode.
>
> ---
> Indeed, setting the ctest command to "ctest" did the trick, see the attached tarball.

Hi Arjen:

I think it would be worthwhile for you to report both the parallel
make issue and the parallel ctest issue that you have encountered to
the MSYS2 list.  I cannot even make an informed guess whether those
two issues are related or not since as far as I know the ctest
application does not use "make" facilities for implementing parallel
ctests.  But maybe the MSYS2 developers can advise you whether both
ctest and make (I would advise you to mention the exact package names
including version numbers that you are using for both in your MSYS2
mailing list post) use a common facility that has a known bug on
MinGW-w64/MSYS2?

More later concerning your actual working "unparallel" result.

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] Discussion about building PLplot on Windows - comp.lang.fortran

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

Hi everyone,



I am currently involved in a discussion about building PLplot for Fortran programs under Windows. It may be that we need to clarify things a lot more.



See: https://groups.google.com/forum/?hl=nl#!topic/comp.lang.fortran/NIJssR9Axj8



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 Fortran on MinGW-w64

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

Hi Alan,


From: Arjen Markus
Sent: Tuesday, March 29, 2016 11:28 AM
To: Arjen Markus; Alan W. Irwin
Cc: PLplot development list
Subject: RE: [Plplot-devel] comprehensive testing results Fortran on MinGW-w64

Hi Alan,

Alas, ctest failed and the script got stuck, so I had to kill it. The problem is presumably that the tests are run in parallel (-j4) and I have had serious problems with parallel make on Cygwin and MinGW. See the attached output file.

I will retry with ctest in a serial mode.

---
Indeed, setting the ctest command to "ctest" did the trick, see the attached tarball.

Regards,

Arjen

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

Re: [Plplot-devel] comprehensive testing results Fortran on MinGW-w64

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

Hi Alan,



Alas, ctest failed and the script got stuck, so I had to kill it. The problem is presumably that the tests are run in parallel (-j4) and I have had serious problems with parallel make on Cygwin and MinGW. See the attached output file.

I will retry with ctest in a serial mode.



From: Arjen Markus [mailto:Arj...@de...]
Sent: Tuesday, March 29, 2016 9:36 AM
To: Alan W. Irwin
Cc: PLplot development list
Subject: Re: [Plplot-devel] comprehensive testing results Fortran on MinGW-w64


Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> However, there are still some remaining issues with this Fortran-only test on your
> MinGW-w64/MSYS2 platform.
>
> 1. Your comprehensive_test.sh.out result shows the following WARNING:
>
> WARNING: git not on PATH so cannot determine if SOURCE_TREE = /d/plplot-
> svn/plplot-git is a git repository or not
>
I now have git installed for MinGW-w64/MSYS2 - via "pacman -S msys/git"

(pacman -Ss git shows a whole bunch of packages that come via a git repository, or at least that is my interpretation)

>
> 2. From the comprehensive_test.sh.out result (which you should always check for
> "no" options to make sure you have not overly constrained the test in some way) it
> appears you are still using the --do_ctest no option when running the
> comprehensive_test.sh script.

Argh, missed that bit - corrected.

>
> 3. From shared/noninteractive/output_tree/cmake.out (which you should always
> check for WARNING messages to see if anything critical is missing), there is a
> WARNING concerning not finding libqhull.  That issue severely limits the plgriddata
> algorithm possibilities. I suggest you install mingw64/mingw-w64-x86_64-qhull-git
> (taken from the last package list you sent me) to attempt to address this issue.
>
> I would appreciate you running one more Fortran-only comprehensive test on your
> MinGW-w64/MSYS2 platform with these 3 issues addressed.
>
Well, that has failed. Qhull is listed (pacman -Ss shows two packages, one for MinGW32 and one for MinGW64), but installing it via any of the following failed - "target not found":

pacman -S qhull

pacman -S mingw64-w64-x86_64-qhull-git

pacman -S qhull-git

pacman -S mingw64/mingw64-w64-x86_64-qhull-git

I will run the tests without qhull. I should probably ask about this on the MinGW list.

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.

Re: [Plplot-devel] comprehensive testing results Fortran on MinGW-w64

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> However, there are still some remaining issues with this Fortran-only test on your
> MinGW-w64/MSYS2 platform.
>
> 1. Your comprehensive_test.sh.out result shows the following WARNING:
>
> WARNING: git not on PATH so cannot determine if SOURCE_TREE = /d/plplot-
> svn/plplot-git is a git repository or not
>
I now have git installed for MinGW-w64/MSYS2 - via "pacman -S msys/git"

(pacman -Ss git shows a whole bunch of packages that come via a git repository, or at least that is my interpretation)

>
> 2. From the comprehensive_test.sh.out result (which you should always check for
> "no" options to make sure you have not overly constrained the test in some way) it
> appears you are still using the --do_ctest no option when running the
> comprehensive_test.sh script.

Argh, missed that bit - corrected.

>
> 3. From shared/noninteractive/output_tree/cmake.out (which you should always
> check for WARNING messages to see if anything critical is missing), there is a
> WARNING concerning not finding libqhull.  That issue severely limits the plgriddata
> algorithm possibilities. I suggest you install mingw64/mingw-w64-x86_64-qhull-git
> (taken from the last package list you sent me) to attempt to address this issue.
>
> I would appreciate you running one more Fortran-only comprehensive test on your
> MinGW-w64/MSYS2 platform with these 3 issues addressed.
>
Well, that has failed. Qhull is listed (pacman -Ss shows two packages, one for MinGW32 and one for MinGW64), but installing it via any of the following failed - "target not found":

pacman -S qhull

pacman -S mingw64-w64-x86_64-qhull-git

pacman -S qhull-git

pacman -S mingw64/mingw64-w64-x86_64-qhull-git

I will run the tests without qhull. I should probably ask about this on the MinGW list.

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 Fortran on MinGW-w64

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

On 2016-03-25 08:50-0000 Arjen Markus wrote:

> Please find the results of the Fortran test on MinGW-w64 in the attachment. This was quite fast, of course, only examining one single language, but still: it is looking very good.

Hi Arjen:

Thanks for your on-going help with MinGW-w64/MSYS2 platform testing.

I agree there are no run-time errors (as before) and the PostScript difference
results look perfect (as before). I was also glad to see (from running

grep '\.exe' shared/noninteractive/build_tree/CMakeCache.txt

) that MinGW-w64/MSYS2 versions of executables were found for
everything which is a nice forward step.

However, there are still some remaining issues with this Fortran-only
test on your MinGW-w64/MSYS2 platform.

1. Your comprehensive_test.sh.out result shows the following WARNING:

WARNING: git not on PATH so cannot determine if SOURCE_TREE = 
/d/plplot-svn/plplot-git is a git repository or not

Once you address this issue, then comprehensive_test.sh.out should
be able to report the exact git commit id that you are testing which
is obviously useful information to have.

You could address this issue a number of ways, but I think the best
way would be to install the MinGW-w64/MSYS2 package "msys/git".  I
found that package name in the package list you sent me, and it
appears there is no equivalent mingw64/mingw-w64-x86_64 package for
git. Note, installation of this git version on your MinGW-w64/MSYS2
platform should only affect how the script identifies the git commit
id, and does not affect the PLplot build in any other way.

2. From the comprehensive_test.sh.out result (which you should always
check for "no" options to make sure you have not overly constrained
the test in some way) it appears you are still using the --do_ctest no option when
running the comprehensive_test.sh script.

3. From shared/noninteractive/output_tree/cmake.out (which you should
always check for WARNING messages to see if anything critical is
missing), there is a WARNING concerning not finding libqhull.  That
issue severely limits the plgriddata algorithm possibilities. I
suggest you install mingw64/mingw-w64-x86_64-qhull-git (taken from the
last package list you sent me) to attempt to address this issue.

I would appreciate you running one more Fortran-only comprehensive
test on your MinGW-w64/MSYS2 platform with these 3 issues addressed.

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 Fortran on MinGW-w64

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

Hi Alan,



Please find the results of the Fortran test on MinGW-w64 in the attachment. This was quite fast, of course, only examining one single language, but still: it is looking very good.



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...]
> Sent: Thursday, March 24, 2016 7:08 PM
> To: Arjen Markus
> Cc: Greg Jung; PLplot development list
> Subject: RE: [Plplot-devel] comprehensive testing results on Cygwin
>
>
> Anyhow, your next actions on this platform should be to do the
> following:
>
> 1. Update your package list (in case there are a few more changes since you did
> that earlier today) and also upgrade your whole
> MinGW-w64/MSYS2 system using the "pacman -Syu" command (taken as an
> example right out of the pacman man page).
>
Did so already - I had to restart the shell after that as nothing worked anymore, but now I do have CMake 3.4.1.

> 2. Assuming 1. works, then run Fortran-only comprehensive testing.


That ought to be easy, starting that rightaway.

>
> 3. Assuming 2. works, install all PLplot-relevant packages for the platform.
>

Clear enough

> 4. Assuming 3. works, do a minimally constrained comprehensive test with some
> iteration with 3 depending on what complaints about missing packages you get from
> cmake.out.


Clear too.

...

>
> If you do something similar yourself with "pacman -Syu" every month or so you
> should follow that up by a minimally constrained comprehensive test of PLplot to
> make sure everything is OK both with all components of PLplot and your MinGW-
> w64/MSYS2 platform.  And similarly with Cygwin.
>
A frequency of once a month feels "right". The Cygwin setup program works along a different philosophy than MinGW-w64's pacman, but I am getting used to both.

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

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

On 2016-03-24 10:22-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
> That certainly did the trick. See the attached list of packages after running "pacman -Sy"

Excellent news, and thanks for that list.

If you look for "installed" in that list, you will find that (as you
said before) you are out of date on quite a few of the packages
including cmake.  Which simply verifies MinGW-w64/MSYS2 is a rolling
release much like Cygwin and Debian testing in this regard where some
new versions of a relatively small subset of the packages tend to be
available every day.

Anyhow, your next actions on this platform should be to do the
following:

1. Update your package list (in case there are a few more changes
since you did that earlier today) and also upgrade your whole
MinGW-w64/MSYS2 system using the "pacman -Syu" command (taken as an
example right out of the pacman man page).

2. Assuming 1. works, then run Fortran-only comprehensive testing.

3. Assuming 2. works, install all PLplot-relevant packages for the platform.

4. Assuming 3. works, do a minimally constrained comprehensive test with
some iteration with 3 depending on what complaints about missing
packages you get from cmake.out.

The next question is how often should you do a system upgrade? When I used to run
Debian testing, I got quite neurotic about keeping absolutely up to
date so I typically ran "apt-get dist-upgrade" daily for a couple of
years often with 10-30 or more packages being upgraded each day. There
were something like 2000 packages installed in total.  On two
different occasions a packaging issue for the lastest version of one
of those ~2000 packages caused a problem that I had to temporarily
work around until the Debian package maintainer fixed their packaging
bug. But except for those two occasions the Debian packaging was
meticulous which demonstrates the amazing capabilities of the
ego-driven Debian packaging volunteers.  However, through lack of
experience I cannot give you similar assurances about the care that is
taken by by those who do Cygwin and MinGW-w64/MSYS2 packaging so you
will likely want to upgrade on a much longer interval than once per
day.  At the same time I wouldn't let it slide too long so you might
want to try upgrading your platform once every month or so including
capturing all pacman output to a file so you keep a clear record
of everything pacman has done.

Debian jessie is also something of a rolling release, but without the
extreme flux of packaging changes you get with Debian testing.  So
to keep meticulous records of what is done by apt-get I
currently run

cd <directory where I am keeping logs of apt-get output>
apt-get update
apt-get dist-upgrade |& tee -a <unique_file_name>

once per month or so, where unique_file_name is the day's date in iso
format, e.g., 20160324.  In bash, the |& pipeline symbol concatanates
stdout and stderr into the pipeline.  Also, the unix tee -a command
appends the results to the named file and also allows them to be
displayed on your terminal which is a very convenient way of keeping
an exact record while also watching what is happening and answering
any questions that the dist-upgrade wants me to answer.

If you do something similar yourself with "pacman -Syu" every month or
so you should follow that up by a minimally constrained comprehensive
test of PLplot to make sure everything is OK both with all components
of PLplot and your MinGW-w64/MSYS2 platform.  And similarly with
Cygwin.

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
__________________________