plplot-devel — Technical discussion about PLplot development

RE: [Plplot-devel] Deadline for 5.1.0 is Monday 8 AM PST = 16:00 UT

[Alan W. I. <ir...@be...>]

On Sat, 26 Jan 2002, Geoffrey Furnish wrote:

> [...]Now, you might suspect its just my code.  And that could well be.
> However, it runs to completion with no upset using many other devices,
> including xwin, ps, and plmeta.  With a metafile, I can render to
> device tk.  Also the plplot C examples work with dev tk.  So I realize
> this is a pretty inconclusive set of data.

The C examples with tk driver may not be adequately exercising the code.
Therefore, I think you should exercise every Tk example to see if there are
any obvious problems on your system.  Here is my script for doing this from
plplot/tmp:

#!/bin/sh
#test suite of all interactive tk stuff that cannot be done by file.
#tk driver (x14c), tcldemos, tkdemos.
export cdir=.
export tcldir=.
export tkdir=.
export plplotbindir=.
$cdir/x14c
$cdir/x17c -dev tk
$tkdir/xtk01 -f tk01
$tkdir/xtk02 -f tk02
$plplotbindir/plserver -f tk03
$tkdir/xtk04 -f tk04
cd $tcldir
$plplotbindir/plserver <<EOF
plstdwin .
plxframe .plw
pack append . .plw {left expand fill}
source plgrid.tcl
proc 1 {} "plgrid .plw.plwin"
1
exit
EOF
cd $tkdir
$plplotbindir/plserver <<EOF
source tkdemos.tcl
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
exit
EOF

If all these examples work well, then I would pick the nearest to your own
use of PLplot and see what is different about yours that is generating an
error.  I suspect it may be one of the obscure API changes that is messing
you about. Recall that part of Maurice's recent work was removing those
nameclashes that occurred in plframe.c between special plframe commands and
Tcl-wrapped PLplot library code commands.  Perhaps your code is calling some
of those special plframe commands that were renamed?  Finally, does your
code work with PLplot 5.0.4? PLplot of September?  PLplot of last week?
There really haven't been that many tk/plframe changes since 5.0.4 so it
should be a relatively quick task to find out which one is causing your
problem.

Since all the examples work (AFAIK), and there have been too many delays
already, I am very much inclined to continue with the tag deadline tomorrow.
Ideally, if you actually find something specifically wrong with PLplot today,
you will also be able to fix it today.

Good luck, and let us know how it goes.

Alan

RE: [Plplot-devel] Deadline for 5.1.0 is Monday 8 AM PST = 16:00 UT

[Geoffrey F. <fu...@ga...>]

Alan W. Irwin writes:
 > Hello everybody.  Since our efforts to release 5.1.0 seem to have stalled,
 > I'm reinitiating the test/release plan.  

Thanks Alan for restarting the count down.

I'm afraid I am writing to report some possibly discouraging news.
The Tk driver is not working for me right now.  I'm getting:

Packet send failed:
         pl_PacketSend -- error writing to fifo: bad file number
TCL command "plclient_link_end" failed:
         no application named "cplace_x86kaig"
Program aborted

when I run my code.  The tk driver starts, the plframe is displayed,
then it all vanishes in a puff of smoke, and 50% of the time or so, it
prints the above message, the other times it all simply vanishes
without a trace.

Now, you might suspect its just my code.  And that could well be.
However, it runs to completion with no upset using many other devices,
including xwin, ps, and plmeta.  With a metafile, I can render to
device tk.  Also the plplot C examples work with dev tk.  So I realize
this is a pretty inconclusive set of data.  

Trying to pin the blame on my own code, I've gotten as far as running
it under electric fence, but again, nothing turns up.  I don't know if
anybody else has experience with electric fence, but I've been using
it a little here ever since I upgraded one of my machines to Red Hat
7.1, and it seems to be pretty good to me, has caught bugs in other
porgrams.  I don't know if I'll be able to run a purified version or
not, as I don't currently have access to a purify license (but am
working on it).

