Hi Alan,


> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
>
> Hi Arjen:
>
> A Linux adaptation of those build instructions got that build to work for me 
> (with
> some spurious warnings because of my old gfortran 4.7.2 version as we have
> discussed before.)
>
> The end result was
>
> irwin@raven> ./x00f
>
> worked and prompted me for device and device file name, and the resulting
> PostScript plot looked good.
>
Great!

> So that is an excellent start, and I especially like the absence of any extra 
> C layer at
> this stage (although we will ultimately need an extremely limited C layer for 
> some of
> the more complex API argument processing); the freedom to choose any real 
> type in
> the examples (so long as that real type is chosen consistently for a single 
> call to a
> PLplot function); and the form of how you have implemented the interface which
> avoids duplicate code to handle the two different PLFLT cases.
>
> However, there are three things we should fix before expanding this further.
>
> 1. Fix plsparseopts
> > -        I have not tested this with command-line arguments yet - that is 
> > the trickier
> part of the code.
>
> In fact, it turns out command-line options do not work correctly, e.g.,
>
> irwin@raven> ./x00f -dev psttfc -o test.psc
>
> Bad command line option "test.psc"
> [....]

I noticed it too, when I tried it after sending the message. It always 
complains about the last option. I will check this.

>
> 2. Fix naming scheme for kind values so the examples (and more importantly 
> user's
> programmes which are depending on plflt) can remain unchanged for backwards
> compatibility.  I have developed some detailed ideas in the way I want to do 
> this, but
> instead of describing those in English I would like to present a commit 
> instead that
> you could evaluate in detail for yourself.
>
Yes, it was pretty much ad hoc what I did to x00f.f90, I wanted to make sure it 
did not arcanely rely on the current style of binding.

> 3. Integrate these changes into our current build and test scheme.
> Again, I would be happy to take responsibility for this.
>

Again, the main reason for doing it that way was to make sure that no traces of 
the current style were left. I built the program in a separate directory with a 
copy of just the C library.

> In sum, I suggest we continue from this good start on the new Fortran binding 
> topic
> with you taking responsibility for topic 1 and me taking responsibility for 
> topics 2 and
> 3 above.
>
> Of course, if I am going to contribute to this development I do need git 
> access to your
> private topic branch work using the usual "git format-patch" and "git am" 
> method that
> is described in README.developers. So for now I suggest your first priority 
> would
> be to present exactly what you have given us here as a tarball in "git 
> format-patch"
> form instead with no further changes (except possibly not including the 
> x00f.f90
> change since I would just revert that, see above).  And that solid git start 
> with just
> your present work and no further except possibly excluding the x00f.f90 change
> would allow us to develop this private topic from there. Of course, I am 
> aware you
> have had some problems with using "git format-patch" in the past, but if those
> continue let me know here or off list, and I think I should be able to give 
> you an exact
> cookbook of what to do to get started.
>
Whenever I need to update the source tree or commit my changes, I follow the 
cookbook to the letter - that way it works for me. So, maybe indeed an update 
of the cookbook is required, but we will see.

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.
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to