Re: [Plplot-devel] PLplot Fortran bindings

[Arjen Markus]

Hi Wadud,



I guess at this moment it is my turn - I was also reminded of a small omission 
in the current code regarding the use of IMPLICIT NONE. It is not propagated 
from the module to the interface blocks. Therefore I want to add that statement 
everywhere where that is appropriate, just to make extra sure that no argument 
has been left implicitly declared.



The next interesting bit is to get the examples to pass with the NAG compiler 
and for that I will gladly accept your offer :).



Regards,



Arjen



From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Tuesday, May 10, 2016 5:06 PM
To: Arjen Markus; Alan W. Irwin
Cc: plplot-devel@lists.sourceforge.net
Subject: RE: [Plplot-devel] PLplot Fortran bindings

Hi Arjen,

Ah, yes, I see the subroutine being passed as an argument - I totally missed 
that. So what would you exactly like me to do  now? I was wondering whether you 
would like a trial version of the NAG Fortran compiler which may make it easier 
:-) Let me know if you would like a NAG Fortran trial licence and I can arrange 
one for you.

Best regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 10 May 2016 15:41
To: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>; Alan W. 
Irwin <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Wadud,



Well, actually it is: look at lines 3441-3487 for instance:

The label fill() is associated with c_plfill (line 3480) and then that label is 
passed as an argument to interface_plshade (line 3499). The label 
interface_plfill() is used as a direct call at line 1518.



I am positive that this will work, but that is what the tests/examples are 
there for. I imagine that the NAG compiler may find one or two issues in that 
code as well, so I would like to suggest you to have the examples built too:



cmake ... -DBUILD_TEST=ON



Regards,



Arjen


From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Tuesday, May 10, 2016 4:07 PM
To: Arjen Markus; Alan W. Irwin
Cc: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings

Hi Arjen,

I wasn't suggesting removing the c_plfill C function - I meant that its 
interface should be removed as it is not being called. The NAG compiler is 
complaining about the multiple binding labels "c_plfill". This may seem valid, 
but if the fill() subroutine is not being called at all, I don't see the need 
to declare interfaces to it.

If I change the binding label of interface_plfill to "fill", the NAG compiler 
does accept it, but will that call the C fill() function?

Regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 10 May 2016 14:36
To: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>; Alan W. 
Irwin <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Wadud,



Well, the first answer (by Wolfgang Kilian - 
https://groups.google.com/forum/?hl=nl#!topic/comp.lang.fortran/-NYIZX-XZag) to 
my post does support NAG's view. Unless there are strongly opposing replies, I 
think the best way forward is to apply the workaround.



The fill() problem you mention is of a different order. In its current form it 
uses two different labels for the same C routine, but the fill routine is 
actually used, so we cannot simply eliminate it. (You have to look carefully 
though to see where and how ;)). I can see two ways forward:

-   Use the same label consistently, either will do. This is only a small 
change in the source code.

-   Use one interface block for c_plfill - right now the block is repeated 
a number of times, mainly to keep these things as local as possible. (I am not 
entirely sure if we can prevent "leakage" of the C names, if we do that. I 
think that was the background for this set-up.)



If you change the label interface_plfill to fill (or vice versa, that is more 
inline with the rest of the naming scheme), is the code accepted by the NAG 
compiler? If so, I will apply that to the repository. I will be busy the next 
few days, but I will try to incorporate it and do the testing.



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, 

Re: [Plplot-devel] PLplot Fortran bindings

[Wadud Miah]

Hi Arjen,

Ah, yes, I see the subroutine being passed as an argument - I totally missed 
that. So what would you exactly like me to do  now? I was wondering whether you 
would like a trial version of the NAG Fortran compiler which may make it easier 
:-) Let me know if you would like a NAG Fortran trial licence and I can arrange 
one for you.

Best regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 10 May 2016 15:41
To: Wadud Miah <wadud.m...@nag.co.uk>; Alan W. Irwin <ir...@beluga.phys.uvic.ca>
Cc: plplot-devel@lists.sourceforge.net
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Wadud,



Well, actually it is: look at lines 3441-3487 for instance:

The label fill() is associated with c_plfill (line 3480) and then that label is 
passed as an argument to interface_plshade (line 3499). The label 
interface_plfill() is used as a direct call at line 1518.



I am positive that this will work, but that is what the tests/examples are 
there for. I imagine that the NAG compiler may find one or two issues in that 
code as well, so I would like to suggest you to have the examples built too:



cmake ... -DBUILD_TEST=ON



Regards,



Arjen


From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Tuesday, May 10, 2016 4:07 PM
To: Arjen Markus; Alan W. Irwin
Cc: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings

Hi Arjen,

I wasn't suggesting removing the c_plfill C function - I meant that its 
interface should be removed as it is not being called. The NAG compiler is 
complaining about the multiple binding labels "c_plfill". This may seem valid, 
but if the fill() subroutine is not being called at all, I don't see the need 
to declare interfaces to it.

If I change the binding label of interface_plfill to "fill", the NAG compiler 
does accept it, but will that call the C fill() function?

Regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 10 May 2016 14:36
To: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>; Alan W. 
Irwin <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Wadud,



Well, the first answer (by Wolfgang Kilian - 
https://groups.google.com/forum/?hl=nl#!topic/comp.lang.fortran/-NYIZX-XZag) to 
my post does support NAG's view. Unless there are strongly opposing replies, I 
think the best way forward is to apply the workaround.



The fill() problem you mention is of a different order. In its current form it 
uses two different labels for the same C routine, but the fill routine is 
actually used, so we cannot simply eliminate it. (You have to look carefully 
though to see where and how ;)). I can see two ways forward:

-   Use the same label consistently, either will do. This is only a small 
change in the source code.

