Hi Wadud,
Well, the first answer (by Wolfgang Kilian -
https://groups.google.com/forum/?hl=nl#!topic/comp.lang.fortran/-NYIZX-XZag) to
my post does support NAG's view. Unless there are strongly opposing replies, I
think the best way forward is to apply the workaround.
The fill() problem you mention is of a different order. In its current form it
uses two different labels for the same C routine, but the fill routine is
actually used, so we cannot simply eliminate it. (You have to look carefully
though to see where and how ;)). I can see two ways forward:
- Use the same label consistently, either will do. This is only a small
change in the source code.
- Use one interface block for c_plfill - right now the block is repeated
a number of times, mainly to keep these things as local as possible. (I am not
entirely sure if we can prevent "leakage" of the C names, if we do that. I
think that was the background for this set-up.)
If you change the label interface_plfill to fill (or vice versa, that is more
inline with the rest of the naming scheme), is the code accepted by the NAG
compiler? If so, I will apply that to the repository. I will be busy the next
few days, but I will try to incorporate it and do the testing.
Regards,
Arjen
From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Tuesday, May 10, 2016 3:04 PM
To: Arjen Markus; Alan W. Irwin
Cc: plplot-devel@lists.sourceforge.net
Subject: RE: [Plplot-devel] PLplot Fortran bindings
Hi again Arjen,
If my comments are valid and you would like to implement my recommendations,
let me know once that is done and I can recompile PLplot with your changes for
another sanity check.
The NAG Fortran compiler is very picky, but it is picky for a reason to ensure
greatest standards compliance and
portability :-)
Regards,
Wadud.
From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 10 May 2016 13:30
To: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>; Alan W.
Irwin <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc:
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings
Hi Wadud,
Thanks for running the example and the issue with fill() - that is probably
some leftover that was not detected by the compilers I use.
Intriguing question regarding the scope of the import statement. I will post
this on comp.lang.fortran - some people there know the standard by heart :).
Regards,
Arjen
From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Tuesday, May 10, 2016 2:27 PM
To: Arjen Markus; Alan W. Irwin
Cc:
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings
Hi Arjen,
Further to my previous email, I think the import statement has to have scope in
the inner interface by declaring it in the outer interface. I had a look at the
Fortran standard and I could not find any statement on this issue. My
colleagues are adamant that this is part of the standard and I will be
contacting a member of the Fortran standard (Malcom Cohen) to clarify this.
Another thing the NAG compiler complained about was the interface declaration
of the external subroutines fill() and interface_plfill() which have the same
binding label c_plfill in file included_plplot_configured_types.f90. In
addition, the external subroutine fill() is not called anywhere so I think
could be removed.
Regards,
Wadud.
From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 09 May 2016 20:26
To: Alan W. Irwin <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>;
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings
Hi Alan,
> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Hi Arjen:
>
> You are absolutely right to ask Wadud to try the above simplest possible
> example
> of importing a type from another module first.
>
> However, another potential issue here is that if the NAG Fortran compiler
> compiles
>
> import :: private_plflt, PLcGrid
>
> from left to right, then it had no problem with importing plflt_private which
> is a type
> defined in a very similar manner to PLcGrid.
>
Aha, I overlooked that detail. That is another indication that the NAG compiler
may be at fault here. Indeed,then it becomes a matter of further extending the
example.
Regards,
Arjen
DISCLAIMER: This message is intended exclusively for the addressee(s) and may
contain confidential and privileged information. If you are not the intended
recipient please notify the sender immediately and destroy this message.
Unauthorized use, disclosure or copying of this 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.
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
