Menu
▾
▴
plplot-devel
|
From: Alan W. I. <ir...@be...> - 2002-06-23 18:48:51
|
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
__________________________
|
|
From: Maurice L. <mj...@ga...> - 2002-06-24 08:11:42
|
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)
|
|
From: Alan W. I. <ir...@be...> - 2002-06-24 16:50:03
|
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 |
|
From: Maurice L. <mj...@ga...> - 2002-06-25 08:19:25
|
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) |
|
From: Alan W. I. <ir...@be...> - 2002-06-25 15:19:37
|
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 |
|
From: Maurice L. <mj...@ga...> - 2002-06-25 19:53:02
|
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) |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X