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

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

Thread view

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: irwin@...
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
__________________________

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 mjl@...
Research Organization for Information Science and Technology of Japan (RIST)

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

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 mjl@...
Research Organization for Information Science and Technology of Japan (RIST)

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

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 mjl@...
Research Organization for Information Science and Technology of Japan (RIST)