Hi Wadud,
I guess at this moment it is my turn - I was also reminded of a small omission
in the current code regarding the use of IMPLICIT NONE. It is not propagated
from the module to the interface blocks. Therefore I want to add that statement
everywhere where that is appropriate, just to make extra sure that no argument
has been left implicitly declared.
The next interesting bit is to get the examples to pass with the NAG compiler
and for that I will gladly accept your offer :).
Regards,
Arjen
From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Tuesday, May 10, 2016 5:06 PM
To: Arjen Markus; Alan W. Irwin
Cc: plplot-devel@lists.sourceforge.net
Subject: RE: [Plplot-devel] PLplot Fortran bindings
Hi Arjen,
Ah, yes, I see the subroutine being passed as an argument - I totally missed
that. So what would you exactly like me to do now? I was wondering whether you
would like a trial version of the NAG Fortran compiler which may make it easier
:-) Let me know if you would like a NAG Fortran trial licence and I can arrange
one for you.
Best regards,
Wadud.
From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 10 May 2016 15:41
To: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>; Alan W.
Irwin <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc:
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings
Hi Wadud,
Well, actually it is: look at lines 3441-3487 for instance:
The label fill() is associated with c_plfill (line 3480) and then that label is
passed as an argument to interface_plshade (line 3499). The label
interface_plfill() is used as a direct call at line 1518.
I am positive that this will work, but that is what the tests/examples are
there for. I imagine that the NAG compiler may find one or two issues in that
code as well, so I would like to suggest you to have the examples built too:
cmake ... -DBUILD_TEST=ON
Regards,
Arjen
From: Wadud Miah [mailto:wadud.m...@nag.co.uk]
Sent: Tuesday, May 10, 2016 4:07 PM
To: Arjen Markus; Alan W. Irwin
Cc:
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings
Hi Arjen,
I wasn't suggesting removing the c_plfill C function - I meant that its
interface should be removed as it is not being called. The NAG compiler is
complaining about the multiple binding labels "c_plfill". This may seem valid,
but if the fill() subroutine is not being called at all, I don't see the need
to declare interfaces to it.
If I change the binding label of interface_plfill to "fill", the NAG compiler
does accept it, but will that call the C fill() function?
Regards,
Wadud.
From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: 10 May 2016 14:36
To: Wadud Miah <wadud.m...@nag.co.uk<mailto:wadud.m...@nag.co.uk>>; Alan W.
Irwin <ir...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>>
Cc:
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: RE: [Plplot-devel] PLplot Fortran bindings
Hi Wadud,
Well, the first answer (by Wolfgang Kilian -
https://groups.google.com/forum/?hl=nl#!topic/comp.lang.fortran/-NYIZX-XZag) to
my post does support NAG's view. Unless there are strongly opposing replies, I
think the best way forward is to apply the workaround.
The fill() problem you mention is of a different order. In its current form it
uses two different labels for the same C routine, but the fill routine is
actually used, so we cannot simply eliminate it. (You have to look carefully
though to see where and how ;)). I can see two ways forward:
- Use the same label consistently, either will do. This is only a small
change in the source code.
- Use one interface block for c_plfill - right now the block is repeated
a number of times, mainly to keep these things as local as possible. (I am not
entirely sure if we can prevent "leakage" of the C names, if we do that. I
think that was the background for this set-up.)
If you change the label interface_plfill to fill (or vice versa, that is more
inline with the rest of the naming scheme), is the code accepted by the NAG
compiler? If so, I will apply that to the repository. I will be busy the next
few days, but I will try to incorporate it and do the testing.
Regards,
Arjen
________________________________
DISCLAIMER: This message is intended exclusively for the addressee(s) and may
contain confidential and privileged information. If you are not the intended
recipient please notify the sender immediately and destroy this message.
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The
Netherlands, Commercial Registration Number 41146461, 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