plplot-general — PLplot user discussion group

Re: [Plplot-general] Some inconsistencies in between plframe and the tcl API

[Maurice L. <mj...@ga...>]

Dean Clamons writes:
 > I've found that the routines plscmap0, plscmap1 and plscol0 all have API's 
 > defined in tclgen.c. That's fine and they seem to work, but in plframe there 
 > are also separate implementations in Cmd which seem to require different 
 > calling sequences. I'm assuming that these are left over from some previous 
 > incarnation. Incidentally, I've looked at the 5.0.2 source files to see if the 
 > problem still exists there. It does.

The color handling routines in plframe use X11 conventions rather than plplot
ones, which is more appropriate for a widget.  I.e. it uses XParseColor to
convert a string into its 3 rgb components.  This lets you use symbolic names
or hex notation for color values.

-- 
Maurice LeBrun    mj...@ga...

[Plplot-general] Some inconsistencies in between plframe and the tcl API

[Dean C. <de...@qu...>]

I've found that the routines plscmap0, plscmap1 and plscol0 all have API's 
defined in tclgen.c. That's fine and they seem to work, but in plframe there 
are also separate implementations in Cmd which seem to require different 
calling sequences. I'm assuming that these are left over from some previous 
incarnation. Incidentally, I've looked at the 5.0.2 source files to see if the 
problem still exists there. It does.

Any reason not to delete these from plframe's Cmd routine?

Dean Clamons
Code 7420
Naval Research Lab
Washington, DC 20375
202-767-2732

Re: [Plplot-general] Problem with color map1 and the tk driver

[Maurice L. <mj...@ga...>]

Dean Clamons writes:
 > I found that when I ran the demo x08c with the tk driver it blew up. With a 
 > little work I traced the problem to the call to plscmap1. Then after a lot more 
 > work I found that the problem is in plr.c.  In routine plr_state in the 
 > PLSTATE_CMAP1 case ot the switch there is no check made to see if the requested 
 > number of colors has been allocated in cmap1. It needs to be changed to 
 > something like:

It's not up to plr_state to determine this kind of thing; that's the driver's
responsibility.  It must honor the caller's wishes and allocate the colormap
regardless of the driver.

The driver then maps this onto something it can handle.  In this case, it
ultimately lands in the X driver.  The X driver allocates its own private copy
of cmap1 the first time it's used.  After that, changes to the internal plplot
color map only change the value of the X color cells.  Interpolation is used
to get a linear best fit.  See xwin.c/AllocCmap1() for more info.

 > In the process of finding this bug I found some problems with the debugging 
 > routines supplied. First the pldebug routine does not print the correct line 
 > and file - it always prints the same line number in the file pldebug.h. In 
 > order to fix this problem I changed the calling sequence to pldebug to pass in 
 > the line and file. The call would look something like:
 > 
 >         pldebug( __LINE__, __FILE__, "plr_state", "PLSTATE_CMAP1\n" );

I noticed that recently too and for 5.0.2 subtantially reworked the debugging
support.  __LINE__ & __FILE__ aren't in there, I almost put them in explicitly
as you write, but in the end decided that most of the uses didn't need it so
now it's left up to the caller to insert a descriptive tag.

I believe the previous pldebug behavior worked fine under HPUX (my old dev
platform), I guess cpp differences.  

 > I also found that it was difficult to find out what was going on on the server, 
 > so I added some options to the run parameters:
 > 
 > -debugfile name - causes any debug output to go to the file "name". By default 
 > it goes to stderr.
 > 
 > -sdebug - causes the program to run the server with the -debug option so that 
 > debugging output will happen on the server
 > 
 > -sdebugfile name - similar to -debugfile but it is passed to the server

Interesting.. yeah these could be handy.

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-general] Problem with color map1 and the tk driver

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

Or maybe the problem depends more on the characteristics of your X
server and the X visual you are using.  Maybe the output of xdpyinfo
would be helpful.  Also, does it (the problem you were seeing) depend
on what other apps are running on the X server at the same time?  For
example, Netscape and XEmacs can sometimes hog colors.  If you're on a
256 pseudocolor visual and most colors are absorbed by a previously
running Netscape, PLplot can get into a bind on color allocation.

Alan W. Irwin writes:
 > On Thu, 15 Feb 2001, Dean Clamons wrote:
 > 
 > > I found that when I ran the demo x08c with the tk driver it blew up.
 > 
 > [...]
 > 
 > > My version of the 
 > > source has now changed quite a bit in order to instrument the programs 
 > > sufficiently enough to find out what was going on. Unfortunately, I did not 
 > > keep very good track of what I changed.
 > > 
 > > Were any of these problems addressed in the 5.0.2 release?
 > > 
 > 
 > I just checked, and I do not have any problem with the tk driver for x08c
 > under 5.0.2.  AFAIK, there was no problem under 5.0.1 as well.
 > 
 > So what plplot version were you using?  Also, please let us know your OS. My
 > testing is limited to Debian.  (I also test on RedHat and solaris, but
 > without Tk for reasons that are in the announcement).
 > 
 > 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-general mailing list
 > Plp...@pl...
 > http://lists.sourceforge.net/lists/listinfo/plplot-general
 > 

Re: [Plplot-general] Problem with color map1 and the tk driver

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

On Thu, 15 Feb 2001, Dean Clamons wrote:

> I found that when I ran the demo x08c with the tk driver it blew up.

[...]

> My version of the 
> source has now changed quite a bit in order to instrument the programs 
> sufficiently enough to find out what was going on. Unfortunately, I did not 
> keep very good track of what I changed.
> 
> Were any of these problems addressed in the 5.0.2 release?
> 

I just checked, and I do not have any problem with the tk driver for x08c
under 5.0.2.  AFAIK, there was no problem under 5.0.1 as well.

