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.