plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] tk driver

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

Vince Darley writes:
 > Can the current plplot be compiled as one or more Tcl extensions on Unix?
 > (i.e. so 'package require plplot' does something useful in a standard Tk
 > shell)?  If so, then at least integrating the first two items below should
 > be relatively easy.

No one has done TEA yet (on the main branch), if that's what you're
asking.

The details are foggy in my brain at this point.  I remember looking
in some detail at the TEA branch a year or so ago, and being concerned
about some aspect of how the TEA branch interacted with device
selection.  I remember there was discussion about it at the time, and
I remember being personally convinced that a better solution was
possible, but by now it has been so long since the discussion that I
cannot remember the details of the problem or of the discussed
solutions.  

I have some TEA work ahead of me in my day job, so it is possible that
I will become engrossed in the whole thing sometime this summer/fall,
but it hasn't percolated to "top priority" quite yet.

BTW, you are welcome to selectively integrate things from your list
below, into the main branch yourself, if you wish.  IMHO, part of the
problem with the TEA branch is that too much happened on it.
Reviewing the changes between TEA and main, is too big a task.  If
the first two items depend on the TEA integration, perhaps you could
just take the bottom three, and move that out of the TEA branch and
into main (assuming they are suitably mature for production use by the
wide world of PLplot folk).

I'm a big fan of named branches, for focused work.  But if the TEA
branch has roughly 5 major tasks all within it, I think that results,
on a purely human level, in an impediment to getting it merged.
Especially if the merge is left to others than the developer(s) on the
branch.  It seems to me that perhaps some of this could've been done
directly on main, or that perhaps a few named branches, each with more
limited scope, could've been employed.

Actually moving over to TEA, is probably a substantive effort, and
surely deserving of a named branch.  But the rest of the stuff, I
would think, should be pretty independent of the TEA work, per se.

 > On Tue, 25 Jun 2002, Maurice LeBrun wrote:
 > > Vince Darley writes:
 > >  > I've been out of touch with plplot development for some time, but was
 > >  > wondering what the current status of the 'Tk' driver is, and whether
 > >  > anything from the 'tea' branch I contributed to (a long time ago) has
 > >  > actually been incorporated into plplot?
 > >  > 
 > >  > * new 'tkwin.c' driver which works on Win/Unix/MacOS with Tk
 > >  > * better plframe widget
 > >  > * better Itcl extended plframe megawidgets
 > >  > * fixes to colour palettes, etc.
 > >  > * fixes to other parts of Tcl<->plplot interaction
 > > 
 > > I integrated the color palette stuff in Jan with enhancement to work with
 > > DirectColor visuals & related support.  As for the rest, my plan is to
 > > continue moving it over piecemeal as I get to it.  The TEA build will have
 > > to wait until our build paradigm is changed to be compatible, i.e. Rafael's
 > > AM/LT work.

Re: [Plplot-devel] tk driver

[Vince D. <vi...@sa...>]

Can the current plplot be compiled as one or more Tcl extensions on Unix?
(i.e. so 'package require plplot' does something useful in a standard Tk
shell)?  If so, then at least integrating the first two items below should
be relatively easy.

On Tue, 25 Jun 2002, Maurice LeBrun wrote:

> Vince Darley writes:
>  > I've been out of touch with plplot development for some time, but was
>  > wondering what the current status of the 'Tk' driver is, and whether
>  > anything from the 'tea' branch I contributed to (a long time ago) has
>  > actually been incorporated into plplot?
>  > 
>  > * new 'tkwin.c' driver which works on Win/Unix/MacOS with Tk
>  > * better plframe widget
>  > * better Itcl extended plframe megawidgets
>  > * fixes to colour palettes, etc.
>  > * fixes to other parts of Tcl<->plplot interaction
> 
> I integrated the color palette stuff in Jan with enhancement to work with
> DirectColor visuals & related support.  As for the rest, my plan is to
> continue moving it over piecemeal as I get to it.  The TEA build will have
> to wait until our build paradigm is changed to be compatible, i.e. Rafael's
> AM/LT work.
> 
> -- 
> Maurice LeBrun    mj...@ga...
> Research Organization for Information Science and Technology of Japan (RIST)
> 

