[GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows

Michael Barton michael.barton at asu.edu
Fri Aug 31 19:33:51 EDT 2007


Paul,


On 8/31/07 1:27 PM, "Paul Kelly" <paul-grass at stjohnspoint.co.uk> wrote:

> Hello Michael
> 
> On Sat, 25 Aug 2007, Michael Barton wrote:
> 
>> Moritz,
>> 
>> Update /gui/tcltk/gis.m/runandoutput.tcl from the cvs and see what happens.
>> I just made a change, suggested by Glynn, that fixed similar symptoms for
>> with with another command (v.what). v.what was kicking out extraneous
>> information when it launched and creating an identical dialog. I've
>> separated out stderr from the normal stdout information when commands are
>> launched from the menu and it works fine now.
> 
> As far as I can see there in that latest change you're redirecting stderr
> to /dev/null. So now there will be no output for the catch command to
> catch in case of an error - so printing out the error message is
> pointless. In any case a popup dialog should be a better option than
> printing to the terminal where the user might not notice it until later -
> or in future there may not even be a terminal, e.g. in WinGRASS but maybe
> we'll change that.

My understanding from Glynn (perhaps wrong) is that a *real* error will
actually show up and be caught by TclTk, but not non-error information sent
to stderr.

I agree about preferring a message box. I can't really say I was being lazy,
but I wanted to get all statements caught right away, and it was a large
number to go through.

> 
> I'd suggest using the catch command something as follows (this is adapting
> what's in epsg_option.tcl):
> 
> catch {set code [exec -- $program --tcltk]} errMsg
> 
> if {[lindex $::errorCode 0] eq "CHILDSTATUS"} {
>      DialogGen .wrnDlg [G_msg "Error running command!"] warning \
>      [format [G_msg "%s returned the following message:\n%s"] $program
> $errMsg] \
>      0 OK
> } elseif {$errMsg != ""} {
>          DialogGen .wrnDlg [format [G_msg "Informational output from %s"]
> $program] info \
>          [format [G_msg "%s returned the following informational
> message:\n%s"] $program $errMsg] \
>          0 OK
>      }
> }
> 
> DialogGen is a nice little routine in gis_set.tcl that pops up a dialog
> box. There are some comments in gis_set.tcl on how to use it.

I've seen it, but would probably use the native tk_messageBox. It takes
about the same amount of code in the original program.

I started to put this in, but the problem with the mixing of stdout and
stderr for non-errors resulted in a message box that ran off the screen with
extraneous output from a problematic GRASS command. So I decided that until
that was fixed I'd just re-route all catch output to the terminal. And it
was also faster to do all the needed catch statements that way.

> 
> Please note that I'm not saying this is what you should do, nor that I
> necessarily recommend doing it now - my original comments about catching
> errors properly where really just suggestions about something that we
> should look out for in the future, as I thought it would be too much work
> do do it thoroughly and properly now so soon before 6.3.0 without
> introducing new unexpected behaviour and so on.

Understood. My time has become considerably shorter of course, and I been
trying to fix some other issues. Hopefully as they get fewer, it may be
possible to in a batch, go in and add some kind of dialog or messagebox for
error code. It would be cleaner and more professional looking to do that.

> 
> Possible problems with and notes about the above code:
> - With the catch where it is - I'm not sure if it actually catches the
> "exec" command or just the "set" command

It catches the exec command in this case. The set receives any error
message.

> - Checking the return status of the command is better than checking the
> return value of catch, because, as we've seen lots of times - Tcl will
> assume an error has happened if *any* output is written to stderr - a
> usage convention not shared by GRASS.

I *think* this is solved by redirecting the original output to devnull

> - Output issued to stderr but when the command has exited successfully
> should be handled by the second block of the if statement, and popped up
> for the user to read and then continue.

Again, I *think* that we will now only get an error message with a real
error. The user should not have to read a message and click OK if there is
no error.

> - To be neater and less confusing to the user, the possiblity of a command
> exiting with a non-zero return code but not writing anything to stderr
> should probably also be handled.

I suppose that this could be dealt with by if {$error != ""} { ...create the
messagebox...}

Thanks again for the thoughtful comments.

Michael


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

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




More information about the grass-dev mailing list