So what plplot version were you using?  Also, please let us know your OS. My
testing is limited to Debian.  (I also test on RedHat and solaris, but
without Tk for reasons that are in the announcement).

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-general] Problem with color map1 and the tk driver

[Dean C. <de...@qu...>]

I found that when I ran the demo x08c with the tk driver it blew up. With a 
little work I traced the problem to the call to plscmap1. Then after a lot more 
work I found that the problem is in plr.c.  In routine plr_state in the 
PLSTATE_CMAP1 case ot the switch there is no check made to see if the requested 
number of colors has been allocated in cmap1. It needs to be changed to 
something like:

    case PLSTATE_CMAP1:{
        U_SHORT ncol1;

        plr_rd( pdf_rd_2bytes(plr->pdfs, &ncol1) );
        if( ncol1 > plsc->ncol1 ){
          plsc->cmap1 = (PLColor *) realloc(plsc->cmap1, ncol1 * 
sizeof(PLColor)
 );
        }
        plsc->ncol1 = ncol1;
        for (i = 0; i < plsc->ncol1; i++) {
            plr_rd( pdf_rd_1byte(plr->pdfs, &plsc->cmap1[i].r) );
            plr_rd( pdf_rd_1byte(plr->pdfs, &plsc->cmap1[i].g) );
            plr_rd( pdf_rd_1byte(plr->pdfs, &plsc->cmap1[i].b) );
        }
        plP_state(PLSTATE_CMAP1);
        break;
   }

I believe the PLSTATE_CMAP0 case should be similarly patched.

In the process of finding this bug I found some problems with the debugging 
routines supplied. First the pldebug routine does not print the correct line 
and file - it always prints the same line number in the file pldebug.h. In 
order to fix this problem I changed the calling sequence to pldebug to pass in 
the line and file. The call would look something like:

        pldebug( __LINE__, __FILE__, "plr_state", "PLSTATE_CMAP1\n" );

I also found that it was difficult to find out what was going on on the server, 
so I added some options to the run parameters:

-debugfile name - causes any debug output to go to the file "name". By default 
it goes to stderr.

-sdebug - causes the program to run the server with the -debug option so that 
debugging output will happen on the server

-sdebugfile name - similar to -debugfile but it is passed to the server

If anyone is interested in these changes, please contact me. My version of the 
source has now changed quite a bit in order to instrument the programs 
sufficiently enough to find out what was going on. Unfortunately, I did not 
keep very good track of what I changed.

Were any of these problems addressed in the 5.0.2 release?

Dean Clamons
Code 7420
Naval Research Lab
Washington, DC 20375
202-767-2732

[Plplot-general] Debian packages for PLplot 5.0.1 available

[Rafael L. <ra...@ic...>]

This announcement is for the Debian users of PLplot out there.

Debian packages for the "almost" latest stable release of PLplot (5.0.1) are
available.  Debian packages for version 5.0.2 will be available in the near
future, as time permits.

The packages work for the potato distribution (2.2). We have set up an
apt-getable location in the PLplot web site.  This is a convenience for the
potato users, since there is no need to upgrade to the unstable (or testing)
version in order to get the latest PLplot for Debian.

To upgrade your packages, just add the following lines to your
/etc/apt/sources.list:

    deb http://plplot.sourceforge.net/resources/debian ./ 
    deb-src http://plplot.sourceforge.net/resources/debian ./ 

then run "apt-get update" and "apt-get dist-upgrade" and you should be okay.
Please notice that there has been a package reorganization, and some names
changed.  I tried to make the upgrade as smooth as possible, but there may
be still some bugs.  In particular, there are now two conflicting packages,
plplot-xwin and plplot-tcl, both dependent on plplot-common.  The old plplot
package is now just an empty transition package.

