plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] PLplot Fortran bindings

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

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:Arj...@de...]
Sent: 10 May 2016 15:41
To: Wadud Miah <wad...@na...>; Alan W. Irwin <ir...@be...>
Cc: plp...@li...
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:wad...@na...]
Sent: Tuesday, May 10, 2016 4:07 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...<mailto:plp...@li...>
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:Arj...@de...]
Sent: 10 May 2016 14:36
To: Wadud Miah <wad...@na...<mailto:wad...@na...>>; Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: plp...@li...<mailto:plp...@li...>
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.

________________________________

Re: [Plplot-devel] PLplot Fortran bindings

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

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:wad...@na...]
Sent: Tuesday, May 10, 2016 4:07 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...
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:Arj...@de...]
Sent: 10 May 2016 14:36
To: Wadud Miah <wad...@na...<mailto:wad...@na...>>; Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: plp...@li...<mailto:plp...@li...>
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.

Re: [Plplot-devel] PLplot Fortran bindings

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

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:Arj...@de...]
Sent: 10 May 2016 14:36
To: Wadud Miah <wad...@na...>; Alan W. Irwin <ir...@be...>
Cc: plp...@li...
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:wad...@na...]
Sent: Tuesday, May 10, 2016 3:04 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...<mailto:plp...@li...>
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:Arj...@de...]
Sent: 10 May 2016 13:30
To: Wadud Miah <wad...@na...<mailto:wad...@na...>>; Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: plp...@li...<mailto:plp...@li...>
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:wad...@na...]
Sent: Tuesday, May 10, 2016 2:27 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...<mailto:plp...@li...>
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:Arj...@de...]
Sent: 09 May 2016 20:26
To: Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: Wadud Miah <wad...@na...<mailto:wad...@na...>>; plp...@li...<mailto:plp...@li...>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> 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:

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:

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



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

________________________________

Re: [Plplot-devel] PLplot Fortran bindings

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

Hi 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:wad...@na...]
Sent: Tuesday, May 10, 2016 3:04 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...
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:Arj...@de...]
Sent: 10 May 2016 13:30
To: Wadud Miah <wad...@na...<mailto:wad...@na...>>; Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: plp...@li...<mailto:plp...@li...>
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:wad...@na...]
Sent: Tuesday, May 10, 2016 2:27 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...<mailto:plp...@li...>
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:Arj...@de...]
Sent: 09 May 2016 20:26
To: Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: Wadud Miah <wad...@na...<mailto:wad...@na...>>; plp...@li...<mailto:plp...@li...>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> 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:

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.

Re: [Plplot-devel] PLplot Fortran bindings

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

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:Arj...@de...]
Sent: 10 May 2016 13:30
To: Wadud Miah <wad...@na...>; Alan W. Irwin <ir...@be...>
Cc: plp...@li...
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:wad...@na...]
Sent: Tuesday, May 10, 2016 2:27 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...<mailto:plp...@li...>
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:Arj...@de...]
Sent: 09 May 2016 20:26
To: Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: Wadud Miah <wad...@na...<mailto:wad...@na...>>; plp...@li...<mailto:plp...@li...>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> 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:

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



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

________________________________

Re: [Plplot-devel] PLplot Fortran bindings

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

Hi Arjen,

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

Regards,
Wadud.

From: Arjen Markus [mailto:Arj...@de...]
Sent: 10 May 2016 13:30
To: Wadud Miah <wad...@na...>; Alan W. Irwin <ir...@be...>
Cc: plp...@li...
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:wad...@na...]
Sent: Tuesday, May 10, 2016 2:27 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...<mailto:plp...@li...>
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:Arj...@de...]
Sent: 09 May 2016 20:26
To: Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: Wadud Miah <wad...@na...<mailto:wad...@na...>>; plp...@li...<mailto:plp...@li...>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> 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:

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



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

________________________________

Re: [Plplot-devel] PLplot Fortran bindings

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

