[Plplot-devel] Re: simple PLPLOT interface for PDL

[Doug H. <dh...@uc...>]

Salut, Rafael:

> > -- I have no need for a perl *and* a PDL interface, just a PDL
> >    interface.
> 
> Actually, I am not sure neither that I need both interfaces.  I would
> happily keep only the PDL one in my project.  The idea of supporting PDL
> came later in my work and this is the reason I have both now.
> 
> > -- I don't want to have the extra dependencies on swig, XML::Parser
> >    and XML::DOM.
> 
> Those are requirements only on the developer side.  My initial plan was to
> provide the Perl glueing code generated by SWIG in the distribution
> tarballs, so that the end user do not need SWIG.  When I started the
> project, I quickly realized that SWIG saves me a lot of work.

I've used SWIG a lot as well, but for interfacing to PDL, PP is the way
to go.
I was able to write the program to convert the function defs from
plplot.h to pp_def calls in about 4 hours.  That was all it took to
create the low level interface.  The resulting calls are also more
flexible.  For example, one can 'thread' calls over multiple dimensions
in a PDL, like so:

# One plot
$x = sequence(10);
$y = $x**2;
plpoin($x->nelem, $x, $y, 1);

# Two plots
$x = sequence(10)->cat(sequence(10)*2); # 10 x 2 array
$y = $x**2;
$c = PDL->new(1,2); # two separate symbols
plpoin(PDL->new(10,10), $x, $y, $c);

> 
> The dependency on the XML parser modules is also only on the developer side,
> but its necessity is a matter of philosophy inside the whole PLplot project.
> The PLplot development team is putting a lot of efforts in the Docbook
> documentation for the API.  The file api.xml is expected to faithfully
> reflect the C library.  By parsing that file, I automatically generates the
> correct Perl bindings for *all* functions in the library (well, at least in
> theory).

I copied all the functions I was interested in to my PP definition file
from plplot.h.  I left out a few of them, such as those that require
function pointers.

> 
> Of course, we could keep a huge PLplot_wrap.c independently and fixing it
> each time the API changes or a new function is added.  I frankly prefer my
> approach.

Yeah, its best to regenerate that each time.

> 
> > -- I believe the PP style interface is simpler and cleaner than trying
> > to
> >    use swig and then add PDL support.
> > -- I want a simple OO-style interface.
> >
> > So far, I can do this sort of thing (from the test.pl):
> >
> > my $pl = PDL::Graphics::PLPLOT->new (DEV  => "png",
> >                                      FILE => "test.png",
> >                                      BG   => [255,255,255]); # white
> > my $x  = sequence(10);
> > my $y  = $x**2;
> > $pl->line($x, $y, BOX => [-5,10,0,200]);
> > $pl->close;
> 
> I like your proposal very much, but remember that you can easily implement
> the PDL::Graphics::PLPLOT module on top of my Perl bindings module
> PLplot.pm.  Otherwise, we are going to duplicate the effort that I already
> did.

I like the PP interface in that its easy to install and has no
dependencies outside of PLplot and PDL.  I'm looking at applications
that are quickly deployable, so I'm trying to reduce dependencies. 
Thats why I like PLplot incidentally--compared to PGPLOT it is dead
simple to install.

I think our interfaces might serve two slightly different needs,
though.  I'm not intending for mine to be exhaustive.  I just want
something quick, easy and light-weight for my web applications.  Yours
might might be better considered the 'reference' implementation that
allows access to all features of PLplot.

> 
> [By the way, we prefer to use PLplot (first "P" and "L" uppercase) instead
> of PLPLOT (all caps).]

OK, I'll change the name.  (What does the PL stand for, anyway?)

> 
> > I'm using an OO style interface since its clean, but I am not planning on
> > allowing two plotting sessions at one time, as this runs afoul of PLPLOT's
> > (and PGPLOT's) philosophy of storing global state data.
> 
> That sounds wise.
> 
> > I am planning on keeping this module separate for a while so I can update
> > it easily for my needs, but I will release it on CPAN periodically.  I
> > could also put it in CVS on source forge if anyone is interested.
> 
> You might also consider contributing your code to the PLplot project hosted
> at SourceForge.  In that case, I could even help with occasional hacks...

That might be a good idea once it is more mature.  For the moment, I'm
thinking of maintaining it as a separate package on CPAN so I can add
features quickly without needing to update my PLplot or stay on the
bleeding edge of same...

Merci, 

  Doug Hunt


> 
> --
> Rafael Laboissiere

-- 
dh...@uc...
Software Engineer III, Sometimes Sysadmin
UCAR - COSMIC, Tel. (303) 497-2611