Please, report any bugs using the Debian BTS (Bug Tracking System,
http://bugs.debian.org), the more convinient way beeing through the command
reportbug (available in the Debian package with the same name).

-- 
Rafael Laboissiere <ra...@de...>

[Plplot-general] plplot-5.0.2 has been released

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

It has been a month since PLplot-5.0.1, and we thought another stable
release was appropriate at this time.

Get this new PLplot-5.0.2 as a tarball file release at
http://sourceforge.net/projects/plplot.  It was created from the current CVS
head which has benefited quite a lot from steady bug fixing over the last
month (for example, file familying now works, and the plmeta now properly
outputs to pipes).

Version 5.0.2 supersedes all previous versions. Please note that for
improved stability you should use the tarball release and not the CVS HEAD.
(We try things on the HEAD which might momentarily break plplot from time to
time.)

Note we also have some innovation in the new release as well as bug fixing.

(1) The python xw??.py examples should now work right out of the box without
fooling around with PYTHONPATH.

(2) Install file locations now conform to the FHS.  So, for example, you
will find the examples installed at $prefix/share/doc/plplot/examples.

(3) The content of the documentation source has been greatly improved from
5.0.1.  We have now completely finished going through the doc directory for
several generations of notes on various topics and incorporated all this
material (with substantial updates and expansions) into our docbook source.
The result is new docbook sections/chapters on devices, driver functions,
plrender and metafiles, familying, interactive output devices, color, and C
and fortran bindings. We have added API sections that are specialized to C
and fortran.  We have also added a bibliography and reorganized the material
so that all the reference material (bibliography and API sections) appear at
the back of the document.  We have now removed virtually all the old files
in doc so there is no longer the potential of getting confused with these
older generations of documentation.

We don't anticipate the addition of too many more chapters or sections to
the documentation, but some refinement of the existing chapters/sections
still needs to be done.  If you are interested in helping with this effort,
please contact yours truly (ir...@be...).

(4) Our DocBook source can be built into PLplot documentation in a variety
of formats (currently html, dvi, postscript, pdf, info, and man).  Our CVS
does not have these files because they are generated rather than source
files.  However, you can always get the latest forms of these results from
http://www.plplot.org/resources/docbook-manual/, and for your convenience we
have also bundled these results into the doc directory of the 5.0.2 tarball.

Tests:

Release version 5.0.2 has been extensively tested on Debian potato with
double precision configured. The cdemos, cxxdemos (c++), fdemos (fortran),
tcldemos, tkdemos, and the new standalone xw??.py python demos all now work
well on potato. Similar tests show good results on RedHat 6.2 except for
Tcl/Tk whose 8.0 version on RH 6.2 is too old for us to support. We have not
yet upgraded our test box to RedHat 7.0 (which does include a Tcl/Tk/iTcl
version that we support), and until we do this upgrade, we would appreciate
any RedHat 7.0 reports our users could give us. Similar tests (excluding
Tcl/Tk and python because we would have had to download configure, build,
and install these packages ourselves) show good results on solaris (SunOS
5.6 Generic_105181-23 sun4u sparc SUNW,Ultra-2 = solaris 2.6).

Putting on my yplot (http://sourceforge.net/projects/yplot) hat momentarily,
I have also rebuilt yplot, the convenient yorick front end to plplot. The
new yplot version (to be released soon) is based on plplot-5.0.2 libraries,
and I have just confirmed it gives excellent results for a wide variety of
36 different scientific plots from my present research.

Please send bug reports, comments, and questions to this list, and
have fun (and profit) with the new 5.0.2 release of plplot!

Alan W. Irwin

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-general] Using plplot in an interactive environment

[Andreas D. <qu...@ma...>]

On Fri, Feb 09, 2001 at 02:39:25PM -0600, Maurice LeBrun wrote:
> Andreas Dietrich writes:
>  > c) Generate immediate plmeta-represenation in the main process and
>  > fork()/exec(plrender) to display it. This could even provide interactive
>  > data readout via fifo. Drawback: plrender cannot read from a pipe or a 
>  > fifo(fgetpos fails). This means
> Your change works fine.  Just a case of bitrot, since I almost never test
> the i/o to/from a pipe.  Certainly the plmeta driver is supposed to be able to
> write to a pipe, and plrender to read from one.  I remember adding that
> capability, ages ago.  I tested it with:
> 
> x07c -dev plm -o - | plrender -dev xwin -i -
> 
> works great.  Available in current cvs image.

How embarassing ;-) what I tried (and found not working) was something like
plrender -dev xwin -i test.fifo

You are right, it works great.

Thank you very much for your time.

Andreas
-- 
"We've heard that a million monkeys at a million keyboards could produce the
complete works of Shakespeare. Now, thanks to the Internet, we know this is not
true."  -- Robert Wilensky

Re: [Plplot-general] Using plplot in an interactive environment

[Maurice L. <mj...@ga...>]

Andreas Dietrich writes:
 > c) Generate immediate plmeta-represenation in the main process and
 > fork()/exec(plrender) to display it. This could even provide interactive
 > data readout via fifo. Drawback: plrender cannot read from a pipe or a 
 > fifo(fgetpos fails). This means
 > 
 >    + temporary files have to created
 >    
 >    + An existing plot-window cannot be updated or reused. Plrender will read
 >    to EOF and then wait for the window to be closed.
 >     
 > I really like c) because of its simplicity and because it is _almost_
 > working as I want. Now if just plrender could read from a fifo. 
 > 
 > Looking at plmeta.c it seems that writing to a pipe was considered (but not
 > finished, at least one more if(isfile) is needed), so it may be possible to
 > patch plrender to work from a pipe (perhaps losing a feature or two), but I
 > do not yet understand the code good enough. Does anybody out there
 > understand the design of plmeta files?

Your change works fine.  Just a case of bitrot, since I almost never test
the i/o to/from a pipe.  Certainly the plmeta driver is supposed to be able to
write to a pipe, and plrender to read from one.  I remember adding that
capability, ages ago.  I tested it with:

x07c -dev plm -o - | plrender -dev xwin -i -

works great.  Available in current cvs image.

-- 
Maurice LeBrun    mj...@ga...

RE: [Plplot-general] Using plplot in an interactive environment

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

Andreas Dietrich writes:
 > I'm working on a little python module to provide interactive plotting
 > capabilities. Currently I have the following problem.
 > 
 > The xwin driver will not start redrawing the window before plend()
 > is called. Now the problem is, plend() will block until the window
 > is closed (as expected). 

I believe the X windows driver will process the X event loop whenever
a page advance is required.  But yes, I agree it can be very
frustrating when the window becomes unresponsive while the process is
compute bound.

We have considered many options over the years, including some like
what you suggest below.  You can also add a threaded xwin to the list,
so that perhaps the X driver process the X event loop continuously in
a thread in the background.  

I think a key question here is to understand exactly what you are
after.  Are you trying to keep the window responsive even when your
client program is compute bound?  In this case you absolutely must
bust the display code out to a seperate process (using some form of
IPC or another), or drop the event handling code into a thread.  One
or the other, and neither one is currently done exactly in PLplot at
this time.

However, perhaps all you really want is for the output window to be a
bit more useufl and "alive" or "reactive" during moments when the user
wants to interact with it.  In this case, you might be very satisifed
with the plframe widget, which uses the xwin driver, but packages it
as a Tk widget.  Several of us have found this interaction paradigm to
be extremely satisfying as an "interactive PLplot" capability, and it
provides many possibilities for a nice looking GUI on a scientific
code. 

If you want to do this in a Python program, you'll need to build a
python that includes PLplot.  This is documented in the
bindings/python/readme file, but it is admittedly a nontrivial
undertaking.  If you get that done, however, you might try out
pytkdemo to get a feel for what the Python plframe widget support can
bring to your code.  It has some rough edges, for sure, but overall I
think you might find this very satisfying.