-   Use one interface block for c_plfill - right now the block is repeated 
a number of times, mainly to keep these things as local as possible. (I am not 
entirely sure if we can prevent "leakage" of the C names, if we do that. I 
think that was the background for this set-up.)



If you change the label interface_plfill to fill (or vice versa, that is more 
inline with the rest of the naming scheme), is the code accepted by the NAG 
compiler? If so, I will apply that to the repository. I will be busy the next 
few days, but I will try to incorporate it and do the testing.



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.

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.


--
Mobile security can be enabling, not merely restricting. Employees

Re: [Plplot-devel] PLplot Fortran bindings

[Arjen Markus]

Hi Wadud,



Well, actually it is: look at lines 3441-3487 for instance:

The label fill() is associated with c_plfill (line 3480) and then that label is 
passed as an argument to interface_plshade (line 3499). The label 
interface_plfill() is used as a direct call at line 1518.



I am positive that this will work, but that is what the tests/examples are 
there for. I imagine that the NAG compiler may find one or two issues in that 
code as well, so I would like to suggest you to have the examples built too:



cmake ... -DBUILD_TEST=ON



Regards,



Arjen



From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Tuesday, May 10, 2016 4:07 PM
To: Arjen Markus; Alan W. Irwin
Cc: plplot-devel@lists.sourceforge.net
Subject: RE: [Plplot-devel] PLplot Fortran bindings

Hi Arjen,

I wasn't suggesting removing the c_plfill C function - I meant that its 
interface should be removed as it is not being called. The NAG compiler is 
complaining about the multiple binding labels "c_plfill". This may seem valid, 
but if the fill() subroutine is not being called at all, I don't see the need 
to declare interfaces to it.

If I change the binding label of interface_plfill to "fill", the NAG compiler 
does accept it, but will that call the C fill() function?

Regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 10 May 2016 14:36
To: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>; Alan W. 
Irwin <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Wadud,



Well, the first answer (by Wolfgang Kilian - 
https://groups.google.com/forum/?hl=nl#!topic/comp.lang.fortran/-NYIZX-XZag) to 
my post does support NAG's view. Unless there are strongly opposing replies, I 
think the best way forward is to apply the workaround.



The fill() problem you mention is of a different order. In its current form it 
uses two different labels for the same C routine, but the fill routine is 
actually used, so we cannot simply eliminate it. (You have to look carefully 
though to see where and how ;)). I can see two ways forward:

-   Use the same label consistently, either will do. This is only a small 
change in the source code.

-   Use one interface block for c_plfill - right now the block is repeated 
a number of times, mainly to keep these things as local as possible. (I am not 
entirely sure if we can prevent "leakage" of the C names, if we do that. I 
think that was the background for this set-up.)



If you change the label interface_plfill to fill (or vice versa, that is more 
inline with the rest of the naming scheme), is the code accepted by the NAG 
compiler? If so, I will apply that to the repository. I will be busy the next 
few days, but I will try to incorporate it and do the testing.



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.
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
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,

I wasn't suggesting removing the c_plfill C function - I meant that its 
interface should be removed as it is not being called. The NAG compiler is 
complaining about the multiple binding labels "c_plfill". This may seem valid, 
but if the fill() subroutine is not being called at all, I don't see the need 
to declare interfaces to it.

If I change the binding label of interface_plfill to "fill", the NAG compiler 
does accept it, but will that call the C fill() function?

Regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 10 May 2016 14:36
To: Wadud Miah <wadud.m...@nag.co.uk>; Alan W. Irwin <ir...@beluga.phys.uvic.ca>
Cc: plplot-devel@lists.sourceforge.net
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Wadud,



Well, the first answer (by Wolfgang Kilian - 
https://groups.google.com/forum/?hl=nl#!topic/comp.lang.fortran/-NYIZX-XZag) to 
my post does support NAG's view. Unless there are strongly opposing replies, I 
think the best way forward is to apply the workaround.



The fill() problem you mention is of a different order. In its current form it 
uses two different labels for the same C routine, but the fill routine is 
actually used, so we cannot simply eliminate it. (You have to look carefully 
though to see where and how ;)). I can see two ways forward:

-   Use the same label consistently, either will do. This is only a small 
change in the source code.

-   Use one interface block for c_plfill - right now the block is repeated 
a number of times, mainly to keep these things as local as possible. (I am not 
entirely sure if we can prevent "leakage" of the C names, if we do that. I 
think that was the background for this set-up.)



If you change the label interface_plfill to fill (or vice versa, that is more 
inline with the rest of the naming scheme), is the code accepted by the NAG 
compiler? If so, I will apply that to the repository. I will be busy the next 
few days, but I will try to incorporate it and do the testing.



Regards,



Arjen


From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Tuesday, May 10, 2016 3:04 PM
To: Arjen Markus; Alan W. Irwin
Cc: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings

Hi again Arjen,

If my comments are valid and you would like to implement my recommendations, 
let me know once that is done and I can recompile PLplot with your changes for 
another sanity check.

The NAG Fortran compiler is very picky, but it is picky for a reason to ensure 
greatest standards compliance and
portability :-)

Regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 10 May 2016 13:30
To: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>; Alan W. 
Irwin <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Wadud,



Thanks for running the example and the issue with fill() - that is probably 
some leftover that was not detected by the compilers I use.



Intriguing question regarding the scope of the import statement. I will post 
this on comp.lang.fortran - some people there know the standard by heart :).



Regards,



Arjen


From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Tuesday, May 10, 2016 2:27 PM
To: Arjen Markus; Alan W. Irwin
Cc: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings

Hi Arjen,