Re: [Plplot-devel] programming help for Plplot...

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

Are you using a build from the very latest CVS (in last day or so) using
the new python interface?  You will need swig-1.3.x for that build.

Or did you stick with that build from CVS I helped you with a week or so ago
which was based on the old python interface?

Much has changed in that time.  My advice is to use a build from the latest
CVS.

When I do that, xw16.py (which uses plshades) works fine with either the
single or double-precision library.  Follow what was done in xw16.py (with
setup as in pythondemos.py) and you should be fine.

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

> Hello...
>
> I using plplot to plot a contour graph... but I get
> this error
>
> plshades(S, -1, 1, -1, 1, shedge, fill_width,
> cont_color, cont_width, 1)
>
> TypeError: Array can not be safely cast to required
> type
>
> Does anybody know why the Array can not be safely
> cast?
>
> S is a 2D array...
>
> Thanks
>
> Take Care,
>
> Dustin
>
>
> ______________________________________________________________________
> Post your ad for free now! http://personals.yahoo.ca
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Jabber Inc.
> Don't miss the IM event of the season | Special offer for OSDN members!
> JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

[Plplot-devel] programming help for Plplot...

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

Hello...

I using plplot to plot a contour graph... but I get
this error

plshades(S, -1, 1, -1, 1, shedge, fill_width,
cont_color, cont_width, 1)

TypeError: Array can not be safely cast to required
type

Does anybody know why the Array can not be safely
cast?

S is a 2D array... 

Thanks 

Take Care,

Dustin


______________________________________________________________________ 
Post your ad for free now! http://personals.yahoo.ca

Re: [Plplot-devel] Bug in tk driver/python interaction

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

Alan W. Irwin writes:
 > One minor thing I noticed was the name is displayed as "pythondemos_py".  Is
 > there no escape character to convince the parser to treat "." as a normal
 > character?  If so, then replacing "." by "_" is probably the best that can
 > be done.

Trying to keep the "." would probably descend into quoting hell pretty quick
IMO, so I opted for a simple/quick replacement.

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

Re: [Plplot-devel] plfill3 clipping bug?

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

On Tue, 25 Jun 2002, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > This came up in discussion with Gary.
>  >
>  > If you look at function c_plfill inside plfill.c it uses the clipping
>  > interface to call plP_fill, but c_plfill3 right after it calls plP_fill
>  > directly.
>  >
>  > Is there some reason for this, or is this a clipping bug for plfill3?
>
> I'm not aware of (or can't recall) any reason for the difference.  So I'd
> guess a bug.  Unfortunately it doesn't seem to be used by any example
> programs.

I noticed that as well, and I am not sure how you would modify an existing
example to use this function.

But since plfill3 is not tested by us, I decided users had to be wary of
using this function in any case.  Thus, since Gary, you, and I have all made
educated guesses that plfill3 should use the clipping interface I decided to
put the change into CVS with some warning commentary near the clipping
interface call.

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

Re: [Plplot-devel] Bug in tk driver/python interaction

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

On Tue, 25 Jun 2002, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > So I guess the only remaining question is how can you change the underlying
>  > code so that invoking program names with a "." in them (such as in the above
>  > C code test and also in the original python example) are acceptable to the
>  > tk driver.
>
> Try out the new tk.c and see if it works for you.

Yes,

./pythondemos.py -dev tk

plots well now without any error messages which is the main thing.  Thanks
very much for dealing with this so swiftly.

One minor thing I noticed was the name is displayed as "pythondemos_py".  Is
there no escape character to convince the parser to treat "." as a normal
character?  If so, then replacing "." by "_" is probably the best that can
be done.

Alan

Re: [Plplot-devel] plfill3 clipping bug?

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

