[GRASS-dev] Re: r49205 - in grass/trunk: lib/python raster/r.info

GRASS GIS GRASS GIS developer
1

Does this mean that we are abandoning the idea to have -g determine *how* out put is printed (i.e., shell-script style) and use other flags to determine *what* is printed?

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Nov 27, 2011, at 10:00 AM, <grass-dev-request@lists.osgeo.org> wrote:

Date: Sat, 26 Nov 2011 17:50:39 -0800 (PST)
From: Hamish <hamish_b@yahoo.com>
Subject: [GRASS-dev] Re: r49205 - in grass/trunk: lib/python
       raster/r.info
To: Martin Landa <landa.martin@gmail.com>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>
Message-ID:
       <1322358639.73854.YahooMailClassic@web110016.mail.gq1.yahoo.com>
Content-Type: text/plain; charset=iso-8859-1

Martin:

current situation is

r.info
? -g???Print raster array information only

[in shell script style!]

? -e???Print extended metadata information only

[also in shell script style!]

v.info
? -g???Print region info in shell script style
? -e???Print extended metadata info in shell
script style

which forces to open discussion again.

..did it ever close? :slight_smile:

what is new since last we discussed this is r.info's
many shell script style flags are now grouped* so
it is not as messy in the module GUI. IMHO it is a
good compromise, and consistent design among modules
is still respected.

[*] Changeset 49293 – GRASS GIS

so -rgstmpud becomes -ger instead of just one huge
-g. Non shell-script safe foo=(bar) things are kept
in -e, so you can still `eval` -g. Instances of
'(none)' have been changed to '"none"' to become
more shell friendly as well.

I would still incline to use `-g` for shell
script output as used in others modules.
I have counted more than 45 modules in trunk
which use `-g` for shell script style output.

huh? I don't understand what you are talking about.

** r.info -g, v.info -g, and g.region -g DO all
print eval-safe shell script style ** same as ever,
still shell script style, still similar to -g in
other modules...

Keep in mind that r.info and v.info's default
"pretty" output mode is a tractor-fed dot-matrix
printer style report, not a "foo: bar" listing. [and
fwiw there is no point for "min: 1.2345" instead of
"min=1.2345" style, since min= is perfectly human
friendly to read]

What they are not is a full --parsable-debug-data-
dump which may save a gui programmer 5 keystrokes
in a python library which is revisited once every
3 years, but make things totally annoying for a
command line user who uses that same flag 20 times
a day, not to mention making them eval-unsafe.

If you need a --dump-everything-parsable flag some-
where then fine add that (better yet just make a
wrapper --script instead of messing up the code),
but don't remove the fine grained eval-safe shell
script style options in the process. These things
do not have to be mutually exclusive. But -g does
have to stay shell-script (ie eval) safe.

I don't see any reason why `r.info` or `v.info`
should be exceptions.

?! they aren't !?

If you want to see an exception, look at d.what.rast
-t "terse" output flag.

Hamish

2

Michael wrote:

Does this mean that we are abandoning the idea to
have -g determine *how* out put is printed (i.e.,
shell-script style) and use other flags to
determine *what* is printed?

no/yes/in practice it doesn't matter &/or resolves
itself with a natural solution so we are just
arguing over irrelevant abstractions and bike shed
colors at this point.

For one thing that was not ever actually decided.
For g.region it was _attempted_ (amidst unresolved
disagreement), and the result was a huge mess which
took some months to recover from. But in the end
and after all that pain it didn't really matter,
as we were able to please both POVs because -g
always implies -p. If someone wanted to think of it
like -gp they could do that, if someone wanted to
think of it as just a -g button to get a fixed
result, they could do that too (most of the time).
And we were all happy (AFAIK) and could move on to
more productive and important things.

If you want to think about -g being coded to imply
-p as the 'abandoning of the idea' of a strict and
exclusive context switch, then yes we did abandon
that shortly after the idea was first attempted
some years ago. To me that is just a harmless
compromise+convenience which doesn't break anything
for anyone else.