Further to my previous email, I think the import statement has to have scope in 
the inner interface by declaring it in the outer interface. I had a look at the 
Fortran standard and I could not find any statement on this issue. My 
colleagues are adamant that this is part of the standard and I will be 
contacting a member of the Fortran standard (Malcom Cohen) to clarify this.

Another thing the NAG compiler complained about was the interface declaration 
of the external subroutines fill() and interface_plfill() which have the same 
binding label c_plfill in file included_plplot_configured_types.f90. In 
addition, the external subroutine fill() is not called anywhere so I think 
could be removed.

Regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 09 May 2016 20:26
To: Alan W. Irwin <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>; 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Hi Arjen:
>
> You are absolutely right to ask Wadud to try the above simplest possible

Re: [Plplot-devel] PLplot Fortran bindings

[Arjen Markus]

Hi Wadud,



Well, the first answer (by Wolfgang Kilian - 
https://groups.google.com/forum/?hl=nl#!topic/comp.lang.fortran/-NYIZX-XZag) to 
my post does support NAG's view. Unless there are strongly opposing replies, I 
think the best way forward is to apply the workaround.



The fill() problem you mention is of a different order. In its current form it 
uses two different labels for the same C routine, but the fill routine is 
actually used, so we cannot simply eliminate it. (You have to look carefully 
though to see where and how ;)). I can see two ways forward:

-Use the same label consistently, either will do. This is only a small 
change in the source code.

-Use one interface block for c_plfill - right now the block is repeated 
a number of times, mainly to keep these things as local as possible. (I am not 
entirely sure if we can prevent "leakage" of the C names, if we do that. I 
think that was the background for this set-up.)



If you change the label interface_plfill to fill (or vice versa, that is more 
inline with the rest of the naming scheme), is the code accepted by the NAG 
compiler? If so, I will apply that to the repository. I will be busy the next 
few days, but I will try to incorporate it and do the testing.



Regards,



Arjen


From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Tuesday, May 10, 2016 3:04 PM
To: Arjen Markus; Alan W. Irwin
Cc: plplot-devel@lists.sourceforge.net
Subject: RE: [Plplot-devel] PLplot Fortran bindings

Hi again Arjen,

If my comments are valid and you would like to implement my recommendations, 
let me know once that is done and I can recompile PLplot with your changes for 
another sanity check.

The NAG Fortran compiler is very picky, but it is picky for a reason to ensure 
greatest standards compliance and
portability :-)

Regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 10 May 2016 13:30
To: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>; Alan W. 
Irwin <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Wadud,



Thanks for running the example and the issue with fill() - that is probably 
some leftover that was not detected by the compilers I use.



Intriguing question regarding the scope of the import statement. I will post 
this on comp.lang.fortran - some people there know the standard by heart :).



Regards,



Arjen


From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Tuesday, May 10, 2016 2:27 PM
To: Arjen Markus; Alan W. Irwin
Cc: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings

Hi Arjen,

Further to my previous email, I think the import statement has to have scope in 
the inner interface by declaring it in the outer interface. I had a look at the 
Fortran standard and I could not find any statement on this issue. My 
colleagues are adamant that this is part of the standard and I will be 
contacting a member of the Fortran standard (Malcom Cohen) to clarify this.

Another thing the NAG compiler complained about was the interface declaration 
of the external subroutines fill() and interface_plfill() which have the same 
binding label c_plfill in file included_plplot_configured_types.f90. In 
addition, the external subroutine fill() is not called anywhere so I think 
could be removed.

Regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 09 May 2016 20:26
To: Alan W. Irwin <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>; 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Hi Arjen:
>
> You are absolutely right to ask Wadud to try the above simplest possible 
> example
> of importing a type from another module first.
>
> However, another potential issue here is that if the NAG Fortran compiler 
> compiles
>
> import :: private_plflt, PLcGrid
>
> from left to right, then it had no problem with importing plflt_private which 
> is a type
> defined in a very similar manner to PLcGrid.
>

Aha, I overlooked that detail. That is another indication that the NAG compiler 
may be at fault here. Indeed,then it becomes a matter of further extending the 
example.

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 

Re: [Plplot-devel] PLplot Fortran bindings

[Wadud Miah]

Hi again Arjen,

If my comments are valid and you would like to implement my recommendations, 
let me know once that is done and I can recompile PLplot with your changes for 
another sanity check.

The NAG Fortran compiler is very picky, but it is picky for a reason to ensure 
greatest standards compliance and
portability :-)

Regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 10 May 2016 13:30
To: Wadud Miah <wadud.m...@nag.co.uk>; Alan W. Irwin <ir...@beluga.phys.uvic.ca>
Cc: plplot-devel@lists.sourceforge.net
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Wadud,



Thanks for running the example and the issue with fill() - that is probably 
some leftover that was not detected by the compilers I use.



Intriguing question regarding the scope of the import statement. I will post 
this on comp.lang.fortran - some people there know the standard by heart :).



Regards,



Arjen


From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Tuesday, May 10, 2016 2:27 PM
To: Arjen Markus; Alan W. Irwin
Cc: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings

Hi Arjen,

Further to my previous email, I think the import statement has to have scope in 
the inner interface by declaring it in the outer interface. I had a look at the 
Fortran standard and I could not find any statement on this issue. My 
colleagues are adamant that this is part of the standard and I will be 
contacting a member of the Fortran standard (Malcom Cohen) to clarify this.

Another thing the NAG compiler complained about was the interface declaration 
of the external subroutines fill() and interface_plfill() which have the same 
binding label c_plfill in file included_plplot_configured_types.f90. In 
addition, the external subroutine fill() is not called anywhere so I think 
could be removed.

Regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 09 May 2016 20:26
To: Alan W. Irwin <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>; 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Hi Arjen:
>
> You are absolutely right to ask Wadud to try the above simplest possible 
> example
> of importing a type from another module first.
>
> However, another potential issue here is that if the NAG Fortran compiler 
> compiles
>
> import :: private_plflt, PLcGrid
>
> from left to right, then it had no problem with importing plflt_private which 
> is a type
> defined in a very similar manner to PLcGrid.
>

Aha, I overlooked that detail. That is another indication that the NAG compiler 
may be at fault here. Indeed,then it becomes a matter of further extending the 
example.

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.

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.


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

Re: [Plplot-devel] PLplot Fortran bindings

[Wadud Miah]

Hi Arjen,

I tried to read the standards document and got a headache :-) Thanks for 
following it up.

Regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 10 May 2016 13:30
To: Wadud Miah <wadud.m...@nag.co.uk>; Alan W. Irwin <ir...@beluga.phys.uvic.ca>
Cc: plplot-devel@lists.sourceforge.net
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Wadud,



Thanks for running the example and the issue with fill() - that is probably 
some leftover that was not detected by the compilers I use.



Intriguing question regarding the scope of the import statement. I will post 
this on comp.lang.fortran - some people there know the standard by heart :).



Regards,



Arjen


From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Tuesday, May 10, 2016 2:27 PM
To: Arjen Markus; Alan W. Irwin
Cc: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings

Hi Arjen,

Further to my previous email, I think the import statement has to have scope in 
the inner interface by declaring it in the outer interface. I had a look at the 
Fortran standard and I could not find any statement on this issue. My 
colleagues are adamant that this is part of the standard and I will be 
contacting a member of the Fortran standard (Malcom Cohen) to clarify this.

Another thing the NAG compiler complained about was the interface declaration 
of the external subroutines fill() and interface_plfill() which have the same 
binding label c_plfill in file included_plplot_configured_types.f90. In 
addition, the external subroutine fill() is not called anywhere so I think 
could be removed.

Regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 09 May 2016 20:26
To: Alan W. Irwin <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>; 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Hi Arjen:
>
> You are absolutely right to ask Wadud to try the above simplest possible 
> example
> of importing a type from another module first.
>
> However, another potential issue here is that if the NAG Fortran compiler 
> compiles
>
> import :: private_plflt, PLcGrid
>
> from left to right, then it had no problem with importing plflt_private which 
> is a type
> defined in a very similar manner to PLcGrid.
>

Aha, I overlooked that detail. That is another indication that the NAG compiler 
may be at fault here. Indeed,then it becomes a matter of further extending the 
example.

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.

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.


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:

Wilkins

Re: [Plplot-devel] PLplot Fortran bindings

[Arjen Markus]

Hi Wadud,



Thanks for running the example and the issue with fill() - that is probably 
some leftover that was not detected by the compilers I use.



Intriguing question regarding the scope of the import statement. I will post 
this on comp.lang.fortran - some people there know the standard by heart :).



Regards,



Arjen



From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Tuesday, May 10, 2016 2:27 PM
To: Arjen Markus; Alan W. Irwin
Cc: plplot-devel@lists.sourceforge.net
Subject: RE: [Plplot-devel] PLplot Fortran bindings

Hi Arjen,

Further to my previous email, I think the import statement has to have scope in 
the inner interface by declaring it in the outer interface. I had a look at the 
Fortran standard and I could not find any statement on this issue. My 
colleagues are adamant that this is part of the standard and I will be 
contacting a member of the Fortran standard (Malcom Cohen) to clarify this.

Another thing the NAG compiler complained about was the interface declaration 
of the external subroutines fill() and interface_plfill() which have the same 
binding label c_plfill in file included_plplot_configured_types.f90. In 
addition, the external subroutine fill() is not called anywhere so I think 
could be removed.

Regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 09 May 2016 20:26
To: Alan W. Irwin <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>; 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Hi Arjen:
>
> You are absolutely right to ask Wadud to try the above simplest possible 
> example
> of importing a type from another module first.
>
> However, another potential issue here is that if the NAG Fortran compiler 
> compiles
>
> import :: private_plflt, PLcGrid
>
> from left to right, then it had no problem with importing plflt_private which 
> is a type
> defined in a very similar manner to PLcGrid.
>

Aha, I overlooked that detail. That is another indication that the NAG compiler 
may be at fault here. Indeed,then it becomes a matter of further extending the 
example.

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.

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.


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.
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
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,

Further to my previous email, I think the import statement has to have scope in 
the inner interface by declaring it in the outer interface. I had a look at the 
Fortran standard and I could not find any statement on this issue. My 
colleagues are adamant that this is part of the standard and I will be 
contacting a member of the Fortran standard (Malcom Cohen) to clarify this.

Another thing the NAG compiler complained about was the interface declaration 
of the external subroutines fill() and interface_plfill() which have the same 
binding label c_plfill in file included_plplot_configured_types.f90. In 
addition, the external subroutine fill() is not called anywhere so I think 
could be removed.

Regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 09 May 2016 20:26
To: Alan W. Irwin <ir...@beluga.phys.uvic.ca>
Cc: Wadud Miah <wadud.m...@nag.co.uk>; plplot-devel@lists.sourceforge.net
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Hi Arjen:
>
> You are absolutely right to ask Wadud to try the above simplest possible 
> example
> of importing a type from another module first.
>
> However, another potential issue here is that if the NAG Fortran compiler 
> compiles
>
> import :: private_plflt, PLcGrid
>
> from left to right, then it had no problem with importing plflt_private which 
> is a type
> defined in a very similar manner to PLcGrid.
>

Aha, I overlooked that detail. That is another indication that the NAG compiler 
may be at fault here. Indeed,then it becomes a matter of further extending the 
example.

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.

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.


--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
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,

