[GRASS-dev] Re: single-click zoom doesn't preserve aspect ratio

[Michael Barton]

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 at yahoo.com>
> Date: Wed, 8 Nov 2006 19:43:46 +1300
> To: Michael Barton <michael.barton at asu.edu>
> Subject: Re: [GRASS-dev] Re: single-click zoom doesn't preserve aspect ratio
> 
> Michael 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=633
>> 
>> Will 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