plplot-devel — Technical discussion about PLplot development

[Plplot-devel] Suggested API change for plpoly3

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

The current plpoly3 API is

c_plpoly3(PLINT n, PLFLT *x, PLFLT *y, PLFLT *z, PLINT *draw)

where abs(n) is the dimension of the x, y, z, and draw arrays.

The sign of n is used for an entirely different purpose, if positive, the
points are drawn in a clockwise way, if negative they are drawn
counter-clockwise way, and this direction of drawing combined with the point
data affects the choice of whether the 3D polygon is facing the viewer or
not and whether it will be drawn or not.

On general grounds, I would prefer to separate the two different purposes
(dimensions and clockwise flag) into two separate parameters.  Also, our
python, yorick, and java front ends carry the dimensions of vectors as part
of the array object, and those dimensions cannot be negative.  So in any
case I want to make a C function which is identical to plpoly3 except its
first argument is not allowed to be negative and it has an additional
(sixth) argument which is a clockwise flag.  This C function will be the
one wrapped for python (and presumably the other front ends with vector
objects).

That leaves the question of what to do with plpoly3, and I especially invite
Maurice and Geoffrey to discuss this.  Should we preserve it for a while as
a deprecated function that we will eventually drop? Or should we simply
change the argument list of plpoly3 so that it has the required 6 arguments?
If the latter, does that mean everybody would have to change any programme
that called plpoly3 or would a 5-argument call still work with the 6th
argument being taken as NULL? I am showing my complete ignorance of the
consequences of increasing the number of arguments for a shared library, and
I don't really know what compiler error (if any) or warning would result
from a 5 parameter call to a function which is declared in a header to have
6 parameters.  But I am prepared to be educated on these matters....;-)

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] python interface changes

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

To be compatible with the C interface to PLPlot, I am redefining the PARSE
constant names available from the python pl module using the prefix PL_ on
all names.  So what before was defined as PARSE_FULL for the pl module is
now defined as PL_PARSE_FULL, for example.

I have also been trying out the swig method for generating plmodule.c (which
automatically generates the PARSE constants with the correct names which
first drew my attention to the above problem with the hand-crafted
plmodule.c). There are still 7 minor issues affecting mostly xw08.py,
xw09.py, xw16.py and xw18.py in the swig-based approach. I am discussing
those with Gary Bishop.  The remaining examples work great with plmodule.c
generated by the swig approach and the double-precision form of the plplot
library.  This is an encouraging preliminary result. I am also discussing
with Gary the possibility of using the single-precision plplot library with
the swig-generated plmodule.c which would be a nice improvement on the
current hand-crafted plmodule.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
__________________________

[Plplot-devel] Re: Interesting Linux stuff going on at WalMart

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

OOPS.  I mis-posted my WalMart/Linux remarks to plplot_devel rather than the
correct list, the Victoria Linux Users Group mailing list. Even though
off-topic, I hope you enjoyed my remarks anyway....;-)

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] Interesting Linux stuff going on at WalMart

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

WalMart has been willing to thumb their nose at MS and sell computers
without the MS OS for some time, and now they have made a deal with Lindows
to pre-install Linux.  (See http://lwn.net/Articles/2658/ and
http://www.internetnews.com/infra/article.php/1366951). Note, these models
are apparently only available from their webstore and not their bricks and
mortar stores.

Ordinarily, I don't have much time for WalMart, but I believe it is
extremely significant that such a large chain as this is preinstalling Linux
on a variety (8 different models, IIRC) of their computers.  I suspect Linux
market share is going to skyrocket as the result of this deal because one of
the huge bottlenecks for Linux adoption has been the difficulty in getting
*large* vendors to preinstall it. Of course, the likes of Pogo have been
around for some time to preinstall Linux for you, but they just don't have
the marketing clout of a WalMart.  Anyhow, it is quite a sign that Linux is
on the edge of becoming mainstream for the home market, and this deal must
have MS gritting their teeth in fear and anger.

I know nothing about Lindows except that they staved off a suit by MS on
their name.  Some better-known distribution such as elx or lycoris may have
been a better choice for WalMart.  Nevertheless, the point is these
preinstalled PC's must be Linux compatible so you should be able to easily
install another distribution if you so choose.  Or you should be able to buy
the WalMart OS-less model and install Linux if it is identical to the
hardware on the Linux pre-installed model.

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] Recent CVS changes

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

(1) pbm.c driver changes donated by Gary Bishop which allow you to change
the size and background color.  I have only done minimalist testing of these
changes so if any of you have an interest in the pbm driver, please give
this a hammering.

(2) xw17.py donated by Gary Bishop.  This gives equivalent of x17c, but
the xw17.py results are different each time (and different from the
constant x17c results) because the python random generator is different
from drand48 used in x17c.c.  Also, the x17c.c result uses a constant
seed while the python random number generator picks a seed depending on
the time of day.

(3) plmodule.c changes to implement python wrappers for plstripa, plstripc,
and plstripd.  These are required for xw17.py to work.

