[GRASS5] Need help debugging problem with thematic mapping script

GRASS GIS GRASS GIS developer
1

IR17;ve run into a small but annoying bug that shows up when implementing the thematic mapping script in the GIS Manager. I’ve tried innumerable ways to fix this—trying tweaks in d.m.tcl, d.vect.thematic, and thematic.tcl–but it still occurs. Here is the strange behavior.

If you create a thematic map layer in the GIS Manager, and select the option to create a graphic legend, the GIS Manager will hang unless the monitor for the legend display is already running. If the monitor for the legend is NOT running, d.vect.thematic will start the monitor and draw the legend. However, all processing will then stop and the GIS Manager will hang. If you close this monitor, processing will continue and the GIS Manager will respond. If the monitor chosen for the legend IS running, processing will proceed normally.

As far as I can tell, this behavior is the same regardless of how the script is actually run in the GIS Manger (i.e., run using the TclTk open command, run in a terminal, run using exec, etc.).

Here is what is actually happening in the script. If you create a thematic map layer in the GIS Manager, and select the option to create a graphic legend, the d.vect.thematic script will use an if clause to check to see if the monitor selected for the legend is running. If the monitor chosen for the legend is NOT running, the script will start the monitor (d.mon start=). If it IS running, the script will select that monitor (d.mon select=). Then the script will continue to erase the monitor (d.erase), draw the legend using d.graph (d.graph input=), and reselect the original display monitor used for thematic map display (d.mon select=).

The only difference between the situation of the chosen legend monitor being running or not is that the script will start the monitor if not running and select it if running. Then the same commands are run in either case. The script is doing all this correctly—even running the commands and proceeding the the cleanup procedure that ends the script. BUT it hangs the GIS Manager if it has to start the monitor; it does not hang the GIS Manager if it has to select the monitor.

I am completely baffled. Hopefully someone else can figure this out. Thanks.

Michael

Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

2

Michael Barton wrote:

I¹ve run into a small but annoying bug that shows up when implementing the
thematic mapping script in the GIS Manager. I¹ve tried innumerable ways to
fix this...trying tweaks in d.m.tcl, d.vect.thematic, and thematic.tcl--but it
still occurs. Here is the strange behavior.

If you create a thematic map layer in the GIS Manager, and select the option
to create a graphic legend, the GIS Manager will hang unless the monitor for
the legend display is already running. If the monitor for the legend is NOT
running, d.vect.thematic will start the monitor and draw the legend.
However, all processing will then stop and the GIS Manager will hang. If you
close this monitor, processing will continue and the GIS Manager will
respond. If the monitor chosen for the legend IS running, processing will
proceed normally.

As far as I can tell, this behavior is the same regardless of how the script
is actually run in the GIS Manger (i.e., run using the TclTk open command,
run in a terminal, run using exec, etc.).

Here is what is actually happening in the script. If you create a thematic
map layer in the GIS Manager, and select the option to create a graphic
legend, the d.vect.thematic script will use an if clause to check to see if
the monitor selected for the legend is running. If the monitor chosen for
the legend is NOT running, the script will start the monitor (d.mon start=).
If it IS running, the script will select that monitor (d.mon select=). Then
the script will continue to erase the monitor (d.erase), draw the legend
using d.graph (d.graph input=), and reselect the original display monitor
used for thematic map display (d.mon select=).

Tcl's exec command (which is being called by the default undefined
command handler; you're trying to run d.mon as a Tcl command, where it
should really be "exec d.mon ...") sets the process' stdout to a pipe.

The result of the exec command is the data which the process writes to
its stdout (the pipe), so exec can't return until it receives EOF,
i.e. when the write end of the pipe has been closed.

The driver is a child of d.mon, and so inherits the pipe as its
stdout. It never closes it, so the exec command won't get EOF and
won't terminate.

The easiest solution is to add >/dev/null or >@stdout to the exec
command.

--
Glynn Clements <glynn@gclements.plus.com>

3

Thanks much Glynn.

If I add >/dev/null or >@stdout to the grass commands (d.mon only?) inside
d.vect.thematic will this do the trick? Any reason to choose one over the
other?

The run_panel procedure in d.m.tcl traps stdout at the level of the tcl open
command, at least. Will this carry through to the output from commands
inside the script if I use >@stdout?

Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Glynn Clements <glynn@gclements.plus.com>
Date: Mon, 14 Nov 2005 09:58:02 +0000
To: Michael Barton <michael.barton@asu.edu>
Cc: Grass Developers List <grass5@grass.itc.it>
Subject: Re: [GRASS5] Need help debugging problem with thematic mapping script

Michael Barton wrote:

I¹ve run into a small but annoying bug that shows up when implementing the
thematic mapping script in the GIS Manager. I¹ve tried innumerable ways to
fix this...trying tweaks in d.m.tcl, d.vect.thematic, and thematic.tcl--but
it
still occurs. Here is the strange behavior.

If you create a thematic map layer in the GIS Manager, and select the option
to create a graphic legend, the GIS Manager will hang unless the monitor for
the legend display is already running. If the monitor for the legend is NOT
running, d.vect.thematic will start the monitor and draw the legend.
However, all processing will then stop and the GIS Manager will hang. If you
close this monitor, processing will continue and the GIS Manager will
respond. If the monitor chosen for the legend IS running, processing will
proceed normally.

As far as I can tell, this behavior is the same regardless of how the script
is actually run in the GIS Manger (i.e., run using the TclTk open command,
run in a terminal, run using exec, etc.).

Here is what is actually happening in the script. If you create a thematic
map layer in the GIS Manager, and select the option to create a graphic
legend, the d.vect.thematic script will use an if clause to check to see if
the monitor selected for the legend is running. If the monitor chosen for
the legend is NOT running, the script will start the monitor (d.mon start=).
If it IS running, the script will select that monitor (d.mon select=). Then
the script will continue to erase the monitor (d.erase), draw the legend
using d.graph (d.graph input=), and reselect the original display monitor
used for thematic map display (d.mon select=).

Tcl's exec command (which is being called by the default undefined
command handler; you're trying to run d.mon as a Tcl command, where it
should really be "exec d.mon ...") sets the process' stdout to a pipe.

The result of the exec command is the data which the process writes to
its stdout (the pipe), so exec can't return until it receives EOF,
i.e. when the write end of the pipe has been closed.

The driver is a child of d.mon, and so inherits the pipe as its
stdout. It never closes it, so the exec command won't get EOF and
won't terminate.

The easiest solution is to add >/dev/null or >@stdout to the exec
command.

--
Glynn Clements <glynn@gclements.plus.com>

4

Michael Barton wrote:

If I add >/dev/null or >@stdout to the grass commands (d.mon only?) inside
d.vect.thematic will this do the trick?

Yes. You only need to do it when running a command which creates
long-lived children (e.g. "d.mon start=..."), but you can do it
whenever you don't require the command's output.

Any reason to choose one over the other?

Using >/dev/null will discard the output, while >@stdout will let it
go to where d.vect.thematic's stdout goes (e.g. the terminal from
which d.vect.thematic was run).

The run_panel procedure in d.m.tcl traps stdout at the level of the tcl open
command, at least. Will this carry through to the output from commands
inside the script if I use >@stdout?

If you use ">@stdout 2>@stderr", then no redirection will occur, i.e.
the command will inherit its stdout and stderr. If you don't redirect
them at all, they get redirected to Tcl itself; stdout is captured and
returned as the result of exec (as a string) or open (as a file
handle), while stderr is monitored and an error generated if anything
is written to it.

--
Glynn Clements <glynn@gclements.plus.com>