We have some work underway to simplify the process of introducing
PLplot and plframe in particular, to python, without having to do all
the complex stuff explained in bindings/python/readme, but this work
is outstanding at this time, and we cannot promise an ETA.  There are
some fairly complex issues involved.

 > I considered the following solutions:
 > 
 > a)Fork whenever a plot has to be drawn. 
 > [...]  Not good.

I agree, forking your whole compute/data intensive code just to make a
plot, sounds like massive overkill.

 > b) Fork a plotter on startup. Send commands and data to it via
 > IPC. Let it fork more processes do handle each window. No obvious
 > problems, but needs a IPC mechanism to be designed and implemented.

Right.  This is sort-of how the OS/2 PM driver works, and I think it
serves a valuable role in that environment.  A key difference is that
the OS/2 PM driver sends data through an OS/2 named pipe, to just a
single plot server process.  I think it was called pmserv or something
like that.  Anyway, you start that once, and then the OS/2 PM driver
just sends it plot commands over the named pipe (like a Unix fifo).
This notion could be carried over to X as well, and I agree there
could be some major benefits to this model.  The IPC could be done
with either sockets or shared memory, and I think this idea has some
real merit.  The OS/2 PM driver could serve as an excellent stepping
stone in the construction of a standalone X driver, as well.

One significant drawback of this approach, is that many people
currently capture the X window id from PLplot's xwin driver, and use
it for other stuff too (or vice versa).  There have been posts to the
PLplot mailing list over the years that have made it clear that some
people are sharing the X window betwen PLplot and the rest of their
code, for whatever purposes they may have for such activity.  I think
this would be hard or perhaps next to impossible with this bifurcated
X driver notion.  But maybe not.  X has this "reparenting" notion, so
that actually X windows in a single app can actually be driven by
seperate processes.  So I don't know, perhaps there could be joy down
this path too.

All in all, its a very complex set of issues.  I am pesonally inclined
to think that a freestanding X driver operating analogously to the
OS/2 PM driver, would be a good thing for PLplot, and implemented over
sockets.  But this is not under development at this time.

 > c) Generate immediate plmeta-represenation in the main process and
 > fork()/exec(plrender) to display it. This could even provide interactive
 > data readout via fifo. Drawback: plrender cannot read from a pipe or a 
 > fifo(fgetpos fails). This means
 > 
 >    + temporary files have to created
 >    
 >    + An existing plot-window cannot be updated or reused. Plrender will read
 >    to EOF and then wait for the window to be closed.
 >     
 > I really like c) because of its simplicity and because it is _almost_
 > working as I want. Now if just plrender could read from a fifo. 

I'm not sure how feasible it is to make plrender read from a fifo, or
a socket.  It might actually be easier for you to write your own
Tk-based plrender-like app that uses Tcl's "file event" thing to just
automatically notice when new plmeta files are "deposited" by your
main program.  So you could have a deal where you spin off (fork/exec
perhaps, or maybe just start it before by hand seperately) your Tk based
rendering engine.  Then you run your code and it drops distinct
metafiles from time to time, and then your one renderer notices when
they show up and renders them in turn.

But I wonder if you really need this.  It sounds like you might be
able to be happy with a PLplot-enhanced python, and using the
Plrame.py widget support.

 > Looking at plmeta.c it seems that writing to a pipe was considered
 > (but not finished, at least one more if(isfile) is needed), so it
 > may be possible to patch plrender to work from a pipe (perhaps
 > losing a feature or two), but I do not yet understand the code good
 > enough. Does anybody out there understand the design of plmeta
 > files?
 > 
 > Any other comments?

I'd probably look at the OS/2 PM driver if I was gonna start a new
seperate-process display capability.  I doubt plmeta and plrender are
really the most suitable starting place.  In particular, those codes
may be sufficiently complex that it might be challenging to keep them
doing their current job stably while adding in this fifo business.  

-- 
Geoffrey Furnish            Actel Corporation        fu...@ac...
Senior Staff Engineer      955 East Arques Ave       voice: 408-522-7528
Placement & Routing     Sunnyvale, CA   94086-4533   fax:   408-522-8041

[Plplot-general] Using plplot in an interactive environment

[Andreas D. <qu...@ma...>]

Hello.

I'm working on a little python module to provide interactive plotting
capabilities. Currently I have the following problem.

The xwin driver will not start redrawing the window before plend() is
called. Now the problem is, plend() will block until the window is closed (as
expected). I considered the following solutions:

a)Fork whenever a plot has to be drawn. 
 
Easy, but has a catch, as illustrated in this example: User has a big dataset
(50Mb, 100Mb or more) in core. He tries something, generates a plot. In this
implementaion the interpreter will fork, inheriting all of the fathers core
(Thanks to copy-on-write this does not immediatly mean that memory demand
doubles). User is not satisfied and tries some more things, in the end
having 6 plot windows open, each handled by a seperated process which
inherited the big data set from its father. Now imagine user scraps the
dataset (say, by reloading from disk): thanks to copy-on-write the OS will start
to look for memory to provide 6 useless copies of data to all those
plot-processes. Not good.

b) Fork a plotter on startup. Send commands and data to it via IPC. Let it
fork more processes do handle each window. No obvious problems, but needs a
IPC mechanism to be designed and implemented.

c) Generate immediate plmeta-represenation in the main process and
fork()/exec(plrender) to display it. This could even provide interactive
data readout via fifo. Drawback: plrender cannot read from a pipe or a 
fifo(fgetpos fails). This means

   + temporary files have to created
   
   + An existing plot-window cannot be updated or reused. Plrender will read
   to EOF and then wait for the window to be closed.
    
I really like c) because of its simplicity and because it is _almost_
working as I want. Now if just plrender could read from a fifo. 

Looking at plmeta.c it seems that writing to a pipe was considered (but not
finished, at least one more if(isfile) is needed), so it may be possible to
patch plrender to work from a pipe (perhaps losing a feature or two), but I
do not yet understand the code good enough. Does anybody out there
understand the design of plmeta files?

