[GRASS-dev] g.rename consolidation

[H_B]

Jáchym Èepický wrote:

In my opinion, GRASS modules are verbosed too much (e.g. see
r.terraflow). Message has for the user only then sence, if it is
error, warning or user will have to wait longer time (so G_percent
should be used imidietly after this). otherwise it is task for G_debug

So basicly, I would like to remove most of the "closing maps" and
similar messages. if you want to inform the user about e.g. how many
points were processed, we should use fprintf to stdout for it, since
this is not a message, but a result...

Rather than a full delete, if you wish to get rid of status/progress
messages (for quick running modules) please move the messages to
G_debug(1,"") etc. It would be nice to able to run with DEBUG=1 all the
time without huge amounts of noise, so maybe some of the existing
less interesting debug-1 messages could move to debug-2, etc.

(without violating these rules from lib/gis/debug.c)
* Levels: (recommended levels)
* 1 - message is printed once or few times per module
* 3 - each row (raster) or line (vector)
* 5 - each cell (raster) or point (vector)

I'm still not sure when to use --verbose vs. G_debug(1,).
ie due to the existence of G_debug(1,) is there any need for --verbose?
When to use one or the other? Do we really need --verbose at all?

I think it is a pain to always advertise --verbose, when it is only used
in a few modules. How are you supposed to guess that it does anything?

thanks,
Hamish

[H_B]

> Glynn Clements wrote:
>> Tcl knows when a process finishes by the "eof" from the stream
>> identifier which "open |..." returns. There's no reason why the
>> Tcl/Tk GUI can't add something to the gronsole when the command has
>> finished, regardless of whether or not the module uses
>> G_done_message().
>

H:

> then let's do it!

Michael Barton wrote:

Isn't this what Cedrick's code already does? When a module starts, a
little running person icon shows up in the output window (i.e., the
module is "running"). When the module finishes, the little runner goes
away.

I'd prefer to see this in the module's gui window "Output" tab, not the
gis.m output console.

Or at minimum replace the spent runner with a green tick mark if the
module exited with a successful exit code.

Hamish

[cmbarton]

Both of these sound like good ideas.

Michael

On 2/26/07 10:28 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Glynn Clements wrote:

Tcl knows when a process finishes by the "eof" from the stream
identifier which "open |..." returns. There's no reason why the
Tcl/Tk GUI can't add something to the gronsole when the command has
finished, regardless of whether or not the module uses
G_done_message().

H:

then let's do it!

Michael Barton wrote:

Isn't this what Cedrick's code already does? When a module starts, a
little running person icon shows up in the output window (i.e., the
module is "running"). When the module finishes, the little runner goes
away.

I'd prefer to see this in the module's gui window "Output" tab, not the
gis.m output console.

Or at minimum replace the spent runner with a green tick mark if the
module exited with a successful exit code.

Hamish

__________________________________________
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

[marisn]

Hi,

just to illustrate my point, that current way of notifying user about
process run is not intuitive.

Take look at this screenshot:
http://www.gisnet.lv/ggmlinux/Grass-25.png

Is r.watershed still runing? (Those, who know GRASS enough, will
notice, that "RUN" button is enabled - r.watershed is not running
anymore) Is r.watershed finised it's run with success? And what would
happen, if gis.m output window is covered (behind) other windows? I
have moved output window to top, but normaly it would be behind all
other gis.m windows.

r.watershed isn't worst module - just run some of v.* modules, that
require rebuilding tolopgy and picture will become worse, as output in
gis.m output window just scrolls up with every line and that progress
bar/runner just goes far, far away.

Just my 0.002,
Maris.

2007/2/27, Michael Barton <michael.barton@asu.edu>:

Both of these sound like good ideas.

Michael

On 2/26/07 10:28 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:

>>> Glynn Clements wrote:
>>>> Tcl knows when a process finishes by the "eof" from the stream
>>>> identifier which "open |..." returns. There's no reason why the
>>>> Tcl/Tk GUI can't add something to the gronsole when the command has
>>>> finished, regardless of whether or not the module uses
>>>> G_done_message().
>>>
> H:
>>> then let's do it!
>
> Michael Barton wrote:
>> Isn't this what Cedrick's code already does? When a module starts, a
>> little running person icon shows up in the output window (i.e., the
>> module is "running"). When the module finishes, the little runner goes
>> away.
>
> I'd prefer to see this in the module's gui window "Output" tab, not the
> gis.m output console.
>
> Or at minimum replace the spent runner with a green tick mark if the
> module exited with a successful exit code.
>
> Hamish