So now we have some modules (mainly r.univar) where
-g acts to change the nature of the output, and
most modules where you press that button you get a
fixed response and can think of the "why" of it
anyway you like.. Because typically you get the same
output from both ways of thinking of it: you use -g
when you want to get shell style output & it just
works. I have a hard time imagining users ever
being very confused by this minor distinction when
they get what they want from either way of thinking
about it. If you want to confuse users having a -g
concept switch which outputs nothing when used
alone seems like a great way to do it.

Since I have never fully understood the "-g should
be for shell script style only!" comments (because
that has never changed), the best I can figure is
that r.info and v.info's report-form output is being
interpreted in others' eyes as the "-p" flag (which
doesn't exist), and so the idea is that -g shows
everything that the report-form shows, but in
a more parsable format. Breaking that long list of
report-form variables into 3 or so bite sized and
conceptually grouped chunks just doesn't seem so
horribly controversial to me. but maybe I miss the
point.

r.info and v.info basically remain almost identical
in usage as they always have been. nothing much has
changed except a bit of cleanup and consolidation.

honestly this thing is such a non-issue and we have
so many real bugs we could spend our finite energy
and time on..

through flexibility comes strength,
Hamish

3

2011/11/27 Hamish <hamish_b@yahoo.com>:

honestly this thing is such a non-issue and we have
so many real bugs we could spend our finite energy
and time on..

I absolutely agree with you! Unfortunately this long discussion about
such things is not an exception, in other words I remember quite a lot
discussions like that. I would prefer to focus myself on working
rather then discussing day and night meaning of the flags or so. Just
my personal opinion.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

4

Shrug. Seemed like a good idea, but not a big deal one way or another as long as parsable out can be had. Still, consistency is desirable when wrapping command line code in a GUI in order to avoid custom coding each module. This is less important for typing to the command line.

Michael Barton
School of Human Evolution &Social Change
Center for Social Dynamics & Complexity
Arizona State University

...Sent from my iPad

On Nov 26, 2011, at 11:51 PM, "Hamish" <hamish_b@yahoo.com> wrote:

Michael wrote:

Does this mean that we are abandoning the idea to
have -g determine *how* out put is printed (i.e.,
shell-script style) and use other flags to
determine *what* is printed?

no/yes/in practice it doesn't matter &/or resolves
itself with a natural solution so we are just
arguing over irrelevant abstractions and bike shed
colors at this point.

For one thing that was not ever actually decided.
For g.region it was _attempted_ (amidst unresolved
disagreement), and the result was a huge mess which
took some months to recover from. But in the end
and after all that pain it didn't really matter,
as we were able to please both POVs because -g
always implies -p. If someone wanted to think of it
like -gp they could do that, if someone wanted to
think of it as just a -g button to get a fixed
result, they could do that too (most of the time).
And we were all happy (AFAIK) and could move on to
more productive and important things.

If you want to think about -g being coded to imply
-p as the 'abandoning of the idea' of a strict and
exclusive context switch, then yes we did abandon
that shortly after the idea was first attempted
some years ago. To me that is just a harmless
compromise+convenience which doesn't break anything
for anyone else.

So now we have some modules (mainly r.univar) where
-g acts to change the nature of the output, and
most modules where you press that button you get a
fixed response and can think of the "why" of it
anyway you like.. Because typically you get the same
output from both ways of thinking of it: you use -g
when you want to get shell style output & it just
works. I have a hard time imagining users ever
being very confused by this minor distinction when
they get what they want from either way of thinking
about it. If you want to confuse users having a -g
concept switch which outputs nothing when used
alone seems like a great way to do it.

Since I have never fully understood the "-g should
be for shell script style only!" comments (because
that has never changed), the best I can figure is
that r.info and v.info's report-form output is being
interpreted in others' eyes as the "-p" flag (which
doesn't exist), and so the idea is that -g shows
everything that the report-form shows, but in
a more parsable format. Breaking that long list of
report-form variables into 3 or so bite sized and
conceptually grouped chunks just doesn't seem so
horribly controversial to me. but maybe I miss the
point.

r.info and v.info basically remain almost identical
in usage as they always have been. nothing much has
changed except a bit of cleanup and consolidation.

honestly this thing is such a non-issue and we have
so many real bugs we could spend our finite energy
and time on..

through flexibility comes strength,
Hamish