Any other comments?

thanks. Andreas



To get the plmeta driver to _write_ to a pipe only a minimal change was needed

--- plplot/drivers/plmeta.c.bak	Thu Feb  8 13:50:45 2001
+++ plplot/drivers/plmeta.c	Thu Feb  8 13:56:01 2001
@@ -622,6 +622,7 @@
 WriteFileHeader(PLStream *pls)
 {
     PLmDev *dev = (PLmDev *) pls->dev;
+    int isfile = (pls->output_type == 0);
     FILE *file = pls->OutFile;
 
     dbug_enter("WriteFileHeader(PLStream *pls");
@@ -631,10 +632,10 @@
 
 /* Write file index info.  Right now only number of pages. */
 /* The order here is critical */
-
-    if (pl_fgetpos(file, &dev->index_offset))
-	plexit("WriteFileHeader: fgetpos call failed");
-
+    if (isfile) {
+        if (pl_fgetpos(file, &dev->index_offset))
+            plexit("WriteFileHeader: fgetpos call failed");
+    }
     plm_wr( pdf_wr_header(pls->pdfs, "pages") );
     plm_wr( pdf_wr_2bytes(pls->pdfs, (U_SHORT) 0) );
 

-- 
"We've heard that a million monkeys at a million keyboards could produce the
complete works of Shakespeare. Now, thanks to the Internet, we know this is not
true."  -- Robert Wilensky

Re: [Plplot-general] changing plot labels

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

Look at
http://plplot.org/resources/docbook-manual/plplotdoc-html-0.4.1/annotation.html
where the tradeoffs between fixed and floating point labelling are
extensively discussed. Also follow the links to plprec, plsxax, plsyax, and
plszax.

These routines should give your users complete control over whether fixed
or floating point is used in their labels.

Fixed or floating point labels are often a matter of taste, so I will be
reluctant to make any large changes in the default decision (which can be
overridden as above) since a default satisfying one group of users might
piss off another group.

However, last year I did go through the code to refine the fixed versus
floating point labelling decision as much as possible so the new results
were in a small minority of cases that I tested not identical to those from
an older snapshot.  But with the new code the possibility of making a
nonsensical default decision is now reduced considerably.  (For example, the
old code did not properly account for the space taken up by the negative
sign on a label if the data range included both positive and negative
numbers.) Of course, be sure to send in a report if you find any bugs in the
current code for this fixed versus floating point labelling decision.

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 Tue, 6 Feb 2001, Michael wrote:

> Hi all,
> 
> I'm getting a release of software out that uses new plplot library.  My 
> users do not like the scale changes on the plots and want me to turn them 
> off.  The question is HOW?
> 
> I have not been able to find an option or setting to go back to the old 
> plot tick labels.  Please point me in the right direction.
> 
> To clarify what I mean.  The old plplot would label the tick marks on the 
> plots from .001 to .006.  The version I have up and running would change to 
> labels to be 1.0 to 6.0 and add a new label to show the scale.
> 
> Thanks, Michael
> 
> 
> _______________________________________________
> Plplot-general mailing list
> Plp...@pl...
> http://lists.sourceforge.net/lists/listinfo/plplot-general
> 

[Plplot-general] changing plot labels

[Michael <Mic...@ms...>]

Hi all,

I'm getting a release of software out that uses new plplot library.  My 
users do not like the scale changes on the plots and want me to turn them 
off.  The question is HOW?

I have not been able to find an option or setting to go back to the old 
plot tick labels.  Please point me in the right direction.

To clarify what I mean.  The old plplot would label the tick marks on the 
plots from .001 to .006.  The version I have up and running would change to 
labels to be 1.0 to 6.0 and add a new label to show the scale.

Thanks, Michael

Re: [Plplot-general] Windows Visual Studio Port ?

[Dirk E. <dir...@iw...>]

On 2001.01.30 17:45:04 -0500 Bryan Peterson wrote:
> I don't personally use Windows much (most of my work is on Linux and
> Compaq Unix) but one member of our group has compiled the  
> to run under windows using Visual Studio and even included the fortran
> support with Compaq Visual Fortran.  It hasn't been tested extensively
> but
> everything that he has tried has worked.  If anyone is interested either
> he or I can pass on his experience and hints on how to make it work.

Well, persoanlly I'm also using Linux ...
The main help would be to have the driver for the graphics (screen) output
in windows,
where there is only a dos-driver as far as I noticed.
If I could take the makefile (.dsw) of snapshot 990122 visual studio, I
could try
to get it running for 5.0.1.

Thanks for all the help!


Regards,
Dirk

