[GRASS5] Messages and GUI

[Radim_Blazek]

I have added G_messages and modified a bit G_percent, G_warning
and G_fatal_error. If GRASS_MESSAGE_FORMAT enviroment (not GRASS) variable
is set to 'gui', those functions print messages in format
suitable for parsing by GUI. gui.tcl was also modified and
displays progress bar if G_percent is used and adds icons to output box.
http://mpa.itc.it/radim/g51/messages1.png

Subject for discussion.

Question: G_warning/G_messages/G_fatal_error can print more lines,
how to tell to GUI that it is one message?

Radim

[Glynn_Clements1]

Radim Blazek wrote:

I have added G_messages and modified a bit G_percent, G_warning
and G_fatal_error. If GRASS_MESSAGE_FORMAT enviroment (not GRASS) variable
is set to 'gui', those functions print messages in format
suitable for parsing by GUI. gui.tcl was also modified and
displays progress bar if G_percent is used and adds icons to output box.
http://mpa.itc.it/radim/g51/messages1.png

Subject for discussion.

Question: G_warning/G_messages/G_fatal_error can print more lines,
how to tell to GUI that it is one message?

Print begin/end markers rather than a prefix in front of each line,
e.g.

  GRASS_INFO_WARNING
  message
  goes
  here
  GRASS_INFO_END

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

[cmbarton]

This is very nice and will make GRASS behavior more intelligible to users.
I'm not sure exactly what your question is. Perhaps Glynn or Hamish
understands better. I take it that for this to work well, G_percent must be
called by the C module?

Michael

On 11/12/04 9:22 AM, "Radim Blazek" <blazek@itc.it> wrote:

I have added G_messages and modified a bit G_percent, G_warning
and G_fatal_error. If GRASS_MESSAGE_FORMAT enviroment (not GRASS) variable
is set to 'gui', those functions print messages in format
suitable for parsing by GUI. gui.tcl was also modified and
displays progress bar if G_percent is used and adds icons to output box.
http://mpa.itc.it/radim/g51/messages1.png

Subject for discussion.

Question: G_warning/G_messages/G_fatal_error can print more lines,
how to tell to GUI that it is one message?

Radim

______________________________
Michael Barton, Professor of Anthropology
School of Human, Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

[Radim_Blazek]

Glynn Clements wrote:

Radim Blazek wrote:

I have added G_messages and modified a bit G_percent, G_warning
and G_fatal_error. If GRASS_MESSAGE_FORMAT enviroment (not GRASS) variable
is set to 'gui', those functions print messages in format
suitable for parsing by GUI. gui.tcl was also modified and
displays progress bar if G_percent is used and adds icons to output box.
http://mpa.itc.it/radim/g51/messages1.png

Subject for discussion.

Question: G_warning/G_messages/G_fatal_error can print more lines,
how to tell to GUI that it is one message?

Print begin/end markers rather than a prefix in front of each line,
e.g.

  GRASS_INFO_WARNING
  message
  goes
  here
  GRASS_INFO_END

Cannot it happen that messages printed by a module and
a process created by the module (e.g. dbmi driver)
will be mixed together? For example:

GRASS_INFO_ERROR
module message 1
GRASS_INFO_ERROR
driver message 1
module message 2
module message 3
GRASS_INFO_END
driver message 2
GRASS_INFO_ERROR

Radim

[Radim_Blazek]

Michael Barton wrote:

This is very nice and will make GRASS behavior more intelligible to users.
I'm not sure exactly what your question is. Perhaps Glynn or Hamish
understands better. I take it that for this to work well, G_percent must be
called by the C module?

Yes.

Radim

[Huidae_Cho]

What about having a global message index so that we can number all messages:

GRASS_INFO_ERROR1
module message 1
GRASS_INFO_ERROR2
driver message 1
module message 2
module message 3
GRASS_INFO_WARNING3
module message 2
GRASS_INFO_END3
...
GRASS_INFO_END1

But, I think a prefix will work better and easier.

Huidae Cho

On Fri, 12 Nov 2004 19:22:31 +0100, Radim Blazek <blazek@itc.it> wrote:

Glynn Clements wrote:

> Radim Blazek wrote:
>
>
>>I have added G_messages and modified a bit G_percent, G_warning
>>and G_fatal_error. If GRASS_MESSAGE_FORMAT enviroment (not GRASS) variable
>>is set to 'gui', those functions print messages in format
>>suitable for parsing by GUI. gui.tcl was also modified and
>>displays progress bar if G_percent is used and adds icons to output box.
>>http://mpa.itc.it/radim/g51/messages1.png
>>
>>Subject for discussion.
>>
>>Question: G_warning/G_messages/G_fatal_error can print more lines,
>>how to tell to GUI that it is one message?
>
>
> Print begin/end markers rather than a prefix in front of each line,
> e.g.
>
> GRASS_INFO_WARNING
> message
> goes
> here
> GRASS_INFO_END

