[GRASS5] G_done_msg()

Any objections to removing the tests in G_done_msg() and just using:

int G_done_msg(char *msg)
{
    fprintf (stderr, _("%s complete. %s\n"), G_program_name(), msg);
    return 0;
}

?

I would like to have the "all done" message show up in the Tcl windows
as it is not always obvious when a long running module is actually
complete. Currently (for me) the tests make the GUI windows skip it.

I don't understand why it would skip if getlogin() didn't match
G_whoami(). [G_whoami() calls getpwuid(getuid())]

Piping to stderr should obviate the isatty() checks.

Even better would be to have G_done_msg() trigger a green check-mark
icon in the tcl GUI, just like G_warning() and G_fatal_error() trigger
coloured "!" and "X" icons.

Hamish

Hi,

that can be all done in GUI without changes in GRASS modules,
like it works in QGIS:
http://mpa.itc.it/radim/qgis/grass-tools4.png

I think that GRASS modules talk too much, I would be in favour
of reducing messages instead of adding new.
Regarding G_done_msg() I believe that exit(0) says the
same and it is sufficient. It only depends on GIU around
how it interprets the exit status.

Radim

On 12/6/05, Hamish <hamish_nospam@yahoo.com> wrote:

Any objections to removing the tests in G_done_msg() and just using:

int G_done_msg(char *msg)
{
    fprintf (stderr, _("%s complete. %s\n"), G_program_name(), msg);
    return 0;
}

?

I would like to have the "all done" message show up in the Tcl windows
as it is not always obvious when a long running module is actually
complete. Currently (for me) the tests make the GUI windows skip it.

I don't understand why it would skip if getlogin() didn't match
G_whoami(). [G_whoami() calls getpwuid(getuid())]

Piping to stderr should obviate the isatty() checks.

Even better would be to have G_done_msg() trigger a green check-mark
icon in the tcl GUI, just like G_warning() and G_fatal_error() trigger
coloured "!" and "X" icons.

Hamish

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

that can be all done in GUI without changes in GRASS modules,
like it works in QGIS:
http://mpa.itc.it/radim/qgis/grass-tools4.png

exactly what I think is needed.

I think that GRASS modules talk too much, I would be in favour
of reducing messages instead of adding new.
Regarding G_done_msg() I believe that exit(0) says the
same and it is sufficient. It only depends on GIU around
how it interprets the exit status.

Wasn't there a problem with the way GRASS Tcl code ran the modules,
where it the window never really knew when the module finished after you
hit "run"? (why we can't grey-out the "run" button while the module is
processing) I haven't really kept up with Michael and Glynn's spawning
changes, so this might be an outdated issue now. ??

Currently for long running number crunching modules run from the GUI,
unless you run top or gkrellm or somthing, you are left wondering as to
when it is done...

Agreed that G_done_msg() really isn't needed when run from the command
line. It is friendly though. Maybe add a debug level=1 test or something
if not run from the GUI.

Hamish

Hamish wrote:

> I think that GRASS modules talk too much, I would be in favour
> of reducing messages instead of adding new.
> Regarding G_done_msg() I believe that exit(0) says the
> same and it is sufficient. It only depends on GIU around
> how it interprets the exit status.

Wasn't there a problem with the way GRASS Tcl code ran the modules,
where it the window never really knew when the module finished after you
hit "run"?

[I'll summarise an import point which came up in off-list discussion.]

Unless you redirect the output of a process, it is returned to Tcl by
setting the process' stdout to the writer end of a pipe (with Tcl
keeping the reader end).

If the program spawns children, and allows them to inherit its stdout,
then the output from the children is indistinguishable from the output
from the original program. Consequently, exec won't return until any
children have closed their copy of the write end of the pipe (either
explicitly, or by terminating).

E.g. if you do "exec d.mon start=x0", the return value from exec will
be anything written to stdout by either d.mon, mon.start, or XDRIVER.
IOW, exec will not return until the XDRIVER process terminates.

If you don't want this behaviour (and you probably don't), possible
solutions are:

1. Have the exec command redirect d.mon's stdout to d.m's stdout
(which is probably a terminal), i.e.

  exec d.mon start=x0 >@stdout

2. Change mon.start so that XDRIVER doesn't inherit stdout. But then
you won't see any messages from XDRIVER.

3. Change XDRIVER to close its standard descriptors (this is how most
"daemon" programs behave). Again, it can't write diagnostic messages
to stdout or stderr if they have been closed.

Note that this is particularly counter-intuitive when running e.g.
d.resize, which stops the old driver and starts a new one. The new
driver will be a child of whatever called d.resize, and will inherit
its standard descriptors (which may be complete different to those
used by the old driver).

(why we can't grey-out the "run" button while the module is
processing)

That should be easy enough to implement.

In run_cmd, add:

  $opt($dlg,path).run configure -state disabled

when the command starts successfully, i.e.:

  if { $ret } {
    error $fh
  } {
    fconfigure $fh -blocking 0
    fileevent $fh readable [list prnout $dlg $fh]
    $opt($dlg,path).run configure -state disabled
  }

In prnout, add:

  $opt($dlg,path).run configure -state normal

when EOF is detected, i.e.:

  if [eof $fh] {
    close $fh
    $opt($dlg,path).run configure -state normal
  } else {

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