I did this last change by hand, but that may be the last time I do so. Gary
has used an entirely different swig-based approach for generating the python
wrappers which I intend to evaluate soon.  Similar in spirit to the tcl
interface, I may want to adapt his approach to a semi-automated method where
swig would generate all the generic python wrappers.  These would be
supplemented by hand-built wrappers for the difficult cases.  I believe such
a semi-automated approach is a lot easier to maintain than the current
plmodule.c which is completely built by hand (and where there is presumably
key functionality such as the recently discovered plstrip[acd] still missing
from the resulting plplot API for python).

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] Please test the new setup.py python module build

[<jc...@fe...>]

On Saturday 08 June 2002 20:45, Alan W. Irwin wrote:
| In CVS I have replaced the old deprecated "Makefile.pre.in" method of
| building plplot python extension modules in Unix/Linux with the new,
| approved "setup.py" method.
|
| This new method works fine on my Debian system.  An incomplete test
| on RH 7.2 (which uses python-1.5) also worked fine.
|
| Olof et al. also recently adopted the "setup.py" method to build the
| python plplot extension modules on the sys/win32/msdev/ platform.
|
| Those of you with an interest in python on either Unix or windows are
| urged to give these changes a try from the latest CVS version of
| PLplot.

Hi,

pythondemos.py and prova.py work in the tmp directory on (a not clean)=20
suse-7.2 with python-2.0 and PyQt-2.4

Joao

[Plplot-devel] Please test the new setup.py python module build

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

In CVS I have replaced the old deprecated "Makefile.pre.in" method of
building plplot python extension modules in Unix/Linux with the new,
approved "setup.py" method.

This new method works fine on my Debian system.  An incomplete test on
RH 7.2 (which uses python-1.5) also worked fine.

Olof et al. also recently adopted the "setup.py" method to build the
python plplot extension modules on the sys/win32/msdev/ platform.

Those of you with an interest in python on either Unix or windows are
urged to give these changes a try from the latest CVS version of PLplot.

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] My example consistency work is done except for java

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

Alan,

Thank you very much.  This was a very substantial undertaking, and I
really appreciate your sticktuitiveness which brought this to such an
important conclusion.

Alan W. Irwin writes:
 > I just got rid of the last major discrepancies to be found between the
 > examples for the C, tcl, and python (and yorick) front ends for examples
 > 1-18, excluding 14 and 17.  I will do the same for java as soon as the
 > appropriate additions to javabind.c have been made by Geoffrey.  I encourage
 > others to make the examples similarly consistent for Octave and fortran.
 > Java and those two front ends are the top consistency priority now, but when
 > the C++ and perl examples are completed, I suggest every effort should be
 > made to produce consistent example results there as well.
 > 
 > Consistent postscript results for every front end for each of the examples
 > are boring (;-)), but such results are an excellent consistency check that
 > the plplot API has been implemented properly for every front end and also
 > an excellent teaching tool if somebody is trying to expand their knowledge
 > of plplot to more than one front end.
 > 
 > If you change any of these examples for any of the front ends (i.e.,
 > something as simple as a colour or line width change) I would appreciate you
 > doing it for all front ends to maintain the consistency that I have now
 > achieved.

[Plplot-devel] My example consistency work is done except for java

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

I just got rid of the last major discrepancies to be found between the
examples for the C, tcl, and python (and yorick) front ends for examples
1-18, excluding 14 and 17.  I will do the same for java as soon as the
appropriate additions to javabind.c have been made by Geoffrey.  I encourage
others to make the examples similarly consistent for Octave and fortran.
Java and those two front ends are the top consistency priority now, but when
the C++ and perl examples are completed, I suggest every effort should be
made to produce consistent example results there as well.

Consistent postscript results for every front end for each of the examples
are boring (;-)), but such results are an excellent consistency check that
the plplot API has been implemented properly for every front end and also
an excellent teaching tool if somebody is trying to expand their knowledge
of plplot to more than one front end.

If you change any of these examples for any of the front ends (i.e.,
something as simple as a colour or line width change) I would appreciate you
doing it for all front ends to maintain the consistency that I have now
achieved.

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] help with plplot

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

We have a home-brew way to find where the python directories are which is
suitable for the systems we are familiar with. But when that configuration
system breaks down (as I did recently for RedHat 7.2 and from your report it
sounds like the same thing is happening for MacOS X) we can override the
system in the following way:

PY_VERSION=python -c 'import sys ; print sys.version[0:3]'
export
PYTHON_INC_DIR=/usr/include/python${PY_VERSION}/
echo PYTHON_INC_DIR=${PYTHON_INC_DIR}
export PYTHON_MOD_DIR=/usr/lib/python${PY_VERSION}/
export PYTHON_CFG_DIR=${PYTHON_MOD_DIR}/config
export PYTHON_NUM_DIR=${PYTHON_INC_DIR}/Numeric/
export PYTHON_MACH_DIR=${PYTHON_MOD_DIR}/site-packages
export PYTHON_DIR=${PYTHON_MACH_DIR}