__________________________________________
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

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

[Jachym_Cepicky]

--verbose is here to set temporary GRASS_VERBOSE to heigher level, if
it is set to 0 or 1

so it makes sence to have it, but Im not sure, if it makes sence to
have it in the help message na all the manual pages..

j

2007/2/27, Hamish <hamish_nospam@yahoo.com>:

Jáchym Èepický wrote:
> In my opinion, GRASS modules are verbosed too much (e.g. see
> r.terraflow). Message has for the user only then sence, if it is
> error, warning or user will have to wait longer time (so G_percent
> should be used imidietly after this). otherwise it is task for G_debug
>
> So basicly, I would like to remove most of the "closing maps" and
> similar messages. if you want to inform the user about e.g. how many
> points were processed, we should use fprintf to stdout for it, since
> this is not a message, but a result...

Rather than a full delete, if you wish to get rid of status/progress
messages (for quick running modules) please move the messages to
G_debug(1,"") etc. It would be nice to able to run with DEBUG=1 all the
time without huge amounts of noise, so maybe some of the existing
less interesting debug-1 messages could move to debug-2, etc.

(without violating these rules from lib/gis/debug.c)
* Levels: (recommended levels)
* 1 - message is printed once or few times per module
* 3 - each row (raster) or line (vector)
* 5 - each cell (raster) or point (vector)

I'm still not sure when to use --verbose vs. G_debug(1,).
ie due to the existence of G_debug(1,) is there any need for --verbose?
When to use one or the other? Do we really need --verbose at all?

I think it is a pain to always advertise --verbose, when it is only used
in a few modules. How are you supposed to guess that it does anything?

thanks,
Hamish

--
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub

[martinl]

Hi,

just to summarize, I suggest to reduce verbosity levels to three levels:

--q 0 MIN_LEVEL (only warnings + fatal_errors)
     1 STD_LEVEL (progress information)
--v 2 MAX_LEVEL (any "useful" information, another points is what is "useful")

E.g. Vect_build () output:

0 ... nothing printed
1 ... Registering lines: ... , etc.
2 ... all current info

Three level are enough I think, then we should move selected messages
to G_debug (1, ).

Any objections (in case I missed something)?

Martin

2007/2/27, Hamish <hamish_nospam@yahoo.com>:

Jáchym Èepický wrote:
> In my opinion, GRASS modules are verbosed too much (e.g. see
> r.terraflow). Message has for the user only then sence, if it is
> error, warning or user will have to wait longer time (so G_percent
> should be used imidietly after this). otherwise it is task for G_debug
>
> So basicly, I would like to remove most of the "closing maps" and
> similar messages. if you want to inform the user about e.g. how many
> points were processed, we should use fprintf to stdout for it, since
> this is not a message, but a result...

Rather than a full delete, if you wish to get rid of status/progress
messages (for quick running modules) please move the messages to
G_debug(1,"") etc. It would be nice to able to run with DEBUG=1 all the
time without huge amounts of noise, so maybe some of the existing
less interesting debug-1 messages could move to debug-2, etc.

(without violating these rules from lib/gis/debug.c)
* Levels: (recommended levels)
* 1 - message is printed once or few times per module
* 3 - each row (raster) or line (vector)
* 5 - each cell (raster) or point (vector)

I'm still not sure when to use --verbose vs. G_debug(1,).
ie due to the existence of G_debug(1,) is there any need for --verbose?
When to use one or the other? Do we really need --verbose at all?

I think it is a pain to always advertise --verbose, when it is only used
in a few modules. How are you supposed to guess that it does anything?

thanks,
Hamish

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

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

[Glynn_Clements1]

Hamish wrote:

> In my opinion, GRASS modules are verbosed too much (e.g. see
> r.terraflow). Message has for the user only then sence, if it is
> error, warning or user will have to wait longer time (so G_percent
> should be used imidietly after this). otherwise it is task for G_debug
>
> So basicly, I would like to remove most of the "closing maps" and
> similar messages. if you want to inform the user about e.g. how many
> points were processed, we should use fprintf to stdout for it, since
> this is not a message, but a result...