Since the data I am providing is so inconclusive, I don't want it to
hold up the release by itself.  If no one but me is having troubles
with the tk driver, we should press on with the release.  But it would
be nice if other people with substantial PLplot client codes could
just give the current cvs head a whirl, and make sure the tk driver
and plframe widget work for you today as well as they did a month
ago.  If others notice trouble, speak up on plplot-devel.

If no one but me finds problems, I think Alan should proceed as
planned, presuming the problem is of my own creation.  But if anybody
else has evidence the tk driver isn't working right, then in that case
I think maybe we should find a way to dig deeper.

Cheers to all,

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

[Plplot-devel] Deadline for 5.1.0 is Monday 8 AM PST = 16:00 UT

[Alan W. I. <ir...@be...>]

Hello everybody.  Since our efforts to release 5.1.0 seem to have stalled,
I'm reinitiating the test/release plan.  Please get all your final checkins
that you want included in this release finished by the hard deadline of 8
AM PST (= 16:00 UT) Monday at which time the final release testing will
commence.

Here is the new plan (thanks to Geoffrey for suggesting this).  On Monday 8
A.M PST I will tag CVS HEAD with v5_1_0_rc1.  This will allow me to go about
my testing business while you guys use CVS any way you like. It also allows
any of you to obtain exactly the version I am testing (in case of an
emergency where I absolutely need your help) regardless of subsequent CVS
activity.  Thus, with this new plan there is no CVS freeze at all, just a
deadline if you want your stuff included in 5.1.0.

Assuming all my tests go well ("well" here means that the results should be
as good as my tests for 5.0.4 so I won't be treating any of our known bugs
for 5.0.4 as release critical), I will simply ignore anything you put into
CVS after 8 AM Monday and retag my non-updated local copy as v5_1_0_final
after the completion of the tests and just before the 5.1.1 release.

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
__________________________

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

[Geoffrey F. <fu...@ga...>]

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...

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

[Karl G. <kg...@ph...>]

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
> __________________________

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

[Alan W. I. <ir...@be...>]

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
__________________________

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

[Karl G. <kg...@ph...>]

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

Re: [Plplot-devel] linuxvga driver

[<jca...@in...>]

On Thursday 24 January 2002 22:45, Alan W. Irwin wrote:
| On Thu, 24 Jan 2002, Alan W. Irwin wrote:
| > I cannot remember whether it was Maurice or Geoffrey who
| > investigated this a long time ago, but according to my memory of
| > the results back then you always need root in order to use this
| > driver. Therefore, I have never run or tested it.  If there is no
| > way to get around this root-only limitation of libsvga, I think
| > this driver should be disabled in the interests of security.
|
| For what it is worth, there might be a way to run and test this
| driver safely.  Apparently
| (http://packages.debian.org/testing/libs/svgalib1-libggi2.html) you
| can run a svgalib wrapper on top of libggi.  In turn this can be
| run (http://packages.debian.org/testing/libs/libggi2.html) on top
| of a lot of different backends.  If you choose to run libggi on top
| of X, there should be no root problem.

There is no point in using svga if you have X ;-).

I just reported this, I don't use it.

Joao

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

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

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

Re: [Plplot-devel] linuxvga driver

[Alan W. I. <ir...@be...>]

On Thu, 24 Jan 2002, Geoffrey Furnish wrote:

> Alan W. Irwin writes:
>  > I cannot remember whether it was Maurice or Geoffrey who investigated this a
>  > long time ago, but according to my memory of the results back then you
>  > always need root in order to use this driver. Therefore, I have never run or
>  > tested it.  If there is no way to get around this root-only limitation of
>  > libsvga, I think this driver should be disabled in the interests of security.
>
> :-).
>
> /home/furnish> ll /usr/bin/X11/XFree86
> -rws--x--x    1 root     root      1773168 Jan 18  2001  /usr/bin/X11/XFree86*
>
> The "no run-as-root software allowed" rule, would make for a text only
> computing experience.