./configure ....

You will have to adjust these lines for the locations of the python files in
your system.  Also, these lines are specific to the bash shell environment so
you may have to adjust the syntax if you are using something else on MacOS X.

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, 4 Jun 2002, D tang wrote:

> Hello,
>
> When I do the './configure' I get this error
>
> checking for Python.h... no
> warning: can't find Python.h, setting enable_python to
> no
>
> how can I solve this problem?
>
> I am using the MaC OS X/darwin operating system!
>
> Thanks
>
> Dustin
>
>
>
> ______________________________________________________________________
> Movies, Music, Sports, Games! http://entertainment.yahoo.ca
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

[Plplot-devel] help with plplot

[D t. <dus...@ya...>]

Hello,

When I do the './configure' I get this error

checking for Python.h... no
warning: can't find Python.h, setting enable_python to
no

how can I solve this problem? 

I am using the MaC OS X/darwin operating system!

Thanks 

Dustin



______________________________________________________________________ 
Movies, Music, Sports, Games! http://entertainment.yahoo.ca

[Plplot-devel] SWIG-based wrapper for PLplot

[Gary B. <gb...@cs...>]

I figured out plshade1. I also realized that a list of what *is* wrapped might 
be more useful than a list of what is *not*. Here is the list from the 
generated .c file.