Rather than a full delete, if you wish to get rid of status/progress
messages (for quick running modules) please move the messages to
G_debug(1,"") etc. It would be nice to able to run with DEBUG=1 all the
time without huge amounts of noise, so maybe some of the existing
less interesting debug-1 messages could move to debug-2, etc.

(without violating these rules from lib/gis/debug.c)
* Levels: (recommended levels)
* 1 - message is printed once or few times per module
* 3 - each row (raster) or line (vector)
* 5 - each cell (raster) or point (vector)

I'm still not sure when to use --verbose vs. G_debug(1,).
ie due to the existence of G_debug(1,) is there any need for --verbose?
When to use one or the other? Do we really need --verbose at all?

Debug output is meant for developers, verbose messages for users.

One distinction is that messages (even verbose messages) should
ideally be localised, while debug output should never be localised.

--
Glynn Clements <glynn@gclements.plus.com>

[Glynn_Clements1]

Martin Landa wrote:

just to summarize, I suggest to reduce verbosity levels to three levels:

--q 0 MIN_LEVEL (only warnings + fatal_errors)
     1 STD_LEVEL (progress information)
--v 2 MAX_LEVEL (any "useful" information, another points is what is "useful")

E.g. Vect_build () output:

0 ... nothing printed
1 ... Registering lines: ... , etc.
2 ... all current info

Three level are enough I think, then we should move selected messages
to G_debug (1, ).

Any objections (in case I missed something)?

That seems reasonable.

On a related note, I would appreciate some way to disable percentage
output separately from other messages. My usual terminal (XEmacs'
shell-mode) doesn't support ^H, so the G_percent() output is garbage.

--
Glynn Clements <glynn@gclements.plus.com>

[Jachym_Cepicky]

Hi,
after discussion with Martin, I suggest:

GRASS_VERBOSE=0 ... QUIET_MODE - print nothing
GRASS_VERBOSE=1 ... PERCENT_MODE - print only progress information
(with relevant messge maybe?)
GRASS_VERBOSE=2 ... MESSAGE_MODE - print only messages, withou any
progress information
GRASS_VERBOSE=3 ... PERMSG_MODE - print progress and messages

GRASS> g.module --q -> QUIET_MODE
GRASS> g.module --v -> PERMSG_MODE

We are also discussing another problem:

If GRASS_VERBOSE==1, only percents are printed out, which is a little
bit confusing. It would be great, if the output would look like this:

GRASS> GRASS_VERBOSE=1; v.convert in out
Reading vector lines: 50 %
Writing vector lines: 23 %

But how to perform this?

1) On module level:
  if (G_verbose() == PERCENT_MODE) G_message("Reading vector lines");

2) Introduce new function:
  G_message_percent("Reading vector lines");

3) Add new parameter to G_percent:
   G_percent("Reading vector lines", x,y);
   or maybe better:
   char s="Reading vector lines";
   G_percent(*s, x,y);

Some comments added to wiki

j
2007/2/27, Glynn Clements <glynn@gclements.plus.com>:

Martin Landa wrote:

> just to summarize, I suggest to reduce verbosity levels to three levels:
>
> --q 0 MIN_LEVEL (only warnings + fatal_errors)
> 1 STD_LEVEL (progress information)
> --v 2 MAX_LEVEL (any "useful" information, another points is what is "useful")
>
> E.g. Vect_build () output:
>
> 0 ... nothing printed
> 1 ... Registering lines: ... , etc.
> 2 ... all current info
>
> Three level are enough I think, then we should move selected messages
> to G_debug (1, ).
>
> Any objections (in case I missed something)?

That seems reasonable.

On a related note, I would appreciate some way to disable percentage
output separately from other messages. My usual terminal (XEmacs'
shell-mode) doesn't support ^H, so the G_percent() output is garbage.

--
Glynn Clements <glynn@gclements.plus.com>

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub

[Maciej_Sieczka2]

Michael Barton wrote:

TclTk has a nice progress bar capabilities. But it needs consistent
information to read. There is a progress bar built into the map display that
tracks display progress. For modules that output consistent progress
information, there is the green progress bar in the autogenerated dialog.
The holes are for modules that don't output progress information in a
consistent format and for scripts that tend not to output it at all.

