[GRASS-dev] Re: georectifier fixes for Debian

Hamish hamish_nospam at yahoo.com
Fri Nov 3 02:00:38 EST 2006


Michael Barton wrote:
> I got a student here with Debian Ubuntu (Mepis) to try the --ui switch
> for the i.group command in georectify.tcl. It seems to solve the
> problem of i.group flashing on and off.

I have just updated to the latest CVS and the georectifier is now
working properly (AFAIU), running i.group from the other side of the
looking glass & all.

great!

> Thanks very much Hamish for suggesting it. It's in the cvs now. I'm
> copying Markus so that he can backport it to 6.2.1

in 6.2.0 the "2. create a group" button now is a no-op for me (note I'm
currently at 100% cpu + 80% RAM for a modelling task, so race-for-
resource errors might be different). Not a big deal, but we'll have to
answer the question of how to set the group up in another grass session
eventually. If this is the only last-minute 6.2.0 breakage I'll be very
happy.


Otto:
> > the i.group window opens, but when I close the "error" message below
> > appears, but I can still go on rectiifying.
> > 
> > child process exited abnormally
> > child process exited abnormally
> >      while executing
> >  "exec -- $cmd --ui"
> >      (procedure "GRMap::group" line 17)
> >      invoked from within
> >  "GRMap::group"
> >      ("uplevel" body line 1)
> >      invoked from within
> >  "uplevel \#0 $cmd"
> >      (procedure "Button::_release" line 18)
> >      invoked from within
> >  "Button::_release .grstart.mf.frame.group.a"
> >      (command bound to event)
> >  and set GCPs

No harm in it, AFAIK, just normal termination(?). The "catch" statement
hides this error message. Unfortunately the "catch" was also catching a
genuine error (expecting command line options; thus it needs a --ui GUI
[why is that?]).

>From what I've heard here the Tcl return test is bogus so there is no
way to test a good exit from a bad one?

perhaps gis.m could use a global DEBUG 0/1 setting like the start of the
nviz2.2_script has. With it changed to 1 it could disable the catches,
etc. or maybe better it could test on startup if the gisenv DEBUG was >
0 to set a global DEBUG var.


Hamish




More information about the grass-dev mailing list