static PyMethodDef SwigMethods[] = {
         { (char *)"pladv", _wrap_pladv, METH_VARARGS },
         { (char *)"plarrows", _wrap_plarrows, METH_VARARGS },
         { (char *)"plaxes", _wrap_plaxes, METH_VARARGS },
         { (char *)"plbin", _wrap_plbin, METH_VARARGS },
         { (char *)"plbop", _wrap_plbop, METH_VARARGS },
         { (char *)"plbox", _wrap_plbox, METH_VARARGS },
         { (char *)"plbox3", _wrap_plbox3, METH_VARARGS },
         { (char *)"plxormod", _wrap_plxormod, METH_VARARGS },
         { (char *)"plcol0", _wrap_plcol0, METH_VARARGS },
         { (char *)"plcol1", _wrap_plcol1, METH_VARARGS },
         { (char *)"pltr0", _wrap_pltr0, METH_VARARGS },
         { (char *)"pltr1", _wrap_pltr1, METH_VARARGS },
         { (char *)"pltr2", _wrap_pltr2, METH_VARARGS },
         { (char *)"plcont", _wrap_plcont, METH_VARARGS },
         { (char *)"plcpstrm", _wrap_plcpstrm, METH_VARARGS },
         { (char *)"pldid2pc", _wrap_pldid2pc, METH_VARARGS },
         { (char *)"pldip2dc", _wrap_pldip2dc, METH_VARARGS },
         { (char *)"plend", _wrap_plend, METH_VARARGS },
         { (char *)"plend1", _wrap_plend1, METH_VARARGS },
         { (char *)"plenv", _wrap_plenv, METH_VARARGS },
         { (char *)"pleop", _wrap_pleop, METH_VARARGS },
         { (char *)"plerrx", _wrap_plerrx, METH_VARARGS },
         { (char *)"plerry", _wrap_plerry, METH_VARARGS },
         { (char *)"plfamadv", _wrap_plfamadv, METH_VARARGS },
         { (char *)"plfill", _wrap_plfill, METH_VARARGS },
         { (char *)"plfill3", _wrap_plfill3, METH_VARARGS },
         { (char *)"plflush", _wrap_plflush, METH_VARARGS },
         { (char *)"plfont", _wrap_plfont, METH_VARARGS },
         { (char *)"plfontld", _wrap_plfontld, METH_VARARGS },
         { (char *)"plgchr", _wrap_plgchr, METH_VARARGS },
         { (char *)"plgcol0", _wrap_plgcol0, METH_VARARGS },
         { (char *)"plgcolbg", _wrap_plgcolbg, METH_VARARGS },
         { (char *)"plgcompression", _wrap_plgcompression, METH_VARARGS },
         { (char *)"plgdev", _wrap_plgdev, METH_VARARGS },
         { (char *)"plgdidev", _wrap_plgdidev, METH_VARARGS },
         { (char *)"plgdiori", _wrap_plgdiori, METH_VARARGS },
         { (char *)"plgdiplt", _wrap_plgdiplt, METH_VARARGS },
         { (char *)"plgfam", _wrap_plgfam, METH_VARARGS },
         { (char *)"plgfnam", _wrap_plgfnam, METH_VARARGS },
         { (char *)"plglevel", _wrap_plglevel, METH_VARARGS },
         { (char *)"plgpage", _wrap_plgpage, METH_VARARGS },
         { (char *)"plgra", _wrap_plgra, METH_VARARGS },
         { (char *)"plgspa", _wrap_plgspa, METH_VARARGS },
         { (char *)"plgstrm", _wrap_plgstrm, METH_VARARGS },
         { (char *)"plgver", _wrap_plgver, METH_VARARGS },
         { (char *)"plgxax", _wrap_plgxax, METH_VARARGS },
         { (char *)"plgyax", _wrap_plgyax, METH_VARARGS },
         { (char *)"plgzax", _wrap_plgzax, METH_VARARGS },
         { (char *)"plhist", _wrap_plhist, METH_VARARGS },
         { (char *)"plhls", _wrap_plhls, METH_VARARGS },
         { (char *)"plinit", _wrap_plinit, METH_VARARGS },
         { (char *)"pljoin", _wrap_pljoin, METH_VARARGS },
         { (char *)"pllab", _wrap_pllab, METH_VARARGS },
         { (char *)"pllightsource", _wrap_pllightsource, METH_VARARGS },
         { (char *)"plline", _wrap_plline, METH_VARARGS },
         { (char *)"plline3", _wrap_plline3, METH_VARARGS },
         { (char *)"pllsty", _wrap_pllsty, METH_VARARGS },
         { (char *)"plmap", _wrap_plmap, METH_VARARGS },
         { (char *)"plmeridians", _wrap_plmeridians, METH_VARARGS },
         { (char *)"plmesh", _wrap_plmesh, METH_VARARGS },
         { (char *)"plmkstrm", _wrap_plmkstrm, METH_VARARGS },
         { (char *)"plmtex", _wrap_plmtex, METH_VARARGS },
         { (char *)"plot3d", _wrap_plot3d, METH_VARARGS },
         { (char *)"plotsh3d", _wrap_plotsh3d, METH_VARARGS },
         { (char *)"plpat", _wrap_plpat, METH_VARARGS },
         { (char *)"plpoin", _wrap_plpoin, METH_VARARGS },
         { (char *)"plpoin3", _wrap_plpoin3, METH_VARARGS },
         { (char *)"plpoly3", _wrap_plpoly3, METH_VARARGS },
         { (char *)"plprec", _wrap_plprec, METH_VARARGS },
         { (char *)"plpsty", _wrap_plpsty, METH_VARARGS },
         { (char *)"plptex", _wrap_plptex, METH_VARARGS },
         { (char *)"plreplot", _wrap_plreplot, METH_VARARGS },
         { (char *)"plrgb", _wrap_plrgb, METH_VARARGS },
         { (char *)"plrgb1", _wrap_plrgb1, METH_VARARGS },
         { (char *)"plschr", _wrap_plschr, METH_VARARGS },
         { (char *)"plscmap0n", _wrap_plscmap0n, METH_VARARGS },
         { (char *)"plscmap1n", _wrap_plscmap1n, METH_VARARGS },
         { (char *)"plscmap0", _wrap_plscmap0, METH_VARARGS },
         { (char *)"plscmap1", _wrap_plscmap1, METH_VARARGS },
         { (char *)"plscmap1l", _wrap_plscmap1l, METH_VARARGS },
         { (char *)"plscol0", _wrap_plscol0, METH_VARARGS },
         { (char *)"plscolbg", _wrap_plscolbg, METH_VARARGS },
         { (char *)"plscolor", _wrap_plscolor, METH_VARARGS },
         { (char *)"plscompression", _wrap_plscompression, METH_VARARGS },
         { (char *)"plsdev", _wrap_plsdev, METH_VARARGS },
         { (char *)"plsdidev", _wrap_plsdidev, METH_VARARGS },
         { (char *)"plsdimap", _wrap_plsdimap, METH_VARARGS },
         { (char *)"plsdiori", _wrap_plsdiori, METH_VARARGS },
         { (char *)"plsdiplt", _wrap_plsdiplt, METH_VARARGS },
         { (char *)"plsdiplz", _wrap_plsdiplz, METH_VARARGS },
         { (char *)"plsesc", _wrap_plsesc, METH_VARARGS },
         { (char *)"pl_setcontlabelparam", _wrap_pl_setcontlabelparam, 
METH_VARARGS },
         { (char *)"pl_setcontlabelformat", _wrap_pl_setcontlabelformat, 
METH_VARARGS },
         { (char *)"plsfam", _wrap_plsfam, METH_VARARGS },
         { (char *)"plsfnam", _wrap_plsfnam, METH_VARARGS },
         { (char *)"plshade", _wrap_plshade, METH_VARARGS },
         { (char *)"plshade1", _wrap_plshade1, METH_VARARGS },
         { (char *)"plsmaj", _wrap_plsmaj, METH_VARARGS },
         { (char *)"plsmin", _wrap_plsmin, METH_VARARGS },
         { (char *)"plsori", _wrap_plsori, METH_VARARGS },
         { (char *)"plspage", _wrap_plspage, METH_VARARGS },
         { (char *)"plspause", _wrap_plspause, METH_VARARGS },
         { (char *)"plsstrm", _wrap_plsstrm, METH_VARARGS },
         { (char *)"plssub", _wrap_plssub, METH_VARARGS },
         { (char *)"plssym", _wrap_plssym, METH_VARARGS },
         { (char *)"plstar", _wrap_plstar, METH_VARARGS },
         { (char *)"plstart", _wrap_plstart, METH_VARARGS },
         { (char *)"plstripc", _wrap_plstripc, METH_VARARGS },
         { (char *)"plstripa", _wrap_plstripa, METH_VARARGS },
         { (char *)"plstripd", _wrap_plstripd, METH_VARARGS },
         { (char *)"plimage", _wrap_plimage, METH_VARARGS },
         { (char *)"plstyl", _wrap_plstyl, METH_VARARGS },
         { (char *)"plsvpa", _wrap_plsvpa, METH_VARARGS },
         { (char *)"plsxax", _wrap_plsxax, METH_VARARGS },
         { (char *)"plsxwin", _wrap_plsxwin, METH_VARARGS },
         { (char *)"plsyax", _wrap_plsyax, METH_VARARGS },
         { (char *)"plsym", _wrap_plsym, METH_VARARGS },
         { (char *)"plszax", _wrap_plszax, METH_VARARGS },
         { (char *)"pltext", _wrap_pltext, METH_VARARGS },
         { (char *)"plvasp", _wrap_plvasp, METH_VARARGS },
         { (char *)"plvpas", _wrap_plvpas, METH_VARARGS },
         { (char *)"plvpor", _wrap_plvpor, METH_VARARGS },
         { (char *)"plvsta", _wrap_plvsta, METH_VARARGS },
         { (char *)"plw3d", _wrap_plw3d, METH_VARARGS },
         { (char *)"plwid", _wrap_plwid, METH_VARARGS },
         { (char *)"plwind", _wrap_plwind, METH_VARARGS },
         { (char *)"plsError", _wrap_plsError, METH_VARARGS },
         { (char *)"plClearOpts", _wrap_plClearOpts, METH_VARARGS },
         { (char *)"plResetOpts", _wrap_plResetOpts, METH_VARARGS },
         { (char *)"plSetUsage", _wrap_plSetUsage, METH_VARARGS },
         { (char *)"plsetopt", _wrap_plsetopt, METH_VARARGS },
         { (char *)"plSetOpt", _wrap_plSetOpt, METH_VARARGS },
         { (char *)"plParseOpts", _wrap_plParseOpts, METH_VARARGS },
         { (char *)"plOptUsage", _wrap_plOptUsage, METH_VARARGS },
         { (char *)"plHLS_RGB", _wrap_plHLS_RGB, METH_VARARGS },
         { (char *)"plRGB_HLS", _wrap_plRGB_HLS, METH_VARARGS },

Re: [Plplot-devel] x16.java ready for testing

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

Hello Geoffrey:

x18.java is done.  Thus, "later this week" turned out to be two hours later.
It usually works the other way....;-) This example will test pls.poly3 and
pls.poin3 when you get to them.