Alan W. Irwin writes:
 > This came up in discussion with Gary.
 > 
 > If you look at function c_plfill inside plfill.c it uses the clipping
 > interface to call plP_fill, but c_plfill3 right after it calls plP_fill
 > directly.
 > 
 > Is there some reason for this, or is this a clipping bug for plfill3?

I'm not aware of (or can't recall) any reason for the difference.  So I'd
guess a bug.  Unfortunately it doesn't seem to be used by any example
programs. 

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

Re: [Plplot-devel] plotsh3d changes

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

Gary Bishop writes:
 > Hi,
 > 
 > Alan asked me to follow up to the list with a brief description of what 
 > I did to fix the "missing triangles bug" in plotsh3d.
 > 
 > The old code attempted to modify the hidden-line algorithm to do hidden 
 > surfaces. This is very difficult. Hidden-line algorithms are much more 
 > complicated than hidden-surface algorithms. So much so that the modern 
 > way to do hidden lines is with a hidden-surface algorithm that draws 
 > polygons that have their edges shaded and their middles background colored.

Yeah, the old way seemed to be one of those problems that was theoretically
possible, but would probably drive you nuts trying to figure it out.  And
definitely not worth the time.

 > I didn't want to fool with the hidden-line algorithm so I wrote a 
 > completely separate algorithm for doing the hidden surface removal. I'm 
 > using a simple back-to-front ("painters") algorithm. I figure out which 
 > is the back most corner of the data and work toward the front from there.

It looks great, thanks.

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

Re: [Plplot-devel] Bug in tk driver/python interaction

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

Alan W. Irwin writes:
 > So I guess the only remaining question is how can you change the underlying
 > code so that invoking program names with a "." in them (such as in the above
 > C code test and also in the original python example) are acceptable to the
 > tk driver.

Try out the new tk.c and see if it works for you.

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

Re: [Plplot-devel] tk driver

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

Vince Darley writes:
 > I've been out of touch with plplot development for some time, but was
 > wondering what the current status of the 'Tk' driver is, and whether
 > anything from the 'tea' branch I contributed to (a long time ago) has
 > actually been incorporated into plplot?
 > 
 > * new 'tkwin.c' driver which works on Win/Unix/MacOS with Tk
 > * better plframe widget
 > * better Itcl extended plframe megawidgets
 > * fixes to colour palettes, etc.
 > * fixes to other parts of Tcl<->plplot interaction

I integrated the color palette stuff in Jan with enhancement to work with
DirectColor visuals & related support.  As for the rest, my plan is to
continue moving it over piecemeal as I get to it.  The TEA build will have
to wait until our build paradigm is changed to be compatible, i.e. Rafael's
AM/LT work.

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

[Plplot-devel] plfill3 clipping bug?

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

This came up in discussion with Gary.

If you look at function c_plfill inside plfill.c it uses the clipping
interface to call plP_fill, but c_plfill3 right after it calls plP_fill
directly.

Is there some reason for this, or is this a clipping bug for plfill3?

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] plotsh3d changes

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

I would like to add since this was number one on my bug list, I am extremely
happy to see this fixed!

Thanks, Gary.

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] plotsh3d changes

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

Hi,

Alan asked me to follow up to the list with a brief description of what 
I did to fix the "missing triangles bug" in plotsh3d.

The old code attempted to modify the hidden-line algorithm to do hidden 
surfaces. This is very difficult. Hidden-line algorithms are much more 
complicated than hidden-surface algorithms. So much so that the modern 
way to do hidden lines is with a hidden-surface algorithm that draws 
polygons that have their edges shaded and their middles background colored.

I didn't want to fool with the hidden-line algorithm so I wrote a 
completely separate algorithm for doing the hidden surface removal. I'm 
using a simple back-to-front ("painters") algorithm. I figure out which 
is the back most corner of the data and work toward the front from there.

The code would be quite concise if it wasn't for the need to draw the 
background grid lines (particularly ugly), and the sides (simple).

The output looks good on devices that support fill. It looks weird on 
devices that don't but the old method did too.

gb

Re: [Plplot-devel] Bug in tk driver/python interaction

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

