Hamish,
We just updated on an FC4 machine and the TclTk interface fails at startup
with a can't find parts(w) error. However, if we start gis.m manually from
the command line after this it starts fine. If I run g.region -g it produces
the proper data for "parts(w), etc". So something is happening to prevent
g.region from initially working or passing its information to the TclTk
variables when first moving from the startup screen to the GUI. This worked
fine with an updated GUI but without updated C-code until we recompiled
today.
In another case (a new FC6 machine), we get the same error, but for a
different reason. In that case we can't start because gdal is not installed
and g.region fails.
I can trap a g.region call, but I don't know yet if that will help the first
case. It won't help the second one because g.region needs to work to
initialize the displays.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
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
From: Hamish <hamish_nospam@yahoo.com>
Date: Wed, 8 Nov 2006 19:43:46 +1300
To: Michael Barton <michael.barton@asu.edu>
Subject: Re: [GRASS-dev] Re: single-click zoom doesn't preserve aspect ratioMichael Barton wrote:
You put your finger on the biggest problem. TclTk can indicate why it
fails internally, but (especially important in this case), not what
external factor is causing TclTk to fail.In this case, the array "parts" is populated by running and parsing
g.region -ug.Each "part" is a value from g.region -g
n=4928000
s=4914020
w=590010
e=609000
nsres=30
ewres=30
rows=466
cols=633Will be parsed as parts(n) = 4928000, parts(s) = 4914020, etc.
So it looks like g.region -g is not returning anything to populate the
array.Is it g.region per se, or just that g.region happens to be the first
GRASS module called in the session? I am suspecting the latter.I agree it is way too much work to catch all errors, but if we know
where the symptoms of total breakage will first appear, then we can
focus the error checking in that one place. I guess where this place
will be, will become readily apparent after a few more users make
themselves broken installs.best,
Hamish