This is my final java example for the forseeable future since I don't expect
we will be implementing examples 14, 17, 19, or 20 in java.

Here is what I see as the remaining ToDo list for java:

(1) Implement all the API demanded by the examples.  This affects x08.java
(pls.scmap1l), x16.java (pls.shade [only partially completed] and pls.shades),
and x18.java (pls.poly3 and pls.poin3).

(2) Cleanups: Drop redundant dimensions from pls.line and pls.poin that I
have discussed before.  You have also mentioned in
plplot/bindings/java/README.javaAPI: "[Update, 1/18/02: The plcont wrappers
do the 2-d lifetime management stuff right.  Other 2-d functions (using
jobjectarrays) should be retrofitted, and certainly new wrappers involving
2-d data args should be modelled after the plcont memory management style.]"
Does this still need to be done?

(3) Finish the remaining common API that is not tested by the examples.

I believe (1) should be our top priority since finishing the API used by the
examples is a worthy goal that can be accomplished fairly easily.

If (and I realize that is a big if) you also find the time to do (2) and (3)
in the next month or so I think that important completion of the java front
end would warrant putting out a new minor (5.1.1) release of plplot.

I hasten to add I have no definite release plans at this stage because there
have not been many important commits since 5.1.0.  But if something
important (such as finishing the java front end) does happen, I am willing
to do a 5.1.1 release so our ordinary users can access 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 Mon, 27 May 2002, Alan W. Irwin wrote:

> Hello Geoffrey,
>
> x16.java is now ready to test both pls.shade (the 1D and 2D x and y array
> part [including coordinate wrapping] that is not implemented yet) and
> pls.shades (not implemented at all yet).
>
> x18.java is the only remaining java example that I intend to write, and
> that should follow sometime later this week.
>
> 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
> __________________________
>
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

[Plplot-devel] SWIG wrapper of PLplot for Python.

[Gary B. <gb...@cs...>]

I think I've got an almost complete wrapper working for the PLplot API. The 
only functions not wrapped are:

plfcont, plshade1, plfshade, plgFileDevs, plgDevs, plsKeyEH, plsButtonEH, 
plsexit, pltr2p, pltr0f, pltr2f, plf2eval2, plf2eval, plf2evalr, plMergeOpts, 
pl?file, plgesc, pl_cmd, plFindName, plFindCommand, plGetName, plGetInt, 
plGetFlt, pl*2dGrid, plGetCursor, plTranslateCursor

I believe all of those could be done with some additional effort.

I believe this wrapper will work with PLFLT set to float but I haven't tried 
it.

My wrapper for plcont, plshade, and plstyl are different from those provided 
by plmodule.c. Mine adhere to the C-API like this:

plcont(2Darray z, int kx, int lx, int ky, int ly, 1Darray c, callable 
pltrfunc, object data)

The arrays are Numeric arrays. The "callable" is any Python function. It 
should take 2 or 3 arguments and return a sequence with 2 floats. The "data" 
is an arbitrary Python object.

I also wrapped pltr0, pltr1, and pltr2. They expect the "data" member above to 
be a sequence with 2 Numeric arrays of appropriate dimensions.

plshade(2darray z, left, right, bottom, top, smin, smax, scmap, scolor, 
swidth, min_color, min_width, max_color, max_width, rectangular, callable 
pltrfunc, data)

It would be easy to add the "defined" callback to this if there is interest.

plstyl(1darray, 1darray). No first numeric argument. Pass empty list to reset.

All the examples work with this wrapper after modifications to the calls of 
the above functions. The modifications make the python examples more similar 
to the c examples, including the use of mypltr in xw09.py.

Anyone is welcome to this wrapper if you want it.
gb

[Plplot-devel] x16.java ready for testing

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

Hello Geoffrey,

x16.java is now ready to test both pls.shade (the 1D and 2D x and y array
part [including coordinate wrapping] that is not implemented yet) and
pls.shades (not implemented at all yet).

x18.java is the only remaining java example that I intend to write, and
that should follow sometime later this week.

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] plcont/plshade/plshades wrap argument in Python API?

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

Yes, an extra array is required, but no, such an extra allocation, copy, and
eventually free is not that expensive compared with the cpu effort required
to actually plot.  As part of a recent debugging exercise on this I compared
wrapped results and "unwrapped" results where the extra set of points at
theta = 2 pi was allocated from the get go as part of the example rather
than relying on wrap to internally add a point at theta = 0. The plotted
results were identical, and I didn't notice any speed difference at all.