Is it possible to make the script output progress info in way tcl/tk
GRASS GUI could use it?

Maciek

[Glynn_Clements1]

Maciej Sieczka wrote:

Michael Barton wrote:
> TclTk has a nice progress bar capabilities. But it needs consistent
> information to read. There is a progress bar built into the map display that
> tracks display progress. For modules that output consistent progress
> information, there is the green progress bar in the autogenerated dialog.
> The holes are for modules that don't output progress information in a
> consistent format and for scripts that tend not to output it at all.

Is it possible to make the script output progress info in way tcl/tk
GRASS GUI could use it?

  if [ "$GRASS_MESSAGE_FORMAT" = "gui" ] ; then
    echo "GRASS_INFO_PERCENT: $percent" >&2
  fi

It could get tricky if the script calls modules which output their own
percentages.

I suppose that the script *could* process the commands' stderr, parse
the percentages and re-emit them to its own stderr, scaled according
to the proportion of the task that the command represents. Although,
I'm not expecting to see many scripts actually taking that approach.

--
Glynn Clements <glynn@gclements.plus.com>

[Maciej_Sieczka2]

Glynn Clements wrote:

Maciej Sieczka wrote:

Michael Barton wrote:

TclTk has a nice progress bar capabilities. But it needs consistent
information to read. There is a progress bar built into the map display that
tracks display progress. For modules that output consistent progress
information, there is the green progress bar in the autogenerated dialog.
The holes are for modules that don't output progress information in a
consistent format and for scripts that tend not to output it at all.

Is it possible to make the script output progress info in way tcl/tk
GRASS GUI could use it?

  if [ "$GRASS_MESSAGE_FORMAT" = "gui" ] ; then
    echo "GRASS_INFO_PERCENT: $percent" >&2
  fi

Thank you (I couldn't find this GRASS_INFO_PERCENT documented in
variables.html).

It could get tricky if the script calls modules which output their own
percentages.

I suppose that the script *could* process the commands' stderr, parse
the percentages and re-emit them to its own stderr, scaled according
to the proportion of the task that the command represents. Although,
I'm not expecting to see many scripts actually taking that approach.

Just one (I hope ) question more: could I somehow disable module's
progress output alone, still letting it print it's ERRORs, ie. not
sending both it's sdout and stderr to /dev/null?

Maciek

[H_B]

Maciej Sieczka wrote:

Just one (I hope ) question more: could I somehow disable module's
progress output alone, still letting it print it's ERRORs, ie. not
sending both it's sdout and stderr to /dev/null?

that is what --quiet and GRASS_VERBOSE=0 is supposed to do. But
migrating messages to obey that is of course a work in progress.

Hamish

[Glynn_Clements1]

Maciej Sieczka wrote:

>>> TclTk has a nice progress bar capabilities. But it needs consistent
>>> information to read. There is a progress bar built into the map display that
>>> tracks display progress. For modules that output consistent progress
>>> information, there is the green progress bar in the autogenerated dialog.
>>> The holes are for modules that don't output progress information in a
>>> consistent format and for scripts that tend not to output it at all.
>> Is it possible to make the script output progress info in way tcl/tk
>> GRASS GUI could use it?

> if [ "$GRASS_MESSAGE_FORMAT" = "gui" ] ; then
> echo "GRASS_INFO_PERCENT: $percent" >&2
> fi

Thank you (I couldn't find this GRASS_INFO_PERCENT documented in
variables.html).

GRASS_INFO_PERCENT isn't a variable; it's part of the syntax used for
progress output when modules are being run from a GUI. The default
output (using backspace characters to overwrite the previous output)
is awkward to parse, especially if any other output gets interleaved
with the percentages.

GRASS_MESSAGE_FORMAT is listed in variables.html, but it doesn't
specify its precise semantics.

> It could get tricky if the script calls modules which output their own
> percentages.
>
> I suppose that the script *could* process the commands' stderr, parse
> the percentages and re-emit them to its own stderr, scaled according
> to the proportion of the task that the command represents. Although,
> I'm not expecting to see many scripts actually taking that approach.

Just one (I hope ) question more: could I somehow disable module's
progress output alone, still letting it print it's ERRORs, ie. not
sending both it's sdout and stderr to /dev/null?