On Mon, 24 Jun 2002, Maurice LeBrun wrote:

> [...] So I bet if that last '.py' were
> stripped off, it'd work.

Yep, that works fine.  When I

cp pythondemos.py pytest
./pytest -dev tk

The plotting works fine and the name (pytest) is displayed properly with
the new python interface.

To close off the possibility this was python specific I also did this test.

cp x08c test.x08c
./test.x08c -dev tk

and that invoked the same error.

> The tk driver uses:
>
> /* Initialize top level window */
> /* Request a variant on pls->program (if set) for the main window name */
>
>     if (pls->program == NULL)
>         pls->program = "plclient";
>
> to set the window name.  pls-program is set by $0 passed to the plargs
> facility, unless the caller specifies the PL_PARSE_NOPROGRAM option.
> So you should just need to pass argc/argv without having munged it ($0 at
> least) to plParseOpts.

I checked that that the correct argv string was being passed to the python
version of plParseOpts.  It is possible the "le" name result we were getting
for the old python interface was due to some problem with the python wrapper
for plParseOpts, but I haven't investigated further for that situation with
the pytest name. But apparently that is not a problem for the new python
interface since it delivers the name pytest without a problem.

So I guess the only remaining question is how can you change the underlying
code so that invoking program names with a "." in them (such as in the above
C code test and also in the original python example) are acceptable to the
tk driver.

Alan

[Plplot-devel] tk driver

[Vince D. <vi...@sa...>]

I've been out of touch with plplot development for some time, but was
wondering what the current status of the 'Tk' driver is, and whether
anything from the 'tea' branch I contributed to (a long time ago) has
actually been incorporated into plplot?

* new 'tkwin.c' driver which works on Win/Unix/MacOS with Tk
* better plframe widget
* better Itcl extended plframe megawidgets
* fixes to colour palettes, etc.
* fixes to other parts of Tcl<->plplot interaction

anyone ever looked at that again?

cheers,

-- Vince

<http://www.santafe.edu/~vince>

re: [Plplot-devel] python bindings not buildable?

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

Oops, that should have read "... include generated plplotcmodule.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 Mon, 24 Jun 2002, Alan W. Irwin wrote:

> I have already written in my private notes for the next release a reminder
> to include generated plmodule.c_* in the tarball for the convenience of our
> ordinary users.
>
> However, from previous discussions on this list, I felt it was reasonable to
> ask cvs users to download the appropriate tools for themselves rather than
> cluttering up cvs with generated files which then have to be checked in in
> synch with the files used to create them.
>
> 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, 24 Jun 2002, Gary Bishop wrote:
>
> > I'm guessing you have an old version of SWIG. It needs 1.3.11.
> >
> > I haven't done a fresh checkout yet but my understanding was that Alan
> > was going to include plmodule.c_* so folks wouldn't necessarily have to
> > run SWIG.
> >
> > gb
> >
> >
> > -------------------------------------------------------
> > Sponsored by:
> > ThinkGeek at http://www.ThinkGeek.com/
> > _______________________________________________
> > Plplot-devel mailing list
> > Plp...@li...
> > https://lists.sourceforge.net/lists/listinfo/plplot-devel
> >
>
>
>
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] python bindings not buildable?

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

I am virtually positive this is a result of using swig version 1.1. As
discussed previously you need version 1.3.x (where x is 11 for my version
where everything works) version 1.1.x will not do.

The latest swig (actually version 1.3.13) can be obtained
from http://sourceforge.net/project/showfiles.php?group_id=1645.  See the
release notes there for a discussion of the large changes from
version 1.1 to 1.3.

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, 24 Jun 2002, Maurice LeBrun wrote:

> This is what I got from a fresh checkout under RH7.3:
>
> ...
> swig -python -o plplotcmodule_p.c_double -c++ -DPL_DOUBLE plplotcmodule.i
> Generating wrappers for Python
> plplotcmodule.i : Line 99. Syntax error in input.
> plplotcmodule.i : Line 104. Syntax error in input.
> plplotcmodule.i : Line 138. Syntax error in input.
> plplotcmodule.i : Line 141. Syntax error in input.
> plplotcmodule.i : Line 150. Syntax error in input.
> plplotcmodule.i : Line 181. Syntax error in input.
> plplotcmodule.i : Line 186. Syntax error in input.
> plplotcmodule.i : Line 241. Syntax error in input.
> plplotcmodule.i : Line 244. Syntax error in input.
> plplotcmodule.i : Line 249. Syntax error in input.
> plplotcmodule.i : Line 253. Syntax error in input.
> plplotcmodule.i : Line 267. Syntax error in input.
> plplotcmodule.i : Line 274. Syntax error in input.
> plplotcmodule.i : Line 284. Syntax error in input.
> plplotcmodule.i : Line 291. Syntax error in input.
> plplotcmodule.i : Line 297. Syntax error in input.
> plplotcmodule.i : Line 326. Syntax error in input.
> plplotcmodule.i : Line 327. Syntax error in input.
> plplotcmodule.i : Line 345. Syntax error in input.
> plplotcmodule.i : Line 433. Syntax error in input.
> plplotcmodule.i : Line 434. Syntax error in input.
> plplotcmodule.i : Line 827. Syntax error in input.
> Confused by earlier errors. Bailing out
>
> --
> Maurice LeBrun    mj...@ga...
> Research Organization for Information Science and Technology of Japan (RIST)
>
>
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

re: [Plplot-devel] python bindings not buildable?

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

I have already written in my private notes for the next release a reminder
to include generated plmodule.c_* in the tarball for the convenience of our
ordinary users.

However, from previous discussions on this list, I felt it was reasonable to
ask cvs users to download the appropriate tools for themselves rather than
cluttering up cvs with generated files which then have to be checked in in
synch with the files used to create them.

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, 24 Jun 2002, Gary Bishop wrote:

> I'm guessing you have an old version of SWIG. It needs 1.3.11.
>
> I haven't done a fresh checkout yet but my understanding was that Alan
> was going to include plmodule.c_* so folks wouldn't necessarily have to
> run SWIG.
>
> gb
>
>
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

re: [Plplot-devel] python bindings not buildable?

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

I'm guessing you have an old version of SWIG. It needs 1.3.11.

I haven't done a fresh checkout yet but my understanding was that Alan 
was going to include plmodule.c_* so folks wouldn't necessarily have to 
run SWIG.

gb

[Plplot-devel] python bindings not buildable?

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

This is what I got from a fresh checkout under RH7.3:

...
swig -python -o plplotcmodule_p.c_double -c++ -DPL_DOUBLE plplotcmodule.i
Generating wrappers for Python
plplotcmodule.i : Line 99. Syntax error in input.
plplotcmodule.i : Line 104. Syntax error in input.
plplotcmodule.i : Line 138. Syntax error in input.
plplotcmodule.i : Line 141. Syntax error in input.
plplotcmodule.i : Line 150. Syntax error in input.
plplotcmodule.i : Line 181. Syntax error in input.
plplotcmodule.i : Line 186. Syntax error in input.
plplotcmodule.i : Line 241. Syntax error in input.
plplotcmodule.i : Line 244. Syntax error in input.
plplotcmodule.i : Line 249. Syntax error in input.
plplotcmodule.i : Line 253. Syntax error in input.
plplotcmodule.i : Line 267. Syntax error in input.
plplotcmodule.i : Line 274. Syntax error in input.
plplotcmodule.i : Line 284. Syntax error in input.
plplotcmodule.i : Line 291. Syntax error in input.
plplotcmodule.i : Line 297. Syntax error in input.
plplotcmodule.i : Line 326. Syntax error in input.
plplotcmodule.i : Line 327. Syntax error in input.
plplotcmodule.i : Line 345. Syntax error in input.
plplotcmodule.i : Line 433. Syntax error in input.
plplotcmodule.i : Line 434. Syntax error in input.
plplotcmodule.i : Line 827. Syntax error in input.
Confused by earlier errors. Bailing out

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