One other point I should have mentioned yesterday that should simplify your
swig life is we subdivide our public API into common API (internal name
starts with "c_", see the #defines in plplot/plplot.h) and the rest, which I
suppose you could also designate as the non-common public API.  The common
API idea historically started as that part of the public API that you could
easily implement from fortran, but it morphed to that part of the public API
that you want all your front ends (fortran, Tcl, python, java, etc.) to
implement since "the rest" are public C functions that are used internally
(often with difficult argument lists to interface) and which should
therefore not be implemented by the front ends.  From time to time we do
move functions from "the rest" to the common API or vice versa.  But when we
do that we are always careful to put the appropriate #defines into
plplot/plplot.h.  Thus, your swig effort can rely on those defines to find
the common API that needs a python interface, and skip the C functions that
are part of the public API but which are really meant for internal use only.

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 Sun, 26 May 2002, Gary Bishop wrote:

> > It's a flag which is 0 (no wrap), 1 (wrap first coordinate), or 2 (wrap
> > second coordinate).  This coordinate wrap idea got started with the Tcl API
> > and migrated to the python and java API's.  The idea is most useful when
> > dealing with polar coordinates (see polar examples for the contour plots
> > (xw09.py) and the shade plots (xw16.py).  When wrap is set, the first angle
> > point is duplicated as the last point by the interface code so that contours
> > and shades are smooth.
> >
>
> Thanks Alan,
>
> Doesn't "wrapping" like this imply allocating storage for another array? This
> could get expensive...
>
> Can anyone comment on the callbacks? Some of the comments in plmodule.c imply
> some of the callbacks aren't really implemented.
>
> gb
>
>

Re: [Plplot-devel] plcont/plshade/plshades wrap argument in Python API?

[Gary B. <gb...@cs...>]

> It's a flag which is 0 (no wrap), 1 (wrap first coordinate), or 2 (wrap
> second coordinate).  This coordinate wrap idea got started with the Tcl API
> and migrated to the python and java API's.  The idea is most useful when
> dealing with polar coordinates (see polar examples for the contour plots
> (xw09.py) and the shade plots (xw16.py).  When wrap is set, the first angle
> point is duplicated as the last point by the interface code so that contours
> and shades are smooth.
>

Thanks Alan,

Doesn't "wrapping" like this imply allocating storage for another array? This 
could get expensive...

Can anyone comment on the callbacks? Some of the comments in plmodule.c imply 
some of the callbacks aren't really implemented.

gb

Re: [Plplot-devel] plcont/plshade/plshades wrap argument in Python API?

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

I can answer (see below) all but the callback question, which I leave to the
others here.

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 Sun, 26 May 2002, Gary Bishop wrote:

> What is the "wrap" argument to some of the functions in the Python API?
>
> Is this some additional functionality that is not in the C api?

Yes.

It's a flag which is 0 (no wrap), 1 (wrap first coordinate), or 2 (wrap
second coordinate).  This coordinate wrap idea got started with the Tcl API
and migrated to the python and java API's.  The idea is most useful when
dealing with polar coordinates (see polar examples for the contour plots
(xw09.py) and the shade plots (xw16.py).  When wrap is set, the first angle
point is duplicated as the last point by the interface code so that contours
and shades are smooth.

BTW, it would be nice if this argument *was* in the C API.  To the C experts
here, is there a way to do that without messing up all those C users who
use the current C API without a wrap argument?

>
> I ask because I'm making a python wrapper with SWIG and I don't know how to
> handle this argument.
>
> I've got all the demos running with a SWIG description file that handles all
> the array/length tricks and handles the PLFLT double/float trick.

As I have told Gary privately before, getting double/float to work right for
the python binding would be a big win for the swig approach since that would
be a pain to hand code.

> It is mostly
> just a copy of the plplot.h file with some tricky SWIG typemaps.
>
> The complications are the irregular interfaces to plcont, plstyl, plshade*,
> etc. I can whip them with python help functions. Are these irregular
> interfaces documented anywhere?

Ultimately, they should be documented in a specialized python API chapter of
the documentation at
http://plplot.sourceforge.net/resources/docbook-manual/plplotdoc-html-0.4.3/
similar to the current Chapter 17 which attempts to deal with the
specialized fortran API.  But for now, the only place where they are
documented (actually not too badly if you look at the detailed comments)
is plmodule.c.

>
> Another question. Do the callback arguments get used for much? I believe I
> could set up the python interface to support python callbacks for these
> functions if it is worth the effort. The "data" argument would become an
> arbitrary Python object in that case. Should be fine.

I cannot answer this one.

Alan

[Plplot-devel] plcont/plshade/plshades wrap argument in Python API?

[Gary B. <gb...@cs...>]

What is the "wrap" argument to some of the functions in the Python API?

Is this some additional functionality that is not in the C api?

I ask because I'm making a python wrapper with SWIG and I don't know how to 
handle this argument.

I've got all the demos running with a SWIG description file that handles all 
the array/length tricks and handles the PLFLT double/float trick. It is mostly 
just a copy of the plplot.h file with some tricky SWIG typemaps.

The complications are the irregular interfaces to plcont, plstyl, plshade*, 
etc. I can whip them with python help functions. Are these irregular 
interfaces documented anywhere?

Another question. Do the callback arguments get used for much? I believe I 
could set up the python interface to support python callbacks for these 
functions if it is worth the effort. The "data" argument would become an 
arbitrary Python object in that case. Should be fine.

Thanks
gb

[Plplot-devel] pls.line and pls.poin arguments need to be changed

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

Hello Geoffrey:

I believe the java API model we are following is to drop all array
dimensions from java argument lists since that information is available from
the array objects.  That is, we are following an API model much like what is
done for the python binding. However, I have just discovered this model is
not followed for pls.line and pls.poin (probably because they were coded
early in the game).  (For pls.poin I am talking about the API variations with
x and y array arguments, not the variations called with one particular (x,y)
point.) Would you be willing to change javabind.c so these functions drop
the redundant dimension information as with the remaining java API?  If so,
I would be willing to change all the examples accordingly.

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] PLplot on OpenGL

[Gary B. <gb...@cs...>]

PLplot is really nice! With one day of work, I've got it running with an 
OpenGL driver.  I have only tried a few of the smaller demos but 3, 8, 10, 17 
work fine.

This port is different from any of the others I have seen because the driver 
assumes that the calling program has established the OpenGL context. As many 
of you likely know, OpenGL is independent of the window system. Other 
libraries like GLUT, wxWindows, Qt, GLX, etc. provide a window system 
interface for OpenGL.

A normal driver based on OpenGL+GLUT should be possible but I'm not interested 
in that. What I want is a pure OpenGL library that I can use from inside a GUI 
to draw 2D and 3D graphs. My aim is a plotting package to use with Python 
either from the command line or as part of a GUI app. I'll do the command line 
interface using Pyro to connect to a "plot server" that manages the windows. 
I'll do the GUI with wxPython which has a wxGLCanvas that I can extend to call 
PLplot to draw graphs. Of course, the "plot server" uses the same wxPython 
class to implement its windows so the parts are nicely orthogonal.

Thanks to the great work done by the PLplot developers, I'm getting closer to 
my dream of getting off Matlab.

Now to get the Python interface working...

gb

[Plplot-devel] Fwd: graceful exit after window close

[<jc...@fe...>]

Hi,

I received the following message from a plplot user, related with=20
window destruction under ms-win:

----------  Forwarded Message  ----------

