[GRASS-dev] Re: [GRASS-user] Re: grassuser Digest, Vol 9, Issue 1

[Michael Barton]

I just was able to compile the cvs version from today. It turns out that
there are 2 issues.

First, g.region -g is functionally replaced by g.region -gp
Second, there has been a format change to the output from g.region -p

Both of these can be fixed in the GUI and I will try to do so today. I have
a couple of suggestions.

I'm not sure about putting the warning in g.region -g. But if it was after
the output, it would be much less harmful in existing scripts (including the
GUI) than if it precedes normal output.

Second, I don't know how the format for g.region -p changed exactly. Perhaps
it's better than before. And I'm strongly in favor of creating better, more
parsable, more consistent, output from commands like g.region. We just need
to be careful about breaking things where it is currently used when this is
done. 

It looks like this affects both the main GUI and the georectifier in this
case.

Michael


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

> Hello Martin
> 
> On Wed, 3 Jan 2007, Martin Landa wrote:
> 
>> Hi,
>> 
>> 2007/1/2, Paul Kelly <paul-grass at stjohnspoint.co.uk>:
>> 
>>> But the other issue is of course - should we be changing the meaning of
>>> the g.region -g flag at all? Why not keep it as it is and add the new
>>> functionality (key=value output in combination with any other flag) to a
>>> totally new flag, to reduce confusion and enhance backwards compatibility?
>> 
>> not sure, there are *a lot of flags* in g.region module. Adding a new
>> one which generally have the same impact as the -g flag (i.e.
>> key=value output) -- I don't know.
>> 
>> Now `g.region -g` (still there is a warning message) is the same as
>> `g.region -pg`. I think that the -g or --g flag should have the same
>> meaning in all GRASS modules: to print parsable output. I changed the
>> -g flag behaviour mainly because I wanted to allow user to use this
>> flag in connection with other print flags, e.g. `g.region -eg`.
> 
> Yes its definitely not a bad thing to sort out the inconsistencies; you
> just need to also check how they affect other parts of GRASS. In
> particuar, gis.m seems to be quite tightly bound to the existing
> behaviour of g.region and its quirks. If you grep for g.region in the
> gui/tcltk/gis.m directory you will see quite a few places where it is
> called with different flags and then the output parsed with a regular
> expression. The return value of the regexp command isn't checked anywhere,
> so if the regular expression doesn't match the output from g.region
> exactly (e.g. because of the new features) then it will fail at some
> stage.
> 
> So it would be worthwhile I think to look at the existing uses of g.region
> and the matching regexps in gis.m and see if they can be rationalised to
> make best use of the new features of g.region.
> Worth checking throughout the whole source code actually - there are a lot
> of things that call g.region and parse its output. Like I said, definitely
> a good idea to sort out the inconsistencies but need to stay
> backward-compatible until we fix everything that depended on the old
> behaviour.
> 
> 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