Cannot it happen that messages printed by a module and
a process created by the module (e.g. dbmi driver)
will be mixed together? For example:

GRASS_INFO_ERROR
module message 1
GRASS_INFO_ERROR
driver message 1
module message 2
module message 3
GRASS_INFO_END
driver message 2
GRASS_INFO_ERROR

Radim

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

[Radim_Blazek]

For more processes, it would be necessary to use PID + ID, I think.

Radim

Huidae Cho wrote:

What about having a global message index so that we can number all messages:

GRASS_INFO_ERROR1
module message 1
GRASS_INFO_ERROR2
driver message 1
module message 2
module message 3
GRASS_INFO_WARNING3
module message 2
GRASS_INFO_END3
...
GRASS_INFO_END1

But, I think a prefix will work better and easier.

Huidae Cho

On Fri, 12 Nov 2004 19:22:31 +0100, Radim Blazek <blazek@itc.it> wrote:

Glynn Clements wrote:

Radim Blazek wrote:

I have added G_messages and modified a bit G_percent, G_warning
and G_fatal_error. If GRASS_MESSAGE_FORMAT enviroment (not GRASS) variable
is set to 'gui', those functions print messages in format
suitable for parsing by GUI. gui.tcl was also modified and
displays progress bar if G_percent is used and adds icons to output box.
http://mpa.itc.it/radim/g51/messages1.png

Subject for discussion.

Question: G_warning/G_messages/G_fatal_error can print more lines,
how to tell to GUI that it is one message?

Print begin/end markers rather than a prefix in front of each line,
e.g.

     GRASS_INFO_WARNING
     message
     goes
     here
     GRASS_INFO_END

Cannot it happen that messages printed by a module and
a process created by the module (e.g. dbmi driver)
will be mixed together? For example:

GRASS_INFO_ERROR
module message 1
GRASS_INFO_ERROR
driver message 1
module message 2
module message 3
GRASS_INFO_END
driver message 2
GRASS_INFO_ERROR

Radim

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

[Glynn_Clements1]

Radim Blazek wrote:

>>I have added G_messages and modified a bit G_percent, G_warning
>>and G_fatal_error. If GRASS_MESSAGE_FORMAT enviroment (not GRASS) variable
>>is set to 'gui', those functions print messages in format
>>suitable for parsing by GUI. gui.tcl was also modified and
>>displays progress bar if G_percent is used and adds icons to output box.
>>http://mpa.itc.it/radim/g51/messages1.png
>>
>>Subject for discussion.
>>
>>Question: G_warning/G_messages/G_fatal_error can print more lines,
>>how to tell to GUI that it is one message?
>
>
> Print begin/end markers rather than a prefix in front of each line,
> e.g.
>
> GRASS_INFO_WARNING
> message
> goes
> here
> GRASS_INFO_END

Cannot it happen that messages printed by a module and
a process created by the module (e.g. dbmi driver)
will be mixed together? For example:

GRASS_INFO_ERROR
module message 1
GRASS_INFO_ERROR
driver message 1
module message 2
module message 3
GRASS_INFO_END
driver message 2
GRASS_INFO_ERROR

Only if the actual message is split across multiple write() calls.

Actually, that's quite possible with the current implementation. As
stderr is unbuffered, each fprintf() call will result in a separate
write.

For the GUI case, you don't need to do the formatting (the GUI can do
that if the text widget can't do it automatically). You can just do
e.g.:

  fprintf(stderr, "%s\n%s\GRASS_INFO_END\n", prefix, msg);

This should result in a single write(); so long as the total message
is less than PIPE_BUF bytes, the data won't be interleaved with that
from another process. On Linux, PIPE_BUF is 4Kb, and the functions
which call print_error() are already limited by a 2000 byte buffer.
POSIX requires that PIPE_BUF is at least 512 bytes, which should be
sufficient for most error messages.

An alternative would be to prefix each line with a message-ID composed
from the PID and a monotonic counter which increments once per
message. All lines beginning with the same ID would be part of a
single message.

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

[Radim_Blazek]

Glynn Clements wrote:

Cannot it happen that messages printed by a module and
a process created by the module (e.g. dbmi driver)
will be mixed together? For example:

GRASS_INFO_ERROR
module message 1
GRASS_INFO_ERROR
driver message 1
module message 2
module message 3
GRASS_INFO_END
driver message 2
GRASS_INFO_ERROR

Only if the actual message is split across multiple write() calls.

Actually, that's quite possible with the current implementation. As
stderr is unbuffered, each fprintf() call will result in a separate
write.

