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