[GRASS-dev] G.region bug when setting 3d resolution??? Maybe not

[Michael Barton]

Hi Paul,

A few thoughts below.


On 1/4/07 7:54 AM, "Paul Kelly" <paul-grass at stjohnspoint.co.uk> wrote:

> 
> I don't think, that the problem is the way the data exchange is handled,
> just that gis.m should be a *little* bit more robust in its handling of
> the output from g.region and other commands used in a similar way to get
> information about the GRASS environment. My two recommendations would be:

I agree about finding ways to increase the robusticity of the GUI. The more
it is used, the more robust it needs to be. And the more robust it is, the
more it will be used.

While specific errors can be trapped if they can be reliably anticipated,
the general TclTk form for error-trapping is the catch command. It is widely
used in the GUI, but could be used in a more sophisticated way to trap and
report errors. TclTk actually does a pretty good job of catching and
reporting errors, returning real information rather than codes. However, it
would better if users could be spared TclTk errors as much as possible.

> 
> 1. Merge the output of stdout and stderr for any commands called like
> this, by adding "|& $env(GISBASE)/etc/grocat" to the end of the command
> line.
> Reason: This will stop Tcl bombing out completely if anything is written
> to stderr (a warning or message, for example).

I think some other solution would be better for two reasons. First, this
construction calls a *nix command from within TclTk. This is problematic for
Windows. A pure TclTk construction would be better. Second, in the most
recent set of problems with g.region, I'm not sure if this would help all
that much anyway. The GUI was reading the text output from g.region -g OK,
the problem is that it was the wrong output. It was expecting [key]=[value].
The first [key] included the warning message. This gave a key that was not
recognizable by the subsequent routine that tried to process the key to get
region values. For this particular routine, a 'catch' command is already in
place to trap real errors and move on. In fact, an error will cause the GUI
to quit relatively gracefully with the GRASS error printed to the terminal.
I implemented this, working with Hamish to solve a recurrent problem that
caused the GUI to give somewhat misleading error messages when GRASS was
improperly installed (usually a gdal installation problem).

This construction probably needs to be used more widely as we identify
potential problem spots. Maybe it is useful wherever a GRASS command is run.
If you have any suggestions or want to check through the code for places you
see as potentially problematic, we can try to beef them up.

> 
> 2. Make the parsing of the command output more robust by actually checking
> the return value of the regexp command (or whichever other Tcl command is
> used to parse the output) before acting on it.
> Reason: If an unexpected line occurs in the output (e.g. a warning) and it
> isn't matched by the regexp, then it will be simply skipped over and no
> action will be taken.

This is a good plan if you know what return value you are expecting. In some
places this makes a lot of sense. It is implemented in some places, but
could probably be expanded. It would be worthwhile to identify such spots.

In this particular case, however, g.region produces a lot of possible return
[key][separator][value] lines. The TclTk routine loops through all of them
and puts them into a list that it later uses for all sorts of things. I'm
not sure if it's efficient to check each line against all possible valid
g.region outputs. The loop read the output 'correctly', it just got output
that was subsequently unusable. Moreover, the new warning is in a difficult
to parse location for reading information. IMHO, it should not be there for
'script' style output.

> 
> I'm willing to help with examples for these if necessary. I think
> improving the robustness of gis.m like this would make debugging problems
> with the GRASS set-up a lot easier.

Thanks. This would be very much appreciated. Now that the GUI code is itself
is pretty robust, if we can identify the most likely spots that can result
in crashes when there are other problems, and solve these with pure TclTk
methods (i.e., cross-platform) it will make for a much better piece of
software.

Michael

> 
> Paul
> 
> 
> 
> 

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

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