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

Wed Dec 16 14:04:15 EST 2009

This makes some sense.

Python compiles at runtime. So the first time you run the GUI, each module will compile the first time it is run. Subsequently, all modules will run the compiled code. If you update and the code in a compiled and uncompiled module do not match, that module will compile the first time you use it again.

Michael
______________________________
C. Michael Barton 
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ  85287-2402
USA

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

On Dec 16, 2009, at 10:34 AM, Dylan Beaudette wrote:

> On Wednesday 16 December 2009, Michael Barton wrote:
>> Darn. All of my ideas about why this doesn't work right don't work. I guess
>> try what Hamish said.
>> 
>> Michael
> 
> OK--
> 
> This time, starting GRASS, and the GUI-- and raster and vector maps are 
> displayed within about 2-6 seconds. I wonder if this is a byte-code compiling 
> thing... the first time GRASS was run with the new modules = slow, closing 
> and opening again = fast?
> 
> looking at the output in top, I could see that a process called 'python' was 
> using 99% of CPU, and about 3% of available memory. Nothing else looked 
> suspicious. 
> 
> I really like the auto-complete stuff, with a little work this may be a 
> workable alternative to the X11-based monitor. It is still about 2-3x slower 
> than the X11 version. Is the GUI faster on GRASS 7?
> 
> Thanks for all of the hard work!
> 
> Cheers,
> Dylan
> 
>> ______________________________
>> C. Michael Barton
>> Director, Center for Social Dynamics & Complexity
>> Professor of Anthropology, School of Human Evolution & Social Change
>> Arizona State University
>> Tempe, AZ  85287-2402
>> USA
>> 
>> voice: 	480-965-6262; fax: 480-965-7671
>> www: 	http://csdc.asu.edu, http://shesc.asu.edu
>> 		http://www.public.asu.edu/~cmbarton
>> 
>> On Dec 16, 2009, at 10:18 AM, Dylan Beaudette wrote:
>>> On Wednesday 16 December 2009, Michael Barton wrote:
>>>> Do you have Python 2.5?  Other version?
>>>> 
>>>> Michael
>>> 
>>> using python 2.5
>>> 
>>> Dylan
>>> 
>>>> ______________________________
>>>> C. Michael Barton
>>>> Director, Center for Social Dynamics & Complexity
>>>> Professor of Anthropology, School of Human Evolution & Social Change
>>>> Arizona State University
>>>> Tempe, AZ  85287-2402
>>>> USA
>>>> 
>>>> voice: 	480-965-6262; fax: 480-965-7671
>>>> www: 	http://csdc.asu.edu, http://shesc.asu.edu
>>>> 		http://www.public.asu.edu/~cmbarton
>>>> 
>>>> On Dec 15, 2009, at 5:32 PM, Dylan Beaudette wrote:
>>>>> On Tuesday 15 December 2009, Michael Barton wrote:
>>>>>> 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
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> No obvious issues, however the GUI does take about 20 seconds to load.
>>>>> OS is Debian/Unstable.
>>>>> 
>>>>> Here is the version info of the wx-related stuff:
>>>>> 
>>>>> libwxbase2.8-0                         2.8.7.1-2+b1
>>>>> python-wxgtk2.8                        2.8.7.1-2+b1
>>>>> wx2.8-headers                          2.8.7.1-2+b1
>>>>> 
>>>>> Cheers,
>>>>> Dylan
>>>>> 
>>>>>> 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
>>>>>>> 