Subject: graceful exit after window close
Date: Tue, 21 May 2002 14:36:19 -0700
From: Adam Conner-Sax
=2E..

I made a small change to PLplot win3.cpp that seems to
give better behavior when the window is destroyed.

I added a "bool isDead" to WinDev.  I set it to true in the init
function.

I set it to false on a WM_DESTROY message

I add a check in the message loop so

"while (!dev->nextPlot) {..."

becomes

"while (!dev->nextPLot && !dev->isDead) {..."

otherwise I get hung up in the message loop after I destroy
the window.

Adam

-------------------------------------------------------

Re: [Plplot-devel] xwin driver bug under PseudoColor Xserver

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

Jo=E3o Cardoso writes:
 > Will it be worth correcting it, or are 256 colors PseudoColor xserve=
rs=20
 > part of the past?

The nice thing about 256 colors PseudoColor visuals is that the colors =
can
be changed on the fly, which makes the TK palette tools really shine.  =
On
a TrueColor visual I had to force a plot redraw on every change, which =
can
go really slow for very complex plots.

Of course, 256 colors is a very small number to be sharing among all yo=
ur
applications.  I gave up on 8 bit displays as soon as I got my first 2M=
B
video card, in which you can (barely) fit a 16 bit 1152x864 display.

Fortunately there now does seem to be a way you can get a 256 color
PseudoColor display while you main X server is 16 bit TrueColor using X=
nest.
Geoff told me about this a few months back, although as he mentioned th=
ere
are still some outstanding bugs.

BTW I do have on my short list of priority items to add the ability to =
switch
the visual in the X driver according to a driver option.  Whenever I ge=
t some
time for plplot hacking again..

--=20
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (=
RIST)

RE: [Plplot-devel] xwin driver bug under PseudoColor Xserver

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

This error report looks susiciously similar to something I discovered
a few months back, and reported to the XFree86 guys as a bug in XF86.
They were skeptical initially, but finaly gave in.  It's been long
enough that I'm having trouble remembering, but it had something to do
with PLplot trying to figure out how many mutable colormap cells there
are by allocating them until they were exhausted, and somehow XF86 was
saying there was one more than there really was, and trouble ensuing
downstream. =20

Jo=E3o Cardoso writes:
 > Hi,
 >=20
 > For some reason I had to use plplot in a 8 bits PseudoColor xserver=20=

 > (256 colors), and got the following error:
 >=20
 > jcard@rick:~/tmp/plplot-clean/tmp > ./x01c -dev xwin -debug
 > Plplot library version: 5.1.0
 > XVisual class =3D=3D PseudoColor
 > xwd->rw_cmap =3D 1
 > Downgrading to r/o cmap.
 > Attempting to allocate r/o colors in cmap0.
 > X Error of failed request:  BadMatch (invalid parameter attributes)
 >   Major opcode of failed request:  1 (X_CreateWindow)
 >   Serial number of failed request:  11
 >   Current serial number in output stream:  15
 >=20
 > Will it be worth correcting it, or are 256 colors PseudoColor xserve=
rs=20
 > part of the past?
 >=20
 > Joao
 >=20
 >=20
 > _______________________________________________________________
 >=20
 > Don't miss the 2002 Sprint PCS Application Developer's Conference
 > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.c=
fm
 >=20
 > _______________________________________________
 > Plplot-devel mailing list
 > Plp...@li...
 > https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] xwin driver bug under PseudoColor Xserver

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

I suspect this is one more variation on a chronic X_CreateWindow problem
that Maurice reviewed "fixes" of (stretching back 7 (!) years) in
http://sourceforge.net/mailarchive/message.php?msg_id=3D151054.

I suggest you temporarily change

case $system in
    SunOS-* )
            AC_DEFINE(USE_DEFAULT_VISUAL)
=09    ;;
    * )
esac

appropriately in configure.in to see see whether defining USE_DEFAULT_VISUA=
L
will workaround your problem for 8-bit pseudocolour X servers.  If it does,
that is one more clue about what the real fix should be.

Alan

email: ir...@be...
phone: 250-727-2902=09FAX: 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 Wed, 22 May 2002, [iso-8859-1] Jo=E3o Cardoso wrote:

> Hi,
>
> For some reason I had to use plplot in a 8 bits PseudoColor xserver
> (256 colors), and got the following error:
>
> jcard@rick:~/tmp/plplot-clean/tmp > ./x01c -dev xwin -debug
> Plplot library version: 5.1.0
> XVisual class =3D=3D PseudoColor
> xwd->rw_cmap =3D 1
> Downgrading to r/o cmap.
> Attempting to allocate r/o colors in cmap0.
> X Error of failed request:  BadMatch (invalid parameter attributes)
>   Major opcode of failed request:  1 (X_CreateWindow)
>   Serial number of failed request:  11
>   Current serial number in output stream:  15
>
> Will it be worth correcting it, or are 256 colors PseudoColor xservers
> part of the past?
>
> Joao
>
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>