For the GUI case, you don't need to do the formatting (the GUI can do
that if the text widget can't do it automatically). You can just do
e.g.:

  fprintf(stderr, "%s\n%s\GRASS_INFO_END\n", prefix, msg);

This should result in a single write(); so long as the total message
is less than PIPE_BUF bytes, the data won't be interleaved with that
from another process. On Linux, PIPE_BUF is 4Kb, and the functions
which call print_error() are already limited by a 2000 byte buffer. POSIX requires that PIPE_BUF is at least 512 bytes, which should be
sufficient for most error messages.

An alternative would be to prefix each line with a message-ID composed
from the PID and a monotonic counter which increments once per
message. All lines beginning with the same ID would be part of a
single message.

SQL statements printed as part of error message can be quite long,
for example for v.to.db option=query, so I have used the second
possibility + GRASS_INFO_END is printed at the end because
somebody could want to open a message window on error.

Radim

[H_B]

>>>>I have added G_messages and modified a bit G_percent, G_warning
>>>>and G_fatal_error. If GRASS_MESSAGE_FORMAT enviroment (not GRASS)
>variable>>>is set to 'gui', those functions print messages in format
>>>>suitable for parsing by GUI. gui.tcl was also modified and
>>>>displays progress bar if G_percent is used and adds icons to
>output box.>>>http://mpa.itc.it/radim/g51/messages1.png

Should d.m set GRASS_MESSAGE_FORMAT=gui? and if so, should it pop up a
window or draw on the main screen?

right now it dumps to the term that started d.m:

[...]
GRASS_INFO_PERCENT: 78
GRASS_INFO_PERCENT: 81
GRASS_INFO_PERCENT: 84
GRASS_INFO_PERCENT: 87
GRASS_INFO_PERCENT: 90
GRASS_INFO_PERCENT: 93
GRASS_INFO_PERCENT: 96
GRASS_INFO_PERCENT: 99
GRASS_INFO_PERCENT: 100

Hamish

[cmbarton]

On 11/14/04 9:37 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:

I have added G_messages and modified a bit G_percent, G_warning
and G_fatal_error. If GRASS_MESSAGE_FORMAT enviroment (not GRASS)

variable>>>is set to 'gui', those functions print messages in format

suitable for parsing by GUI. gui.tcl was also modified and
displays progress bar if G_percent is used and adds icons to

output box.>>>http://mpa.itc.it/radim/g51/messages1.png

Should d.m set GRASS_MESSAGE_FORMAT=gui? and if so, should it pop up a
window or draw on the main screen?

I would vote for setting GRASS_MESSAGE_FORMAT=gui. If someone is using d.m,
they want a GUI and graphic display or at least don't mind it enough to turn
it off.

For where it shows up, I'd vote for in the message window of the module that
is running (I realize that was not one of the choices, but is the most
logical). 2nd choice would be in a popup. The main GRASS term is overly busy
as it is.

Michael

right now it dumps to the term that started d.m:

[...]
GRASS_INFO_PERCENT: 78
GRASS_INFO_PERCENT: 81
GRASS_INFO_PERCENT: 84
GRASS_INFO_PERCENT: 87
GRASS_INFO_PERCENT: 90
GRASS_INFO_PERCENT: 93
GRASS_INFO_PERCENT: 96
GRASS_INFO_PERCENT: 99
GRASS_INFO_PERCENT: 100

Hamish

____________________
C. Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

[Glynn_Clements1]

Hamish wrote:

> >>>>I have added G_messages and modified a bit G_percent, G_warning
> >>>>and G_fatal_error. If GRASS_MESSAGE_FORMAT enviroment (not GRASS)
> >variable>>>is set to 'gui', those functions print messages in format
> >>>>suitable for parsing by GUI. gui.tcl was also modified and
> >>>>displays progress bar if G_percent is used and adds icons to
> >output box.>>>http://mpa.itc.it/radim/g51/messages1.png

Should d.m set GRASS_MESSAGE_FORMAT=gui?

Yes.

and if so, should it pop up a window or draw on the main screen?

Percentages should control a status bar widget which is part of the
dialog window. Warnings should be displayed in the output window,
ideally highlighted. Errors should either be displayed similarly or in
a separate popup.

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

[H_B]

> > >>>>I have added G_messages and modified a bit G_percent,
> > >G_warning>>>and G_fatal_error. If GRASS_MESSAGE_FORMAT enviroment
> > >(not GRASS) variable>>>is set to 'gui', those functions print
> > >messages in format>>>suitable for parsing by GUI. gui.tcl was
> > >also modified and>>>displays progress bar if G_percent is used
> > >and adds icons to output
> > >box.>>>http://mpa.itc.it/radim/g51/messages1.png
>
> Should d.m set GRASS_MESSAGE_FORMAT=gui?

