Details Ticket 4356


Comment | Reply | Take | Open


Serial Number 4356
Subject d.m: d.rast.num fails when called from 'Add comand layer'
Area grass6
Queue grass
Requestors werchowyna@epf.pl
Owner none
Status resolved
Last User Contact Sun Jun 11 14:41:08 2006 (2 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Sun Jun 11 14:41:08 2006 (2 yr ago)
Created Thu Apr 27 15:10:29 2006 (2 yr ago)

Transaction History Ticket 4356


Thu, Apr 27 2006 15:10:29    Request created by guest  
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
Fri, Apr 28 2006 05:31:57    Mail sent by michael.barton@asu.edu  
Return-Path <Michael.Barton@asu.edu>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 27 Apr 2006 20:31:43 -0700
From Michael Barton <michael.barton@asu.edu>
Subject Re: [GRASS5] [bug #4356] (grass) d.m: d.rast.num fails when called from 'Add comand layer'
In-reply-to <20060427131029.520B61005DB@lists.intevation.de>
To Paolo Cavallini via RT <grass-bugs@intevation.de>, grass5@grass.itc.it
Message-id <C076DAAF.A1DB%michael.barton@asu.edu>
MIME-version 1.0
Content-type text/plain; charset=US-ASCII
Content-transfer-encoding 7bit
User-Agent Microsoft-Entourage/11.2.3.060209
Thread-Topic [GRASS5] [bug #4356] (grass) d.m: d.rast.num fails when called from 'Add comand layer'
Thread-Index AcZqdETRg3/wm9ZnEdqqlAAKlXAweg==
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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
> 


Fri, Apr 28 2006 21:22:50    Mail sent by werchowyna@epf.pl  
Return-Path <werchowyna@epf.pl>
Delivered-To grass-bugs@lists.intevation.de
Date Fri, 28 Apr 2006 21:22:42 +0200
From Maciek Sieczka <werchowyna@epf.pl>
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'
Message-Id <20060428212242.2825887b.werchowyna@epf.pl>
In-Reply-To <C076DAAF.A1DB%michael.barton@asu.edu>
References <20060427131029.520B61005DB@lists.intevation.de> <C076DAAF.A1DB%michael.barton@asu.edu>
X-Mailer Sylpheed version 2.1.1 (GTK+ 2.8.6; i486-pc-linux-gnu)
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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/


Fri, Apr 28 2006 21:37:39    Mail sent by michael.barton@asu.edu  
Return-Path <Michael.Barton@asu.edu>
Delivered-To grass-bugs@lists.intevation.de
Date Fri, 28 Apr 2006 12:34:01 -0700
From Michael Barton <michael.barton@asu.edu>
Subject Re: [GRASS5] [bug #4356] (grass) d.m: d.rast.num fails when called from 'Add comand layer'
In-reply-to <20060428212242.2825887b.werchowyna@epf.pl>
To Maciek Sieczka <werchowyna@epf.pl>
Cc Paolo Cavallini via RT <grass-bugs@intevation.de>, grass5@grass.itc.it
Message-id <C077BC39.A21C%michael.barton@asu.edu>
MIME-version 1.0
Content-type text/plain; charset=US-ASCII
Content-transfer-encoding 7bit
User-Agent Microsoft-Entourage/11.2.3.060209
Thread-Topic [GRASS5] [bug #4356] (grass) d.m: d.rast.num fails when called from 'Add comand layer'
Thread-Index AcZq+rNZ8cpFJ9btEdqqlAAKlXAweg==
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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/
> 


Fri, Apr 28 2006 22:04:10    Mail sent by werchowyna@epf.pl  
Return-Path <werchowyna@epf.pl>
Delivered-To grass-bugs@lists.intevation.de
Date Fri, 28 Apr 2006 22:04:04 +0200
From Maciek Sieczka <werchowyna@epf.pl>
To Michael Barton via RT <grass-bugs@intevation.de>
Subject Re: [bug #4356] (grass) d.m: d.rast.num fails when called
Message-Id <20060428220404.818b71a9.werchowyna@epf.pl>
In-Reply-To <20060428193739.30D53101EEC@lists.intevation.de>
References <20060428193739.30D53101EEC@lists.intevation.de>
X-Mailer Sylpheed version 2.1.1 (GTK+ 2.8.6; i486-pc-linux-gnu)
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
On Fri, 28 Apr 2006 21:37:39 +0200 (CEST)
Michael Barton via RT <grass-bugs@intevation.de> wrote:

> 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.

CVS 2006-04-23. d.rast.num from console, with gis.m on, says:

---
No graphics monitor has been selected for output.
Please run "d.mon" to select a graphics monitor
---

Should I grab a newer CVS?

Maciek

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


Mon, May 1 2006 11:47:17    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Mon, 1 May 2006 21:46:53 +1200
From Hamish <hamish_nospam@yahoo.com>
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'
Message-Id <20060501214653.732f4421.hamish_nospam@yahoo.com>
In-Reply-To <C077BC39.A21C%michael.barton@asu.edu>
References <20060428212242.2825887b.werchowyna@epf.pl> <C077BC39.A21C%michael.barton@asu.edu>
X-Mailer Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
X-Face M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
X-Spam-Level
> > 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


Mon, May 1 2006 16:02:28    Mail sent by michael.barton@asu.edu  
Return-Path <Michael.Barton@asu.edu>
Delivered-To grass-bugs@lists.intevation.de
Date Mon, 01 May 2006 07:02:04 -0700
From Michael Barton <michael.barton@asu.edu>
Subject Re: [GRASS5] [bug #4356] (grass) d.m: d.rast.num fails when called from 'Add comand layer'
In-reply-to <20060501214653.732f4421.hamish_nospam@yahoo.com>
To Hamish <hamish_nospam@yahoo.com>
Cc Maciek Sieczka <werchowyna@epf.pl>, Paolo Cavallini via RT <grass-bugs@intevation.de>, grass5@grass.itc.it
Message-id <C07B62EC.A29D%michael.barton@asu.edu>
MIME-version 1.0
Content-type text/plain; charset=US-ASCII
Content-transfer-encoding 7bit
User-Agent Microsoft-Entourage/11.2.3.060209
Thread-Topic [GRASS5] [bug #4356] (grass) d.m: d.rast.num fails when called from 'Add comand layer'
Thread-Index AcZtJ9MhEWk/t9kbEdqxagAKlXAweg==
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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


Mon, May 1 2006 19:29:30    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <17494.17755.957217.643066@cerise.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'
In-Reply-To <20060501214653.732f4421.hamish_nospam@yahoo.com>
References <20060428212242.2825887b.werchowyna@epf.pl> <C077BC39.A21C%michael.barton@asu.edu> <20060501214653.732f4421.hamish_nospam@yahoo.com>
X-Mailer VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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>


Mon, May 1 2006 20:04:06    Mail sent by michael.barton@asu.edu  
Return-Path <Michael.Barton@asu.edu>
Delivered-To grass-bugs@lists.intevation.de
Date Mon, 01 May 2006 11:02:08 -0700
From Michael Barton <michael.barton@asu.edu>
Subject Re: [GRASS5] [bug #4356] (grass) d.m: d.rast.num fails when called from 'Add comand layer'
In-reply-to <17494.17755.957217.643066@cerise.gclements.plus.com>
To Glynn Clements <glynn@gclements.plus.com>, Hamish <hamish_nospam@yahoo.com>
Cc Maciek Sieczka <werchowyna@epf.pl>, Paolo Cavallini via RT <grass-bugs@intevation.de>, grass5@grass.itc.it
Message-id <C07B9B30.21013%michael.barton@asu.edu>
MIME-version 1.0
Content-type text/plain; charset=US-ASCII
Content-transfer-encoding 7bit
User-Agent Microsoft-Entourage/11.2.3.060209
Thread-Topic [GRASS5] [bug #4356] (grass) d.m: d.rast.num fails when called from 'Add comand layer'
Thread-Index AcZtSVyVmvmKOtk8EdqyQQAUUSYxwg==
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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>


Tue, May 2 2006 08:47:19    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Tue, 2 May 2006 18:47:05 +1200
From Hamish <hamish_nospam@yahoo.com>
To grass5@grass.itc.it
Cc grass-bugs@intevation.de
Subject Re: [GRASS5] [bug #4356] (grass) d.m: d.rast.num fails when called from 'Add comand layer'
Message-Id <20060502184705.3ab23cfd.hamish_nospam@yahoo.com>
In-Reply-To <17494.17755.957217.643066@cerise.gclements.plus.com>
References <20060428212242.2825887b.werchowyna@epf.pl> <C077BC39.A21C%michael.barton@asu.edu> <20060501214653.732f4421.hamish_nospam@yahoo.com> <17494.17755.957217.643066@cerise.gclements.plus.com>
X-Mailer Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
X-Face M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
X-Spam-Level
> > 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


Tue, May 2 2006 19:31:54    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <17495.38789.431588.719520@cerise.gclements.plus.com>
Date Tue, 2 May 2006 18:31:49 +0100
To Hamish <hamish_nospam@yahoo.com>
Cc grass5@grass.itc.it, grass-bugs@intevation.de
Subject Re: [GRASS5] [bug #4356] (grass) d.m: d.rast.num fails when called from 'Add comand layer'
In-Reply-To <20060502184705.3ab23cfd.hamish_nospam@yahoo.com>
References <20060428212242.2825887b.werchowyna@epf.pl> <C077BC39.A21C%michael.barton@asu.edu> <20060501214653.732f4421.hamish_nospam@yahoo.com> <17494.17755.957217.643066@cerise.gclements.plus.com> <20060502184705.3ab23cfd.hamish_nospam@yahoo.com>
X-Mailer VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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>


Sun, Jun 11 2006 14:41:08    Status changed to resolved by msieczka  
Sun, Jun 11 2006 14:41:08    Mail sent by msieczka  
Fixed, thanks. Closing it.

Maciek
Comment | Reply | Take | Open

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request