Sounds good to me....;-)

Seriously though, I agree with your implicit point that from the security
perspective there is no real difference between a setuid programme and one
that demands you be root to run it.  However, there is a practical
difference between the two; when you are running root is is much easier to
screw up (inadvertent typing of "rm -rf /", for example....;-)) then when
you are just running a setuid executable.  Also, for what it is worth, the
security reputation of libsvga is not as good as Xfree86.

>
> I think we should leave it in/available.  People can use it or not
> based on their own policy decisions on their own machine.

Fine by me.  Since I wrote what you are responding to, I found and posted a
way (with a lot of effort) that might work to run svgalib-based code safely
(or at least as safe as X).

Alan

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

[Christian S. <c.s...@au...>]

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

Re: [Plplot-devel] linuxvga driver

[Alan W. I. <ir...@be...>]

On Thu, 24 Jan 2002, Alan W. Irwin wrote:

> I cannot remember whether it was Maurice or Geoffrey who investigated this a
> long time ago, but according to my memory of the results back then you
> always need root in order to use this driver. Therefore, I have never run or
> tested it.  If there is no way to get around this root-only limitation of
> libsvga, I think this driver should be disabled in the interests of security.
>

For what it is worth, there might be a way to run and test this driver
safely.  Apparently
(http://packages.debian.org/testing/libs/svgalib1-libggi2.html) you can run
a svgalib wrapper on top of libggi.  In turn this can be run
(http://packages.debian.org/testing/libs/libggi2.html) on top of a lot of
different backends.  If you choose to run libggi on top of X, there should
be no root problem. But whether this all works depends on how good the
wrapper is.  Also, there are complications in building against
svgalib1-libggi2 and also apparently a lot of configuration is required to
get a particular svgalib application to work.  I don't have time to
investigate any further, however.

Re: [Plplot-devel] linuxvga driver

[Geoffrey F. <fu...@ga...>]

Alan W. Irwin writes:
 > I cannot remember whether it was Maurice or Geoffrey who investigated this a
 > long time ago, but according to my memory of the results back then you
 > always need root in order to use this driver. Therefore, I have never run or
 > tested it.  If there is no way to get around this root-only limitation of
 > libsvga, I think this driver should be disabled in the interests of security.

:-).

/home/furnish> ll /usr/bin/X11/XFree86 
-rws--x--x    1 root     root      1773168 Jan 18  2001  /usr/bin/X11/XFree86*

The "no run-as-root software allowed" rule, would make for a text only
computing experience.

I think we should leave it in/available.  People can use it or not
based on their own policy decisions on their own machine.

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

[Christian S. <c.s...@au...>]

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

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

[Christian S. <c.s...@au...>]

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

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

[Karl G. <kg...@ph...>]

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

Easy to propose :)

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

[Karl G. <kg...@ph...>]

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

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

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

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

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

[Christian S. <c.s...@au...>]

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

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

[Karl G. <kg...@ph...>]

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

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

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

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

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

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

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

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

[Alan W. I. <ir...@be...>]

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
>

Re: [Plplot-devel] linuxvga driver

[Alan W. I. <ir...@be...>]

I cannot remember whether it was Maurice or Geoffrey who investigated this a
long time ago, but according to my memory of the results back then you
always need root in order to use this driver. Therefore, I have never run or
tested it.  If there is no way to get around this root-only limitation of
libsvga, I think this driver should be disabled in the interests of security.

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 Thu, 24 Jan 2002, Joao Cardoso wrote:

>
> Hi,
>
> I have commited changes to enable the linuxvga driver to be a dyndriver, as
> it was only partially configured (it appears only in PL_DYNAMIC_DRIVER_LIST).
>
> But I can't use the driver as anormal user, I get:
>
> 	svgalib: Cannot get I/O permissions.
>
> As root I can however use it.
> I make no ideia of what is going on. Any clues?
>
> Joao
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

[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