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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Rafael Laboissiere wrote:

> > What drivers does PLPLOT have?
> 
> Look at http://plplot.sf.net.

Hm, it is not obvious where to find a list of supported devices on that
site. Hints???

 Christian

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

Rafael Laboissiere wrote:

> approach).  However, I think that we should combine our efforts.  I am
> willing to develop a low-level, PP-based layer that would allow access to
> (almost) all features of PLplot.  This will be the result of the combination

How about you look Doug's stuff over once he has put it into PDL CVS. I
guess one should appreciate that Doug needs something usable quickly.
But surely there is nothing wrong with a few iterations to get things
right (-- compare evolution of the PGPLOT interface).

  Christian

How about this:  I will clean things in my 0.01 version up a bit and
then mail the source to Rafael.  He can look at my PP definitions and
come up with a more complete version that either works from the XML file
or the header file.  In the mean time, I will work on the high level
interface.

Regards, 

  Doug

> 
> Rafael Laboissiere wrote:
> 
> > approach).  However, I think that we should combine our efforts.  I am
> > willing to develop a low-level, PP-based layer that would allow access to
> > (almost) all features of PLplot.  This will be the result of the combination
> 
> How about you look Doug's stuff over once he has put it into PDL CVS. I
> guess one should appreciate that Doug needs something usable quickly.
> But surely there is nothing wrong with a few iterations to get things
> right (-- compare evolution of the PGPLOT interface).
> 
>   Christian

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

Raphael:

> 
> However, I still think that the PP definition should be automaticaly
> generated from api.xml (it should be easy to modify my parsing scripts to do
> that), such that there will be a low level layer that will mimic the PLplot
> C API in Perl/PDL.  Then, as a second step, a OO layer can be written atop
> of that low level layer bindings.  Keeping things modular like that has the
> advantage that it will be easy to comply in the future to any generic plot
> API for PDL.

I'm already doing this (creating a low level interface that maps
directly to the plplot calls, and then putting a higher level interface
on top of it) but I'm working from a (slightly edited) version of
plplot.h instead of api.xml.

Is there a benefit to working from api.xml instead of the plplot.h?  All
things being equal, I'd rather work from the source instead of the
doc...

If there is a good reason to use api.xml, I would not mind adding the
XML parser as a dependency.

One thing more:  PP is a great tool for interfacing to PDL, but it has
one small limitation which makes the low level interface less useful to
call directly:  It handles non-PDL arguments (that is char, char * or
function pointers) in the so-called 'OtherPars' section.  This means
that when calling the perl version, the arguments get out of order, so

void c_plmtex(const char *side, PLFLT disp, PLFLT pos, PLFLT just, const
char *text);

becomes in perl:

plmtex($disp, $pos, $just, $side, $text);

(All the char * inputs are put last).

It is for this reason that I generally don't advertise the low level
routines and present users with only the high level versions.

Regards, 

  Doug Hunt

--

> 
> --
> Rafael

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

Reminds me of years ago when Tuomas was proposing an XML replacement to PP.

Easy to propose :)

Rafael Laboissiere wrote:

> As regards code vs. doc, the PLplot developers are willing to keep api.xml
> as accurate as possible.

The logical step is to generate (the protos in) plplot.h from api.xml .
That way they are automatically in sync. If you don't do that I would
shy away from using api.xml for the PDL interface.

  Christian

Try
http://plplot.sourceforge.net/resources/docbook-manual/plplotdoc-html-0.4.3/output-devices.html

That is on the site mentioned, but I agree you have to dig through the
documentation a bit to find it.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

On Fri, 25 Jan 2002, Christian Soeller wrote:

> Rafael Laboissiere wrote:
>
> > > What drivers does PLPLOT have?
> >
> > Look at http://plplot.sf.net.
>
> Hm, it is not obvious where to find a list of supported devices on that
> site. Hints???
>
>  Christian
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Christian:  It seems to support all devices that I am interested in. 
Here is the list:

http://plplot.sourceforge.net/resources/docbook-manual/plplotdoc-html-0.4.3/output-devices.html

Regards, 

  Doug

Christian Soeller wrote:
> 
> Rafael Laboissiere wrote:
> 
> > > What drivers does PLPLOT have?
> >
> > Look at http://plplot.sf.net.
> 
> Hm, it is not obvious where to find a list of supported devices on that
> site. Hints???
> 
>  Christian

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

No Win32 or Os X? Perhaps next.c might do for the latter (yes I know you
can run X-windows).

My point is it is a bit more unix-centric than pgplot

Karl

Karl Glazebrook wrote:
> 
> No Win32 or Os X? Perhaps next.c might do for the latter (yes I know you
> can run X-windows).
> 
> My point is it is a bit more unix-centric than pgplot

Hm, reminds me that there is still no fully functional win32 PGPLOT
(that will build with PDL). All the bits and pieces are there but
somebody needs to f2c the whole of PGPLOT and build it with win32 C. Tim
did this in the past but has lost everything in a hard disc crash.

  Christian

Yes I think so, I recently rebuilt PGPLOT with the latest version
of the Grwin-32 driver (quite nice) and a borrowed copy of Digital
Visual Fortran (yuk).

My experiences are described and the binaries are available -