Currently, no. Supporting e.g. GRASS_MESSAGE_FORMAT=silent would be a
useful enhancement.

--
Glynn Clements <glynn@gclements.plus.com>

[Glynn_Clements1]

Hamish wrote:

> Just one (I hope ) question more: could I somehow disable module's
> progress output alone, still letting it print it's ERRORs, ie. not
> sending both it's sdout and stderr to /dev/null?

that is what --quiet and GRASS_VERBOSE=0 is supposed to do. But
migrating messages to obey that is of course a work in progress.

That will disable all messages except warnings and errors. In
retrospect, that may have been what Maciej was asking for, but I took
"progress output" to mean the percentages and nothing else.

--
Glynn Clements <glynn@gclements.plus.com>

[H_B]

Glynn Clements wrote:

> Just one (I hope ) question more: could I somehow disable
> module's progress output alone, still letting it print it's ERRORs,
> ie. not sending both it's sdout and stderr to /dev/null?

Currently, no. Supporting e.g. GRASS_MESSAGE_FORMAT=silent would be a
useful enhancement.

this little patch adds GRASS_MESSAGE_FORMAT=silent to error.c, but not
for G_percent() as then it would need a global variable. Better to just
put another getenv("GRASS_MESSAGE_FORMAT") and strcmp(,"silent") in
percent.c and clicker.c? Anywhere else?

Hamish

(attachments)

g_info_silent.diff (1.49 KB)

[Glynn_Clements1]

Hamish wrote:

> > Just one (I hope ) question more: could I somehow disable
> > module's progress output alone, still letting it print it's ERRORs,
> > ie. not sending both it's sdout and stderr to /dev/null?
>
> Currently, no. Supporting e.g. GRASS_MESSAGE_FORMAT=silent would be a
> useful enhancement.

this little patch adds GRASS_MESSAGE_FORMAT=silent to error.c, but not
for G_percent() as then it would need a global variable. Better to just
put another getenv("GRASS_MESSAGE_FORMAT") and strcmp(,"silent") in
percent.c and clicker.c? Anywhere else?

G_percent2() already calls G_info_format(), so it should only need
this:

--- lib/gis/percent.c 9 Jan 2007 12:30:08 -0000 2.9
+++ lib/gis/percent.c 2 Mar 2007 06:20:47 -0000
@@ -102,7 +102,7 @@
   : (int) (100 * n / d);

     /* be verbose only 1> */
- if (G_verbose() < 1)
+ if (format == G_INFO_FORMAT_SILENT || G_verbose() < 1)
         return 0;

     if (n <= 0 || n >= d || x > prev + s)

--
Glynn Clements <glynn@gclements.plus.com>

[Glynn_Clements1]

Hamish wrote:

Glynn Clements wrote:

this little patch adds GRASS_MESSAGE_FORMAT=silent to error.c, but not
for G_percent() as then it would need a global variable. Better to just
put another getenv("GRASS_MESSAGE_FORMAT") and strcmp(,"silent") in
percent.c and clicker.c? Anywhere else?

--- lib/gis/error.c 22 Feb 2007 10:18:53 -0000 1.15
+++ lib/gis/error.c 2 Mar 2007 05:31:28 -0000
@@ -282,7 +282,8 @@
       while (print_word(stderr,&w,&len,lead))
         ;

- if ( (type != MSG) && isatty(fileno(stderr))) { /* Bell */
+ if ( (type != MSG) && isatty(fileno(stderr))
+ && (grass_info_format == G_INFO_FORMAT_STANDARD) ) { /* Bell */

This doesn't compile, as grass_info_format is local to
G_info_format(). Fix:

- && (grass_info_format == G_INFO_FORMAT_STANDARD) ) { /* Bell */
+ && (G_info_format() == G_INFO_FORMAT_STANDARD) ) { /* Bell */

Although, technically it shouldn't be printing "\7" without checking
the terminal's termcap/terminfo entry.

[I'm not suggesting that it should actually do that; making libgis
depend upon libtermcap/libtinfo/lib[n]curses would be overkill. Having
the occasional ^G in the output is small fry compared to the string of
^H characters from G_percent().]

--
Glynn Clements <glynn@gclements.plus.com>