On Tuesday 21 January 2003 21:54, Alan W. Irwin wrote:
> I will try to comment on what Joao and Rafael have said.
>
> On Tue, 21 Jan 2003, [iso-8859-1] Jo=E3o Cardoso wrote:
> > On Tuesday 21 January 2003 20:06, Rafael Laboissiere wrote:
> >
> > Hi Rafael!
> >
> > | * Alan W. Irwin <irwin@...> [2003-01-21 10:23]:
> > | > On Mon, 20 Jan 2003, Robert Schwebel wrote:
> > | > > What's the state of the Perl/PDL interface?
> > | >
> > | > I don't know about PDL since that is an independent effort (see
> > | > Doug Hunt's messages to this list right after PLplot-5.1.0 was
> > | > released last year).
> > |
> > | Well, my original Perl bindings code had some limited support to PD=
L.
> > | However, I think that Doug's approach should be superior than mine.
> > |
> > | > We do have a rudimentary perl interface as part of generic PLplot=
,
> > | > but that is unsupported at this time because its developer ran ou=
t
> > | > of time to work on it.
> > |
> > | (That is me. I am still unable to participate to the PLplot effort=
=2E
> > | Too many things on the way.)
> > |
> > | > Personally, I think we should abandon that approach (which depend=
ed
> > | > on parsing the API from our DocBook API chapter) and go with swig
> > | > instead.
> > |
> > | Well, my approach combined both parsing the XML source of the API
> > | _and_ usign swig (see bindings/perl5/README).
>
> OOPS. Sorry I missed that, Rafael. That immediately gives me much mor=
e
> interest in the current perl interface.
>
> > | I do not think that
> > | parsing the XML source is a bad idea, provided that the plplot.h is
> > | also automatically generated. It is unacceptable to have two sourc=
es
> > | of the same information being maintained in parallel.
>
> Rafael, I agree that one source for our API would be better, but it wil=
l
> take some effort, and we have lived with *many* parallel versions of ou=
r
> API descriptions for a long time. So it is the old tradeoff between a
> constant, maintenance problem that makes a steady drain on our time/eff=
ort,
> or doing something much better which requires a lot more immediate
> time/effort but pays off later in reducing the maintenance required.=20
> "Short term pain for long-term gain".
>
> Here is a summary of the current parallel API descriptions. We have the
> docbook chapter describing the API, plplot.h, two separate files descri=
bing
> the API for both java and python, and files describing the API for fort=
ran
> and tcl as well. For the java and python case, the two files are almos=
t
> identical, but they *must* differ slightly because the current java
> interface has cruder support of the call-back functions. Once that is
> sorted out, the two files could be merged together, but not yet. Also,
> these two files differ quite a bit from plplot.h to signal the swig
> typedefs when something special has to be done with arguments (such as
> dropping redundant dimensions from argument lists).
>
> > In that case, let the documentation be generated from the code and no=
t
> > the other way around! And it's easier to maintain plplot.h than
> > api.xml.
>
> Joao, that's because api.xml has extra information such as detailed
> documentation of each argument far beyond the argument types and minima=
l
> documentation that plplot.h has at the moment.
>
> Therefore, since doc/docbook/src/api.xml has the most documentation
> information (by far) in an easily parsable form , I agree with Rafael t=
hat
> this file should be the ultimate source of all other descriptions of ou=
r
> API. To implement that, scripts need to be developed to generate
> include/plplot.h, bindings/python/plplotcapi, bindings/java/plplotcapi,
> bindings/tcl/plapi.tpl, and the equivalent API description file(s) for
> fortran. I have put such scripts in the rough order from highest to lo=
west
> priority. From Rafael's comments above , it also looks like a script h=
as
> already been written to generate the required swig interface file for p=
erl,
> but I imagine there is some more work to do on that as well.
>
> Rafael, generating include/plplot.h from doc/docbook/src/api.xml might =
be
> the type of small project that might interest you. How about it?
That means that when I need to add/change something in plplot.h, because =
I'm=20
*developing*, then I need to change api.xml, run the plplot.h building=20
scripts, make, eventually make install, and then restart from the beginin=
g=20
several times. Is this the development model we want for plplot? I will b=
e=20
out.
Joao
>
> Alan
> __________________________
> Alan W. Irwin
> email: irwin@...
> phone: 250-727-2902
>
> Astronomical research affiliation with Department of Physics and Astron=
omy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the Canadian Centre for Climate Modelling=
and
> Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting
> software package (plplot.org).
>
> __________________________
>
> Linux-powered Science
> __________________________
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> http://www.ictp.com/training/sourceforge.asp
> _______________________________________________
> Plplot-general mailing list
> Plplot-general@...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
|