[GRASS5] [bug #4356] (grass) d.m: d.rast.num fails when called from 'Add comand layer'

Justin_Hickey_via_RT · April 27, 2006, 1:10pm

this bug's URL: http://intevation.de/rt/webrt?serial_num=4356
-------------------------------------------------------------------------

Subject: d.m: d.rast.num fails when called from 'Add comand layer'

Platform: GNU/Linux/x86
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: 2006-04-12

1. Add 'd.rast.num some_layer' using 'Add comand layer'.

2. When the following warning applies to d.rast.num, printed in the terminal...

---
Current window size:
rows: 154
columns: 252

Your current window setting may be too large.
Cells displayed on your graphics window may be too
small for cell category number to be visible.

Do you wish to continue(y/n) [n]
---

...then an GUI error pops up:

child process exited abnormally
child process exited abnormally
    while executing
"exec -- d.rast.num fdrp >@ stdout 2>@ stderr"
    ("eval" body line 1)
    invoked from within
"eval exec -- $cmd >@ stdout 2>@ stderr"
    (procedure "runcmd" line 5)
    invoked from within
"runcmd $cmd"
    (procedure "DmCmd::display" line 13)
    invoked from within
"DmCmd::display $node"
    ("cmd" arm line 2)
    invoked from within
"switch $type {
        group {
            DmGroup::display $node
  }
  raster {
      DmRaster::display $node
  }
  labels {
      DmLabels::display $node
..."
    (procedure "Dm::display_node" line 6)
    invoked from within
"Dm::display_node $n"
    (procedure "DmGroup::display" line 11)
    invoked from within
"DmGroup::display "root" "
    (procedure "Dm::display" line 8)
    invoked from within
"Dm::display"
    ("uplevel" body line 1)
    invoked from within
"uplevel \#0 $cmd"
    (procedure "Button::_release" line 18)
    invoked from within
"Button::_release .mainframe.topf.tb0.bbox1.b0"
    (command bound to event)

3. Even if the region is small enough for the warning not to apply, using 'Zoom' tool in d.m results in the d.zoom GUI popping up, instead of running d.zoom per se.

Maciek

-------------------------------------------- Managed by Request Tracker

cmbarton · April 28, 2006, 3:31am

Are you using d.m or gis.m?

Michael
__________________________________________
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

From: Request Tracker <grass-bugs@intevation.de>
Reply-To: Request Tracker <grass-bugs@intevation.de>
Date: Thu, 27 Apr 2006 15:10:29 +0200 (CEST)
To: <grass5@grass.itc.it>
Subject: [GRASS5] [bug #4356] (grass) d.m: d.rast.num fails when called from
'Add comand layer'

this bug's URL: http://intevation.de/rt/webrt?serial_num=4356
-------------------------------------------------------------------------

Subject: d.m: d.rast.num fails when called from 'Add comand layer'

Platform: GNU/Linux/x86
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: 2006-04-12

1. Add 'd.rast.num some_layer' using 'Add comand layer'.

2. When the following warning applies to d.rast.num, printed in the
terminal...

---
Current window size:
rows: 154
columns: 252

Your current window setting may be too large.
Cells displayed on your graphics window may be too
small for cell category number to be visible.

Do you wish to continue(y/n) [n]
---

...then an GUI error pops up:

child process exited abnormally
child process exited abnormally
    while executing
"exec -- d.rast.num fdrp >@ stdout 2>@ stderr"
    ("eval" body line 1)
    invoked from within
"eval exec -- $cmd >@ stdout 2>@ stderr"
    (procedure "runcmd" line 5)
    invoked from within
"runcmd $cmd"
    (procedure "DmCmd::display" line 13)
    invoked from within
"DmCmd::display $node"
    ("cmd" arm line 2)
    invoked from within
"switch $type {
        group {
            DmGroup::display $node
}
raster {
   DmRaster::display $node
}
labels {
   DmLabels::display $node
..."
    (procedure "Dm::display_node" line 6)
    invoked from within
"Dm::display_node $n"
    (procedure "DmGroup::display" line 11)
    invoked from within
"DmGroup::display "root" "
    (procedure "Dm::display" line 8)
    invoked from within
"Dm::display"
    ("uplevel" body line 1)
    invoked from within
"uplevel \#0 $cmd"
    (procedure "Button::_release" line 18)
    invoked from within
"Button::_release .mainframe.topf.tb0.bbox1.b0"
    (command bound to event)

3. Even if the region is small enough for the warning not to apply, using
'Zoom' tool in d.m results in the d.zoom GUI popping up, instead of running
d.zoom per se.

Maciek

-------------------------------------------- Managed by Request Tracker

Maciej_Sieczka3 · April 28, 2006, 7:22pm

On Thu, 27 Apr 2006 20:31:43 -0700
Michael Barton <michael.barton@asu.edu> wrote:

Are you using d.m or gis.m?

gis.m doesn't use X monitors - d.rast.num will not under gis.m at
all :).

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/

cmbarton · April 28, 2006, 7:34pm

In fact, r.rast.num DOES work under gis.m Fortunately, it doesn't need an
xmonitor. As far as I know it is working fine with error checking for raster
resolution, etc. This is why I'm asking which GUI you are having trouble
with. Since this has changed pretty rapidly, I should also ask which build
date are you working with.

Michael
__________________________________________
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

From: Maciek Sieczka <werchowyna@epf.pl>
Date: Fri, 28 Apr 2006 21:22:42 +0200
To: Michael Barton <michael.barton@asu.edu>
Cc: <grass-bugs@intevation.de>, <grass5@grass.itc.it>
Subject: Re: [GRASS5] [bug #4356] (grass) d.m: d.rast.num fails when called
from 'Add comand layer'

On Thu, 27 Apr 2006 20:31:43 -0700
Michael Barton <michael.barton@asu.edu> wrote:

Are you using d.m or gis.m?

gis.m doesn't use X monitors - d.rast.num will not under gis.m at
all :).

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko
najlepsze z nich!
http://katalog.panoramainternetu.pl/

H_B · May 1, 2006, 9:46am

> Subject: Re: [GRASS5] [bug #4356] (grass) d.m: d.rast.num fails when
> called from 'Add comand layer'

..

>> Are you using d.m or gis.m?
>
> gis.m doesn't use X monitors - d.rast.num will not under gis.m at
> all :).

In fact, r.rast.num DOES work under gis.m Fortunately, it doesn't need
an xmonitor. As far as I know it is working fine with error checking
for raster resolution, etc. This is why I'm asking which GUI you are
having trouble with. Since this has changed pretty rapidly, I should
also ask which build date are you working with.

If you haven't zoomed way in it used to tell you your numbers would be
tiny and did you want to continue? [y]. Then it would get stuck like
that in the output window.

d.rast.num just now updated in CVS not to use G_yes().
If things are very bad, it tells you the problem and G_fatal_error()s.
If things aren't so bad, it gives you a warning.
If things are fine, it doesn't bother you at all.

gis.m already had a test to only run if given < 10,000 cells.

I notice rendering is fairly quick off screen, quite slow on screen.
(e.g fliping to a different workspace speeds it up 100x)
For me calling from gis.m seems to be 100x slow...

AFAICT that's the last of the G_ask() and G_yes()s in the display
modules for things that don't require a full xterm.

Hamish

cmbarton · May 1, 2006, 2:02pm

I notice the slowness too, but don't know why. Thanks for the fixes.

Michael
__________________________________________
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

From: Hamish <hamish_nospam@yahoo.com>
Date: Mon, 1 May 2006 21:46:53 +1200
To: Michael Barton <michael.barton@asu.edu>
Cc: <werchowyna@epf.pl>, <grass-bugs@intevation.de>, <grass5@grass.itc.it>
Subject: Re: [GRASS5] [bug #4356] (grass) d.m: d.rast.num fails when called
from 'Add comand layer'

Subject: Re: [GRASS5] [bug #4356] (grass) d.m: d.rast.num fails when
called from 'Add comand layer'

..

Are you using d.m or gis.m?

gis.m doesn't use X monitors - d.rast.num will not under gis.m at
all :).

In fact, r.rast.num DOES work under gis.m Fortunately, it doesn't need
an xmonitor. As far as I know it is working fine with error checking
for raster resolution, etc. This is why I'm asking which GUI you are
having trouble with. Since this has changed pretty rapidly, I should
also ask which build date are you working with.

If you haven't zoomed way in it used to tell you your numbers would be
tiny and did you want to continue? [y]. Then it would get stuck like
that in the output window.

d.rast.num just now updated in CVS not to use G_yes().
If things are very bad, it tells you the problem and G_fatal_error()s.
If things aren't so bad, it gives you a warning.
If things are fine, it doesn't bother you at all.

gis.m already had a test to only run if given < 10,000 cells.

I notice rendering is fairly quick off screen, quite slow on screen.
(e.g fliping to a different workspace speeds it up 100x)
For me calling from gis.m seems to be 100x slow...

AFAICT that's the last of the G_ask() and G_yes()s in the display
modules for things that don't require a full xterm.

Hamish

Glynn_Clements1 · May 1, 2006, 5:28pm

Hamish wrote:

> > Subject: Re: [GRASS5] [bug #4356] (grass) d.m: d.rast.num fails when
> > called from 'Add comand layer'
..
> >> Are you using d.m or gis.m?
> >
> > gis.m doesn't use X monitors - d.rast.num will not under gis.m at
> > all :).
>
> In fact, r.rast.num DOES work under gis.m Fortunately, it doesn't need
> an xmonitor. As far as I know it is working fine with error checking
> for raster resolution, etc. This is why I'm asking which GUI you are
> having trouble with. Since this has changed pretty rapidly, I should
> also ask which build date are you working with.

If you haven't zoomed way in it used to tell you your numbers would be
tiny and did you want to continue? [y]. Then it would get stuck like
that in the output window.

d.rast.num just now updated in CVS not to use G_yes().
If things are very bad, it tells you the problem and G_fatal_error()s.
If things aren't so bad, it gives you a warning.
If things are fine, it doesn't bother you at all.

gis.m already had a test to only run if given < 10,000 cells.

I notice rendering is fairly quick off screen, quite slow on screen.
(e.g fliping to a different workspace speeds it up 100x)
For me calling from gis.m seems to be 100x slow...

d.rast.num call R_flush() once per character. Ouch.

For the PNG driver, that call causes the image to be written out if it
has been modified (which, in this case, it will be; one more character
has been drawn).

For the X driver, it "clears" the window (i.e. fills it with the
background pixmap, onto which everything is drawn). I suspect that the
X server may defer the filling operation if the window isn't visible.

Fix: remove the R_flush() call from the bottom of draw_number(); it's
completely gratuitous.

Modules should only call that function once a sequence of drawing
operations have completed and no further operations will occur for an
indefinite period (e.g. until the user interacts via the mouse or
terminal).

Actually, any use of that call in a d.* module is either gratuitous,
or indicates an interactive module which need to be changed or
replaced as part of the GUI project.

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

cmbarton · May 1, 2006, 6:02pm

Maybe this will speed up some other modules too. Thanks very much.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Glynn Clements <glynn@gclements.plus.com>
Date: Mon, 1 May 2006 18:28:59 +0100
To: Hamish <hamish_nospam@yahoo.com>
Cc: Michael Barton <michael.barton@asu.edu>, <werchowyna@epf.pl>,
<grass-bugs@intevation.de>, <grass5@grass.itc.it>
Subject: Re: [GRASS5] [bug #4356] (grass) d.m: d.rast.num fails when called
from 'Add comand layer'

Hamish wrote:

Subject: Re: [GRASS5] [bug #4356] (grass) d.m: d.rast.num fails when
called from 'Add comand layer'

..

Are you using d.m or gis.m?

gis.m doesn't use X monitors - d.rast.num will not under gis.m at
all :).

In fact, r.rast.num DOES work under gis.m Fortunately, it doesn't need
an xmonitor. As far as I know it is working fine with error checking
for raster resolution, etc. This is why I'm asking which GUI you are
having trouble with. Since this has changed pretty rapidly, I should
also ask which build date are you working with.

If you haven't zoomed way in it used to tell you your numbers would be
tiny and did you want to continue? [y]. Then it would get stuck like
that in the output window.

d.rast.num just now updated in CVS not to use G_yes().
If things are very bad, it tells you the problem and G_fatal_error()s.
If things aren't so bad, it gives you a warning.
If things are fine, it doesn't bother you at all.

gis.m already had a test to only run if given < 10,000 cells.

I notice rendering is fairly quick off screen, quite slow on screen.
(e.g fliping to a different workspace speeds it up 100x)
For me calling from gis.m seems to be 100x slow...

d.rast.num call R_flush() once per character. Ouch.

For the PNG driver, that call causes the image to be written out if it
has been modified (which, in this case, it will be; one more character
has been drawn).

For the X driver, it "clears" the window (i.e. fills it with the
background pixmap, onto which everything is drawn). I suspect that the
X server may defer the filling operation if the window isn't visible.

Fix: remove the R_flush() call from the bottom of draw_number(); it's
completely gratuitous.

Modules should only call that function once a sequence of drawing
operations have completed and no further operations will occur for an
indefinite period (e.g. until the user interacts via the mouse or
terminal).

Actually, any use of that call in a d.* module is either gratuitous,
or indicates an interactive module which need to be changed or
replaced as part of the GUI project.

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

H_B · May 2, 2006, 6:47am

> I notice rendering is fairly quick off screen, quite slow on screen.
> (e.g fliping to a different workspace speeds it up 100x)
> For me calling from gis.m seems to be 100x slow...

d.rast.num call R_flush() once per character. Ouch.

removed in CVS, thanks. Much faster now.

For the PNG driver, that call causes the image to be written out if it
has been modified (which, in this case, it will be; one more character
has been drawn).

For the X driver, it "clears" the window (i.e. fills it with the
background pixmap, onto which everything is drawn). I suspect that the
X server may defer the filling operation if the window isn't visible.

Fix: remove the R_flush() call from the bottom of draw_number(); it's
completely gratuitous.

Modules should only call that function once a sequence of drawing
operations have completed and no further operations will occur for an
indefinite period (e.g. until the user interacts via the mouse or
terminal).

Actually, any use of that call in a d.* module is either gratuitous,
or indicates an interactive module which need to be changed or
replaced as part of the GUI project.

[display]$ grep -rI R_flush *
d.colors/get_info.c: R_flush() ;
d.colors/interact.c: R_flush() ;
d.geodesic/plot.c: R_flush();
d.histogram/main.c: R_flush();
d.linegraph/linegraph.c: R_flush ();
d.linegraph/linegraph.c: R_flush ();
d.path/select.c: R_flush();
d.path/select.c: R_flush();
d.path/select.c: R_flush();
d.profile/What.c: R_flush();
d.rast/display.c: R_flush() ;
d.rhumbline/plot.c: R_flush();
d.text.freetype/main.c: R_flush();
d.text.freetype/main.c: R_flush();
d.what.vect/flash.c: R_flush();
d.what.vect/flash.c: R_flush();

Hamish

Glynn_Clements1 · May 2, 2006, 5:31pm

Hamish wrote:

> Actually, any use of that call in a d.* module is either gratuitous,
> or indicates an interactive module which need to be changed or
> replaced as part of the GUI project.

[display]$ grep -rI R_flush *
d.colors/get_info.c: R_flush() ;
d.colors/interact.c: R_flush() ;
d.geodesic/plot.c: R_flush();
d.histogram/main.c: R_flush();
d.linegraph/linegraph.c: R_flush ();
d.linegraph/linegraph.c: R_flush ();
d.path/select.c: R_flush();
d.path/select.c: R_flush();
d.path/select.c: R_flush();
d.profile/What.c: R_flush();
d.rast/display.c: R_flush() ;
d.rhumbline/plot.c: R_flush();
d.text.freetype/main.c: R_flush();
d.text.freetype/main.c: R_flush();
d.what.vect/flash.c: R_flush();
d.what.vect/flash.c: R_flush();

Those are all either interactive, or only call R_flush() just before
termination (unnecessary, but harmless), or R_flush() is commented
out or controlled by a macro (e.g. d.text.freetpe only calls it if
FLUSH_EACH_CHAR is defined, which is presumably a debugging feature).

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