Yes.

> and if so, should it pop up a window or draw on the main screen?

Percentages should control a status bar widget which is part of the
dialog window. Warnings should be displayed in the output window,
ideally highlighted. Errors should either be displayed similarly or in
a separate popup.

I was talking about when you hit the d.m "(re)draw" button on the left to
draw whatever commands you have listed. there isn't necessarily a
output window. Not the G_parser() gui windows, they work ok.
Also it would run 0-100% many times for each map on the list..

Hamish

[Glynn_Clements1]

Hamish wrote:

> > > >>>>I have added G_messages and modified a bit G_percent,
> > > >G_warning>>>and G_fatal_error. If GRASS_MESSAGE_FORMAT enviroment
> > > >(not GRASS) variable>>>is set to 'gui', those functions print
> > > >messages in format>>>suitable for parsing by GUI. gui.tcl was
> > > >also modified and>>>displays progress bar if G_percent is used
> > > >and adds icons to output
> > > >box.>>>http://mpa.itc.it/radim/g51/messages1.png
> >
> > Should d.m set GRASS_MESSAGE_FORMAT=gui?
>
> Yes.
>
> > and if so, should it pop up a window or draw on the main screen?
>
> Percentages should control a status bar widget which is part of the
> dialog window. Warnings should be displayed in the output window,
> ideally highlighted. Errors should either be displayed similarly or in
> a separate popup.

I was talking about when you hit the d.m "(re)draw" button on the left to
draw whatever commands you have listed. there isn't necessarily a
output window. Not the G_parser() gui windows, they work ok.
Also it would run 0-100% many times for each map on the list..

So where does the process' output go in this case?

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

[cmbarton]

Hamish and Glynn,

Thanks for copying me. For what it's worth, I guess I don't think a progress
bar is needed for (re)drawing the active monitor from the GIS Manager tool
bar. Unlike a process like v.surf.rst, redrawing the monitor has an inherent
visual indicator of progress--i.e., the map(s) occupy the visual space of
the monitor from top to bottom at varying speed. There is no such inherent
indicator for other processes, so it is helpful to have GRASS provide
one--so you know if there is time to go for a coffee or not

Michael

On 11/17/04 8:49 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

Hamish wrote:

I have added G_messages and modified a bit G_percent,

G_warning>>>and G_fatal_error. If GRASS_MESSAGE_FORMAT enviroment
(not GRASS) variable>>>is set to 'gui', those functions print
messages in format>>>suitable for parsing by GUI. gui.tcl was
also modified and>>>displays progress bar if G_percent is used
and adds icons to output
box.>>>http://mpa.itc.it/radim/g51/messages1.png

Should d.m set GRASS_MESSAGE_FORMAT=gui?

Yes.

and if so, should it pop up a window or draw on the main screen?

Percentages should control a status bar widget which is part of the
dialog window. Warnings should be displayed in the output window,
ideally highlighted. Errors should either be displayed similarly or in
a separate popup.

I was talking about when you hit the d.m "(re)draw" button on the left to
draw whatever commands you have listed. there isn't necessarily a
output window. Not the G_parser() gui windows, they work ok.
Also it would run 0-100% many times for each map on the list..

So where does the process' output go in this case?

______________________________
Michael Barton, Professor of Anthropology
School of Human, Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

[H_B]

> I was talking about when you hit the d.m "(re)draw" button on the left to
> draw whatever commands you have listed. there isn't necessarily a
> output window. Not the G_parser() gui windows, they work ok.
> Also it would run 0-100% many times for each map on the list..

So where does the process' output go in this case?

in the main terminal window, even if I start with 'grass57 -gui'

Hamish

[Glynn_Clements1]

Hamish wrote:

> > I was talking about when you hit the d.m "(re)draw" button on the left to
> > draw whatever commands you have listed. there isn't necessarily a
> > output window. Not the G_parser() gui windows, they work ok.
> > Also it would run 0-100% many times for each map on the list..
>
> So where does the process' output go in this case?

in the main terminal window, even if I start with 'grass57 -gui'

In which case, GRASS_MESSAGE_FORMAT shouldn't be set to 'gui' when
performing redraw.

The setting should probably go into run_cmd in gui.tcl, so that
anything which is having its output processed by prnout uses the GUI
format, while everything else uses the terminal format. E.g.

  set env(GRASS_MESSAGE_FORMAT) gui
  if {[catch {open $cmd r} fh]} {
    unset env(GRASS_MESSAGE_FORMAT)
    error $fh
  } {
    fconfigure $fh -blocking 0
    fileevent $fh readable [list prnout $dlg $fh]
  }
  unset env(GRASS_MESSAGE_FORMAT)

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