Your simple example failed with the NAG compiler, but worked when I added the 
line (shown in boldface):

subroutine use_transform( transform )
  import :: xyz
interface
subroutine transform( data, result )

I don't know what the standard says on this topic, but I think I would be 
explicit and add the additional import statement so that the user defined data 
type is in scope.

Best regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 09 May 2016 19:50
To: Alan W. Irwin <ir...@beluga.phys.uvic.ca>; Wadud Miah <wadud.m...@nag.co.uk>
Cc: plplot-devel@lists.sourceforge.net
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Wadud,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
>
> Hi Wadud:
>
> Thanks very much for your build test of PLplot using the NAG Fortran compiler.
>
> ... >
> To investigate further why the above logic unexpectedly cannot be compiled 
> with
> the NAG compiler, I strongly suggest you make a small one-file example 
> containing
> a simplified plplot_types module that just defines private_plflt, and plcGrid 
> exactly
> like we do, and which also contains another module that includes the above
> subroutine transform.
> Then if that vastly simplified example also fails to compile you have that 
> example to
> take to the NAG developers concerning a possible bug in their compiler.  Or 
> they
> may respond to your report by saying something like this: "to get that Fortran
> standards compliant code to compile with the NAG compiler, you need xxx flag".
>

I prepared a small example (see below) that is generously accepted by the two 
compilers I have access to. I think it exhibits the characteristics of the code 
that is not accepted by the NAG compiler. The only difference that may be 
important is the fact that it does not contain the ISO_C_BINDING features. If 
this small example is accepted, then I would say it is indeed a problem in the 
NAG compiler.

The alternative is that the example is not accepted and that the NAG compiler 
doesn't like the import through the nesting of interfaces. I would not think 
that the example is non-standard, but there can be subtleties that I am 
overlooking here. That is why it is important to see what the NAG compiler 
comes up with.

Regards,

Arjen

! nested_interface.f90 --

! Attempt to reproduce a problem discovered by Wadud Miah

!

module my_types

implicit none



type xyz

integer :: x, y, z

end type xyz

end module my_types



module my_interfaces

use my_types



implicit none



interface

subroutine use_transform( transform )

interface

subroutine transform( data, result )

import :: xyz

type(xyz) :: data

real  :: result

end subroutine transform

end interface

end subroutine use_transform

end interface

end module my_interfaces
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.


--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
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,

Your suggestion has worked with the NAG Fortran compiler:

subroutine interface_plfcont( lookup, grid, nx, ny, kx, lx, ky, ly, 
clevel, nlevel, transform, data ) &
   bind(c,name='plfcont')
import :: c_ptr
import :: private_plint, private_plflt, PLcGrid

[ ... ]

subroutine transform( x, y, tx, ty, data ) bind(c)
import :: private_plflt, PLcGrid
implicit none

This has removed the error. I will look into the sample code to see how the NAG 
Fortran compiler responds to it.

Thanks,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 09 May 2016 18:23
To: Arjen Markus <arjen.mar...@deltares.nl>; Wadud Miah <wadud.m...@nag.co.uk>; 
Alan W. Irwin <ir...@beluga.phys.uvic.ca>
Cc: plplot-devel@lists.sourceforge.net
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Wadud,



Looking at the code, I deduce that your compiler takes all the names available 
to the directly encompassing scope, interface_plfcont, rather than the 
encompassing module. Regardless of whether that is correct behaviour, I think 
the fix is to add PLcGrid to the imports for interface_plfcont.



Could you try that? If it works, I will apply the patch to the repository. I 
will try and concoct a small example so that I can post it on the 
comp.lang.fortran newsgroup for further advice. Quite possibly this is an edge 
case that needs to be sorted out. When I have such a small example, I will send 
it to you, so that you can check that the NAG compiler indeed doesn't like it.



Regards,



Arjen


From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: Monday, May 09, 2016 7:10 PM
To: Wadud Miah; Alan W. Irwin
Cc: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: Re: [Plplot-devel] PLplot Fortran bindings


Hi Wadud,



I will have a closer look at it. I have never had the opportunity to use your 
compiler, so maybe we have been "lucky" sofar.



Regards,



Arjen


From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Monday, May 09, 2016 5:10 PM
To: Arjen Markus; Alan W. Irwin
Cc: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings

Hi Arjen,

The NAG Fortran compiler has picked up a compilation error which I am 
struggling to understand:

Error: 
/home/wadud/builds/plplot-plplot/bindings/f95/included_plplot_real_interfaces.f90,
 line 1112: Cannot IMPORT PLCGRID because it does not exist in the host 
INTERFACE_PLFCONT
   detected at ,@PLCGRID

Going to the offending line in the code shown in boldface:

subroutine transform( x, y, tx, ty, data ) bind(c)
import :: private_plflt, PLcGrid
implicit none
real(kind=private_plflt), value, intent(in) :: x, y
real(kind=private_plflt), intent(out) :: tx, ty
type(PLcGrid), intent(in) :: data
end subroutine transform

It is not complaining about importing private_plflt but is complaining about 
importing PLcGrid and I do not understand how the compiler should know it 
should get this type definition from plplot_small_modules.f90 even though this 
works with other compilers, e.g. gfortran. I don't really know if this is 
significant, but at least I would like to make sense of it.

Best regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 09 May 2016 14:15
To: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>; Alan W. 
Irwin <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Wadud,



That is right. The last argument, plplot-plplot, is actually the name of the 
directory that will contain the source code and auxiliary data files. You will 
get an up-to-date repository that way.



Regards,



Arjen


From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Monday, May 09, 2016 3:05 PM
To: Arjen Markus; Alan W. Irwin
Cc: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings

Hi Arjen,

Apologies for this question as I am not very familiar with Git, but what is the 
Git command I use to clone PLplot which has the corrections? Is it just:

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

Regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 28 April 2016 11:20
To: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>; Alan W. 
Irwin <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourcefo

Re: [Plplot-devel] PLplot Fortran bindings

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Hi Arjen:
>
> You are absolutely right to ask Wadud to try the above simplest possible 
> example
> of importing a type from another module first.
>
> However, another potential issue here is that if the NAG Fortran compiler 
> compiles
>
> import :: private_plflt, PLcGrid
>
> from left to right, then it had no problem with importing plflt_private which 
> is a type
> defined in a very similar manner to PLcGrid.
>


Aha, I overlooked that detail. That is another indication that the NAG compiler 
may be at fault here. Indeed,then it becomes a matter of further extending the 
example.

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.
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
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]

On 2016-05-09 18:50- Arjen Markus wrote:

> Hi Wadud,
>
>
>
>> -Original Message-
>> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
>>
>> Hi Wadud:
>>
>> Thanks very much for your build test of PLplot using the NAG Fortran 
>> compiler.
>>
>> ... >
>> To investigate further why the above logic unexpectedly cannot be compiled 
>> with
>> the NAG compiler, I strongly suggest you make a small one-file example 
>> containing
>> a simplified plplot_types module that just defines private_plflt, and 
>> plcGrid exactly
>> like we do, and which also contains another module that includes the above
>> subroutine transform.
>> Then if that vastly simplified example also fails to compile you have that 
>> example to
>> take to the NAG developers concerning a possible bug in their compiler.  Or 
>> they
>> may respond to your report by saying something like this: "to get that 
>> Fortran
>> standards compliant code to compile with the NAG compiler, you need xxx 
>> flag".
>>
>
>
> I prepared a small example (see below) that is generously accepted by the two 
> compilers I have access to. I think it exhibits the characteristics of the 
> code that is not accepted by the NAG compiler. The only difference that may 
> be important is the fact that it does not contain the ISO_C_BINDING features. 
> If this small example is accepted, then I would say it is indeed a problem in 
> the NAG compiler.
>
> The alternative is that the example is not accepted and that the NAG compiler 
> doesn't like the import through the nesting of interfaces. I would not think 
> that the example is non-standard, but there can be subtleties that I am 
> overlooking here. That is why it is important to see what the NAG compiler 
> comes up with.
>
> Regards,
>
> Arjen
>
> ! nested_interface.f90 --
>
> ! Attempt to reproduce a problem discovered by Wadud Miah
>
> !
>
> module my_types
>
>implicit none
>
>
>
>type xyz
>
>integer :: x, y, z
>
>end type xyz
>
> end module my_types
>
>
>
> module my_interfaces
>
>use my_types
>
>
>
>implicit none
>
>
>
>interface
>
>subroutine use_transform( transform )
>
>interface
>
>subroutine transform( data, result )
>
>import :: xyz
>
>type(xyz) :: data
>
>real  :: result
>
>end subroutine transform
>
>end interface
>
>end subroutine use_transform
>
>end interface
>
> end module my_interfaces

Hi Arjen:

You are absolutely right to ask Wadud to try the above simplest possible
example of importing a type from another module first.

However, another potential issue here is that if the NAG Fortran compiler
compiles

import :: private_plflt, PLcGrid

from left to right, then it had no problem with importing
plflt_private which is a type defined in a very similar manner to
PLcGrid.

So if Wadud verifies the above simple one-type example compiles for the NAG
fortran compiler, then you will likely want to make your example more
complex using two simple types just in case the NAG Fortran compiler
issue is with more than one imported type.  Then if that simple
two-type case has no NAG problem, try using our exact types for
private_plflt and PLcGrid instead.

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

[Arjen Markus]

Hi Wadud,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
>
> Hi Wadud:
>
> Thanks very much for your build test of PLplot using the NAG Fortran compiler.
>
> ... >
> To investigate further why the above logic unexpectedly cannot be compiled 
> with
> the NAG compiler, I strongly suggest you make a small one-file example 
> containing
> a simplified plplot_types module that just defines private_plflt, and plcGrid 
> exactly
> like we do, and which also contains another module that includes the above
> subroutine transform.
> Then if that vastly simplified example also fails to compile you have that 
> example to
> take to the NAG developers concerning a possible bug in their compiler.  Or 
> they
> may respond to your report by saying something like this: "to get that Fortran
> standards compliant code to compile with the NAG compiler, you need xxx flag".
>


I prepared a small example (see below) that is generously accepted by the two 
compilers I have access to. I think it exhibits the characteristics of the code 
that is not accepted by the NAG compiler. The only difference that may be 
important is the fact that it does not contain the ISO_C_BINDING features. If 
this small example is accepted, then I would say it is indeed a problem in the 
NAG compiler.

The alternative is that the example is not accepted and that the NAG compiler 
doesn't like the import through the nesting of interfaces. I would not think 
that the example is non-standard, but there can be subtleties that I am 
overlooking here. That is why it is important to see what the NAG compiler 
comes up with.

Regards,

Arjen

! nested_interface.f90 --

! Attempt to reproduce a problem discovered by Wadud Miah

!

module my_types

implicit none



type xyz

integer :: x, y, z

end type xyz

end module my_types



module my_interfaces

use my_types



implicit none



interface

subroutine use_transform( transform )

interface

subroutine transform( data, result )

import :: xyz

type(xyz) :: data

real  :: result

end subroutine transform

end interface

end subroutine use_transform

end interface

end module my_interfaces

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

On 2016-05-09 15:09- Wadud Miah wrote:

> The NAG Fortran compiler has picked up a compilation error which I am 
> struggling to understand:
>
> Error: 
> /home/wadud/builds/plplot-plplot/bindings/f95/included_plplot_real_interfaces.f90,
>  line 1112: Cannot IMPORT PLCGRID because it does not exist in the host 
> INTERFACE_PLFCONT
>   detected at ,@PLCGRID
>
> Going to the offending line in the code shown in boldface:
>
>subroutine transform( x, y, tx, ty, data ) bind(c)
>import :: private_plflt, PLcGrid
>implicit none
>real(kind=private_plflt), value, intent(in) :: x, y
>real(kind=private_plflt), intent(out) :: tx, ty
>type(PLcGrid), intent(in) :: data
>end subroutine transform
>

> It is not complaining about importing private_plflt but is
complaining about importing PLcGrid and I do not understand how the
compiler should know it should get this type definition from
plplot_small_modules.f90 even though this works with other compilers,
e.g. gfortran. I don't really know if this is significant, but at
least I would like to make sense of it.

Hi Wadud:

Thanks very much for your build test of PLplot using the NAG Fortran
compiler.

To help you navigate through our code that is relevant to the above
build error for the NAG Fortran compiler, both plplot_double.f90
(which defines the plplot_double module) and plplot_single.f90 (which
defines the plplot_single module), contain the line

use plplot_types, only: private_plflt, private_plint, private_plbool, 
private_double, PLcGrid, PLfGrid

before they include "included_plplot_real_interfaces.f90".
Furthermore, if you look in plplot_small_modules.f90 where the
plplot_types module is defined it is straightforward to confirm that
module contains both private_plflt and PLcGRID.  So my opinion is the
above

import :: private_plflt, PLcGrid

should "just work" for compilers that are compliant with the
Fortran 2003 standard.

To investigate further why the above logic unexpectedly cannot be
compiled with the NAG compiler, I strongly suggest you make a small
one-file example containing a simplified plplot_types module that just
defines private_plflt, and plcGrid exactly like we do, and which also
contains another module that includes the above subroutine transform.
Then if that vastly simplified example also fails to compile you have
that example to take to the NAG developers concerning a possible bug
in their compiler.  Or they may respond to your report by saying
something like this: "to get that Fortran standards compliant code to
compile with the NAG compiler, you need xxx flag".

Good luck with your further investigation of the above build error,
and let us know how it goes.

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

[Arjen Markus]

Hi Wadud,



Looking at the code, I deduce that your compiler takes all the names available 
to the directly encompassing scope, interface_plfcont, rather than the 
encompassing module. Regardless of whether that is correct behaviour, I think 
the fix is to add PLcGrid to the imports for interface_plfcont.



Could you try that? If it works, I will apply the patch to the repository. I 
will try and concoct a small example so that I can post it on the 
comp.lang.fortran newsgroup for further advice. Quite possibly this is an edge 
case that needs to be sorted out. When I have such a small example, I will send 
it to you, so that you can check that the NAG compiler indeed doesn't like it.



Regards,



Arjen



From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: Monday, May 09, 2016 7:10 PM
To: Wadud Miah; Alan W. Irwin
Cc: plplot-devel@lists.sourceforge.net
Subject: Re: [Plplot-devel] PLplot Fortran bindings


Hi Wadud,



I will have a closer look at it. I have never had the opportunity to use your 
compiler, so maybe we have been "lucky" sofar.



Regards,



Arjen


From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Monday, May 09, 2016 5:10 PM
To: Arjen Markus; Alan W. Irwin
Cc: plplot-devel@lists.sourceforge.net
Subject: RE: [Plplot-devel] PLplot Fortran bindings

Hi Arjen,

The NAG Fortran compiler has picked up a compilation error which I am 
struggling to understand:

Error: 
/home/wadud/builds/plplot-plplot/bindings/f95/included_plplot_real_interfaces.f90,
 line 1112: Cannot IMPORT PLCGRID because it does not exist in the host 
INTERFACE_PLFCONT
   detected at ,@PLCGRID

Going to the offending line in the code shown in boldface:

subroutine transform( x, y, tx, ty, data ) bind(c)
import :: private_plflt, PLcGrid
implicit none
real(kind=private_plflt), value, intent(in) :: x, y
real(kind=private_plflt), intent(out) :: tx, ty
type(PLcGrid), intent(in) :: data
end subroutine transform

It is not complaining about importing private_plflt but is complaining about 
importing PLcGrid and I do not understand how the compiler should know it 
should get this type definition from plplot_small_modules.f90 even though this 
works with other compilers, e.g. gfortran. I don't really know if this is 
significant, but at least I would like to make sense of it.

Best regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 09 May 2016 14:15
To: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>; Alan W. 
Irwin <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Wadud,



That is right. The last argument, plplot-plplot, is actually the name of the 
directory that will contain the source code and auxiliary data files. You will 
get an up-to-date repository that way.



Regards,



Arjen


From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Monday, May 09, 2016 3:05 PM
To: Arjen Markus; Alan W. Irwin
Cc: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings

Hi Arjen,

Apologies for this question as I am not very familiar with Git, but what is the 
Git command I use to clone PLplot which has the corrections? Is it just:

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

Regards,
Wadud.

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


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<mailto: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 l

Re: [Plplot-devel] PLplot Fortran bindings

[Arjen Markus]

Hi Wadud,



I will have a closer look at it. I have never had the opportunity to use your 
compiler, so maybe we have been "lucky" sofar.



Regards,



Arjen



From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Monday, May 09, 2016 5:10 PM
To: Arjen Markus; Alan W. Irwin
Cc: plplot-devel@lists.sourceforge.net
Subject: RE: [Plplot-devel] PLplot Fortran bindings

Hi Arjen,

The NAG Fortran compiler has picked up a compilation error which I am 
struggling to understand:

Error: 
/home/wadud/builds/plplot-plplot/bindings/f95/included_plplot_real_interfaces.f90,
 line 1112: Cannot IMPORT PLCGRID because it does not exist in the host 
INTERFACE_PLFCONT
   detected at ,@PLCGRID

Going to the offending line in the code shown in boldface:

subroutine transform( x, y, tx, ty, data ) bind(c)
import :: private_plflt, PLcGrid
implicit none
real(kind=private_plflt), value, intent(in) :: x, y
real(kind=private_plflt), intent(out) :: tx, ty
type(PLcGrid), intent(in) :: data
end subroutine transform

It is not complaining about importing private_plflt but is complaining about 
importing PLcGrid and I do not understand how the compiler should know it 
should get this type definition from plplot_small_modules.f90 even though this 
works with other compilers, e.g. gfortran. I don't really know if this is 
significant, but at least I would like to make sense of it.

Best regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 09 May 2016 14:15
To: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>; Alan W. 
Irwin <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Wadud,



That is right. The last argument, plplot-plplot, is actually the name of the 
directory that will contain the source code and auxiliary data files. You will 
get an up-to-date repository that way.



Regards,



Arjen


From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Monday, May 09, 2016 3:05 PM
To: Arjen Markus; Alan W. Irwin
Cc: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings

Hi Arjen,

Apologies for this question as I am not very familiar with Git, but what is the 
Git command I use to clone PLplot which has the corrections? Is it just:

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

Regards,
Wadud.

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


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<mailto: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 <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>; 
plplot-devel@lists.sourceforge.net<mailto: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]
> Se

Re: [Plplot-devel] PLplot Fortran bindings

[Wadud Miah]

Hi Arjen,

The NAG Fortran compiler has picked up a compilation error which I am 
struggling to understand:

Error: 
/home/wadud/builds/plplot-plplot/bindings/f95/included_plplot_real_interfaces.f90,
 line 1112: Cannot IMPORT PLCGRID because it does not exist in the host 
INTERFACE_PLFCONT
   detected at ,@PLCGRID

Going to the offending line in the code shown in boldface:

subroutine transform( x, y, tx, ty, data ) bind(c)
import :: private_plflt, PLcGrid
implicit none
real(kind=private_plflt), value, intent(in) :: x, y
real(kind=private_plflt), intent(out) :: tx, ty
type(PLcGrid), intent(in) :: data
end subroutine transform

It is not complaining about importing private_plflt but is complaining about 
importing PLcGrid and I do not understand how the compiler should know it 
should get this type definition from plplot_small_modules.f90 even though this 
works with other compilers, e.g. gfortran. I don't really know if this is 
significant, but at least I would like to make sense of it.

Best regards,
Wadud.

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 09 May 2016 14:15
To: Wadud Miah <wadud.m...@nag.co.uk>; Alan W. Irwin <ir...@beluga.phys.uvic.ca>
Cc: plplot-devel@lists.sourceforge.net
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Wadud,



That is right. The last argument, plplot-plplot, is actually the name of the 
directory that will contain the source code and auxiliary data files. You will 
get an up-to-date repository that way.



Regards,



Arjen


From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Monday, May 09, 2016 3:05 PM
To: Arjen Markus; Alan W. Irwin
Cc: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings

Hi Arjen,

Apologies for this question as I am not very familiar with Git, but what is the 
Git command I use to clone PLplot which has the corrections? Is it just:

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

Regards,
Wadud.

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


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<mailto: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 <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>; 
plplot-devel@lists.sourceforge.net<mailto: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<mailto: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
>

Re: [Plplot-devel] PLplot Fortran bindings

[Wadud Miah]

Hi Arjen,

Apologies for this question as I am not very familiar with Git, but what is the 
Git command I use to clone PLplot which has the corrections? Is it just:

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

Regards,
Wadud.

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


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<mailto: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 <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>; 
plplot-devel@lists.sourceforge.net<mailto: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<mailto: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<mailto: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 

Re: [Plplot-devel] PLplot Fortran bindings

[Arjen Markus]

Hi Wadud,



That is right. The last argument, plplot-plplot, is actually the name of the 
directory that will contain the source code and auxiliary data files. You will 
get an up-to-date repository that way.



Regards,



Arjen



From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Monday, May 09, 2016 3:05 PM
To: Arjen Markus; Alan W. Irwin
Cc: plplot-devel@lists.sourceforge.net
Subject: RE: [Plplot-devel] PLplot Fortran bindings

Hi Arjen,

Apologies for this question as I am not very familiar with Git, but what is the 
Git command I use to clone PLplot which has the corrections? Is it just:

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

Regards,
Wadud.

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


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<mailto: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 <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>; 
plplot-devel@lists.sourceforge.net<mailto: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<mailto: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<mailto: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 Cygwi

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 perf

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 

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

[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 <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>; 
plplot-devel@lists.sourceforge.net<mailto: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<mailto: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<mailto: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 m

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 <ir...@beluga.phys.uvic.ca>
Cc: Wadud Miah <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 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);

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

[Arjen Markus]

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.

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

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

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
.

@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 

Re: [Plplot-devel] PLplot Fortran bindings

[Wadud Miah]

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...@beluga.phys.uvic.ca]
Sent: 26 April 2016 18:32
To: Wadud Miah <wadud.m...@nag.co.uk>; Arjen Markus <arjen.mar...@deltares.nl>
Cc: plplot-devel@lists.sourceforge.net
Subject: Re: [Plplot-devel] PLplot Fortran bindings

On 2016-04-26 14:47- 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
___

Re: [Plplot-devel] PLplot Fortran bindings

[Alan W. Irwin]

On 2016-04-26 14:47- 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
 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
__

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

[Plplot-devel] PLplot Fortran bindings

[Wadud Miah]

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.


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