Re: [Plplot-devel] Bug in tk driver/python interaction

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

Alan W. Irwin writes:
 > Maurice, this is mostly directed to you.
 > 
 > With the new python interface I am getting the following stack trace from
 > the tk driver when I invoke
 > 
 > ./pythondemos.py -dev tk
 > 
 > bad window path name ".pythondemos.py"
 >   while executing
 > "plframe $w.plwin -relief sunken"
 >   (procedure "plxframe" line 20)
 >   invoked from within
 > "plxframe $w $client_id"
 >   (procedure "plw_create" line 2)
 >   invoked from within
 > "plw_create .pythondemos.py tk"
 >   ("after" script)

There may be *two* errors -- 'bad window path name ".pythondemos.py"' makes me
immediately look at that second "." as the probable culprit, since Tcl/Tk use
.'s to delimit parent-child widget names.  So I bet if that last '.py' were
stripped off, it'd work.

 > With the old python interface I get no such error, but the name of the
 > window (displayed by the desktop environment at the top of the window and
 > also displayed by the tk driver in the second line) are the garbage
 > characters "le" so I suspect the problem has been occurring all along.

No idea, yet.

 > If I do something like
 > 
 > ./x02c -dev tk
 > 
 > The window name is displayed as "x02c".
 > 
 > If I use the fortran front end,
 > 
 > ./x02f
 > 
 > and select the tk device, the window name is displayed as "plclient".
 > 
 > If I use the java front end
 > 
 > java plplot.examples.x02 -dev tk
 > 
 > the window name is displayed as "plclient_1".
 > 
 > I believe there must be some assumptions in the tk driver about what the front
 > end is supposed to supply, and I suspect neither the old or new python
 > front ends have done the job properly.
 > 
 > Maurice, could you have a quick dig around to find out what must be supplied
 > by all front ends so the window name works properly with the tk driver? Once
 > I know that information, I can see what is missing from the python front end
 > (or what is being wrongly supplied [say through some name-clash] that is
 > confusing the tk driver).

The tk driver uses:

/* Initialize top level window */ 
/* Request a variant on pls->program (if set) for the main window name */ 
 
    if (pls->program == NULL) 
        pls->program = "plclient"; 

to set the window name.  pls-program is set by $0 passed to the plargs
facility, unless the caller specifies the PL_PARSE_NOPROGRAM option.
So you should just need to pass argc/argv without having munged it ($0 at
least) to plParseOpts.

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

[Plplot-devel] Bug in tk driver/python interaction

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

Maurice, this is mostly directed to you.

With the new python interface I am getting the following stack trace from
the tk driver when I invoke

./pythondemos.py -dev tk

bad window path name ".pythondemos.py"
  while executing
"plframe $w.plwin -relief sunken"
  (procedure "plxframe" line 20)
  invoked from within
"plxframe $w $client_id"
  (procedure "plw_create" line 2)
  invoked from within
"plw_create .pythondemos.py tk"
  ("after" script)

With the old python interface I get no such error, but the name of the
window (displayed by the desktop environment at the top of the window and
also displayed by the tk driver in the second line) are the garbage
characters "le" so I suspect the problem has been occurring all along.

If I do something like

./x02c -dev tk

The window name is displayed as "x02c".

If I use the fortran front end,

./x02f

and select the tk device, the window name is displayed as "plclient".

If I use the java front end

java plplot.examples.x02 -dev tk

the window name is displayed as "plclient_1".

I believe there must be some assumptions in the tk driver about what the front
end is supposed to supply, and I suspect neither the old or new python
front ends have done the job properly.

Maurice, could you have a quick dig around to find out what must be supplied
by all front ends so the window name works properly with the tk driver? Once
I know that information, I can see what is missing from the python front end
(or what is being wrongly supplied [say through some name-clash] that is
confusing the tk driver).

Thanks in advance.

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] Current status of the python front-end of plplot

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