> Bryan Peterson
> bry...@by...
> 
> On Tue, 30 Jan 2001, Alan W. Irwin wrote:
> 
> > I am probably the least qualified in the core team to answer your
> question
> > since I have no windows experience, but I will take a shot since nobody
> > else has answered you.
> > 
> > In all honesty our principal current platform focus is Linux/Unix, but
> I
> > understand we did have decent windows support in the past, and if
> someone
> > wants to improve that, then we are happy to cooperate with them.
> > 
> > With a browser I would look at a cvs web view of what we have in
> > plplot/sys/win32.  (See
> > http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/plplot/sys/win32/?cvsroot=plplot)
> > In particular I notice the file plplot/sys/win32/msdev/INSTALL.TXT
> which may
> > help to get you started.  Since plplot has substantially changed in the
> last
> > 4 years I expect some tweaking will be required to get it working again
> on
> > windows.  If you do get it working, please give us your changes so we
> can
> > put them into the CVS so all windows users will benefit.
> > 
> > Some related projects which might be of interest to you.
> > 
> > One of our users has just brought sys/dos/DJGGP up to snuff, and those
> > changes should soon be in the CVS head.
> > 
> > A member of the core team got plplot to work well in a cygwin (Unix on
> top
> > of Windows, see http://www.cygwin.com/) environment last year.  His
> stuff is
> > currently not ready to go into the CVS HEAD, but when that happens it
> will
> > mean a significant broadening of our platform support.
> > 
> > Alan W. Irwin
> > 
> > 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 Tue, 30 Jan 2001, Dirk Engelmann wrote:
> > 
> > > Hi!
> > > 
> > > Is there a port for Windows, eventually for Visual Studio
> > > available ?
> > > 
> > > 
> > > 
> > > Thanks for any hints!
> > > 
> > > Dirk Engelmann
> > > 
> > > 
> > > _______________________________________________
> > > Plplot-general mailing list
> > > Plp...@pl...
> > > http://lists.sourceforge.net/lists/listinfo/plplot-general
> > > 
> > 
> > 
> > _______________________________________________
> > Plplot-general mailing list
> > Plp...@pl...
> > http://lists.sourceforge.net/lists/listinfo/plplot-general
> > 
> 
> 
> _______________________________________________
> Plplot-general mailing list
> Plp...@pl...
> http://lists.sourceforge.net/lists/listinfo/plplot-general
> 

Re: [Plplot-general] Windows Visual Studio Port ?

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

Hello Bryan:

In any case I would urge your group member to upgrade to 5.0.1 (see the
5.0.1 file release at sourceforge.net/projects/plplot) since it is a much
more bug-fixed product than that old snapshot which we no longer support.

But beyond that it would be nice if they could provide me with a patch
between a clean tree (no created files such as binary objects or executables
and no CVS directories) of their results that has been upgraded to 5.0.1 and
a clean 5.0.1 tree.  If nothing else, the patch could consist of a file
telling how to get 5.0.1 installed on a current windows system, but I assume
there would be other changes to the sys/win32 tree as well. I would be
willing to facilitate getting that patch into our CVS so other windows users
could benefit from your group member's work.

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 Tue, 30 Jan 2001, Bryan Peterson wrote:

> I don't personally use Windows much (most of my work is on Linux and
> Compaq Unix) but one member of our group has compiled the snapshot 990122
> to run under windows using Visual Studio and even included the fortran
> support with Compaq Visual Fortran.  It hasn't been tested extensively but
> everything that he has tried has worked.  If anyone is interested either
> he or I can pass on his experience and hints on how to make it work.
> 
> Bryan Peterson
> bry...@by...

Re: [Plplot-general] Windows Visual Studio Port ?

[Bryan P. <pet...@ma...>]

I don't personally use Windows much (most of my work is on Linux and
Compaq Unix) but one member of our group has compiled the snapshot 990122
to run under windows using Visual Studio and even included the fortran
support with Compaq Visual Fortran.  It hasn't been tested extensively but
everything that he has tried has worked.  If anyone is interested either
he or I can pass on his experience and hints on how to make it work.

Bryan Peterson
bry...@by...

On Tue, 30 Jan 2001, Alan W. Irwin wrote:

> I am probably the least qualified in the core team to answer your question
> since I have no windows experience, but I will take a shot since nobody
> else has answered you.
> 
> In all honesty our principal current platform focus is Linux/Unix, but I
> understand we did have decent windows support in the past, and if someone
> wants to improve that, then we are happy to cooperate with them.
> 
> With a browser I would look at a cvs web view of what we have in
> plplot/sys/win32.  (See
> http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/plplot/sys/win32/?cvsroot=plplot)
> In particular I notice the file plplot/sys/win32/msdev/INSTALL.TXT which may
> help to get you started.  Since plplot has substantially changed in the last
> 4 years I expect some tweaking will be required to get it working again on
> windows.  If you do get it working, please give us your changes so we can
> put them into the CVS so all windows users will benefit.
> 
> Some related projects which might be of interest to you.
> 
> One of our users has just brought sys/dos/DJGGP up to snuff, and those
> changes should soon be in the CVS head.
> 
> A member of the core team got plplot to work well in a cygwin (Unix on top
> of Windows, see http://www.cygwin.com/) environment last year.  His stuff is
> currently not ready to go into the CVS HEAD, but when that happens it will
> mean a significant broadening of our platform support.
> 
> Alan W. Irwin
> 
> 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 Tue, 30 Jan 2001, Dirk Engelmann wrote:
> 
> > Hi!
> > 
> > Is there a port for Windows, eventually for Visual Studio
> > available ?
> > 
> > 
> > 
> > Thanks for any hints!
> > 
> > Dirk Engelmann
> > 
> > 
> > _______________________________________________
> > Plplot-general mailing list
> > Plp...@pl...
> > http://lists.sourceforge.net/lists/listinfo/plplot-general
> > 
> 
> 
> _______________________________________________
> Plplot-general mailing list
> Plp...@pl...
> http://lists.sourceforge.net/lists/listinfo/plplot-general
> 

Re: [Plplot-general] Windows Visual Studio Port ?

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

I am probably the least qualified in the core team to answer your question
since I have no windows experience, but I will take a shot since nobody
else has answered you.

In all honesty our principal current platform focus is Linux/Unix, but I
understand we did have decent windows support in the past, and if someone
wants to improve that, then we are happy to cooperate with them.

With a browser I would look at a cvs web view of what we have in
plplot/sys/win32.  (See
http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/plplot/sys/win32/?cvsroot=plplot)
In particular I notice the file plplot/sys/win32/msdev/INSTALL.TXT which may
help to get you started.  Since plplot has substantially changed in the last
4 years I expect some tweaking will be required to get it working again on
windows.  If you do get it working, please give us your changes so we can
put them into the CVS so all windows users will benefit.

Some related projects which might be of interest to you.

One of our users has just brought sys/dos/DJGGP up to snuff, and those
changes should soon be in the CVS head.

A member of the core team got plplot to work well in a cygwin (Unix on top
of Windows, see http://www.cygwin.com/) environment last year.  His stuff is
currently not ready to go into the CVS HEAD, but when that happens it will
mean a significant broadening of our platform support.

Alan W. Irwin

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 Tue, 30 Jan 2001, Dirk Engelmann wrote:

> Hi!
> 
> Is there a port for Windows, eventually for Visual Studio
> available ?
> 
> 
> 
> Thanks for any hints!
> 
> Dirk Engelmann
> 
> 
> _______________________________________________
> Plplot-general mailing list
> Plp...@pl...
> http://lists.sourceforge.net/lists/listinfo/plplot-general
> 

Re: [Plplot-general] bug or "feature"?

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

It is a feature....;-)

If you look at
http://plplot.org/resources/docbook-manual/plplotdoc-html-0.4.1/plaxes.html
you see the following documentation which answers your question.

l: Labels axis logarithmically. This only affects the
labels, not the data, and so it is necessary to compute the logarithms of
data points before passing them to any of the drawing routines.

Alan W. Irwin

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 Mon, 29 Jan 2001, Cavendish McKay wrote:

> I would like to make a log-log plot of some data, and I'm working in tcl
> with the most recent version of plplot.  I understand (from the
> documentation) that when one defines logarithmic axes, xmin and xmax (as
> well as ymin and ymax) must be passed as the log of the desired values,
> but should this apply to the data, as well?  When I try to plot the value
> (40, 1.4975e-09), for example, (on a semilog plot), the point appears
> to end up at (40, 1e(1.4975e-09)).  Do I really need to take the log of
> all of my data points before plotting, or is this a bug?
> 
> Cavendish
> 
> ****************************************************************************
> * Cavendish McKay                             cm...@ga... *
> *                                                                          *
> *      You're in trouble when you find it's hard for you to smile          *
> *           A simple song might make it better for a little while.         *
> *                                            ---Sly and the Family Stone   *
> ****************************************************************************

[Plplot-general] Windows Visual Studio Port ?

[Dirk E. <Dir...@IW...>]

Hi!

Is there a port for Windows, eventually for Visual Studio
available ?



Thanks for any hints!

Dirk Engelmann

[Plplot-general] bug or "feature"?

[Cavendish M. <cm...@mo...>]

I would like to make a log-log plot of some data, and I'm working in tcl
with the most recent version of plplot.  I understand (from the
documentation) that when one defines logarithmic axes, xmin and xmax (as
well as ymin and ymax) must be passed as the log of the desired values,
but should this apply to the data, as well?  When I try to plot the value
(40, 1.4975e-09), for example, (on a semilog plot), the point appears
to end up at (40, 1e(1.4975e-09)).  Do I really need to take the log of
all of my data points before plotting, or is this a bug?

Cavendish

****************************************************************************
* Cavendish McKay                             cm...@ga... *
*                                                                          *
*      You're in trouble when you find it's hard for you to smile          *
*           A simple song might make it better for a little while.         *
*                                            ---Sly and the Family Stone   *
****************************************************************************

Re: [Plplot-general] Is PLplot the tool for us?

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

To get a feel for what plplot is capable of check out the results of our C
demos at http://plplot.org/examples/index.html. These examples should go a
long way toward rapidly answering your questions.

Of course, we have more front ends than just C.

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, 26 Jan 2001, Silje Helfjord wrote:

> Hi,
> 
> we're planning a new version of our vizualisation software and are looking
> for new and better solutions for some areas. We need a good tool for 2D
> plotting and are considering PLplot.
> 
> What I'm wondering about is if anyone had time to go over my list and tell
> me if PLplot  has these capabilities.
> 
> 1. Supports curves and scatter plotting with multiple series.
> 2. Multiple plot windows simultaniously
> 3. Plotting a variable against time
> 4. Export of plot-data to ASCII file
> 5. Printing as bitmap
> 6. Supports true vector line drawing for output of plots(for both Win and
> Unix)
> 7. User interactions with plot. (Picking values, ...)
> 8. Formatting plots
> 	- Specifying axis scaling
> 	- Showing grid lines
> 
> If someone could tell me PLplot's possibilities in these areas, they would
> save me a lot of time and I would be very grateful!
> 
> Thanks :)
> 
> ________________________________________
> Silje Helfjord, Software Developer
> Ceetron ASA
> P.O.Box 1247 Pirsenteret
> N-7462 Trondheim, Norway
> E-mail: sil...@ce...
> http://www.ceetron.com
> 
> 
> _______________________________________________
> Plplot-general mailing list
> Plp...@pl...
> http://lists.sourceforge.net/lists/listinfo/plplot-general
> 

RE: [Plplot-general] Is PLplot the tool for us?

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

Silje Helfjord writes:
 > Hi,
 > 
 > we're planning a new version of our vizualisation software and are looking
 > for new and better solutions for some areas. We need a good tool for 2D
 > plotting and are considering PLplot.
 > 
 > What I'm wondering about is if anyone had time to go over my list and tell
 > me if PLplot  has these capabilities.

PLplot is mostly a graphics API library.  You write code (C, C++,
Fortran, Tcl, Python) to call library functions to get plots made.
With that context:

 > 1. Supports curves and scatter plotting with multiple series.

You can issue calls to draw multiple independent polylines in a given
viewport. These individual polylines can be drawn with various colors
and linestyles.  You can also make scatter plots, either with points,
or with other symbols.

 > 2. Multiple plot windows simultaniously

You can have multiple viewports onto an output device.  However, when
you issue plotting output calls, they go to the current default
viewport, rather than having you specify a "viewport id" with each
call.  I don't have a total recollection of everything in PLplot, but
I don't think there exists an api to set the current viewport out of
those defined for the current page.  But you can draw into multiple
viewports on one page, one at a time.