Hi 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:wad...@na...]
Sent: Tuesday, May 10, 2016 2:27 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...
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:Arj...@de...]
Sent: 09 May 2016 20:26
To: Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: Wadud Miah <wad...@na...<mailto:wad...@na...>>; plp...@li...<mailto:plp...@li...>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> 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.

Re: [Plplot-devel] PLplot Fortran bindings

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

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:Arj...@de...]
Sent: 09 May 2016 20:26
To: Alan W. Irwin <ir...@be...>
Cc: Wadud Miah <wad...@na...>; plp...@li...
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> 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.

________________________________

Re: [Plplot-devel] PLplot Fortran bindings

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

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:Arj...@de...]
Sent: 09 May 2016 19:50
To: Alan W. Irwin <ir...@be...>; Wadud Miah <wad...@na...>
Cc: plp...@li...
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Wadud,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> 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.

________________________________

Re: [Plplot-devel] PLplot Fortran bindings

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

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:Arj...@de...]
Sent: 09 May 2016 18:23
To: Arjen Markus <Arj...@de...>; Wadud Miah <wad...@na...>; Alan W. Irwin <ir...@be...>
Cc: plp...@li...
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:Arj...@de...]
Sent: Monday, May 09, 2016 7:10 PM
To: Wadud Miah; Alan W. Irwin
Cc: plp...@li...<mailto:plp...@li...>
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:wad...@na...]
Sent: Monday, May 09, 2016 5:10 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...<mailto:plp...@li...>
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:Arj...@de...]
Sent: 09 May 2016 14:15
To: Wadud Miah <wad...@na...<mailto:wad...@na...>>; Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: plp...@li...<mailto:plp...@li...>
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:wad...@na...]
Sent: Monday, May 09, 2016 3:05 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...<mailto:plp...@li...>
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:Arj...@de...]
Sent: 28 April 2016 11:20
To: Wadud Miah <wad...@na...<mailto:wad...@na...>>; Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: plp...@li...<mailto:plp...@li...>
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:wad...@na...]
Sent: Thursday, April 28, 2016 12:17 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...<mailto:plp...@li...>
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:Arj...@de...]
Sent: Thursday, April 28, 2016 9:55 AM
To: Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: Wadud Miah <wad...@na...<mailto:wad...@na...>>; plp...@li...<mailto:plp...@li...>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Alan,



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



Regards,



Arjen


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

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

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



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

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

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

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

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



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

________________________________

Re: [Plplot-devel] PLplot Fortran bindings

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> 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.

Re: [Plplot-devel] PLplot Fortran bindings

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

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

> Hi Wadud,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>>
>> 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
__________________________

Re: [Plplot-devel] PLplot Fortran bindings

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

Hi Wadud,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> 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.

Re: [Plplot-devel] PLplot Fortran bindings

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

On 2016-05-09 15:09-0000 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
__________________________

Re: [Plplot-devel] PLplot Fortran bindings

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

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:Arj...@de...]
Sent: Monday, May 09, 2016 7:10 PM
To: Wadud Miah; Alan W. Irwin
Cc: plp...@li...
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:wad...@na...]
Sent: Monday, May 09, 2016 5:10 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...
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:Arj...@de...]
Sent: 09 May 2016 14:15
To: Wadud Miah <wad...@na...<mailto:wad...@na...>>; Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: plp...@li...<mailto:plp...@li...>
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:wad...@na...]
Sent: Monday, May 09, 2016 3:05 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...<mailto:plp...@li...>
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:Arj...@de...]
Sent: 28 April 2016 11:20
To: Wadud Miah <wad...@na...<mailto:wad...@na...>>; Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: plp...@li...<mailto:plp...@li...>
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:wad...@na...]
Sent: Thursday, April 28, 2016 12:17 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...<mailto:plp...@li...>
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:Arj...@de...]
Sent: Thursday, April 28, 2016 9:55 AM
To: Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: Wadud Miah <wad...@na...<mailto:wad...@na...>>; plp...@li...<mailto:plp...@li...>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Alan,



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



Regards,



Arjen


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

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

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



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

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

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