http://mrhanky.pha.jhu.edu/~kgb/PGPLOT-Win32/

Note this is not something I intend to do regularly (or maybe again) as like
most people here I prefer UNIX for real work.

I did conclude though that DVF is a pig, I think f2c would be a better approach -

http://www.wzw.tu-muenchen.de/~syring/f2c/f2c.html

Given f2c libs is available for all key os's and the C->f77 calling semantics
are known I think this is the best universal approach.

cheers,

Karl

Karl Glazebrook wrote:

> My experiences are described and the binaries are available -
> 
> http://mrhanky.pha.jhu.edu/~kgb/PGPLOT-Win32/
> 

Read that page, didn't get through to the binaries though. Can you build
the PGPLOT perl interface using these binaries *without* having DVF? I
haven't managed to look at gwcl yet.
If that were possible we could easily make a win32 installable ppm
available.

  Christian

I think the binaries should be there? Note IE has problems opening ftp:// sites

I think trying this with f2c would be the logical next step. I'll try and get
around to it some time.

Karl

Karl Glazebrook wrote:
> 
> My point is it is a bit more unix-centric than pgplot

Thats a *good* thing! ;)

It seems that PLplot is pretty straight forward to add drivers to,
though.

--Doug

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

On Thu, 24 Jan 2002, Karl Glazebrook wrote:

>
> No Win32 or Os X? Perhaps next.c might do for the latter (yes I know you
> can run X-windows).
>
> My point is it is a bit more unix-centric than pgplot
>
> Karl

I would like to respond to this comment since it was CCed to the PLplot
developer's list, and I believe the "it" here refers to PLplot capabilities.

Up to a month ago I would have agreed with the unix-centric assessment of
PLplot since the win32 directory hadn't been worked on for a number of
years. But that is all changed now.  One of our developers got interested
and has just delivered a complete upgrade of plplot/sys/win32/msdev/.  He
claims that plplot now works fine on win98 (and possibly even win95), winNT,
and win2K.  If you have further interest in this (or the other upgraded
capabilities of PLplot) please do an anonymous checkout from the latest CVS
at sf.net/project/plplot ==> "CVS".  Or wait for PLplot version 5.1.0 which
completely supersedes version 5.0.4 and which should be released (check
sf.net/project/plplot ==> "Files") in a few more days.

With regard to PLplot on Mac OS X, there is no port at this time.  However,
my understanding (although I have never tried it myself) is ports to Mac OS
X of Unix Apps are pretty straightforward.  I have not heard anything, but
perhaps one of our developers or users will contribute that effort in the
near future.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Very interesting. If you have a nice win32 driver that would be
an advantage.

Xwindows based drivers would work fine on OS X - pgplot does this for
example, it would be nice to have something native though.

Karl

"Alan W. Irwin" wrote:
> 
> On Thu, 24 Jan 2002, Karl Glazebrook wrote:
> 
> >
> > No Win32 or Os X? Perhaps next.c might do for the latter (yes I know you
> > can run X-windows).
> >
> > My point is it is a bit more unix-centric than pgplot
> >
> > Karl
> 
> I would like to respond to this comment since it was CCed to the PLplot
> developer's list, and I believe the "it" here refers to PLplot capabilities.
> 
> Up to a month ago I would have agreed with the unix-centric assessment of
> PLplot since the win32 directory hadn't been worked on for a number of
> years. But that is all changed now.  One of our developers got interested
> and has just delivered a complete upgrade of plplot/sys/win32/msdev/.  He
> claims that plplot now works fine on win98 (and possibly even win95), winNT,
> and win2K.  If you have further interest in this (or the other upgraded
> capabilities of PLplot) please do an anonymous checkout from the latest CVS
> at sf.net/project/plplot ==> "CVS".  Or wait for PLplot version 5.1.0 which
> completely supersedes version 5.0.4 and which should be released (check
> sf.net/project/plplot ==> "Files") in a few more days.
> 
> With regard to PLplot on Mac OS X, there is no port at this time.  However,
> my understanding (although I have never tried it myself) is ports to Mac OS
> X of Unix Apps are pretty straightforward.  I have not heard anything, but
> perhaps one of our developers or users will contribute that effort in the
> near future.
> 
> Alan
> 
> email: ir...@be...
> phone: 250-727-2902     FAX: 250-721-7715
> snail-mail:
> Dr. Alan W. Irwin
> Department of Physics and Astronomy,
> University of Victoria, P.O. Box 3055,
> Victoria, British Columbia, Canada, V8W 3P6
> __________________________
> 
> Linux-powered astrophysics
> __________________________

Karl Glazebrook writes:
 > 
 > Very interesting. If you have a nice win32 driver that would be
 > an advantage.
 > 
 > Xwindows based drivers would work fine on OS X - pgplot does this for
 > example, it would be nice to have something native though.

There is a native Mac driver in plplot/src/mac, which predates OS X.
And there have certainly been plenty of PLplot users on Mac over the
years.  However, none of the current core team members are Mac-folk,
so I don't know how to characterize it.  In particular, I don't know
if there is something about "OS X" that is problematic for older Mac
code.  Anyway, its there, if that helps.

-- 
Geoffrey Furnish         fu...@ga...

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

Cross-platform, scientific graphics plotting library

plplot-devel