Alternatively, if you use something like the Tk plframe widget, you
can have multiple plframe widgets active in the code at the same time,
and send plots to any of them in any order you like.  If you had one
viewport per plframe, that might get you what you're after.  But
that's a Tk capability.  I don't know how you would translate
something like that to a printer context.  OTOH, simultaneity probably
only matters for gui output.

Also, if you are not using Tk, but are using X, you can create your
own X windows, and associate PLplot output streams with them, and
drive multiple X output windows simultaneously in that way.  There is
an API for setting the current PLplot output stream, and you can have
as many active as you like.  Just set the stream to the right one,
then call the PLplot API that draws the data, then switch streams,
etc.  In this model you would again have one viewport per stream, but
that might be a way to get what you want.

 > 3. Plotting a variable against time

You can define the meanings and the scales of the axes, and make them
anything you wnat.

There is also a recently added "stripchart" facility that allows a
dynamically updating display (on X).  Very cool.

 > 4. Export of plot-data to ASCII file

This would not be a function of PLplot per se.  PLplot is basically a
graphics API library.  You could build a more general interactive data
modelling and plotting tool with it, but such efforts have not been
incorporated into the PLplot project at this time.

 > 5. Printing as bitmap

There are bitmap (for the web) drivers in some stages of development
and deployment, but I would not feel comfortable answering an
unqualified "yes" to this at this time.

 > 6. Supports true vector line drawing for output of plots(for both Win and
 > Unix)

Yes.  For printer-type output devices, absolutely.  If you want GUI
output on WXX, I'm not really personally in-the-know about our
capabilities in that area.

 > 7. User interactions with plot. (Picking values, ...)

Yes, in the X and Tk drivers.

 > 8. Formatting plots
 > 	- Specifying axis scaling
 > 	- Showing grid lines

yes.

 > If someone could tell me PLplot's possibilities in these areas, they would
 > save me a lot of time and I would be very grateful!

You could benefit a lot by just building the C demos and running
them.  In just a few minutes you would be able to get a pretty good
overview for the plot types that are supported.  Alternatively, go to:
	 http://www.plplot.org/examples/index.html
This has pretty much the same info as you would get by compiling and
running them yourself, except you can't see the code directly at the
web site.  But the examples are pretty straightforward, so if you get
the package, you can quickly evaluate what it is like to be a PLplot
client. 

Finally, PLplot is an open development project, so if you make
enhancements to PLplot for your own project, and contribute them back,
they can be incorporated.  Now that we're hosted at sourceforge, we
have pretty much overcome the patch-application-overload bottleneck of
the past.

Best regards,

-- 
Geoffrey Furnish            Actel Corporation        fu...@ac...
Senior Staff Engineer      955 East Arques Ave       voice: 408-522-7528
Placement & Routing     Sunnyvale, CA   94086-4533   fax:   408-522-8041

[Plplot-general] Is PLplot the tool for us?

[Silje H. <sil...@ce...>]

Hi,

we're planning a new version of our vizualisation software and are looking
for new and better solutions for some areas. We need a good tool for 2D
plotting and are considering PLplot.

What I'm wondering about is if anyone had time to go over my list and tell
me if PLplot  has these capabilities.

1. Supports curves and scatter plotting with multiple series.
2. Multiple plot windows simultaniously
3. Plotting a variable against time
4. Export of plot-data to ASCII file
5. Printing as bitmap
6. Supports true vector line drawing for output of plots(for both Win and
Unix)
7. User interactions with plot. (Picking values, ...)
8. Formatting plots
	- Specifying axis scaling
	- Showing grid lines

If someone could tell me PLplot's possibilities in these areas, they would
save me a lot of time and I would be very grateful!

Thanks :)

________________________________________
Silje Helfjord, Software Developer
Ceetron ASA
P.O.Box 1247 Pirsenteret
N-7462 Trondheim, Norway
E-mail: sil...@ce...
http://www.ceetron.com

Re: [Plplot-general] tcl and [incr tcl]

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

My comments apply to the latest stable plplot release, 5.0.1, which you
should get from www.sourceforge.net/projects/plplot as a file release.
This release supersedes any of our previous releases.

plplot-5.0.1 works well on Debian potato which has tcl/tk 8.2, and itcl3.1.
However, it does not work well in RedHat 6.2 which has tcl/tk 8.0.  So if
the configuration finds tcl/tk 8.0 or 8.1 it warns the user those those old
versions aren't supported and it disables tcl/tk.  The rest of plplot is
fine on RedHat 6.2.  For example, all cdemos, fdemos, and xw??.py demos run
well in that environment.

I assume that plplot will work well (including tcl and tk) on RedHat 7.0
since that distribution includes tcl/tk 8.3 and itcl3.1, but we don't
currently have a test box to make sure, so any reports would be welcome.

For other situations make sure you have at least tcl/tk 8.2, and you should
be all right.  

If you re-read your itcl documentation, my guess is they say that tcl/tk 8.0
is required *at minimum*.  Our minimum is a little higher (8.2) and works
well with itcl3.1.

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, 25 Jan 2001, Cavendish McKay wrote:

> I'm a little confused about tcl and [incr tcl] dependencies for
> plplot.  Plplot doesn't want to compile with tcl 8.0, but the latest
> version of [incr tcl] I have found seems to require tcl 8.0.x.  Am I
> missing something somewhere?
> 
> Cavendish
> ****************************************************************************
> * Cavendish McKay                             cm...@ga... *
> *                                                                          *
> *      You're in trouble when you find it's hard for you to smile          *
> *           A simple song might make it better for a little while.         *
> *                                            ---Sly and the Family Stone   *
> ****************************************************************************
> 
> 
> _______________________________________________
> Plplot-general mailing list
> Plp...@pl...
> http://lists.sourceforge.net/lists/listinfo/plplot-general
>