Re: [Plplot-devel] PLplot Fortran bindings

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

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:wad...@na...]
Sent: Monday, May 09, 2016 5:10 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...
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:Arj...@de...]
Sent: 09 May 2016 14:15
To: Wadud Miah <wad...@na...<mailto:wad...@na...>>; Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: plp...@li...<mailto:plp...@li...>
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:wad...@na...]
Sent: Monday, May 09, 2016 3:05 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...<mailto:plp...@li...>
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:Arj...@de...]
Sent: 28 April 2016 11:20
To: Wadud Miah <wad...@na...<mailto:wad...@na...>>; Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: plp...@li...<mailto:plp...@li...>
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:wad...@na...]
Sent: Thursday, April 28, 2016 12:17 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...<mailto:plp...@li...>
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:Arj...@de...]
Sent: Thursday, April 28, 2016 9:55 AM
To: Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: Wadud Miah <wad...@na...<mailto:wad...@na...>>; plp...@li...<mailto:plp...@li...>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Alan,



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



Regards,



Arjen


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

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

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



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

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

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.

Re: [Plplot-devel] PLplot Fortran bindings

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

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:Arj...@de...]
Sent: 09 May 2016 14:15
To: Wadud Miah <wad...@na...>; Alan W. Irwin <ir...@be...>
Cc: plp...@li...
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:wad...@na...]
Sent: Monday, May 09, 2016 3:05 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...<mailto:plp...@li...>
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:Arj...@de...]
Sent: 28 April 2016 11:20
To: Wadud Miah <wad...@na...<mailto:wad...@na...>>; Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: plp...@li...<mailto:plp...@li...>
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:wad...@na...]
Sent: Thursday, April 28, 2016 12:17 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...<mailto:plp...@li...>
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:Arj...@de...]
Sent: Thursday, April 28, 2016 9:55 AM
To: Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: Wadud Miah <wad...@na...<mailto:wad...@na...>>; plp...@li...<mailto:plp...@li...>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Alan,



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



Regards,



Arjen


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

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

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



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

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

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



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

________________________________

Re: [Plplot-devel] PLplot Fortran bindings

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

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:Arj...@de...]
Sent: 28 April 2016 11:20
To: Wadud Miah <wad...@na...>; Alan W. Irwin <ir...@be...>
Cc: plp...@li...
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:wad...@na...]
Sent: Thursday, April 28, 2016 12:17 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...<mailto:plp...@li...>
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:Arj...@de...]
Sent: Thursday, April 28, 2016 9:55 AM
To: Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: Wadud Miah <wad...@na...<mailto:wad...@na...>>; plp...@li...<mailto:plp...@li...>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Alan,



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



Regards,



Arjen


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

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

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



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

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

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

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



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

________________________________

Re: [Plplot-devel] PLplot Fortran bindings

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

Hi 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:wad...@na...]
Sent: Monday, May 09, 2016 3:05 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...
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:Arj...@de...]
Sent: 28 April 2016 11:20
To: Wadud Miah <wad...@na...<mailto:wad...@na...>>; Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: plp...@li...<mailto:plp...@li...>
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:wad...@na...]
Sent: Thursday, April 28, 2016 12:17 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...<mailto:plp...@li...>
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:Arj...@de...]
Sent: Thursday, April 28, 2016 9:55 AM
To: Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: Wadud Miah <wad...@na...<mailto:wad...@na...>>; plp...@li...<mailto:plp...@li...>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Alan,



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



Regards,



Arjen


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

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

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



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

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

Re: [Plplot-devel] qhull 2015

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

On 2016-04-29 11:51-0600 Orion Poplawski wrote:

> qhull 2015 uses new directories for the include files:
>
> - Include headers prefixed with libqhull/, libqhull_r/, or libqhullcpp/
>
> The _r is a re-entrant version apparently.  From http://www.qhull.org/
>
> Qhull 2015.2 introduces reentrant Qhull. It allows concurrent Qhull runs and
> simplifies the C++ interface to Qhull. If you call Qhull from your program,
> you should use reentrant Qhull (libqhull_r) instead of qh_QHpointer (libqhull).
>
> So at the moment phplot does not find qhull because it is looking for
> qhull/qhull_a.h.