Earlier today I committed to CVS the new swig-based python interface that
has been kindly donated by Gary Bishop.

I have tested this new interface with pythondemos.py with both the single-
and double-precision version of the plplot library, and it seems to work
fine for all the xw??.py examples that are exercised by pythondemos.py. That
is a welcome change since the number-one issue for most would-be python
plplot users had been errors created when the old python interface which was
only compatible with double precision was inadvertently used with the
single-precision version of the plplot library.

Implementation details

swig version 1.3.11 or later is required for those using cvs (but not
tarball release users, see discussion below).  1.3.11 is the Debian woody
version you get with the swig1.3 package.  If you have no swig or just
swig-1.1.x you should download swig-1.3.13 from
http://www.swig.org/download.html.  To distinguish between double and single
precision, swig needs to be run with a command-line switch.  This is all
taken care of by the new configuration. The point is that
plplotcmodule.c_single and plplotcmodule.c_double are both produced at build
time, but plplotcmodule.c is symlinked to only one of those in the
configuration step depending on the --with-double configuration option.

I have gone with this approach since I don't know in advance whether our
tarball release users want to build the single or double-precision version
of the plplot library so I will provide both plplotcmodule.c_single and
plplotcmodule.c_double when I create a tarball release.  In this way we
won't be demanding all our tarball release users must have swig, and this
approach is also consistent with our prior decisions about some of our other
generated files such as configure.

swig-1.3.11 still has some issues with documentation strings so part of the
process of creating plplotcmodule.c_single and plplotcmodule.c_double
requires a python script (makedocstrings.py) to take care of the problem.
This is all handled automatically by the Makefile.

The Makefile automatically creates both the plplot_widget and plplotc
extension modules.  The former includes useful widget support functions, and
the latter makes the complete raw common C API of the plplot library
available to python (with redundant dimension information automatically
dropped from the argument lists).  Finally, there is also a new python
module called plplot (implemented with plplot.py) which is a user-friendly
python wrapper for the plplotc module.  This user-friendly version puts in
required python argument list variations for plcont, etc.

Note that the python modules have been renamed from pl and pyqt_pl to plplot
and plplot_widget.  There is a long tradition in python of having meaningful
module names so that is why I wanted plplot in both names.  Also, I replaced
pyqt with widget (in different order) because the widget support functions
in that module can be used not only by pyqt but also apparently by the
Tkinter widget. I decided on this new naming after some private discussion
with Geoffrey.  The change will undoubtedly be annoying to our python users,
but I thought so much else was being changed at this time in the way the
plplot modules are generated, that it was a good opportunity to change the
names as well.

There are a lot of minor issues I still have to clean up such as completing
the documentation strings, implementing some more user-friendly variations
in plplot.py, making sure the installed versions (as opposed to test
versions in plplot/tmp) work, etc.  Also, I have left
plplot/sys/win32/msdev/ completely untouched so there is undoubtedly work to
do there to adjust to the new module names and swig generation approach.
However, if Olof et al have any trouble with this they should consult with
Gary because he got all this working (although without name changes yet, and
apparently handling things somewhat differently than in
plplot/sys/win32/msdev) for his own windows environment before he donated
the software to us.

Despite these minor issues I have discussed, the Unix/Linux/MacOS X build of
the python modules in plplot/tmp should be in good shape both for single and
double precision, and I invite you to give it a test drive.

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] Suggested API change for plpoly3

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

On Thu, 20 Jun 2002, Alan W. Irwin wrote:

> On general grounds, I would prefer to separate the two different purposes
> (dimensions and clockwise flag) into two separate parameters [for
plpoly3]....

I got back private response from Geoffrey supporting the idea of just going
ahead and changing this API since his judgement is that plpoly3 is not
that heavily used.

Therefore, I have gone ahead and made all the changes in CVS in a way which
I believe is consistent, and I also tested the results.  Joao also
encountered this problem before and solved it with his own version of
plpoly3.  I believe I have made the appropriate changes to support that
special version, but he may want to use the native version now in the
interests of simplicity.

Alan