[GRASS-dev] Re: a better console and better diff

[Michael Barton]

What is your OS? 

Something is very squirrelly. I'm also looking at spearfish. All displays should be in a second or two; commands like r.info should be instantaneous. I'm on a MacBook with 2Gb RAM and a 2.4 GHz core duo. So it's not as hot as your machine.

Do you have any other strange issues/messages with the GUI or Python?

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu







On Dec 15, 2009, at 4:49 PM, Dylan Beaudette wrote:

> On Tuesday 15 December 2009, Michael Barton wrote:
>> Hi Dylan,
>> 
>> Thanks very much for trying this out. A few responses below.
>> 
>> On Dec 15, 2009, at 12:07 PM, Dylan Beaudette wrote:
>>> Hi Michael,
>>> 
>>> I applied the patch, and it almost works. After running a command, I am
>>> not presented with a new line-- I need to erase the last command in order
>>> to enter a new one.
>> 
>> This seemed weird so I tried it out. This only happens with d.* commands. I
>> don't know why, but am sure that it is fixable.
> 
> Hi,
> 
> OK. I'll wait and see how things develop with the d.* commands. Overall, I 
> really like the idea, and command-completion is a real time saver!
> 
>>> Also, there is about a 45 second delay between a d.rast command and
>>> output on the canvas... Do you know what could be causing this?
>> 
>> Mine shows up in a second or two. I'm not sure what is causing this but can
>> speculate a little. First, have you turned on the 'constrain display
>> resolution to computational region settings' in the preferences? If so, and
>> if you have a map with a lot of cells, this will render slowly because
>> d.rast has to write out a file with that many pixels, then on the fly
>> compress them into the size that fits into your screen window. This would
>> be the case with any image renderer. The default is to turn this off and
>> have intelligent rendering, where the graphic file rendered by d.rast is
>> sized to match the display window in advance. So it writes comparatively
>> few pixels. For most purposes, GRASS should stay in this mode because you
>> can only see the number of pixels in your display window, regardless of the
>> number of cells in your map.
> 
> I checked, and the 'constrain display resolution to computational region 
> settings' box was un-checked. I am working with the default Spearfish region, 
> so this really isn't all that many cells.
> 
>> If you do not have the 'constrain display resolution..' mode set this way,
>> I'm don't know what the problem is. Even very large maps display quite
>> quickly for me--in a couple seconds at the most. Could be you are out of
>> disk space or RAM???
> 
> 3Gb RAM and 2x XEON processors here, shouldn't be bottleneck there...
> 
> 
>>> Finally, after about 30 seconds I received a warning that d.erase wasn't
>>> yet supported.
>> 
>> This may be related to the slow rendering issue. I get the message that
>> d.erase is not implemented immediately. Note that d.erase should be easy to
>> implement.
>> 
>>> I like the idea here, but the speed of rendering is far too slow for
>>> standard usage.
>> 
>> Clearly this is far too slow, but the rendering speed (or rather its lack)
>> is not a function of either the console or wxPython canvas in this case. Is
>> it that slow when you display from the layer manager too?
>> 
>> Have you tried it for other commands -- all the non display commands? Other
>> shell commands? Any thoughts?
> 
> All commands seem to have a delay-- even executing g.region causes the CPU to 
> jump to 100% for about 15 seconds.
> 
> Cheers,
> Dylan
> 
>> Michael
> 
> 
> 
> -- 
> Dylan Beaudette
> Soil Resource Laboratory
> http://casoilresource.lawr.ucdavis.edu/
> University of California at Davis
> 530.754.7341