Hi Orion:

Thanks for that report.  I will try to build Qhull 2015.2 myself to
figure out the above issue and any other incompatibility between
PLplot and that version of Qhull.  Although there is a lot of other
stuff on my agenda for this forthcoming release, I will try to get the
Qhull 2015.2-related fix(es) into that release as well.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

[Plplot-devel] qhull 2015

[Orion P. <or...@co...>]

qhull 2015 uses new directories for the include files:

 - Include headers prefixed with libqhull/, libqhull_r/, or libqhullcpp/

The _r is a re-entrant version apparently.  From http://www.qhull.org/

Qhull 2015.2 introduces reentrant Qhull. It allows concurrent Qhull runs and
simplifies the C++ interface to Qhull. If you call Qhull from your program,
you should use reentrant Qhull (libqhull_r) instead of qh_QHpointer (libqhull).

So at the moment phplot does not find qhull because it is looking for
qhull/qhull_a.h.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                   http://www.nwra.com

Re: [Plplot-devel] PLplot Fortran bindings

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> 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-0000 Arjen Markus wrote:
>
> > I made the small change I suggested and the results for Cygwin and
> MinGW64 look fine - see the attached files.
>
> Thanks for those two test report tarballs.  Here is my analysis of those results.
>
> 1. Cygwin
>
> After unpacking your report tarball, I didn't spot anything unusual in your
> comprehensive test script arguments except for
>
> --build_command "make -j4"
> --ctest_command "ctest -j4"
>
> I believe you have sometimes found those parallel options to be problematic for
> Cygwin in the past so I would drop them from now on (even though they caused no
> issues for you for this particular comprehensive test).

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

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

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

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

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

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

Good :)

> 2. MinGW-w64/MSYS2
>
> After unpacking your report tarball, I didn't spot anything unusual in your
> comprehensive test script arguments.  For example, there is no parallel build or
> ctest option which is correct for this platform (and also Cygwin, see above
> comment).
>
> Furthermore,
> comprehensive_test.sh.out showed no errors; and
>
> grep -i error */*/output_tree/*.out
>
> and
>
> grep -B1 -A3 "Missing examples" */*/output_tree/*.out |less
>
> gave perfect results.
>
> However, shared/noninteractive/output_tree/cmake.out showed that libqhull was
> missing which adds some important core capabilities to PLplot. If you look at the
> (dated) package list at <https://sourceforge.net/p/msys2/wiki/Packages/> 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
> <https://sourceforge.net/p/msys2/wiki/MSYS2 installation/<https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/>> to get access to the
> latest much-simplified update procedure before installing PLplot dependencies
> including the qhull-related package.
>
That will take me some time to do - I will try and find time for that over the weekend.

> 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.
>
So, to be continued.

Regards,

Arjen

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

Re: [Plplot-devel] PLplot Fortran bindings

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

Hi Arjen:

On 2016-04-28 08:55-0000 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
<https://sourceforge.net/p/msys2/wiki/Packages/> 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
<https://sourceforge.net/p/msys2/wiki/MSYS2 installation/> 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 Victoria (astrowww.phys.uvic.ca).

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

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot Fortran bindings

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

On 2016-04-28 10:19-0000 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:wad...@na...]
> Sent: Thursday, April 28, 2016 12:17 PM
> To: Arjen Markus; Alan W. Irwin
> Cc: plp...@li...
> 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
__________________________

Re: [Plplot-devel] PLplot Fortran bindings

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

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:wad...@na...]
Sent: Thursday, April 28, 2016 12:17 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...
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:Arj...@de...]
Sent: Thursday, April 28, 2016 9:55 AM
To: Alan W. Irwin <ir...@be...<mailto:ir...@be...>>
Cc: Wadud Miah <wad...@na...<mailto:wad...@na...>>; plp...@li...<mailto:plp...@li...>
Subject: RE: [Plplot-devel] PLplot Fortran bindings


Hi Alan,



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



Regards,



Arjen


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

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

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



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

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