[GRASS-dev] a better console and better diff

[Michael Barton]

First, thanks to all who advised me on making a diff that actually
patches correctly (I hope).

Here is a console with full autocomplete and calltips. For GRASS 6.5

I've put it on auto to show how it can work, but the autocompletion
could move to control key combinations too.


--Type a grass command. When you get to the ".", it brings up an
autocomplete list of relevant commands. Keep typing (or mouse up/down)
until you find the one you want and hit return.

--Press <tab> to see full calltips of command syntax for each command
entered (one command per line please)

--As you type the command arguments, hitting "=" and "," following an
"=[string]" combination will bring up context-sensitive lists of
relevant maps or other data sets (e.g. regions where appropriate).

--You can type ctrl-space to bring up a context sensitive list of maps
for raster, vector, etc. at any place in the command.

--Pressing return on the command line will run it.

This will accept shell commands (redirects and pipes don't work but
could), grass commands without arguments (brings up the GUI dialogs),
and grass commands with the short form arguments (r.info mymap) as
well as full grass commands with argument=value format.

****IMPORTANT WARNING***** Turn OFF the preferences/configuration for
default raster color tables. This is causing a bug to affect any
command entered from this console or the existing command prompt.

[Michael Barton]

A quick note. I forgot to mention that there is also command history
as before. Press ctrl-up or ctrl-down.

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

Phone: [phone]
Fax: [phone]
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu

Post by Michael Barton
First, thanks to all who advised me on making a diff that actually
patches correctly (I hope).
Here is a console with full autocomplete and calltips. For GRASS 6.5
I've put it on auto to show how it can work, but the autocompletion
could move to control key combinations too.
--Type a grass command. When you get to the ".", it brings up an
autocomplete list of relevant commands. Keep typing (or mouse up/down)
until you find the one you want and hit return.
--Press <tab> to see full calltips of command syntax for each command
entered (one command per line please)
--As you type the command arguments, hitting "=" and "," following an
"=[string]" combination will bring up context-sensitive lists of
relevant maps or other data sets (e.g. regions where appropriate).
--You can type ctrl-space to bring up a context sensitive list of maps
for raster, vector, etc. at any place in the command.
--Pressing return on the command line will run it.
This will accept shell commands (redirects and pipes don't work but
could), grass commands without arguments (brings up the GUI dialogs),
and grass commands with the short form arguments (r.info mymap) as
well as full grass commands with argument=value format.
****IMPORTANT WARNING***** Turn OFF the preferences/configuration for
default raster color tables. This is causing a bug to affect any
command entered from this console or the existing command prompt.
<
console_example4
.patch><ATT00001.txt><goutput.py><wxgui.py><ATT00002.txt>

[Michael Barton]

For those that ask, here is a set of screenshots showing using the
proposed terminal to enter a simple grass command. Hard to capture the
actual action, but perhaps this series 1-4 conveys it.

Loading Image...
Loading Image...
Loading Image...
Loading Image...

Michael

Post by Michael Barton
A quick note. I forgot to mention that there is also command history
as before. Press ctrl-up or ctrl-down.
Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Phone: [phone]
Fax: [phone]
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu

Post by Michael Barton
First, thanks to all who advised me on making a diff that actually
patches correctly (I hope).
Here is a console with full autocomplete and calltips. For GRASS 6.5
I've put it on auto to show how it can work, but the autocompletion
could move to control key combinations too.
--Type a grass command. When you get to the ".", it brings up an
autocomplete list of relevant commands. Keep typing (or mouse up/
down)
until you find the one you want and hit return.
--Press <tab> to see full calltips of command syntax for each command
entered (one command per line please)
--As you type the command arguments, hitting "=" and "," following an
"=[string]" combination will bring up context-sensitive lists of
relevant maps or other data sets (e.g. regions where appropriate).
--You can type ctrl-space to bring up a context sensitive list of maps
for raster, vector, etc. at any place in the command.
--Pressing return on the command line will run it.
This will accept shell commands (redirects and pipes don't work but
could), grass commands without arguments (brings up the GUI dialogs),
and grass commands with the short form arguments (r.info mymap) as
well as full grass commands with argument=value format.
****IMPORTANT WARNING***** Turn OFF the preferences/configuration for
default raster color tables. This is causing a bug to affect any
command entered from this console or the existing command prompt.
<
console_example4
.patch><ATT00001.txt><goutput.py><wxgui.py><ATT00002.txt>

[Tim Michelsen]

Post by Michael Barton
For those that ask, here is a set of screenshots showing using the
proposed terminal to enter a simple grass command. Hard to capture the
actual action, but perhaps this series 1-4 conveys it.
http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console1.jpg
http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console2.jpg
http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console3.jpg
http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console4.jpg
Michael

Great.
Will this go into the offical code?

[Dylan Beaudette]

Post by Michael Barton
For those that ask, here is a set of screenshots showing using the
proposed terminal to enter a simple grass command. Hard to capture the
actual action, but perhaps this series 1-4 conveys it.
http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console1.jpg
http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console2.jpg
http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console3.jpg
http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console4.jpg
Michael

Post by Michael Barton
A quick note. I forgot to mention that there is also command history
as before. Press ctrl-up or ctrl-down.
Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Phone: [phone]
Fax: [phone]
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu

Post by Michael Barton
First, thanks to all who advised me on making a diff that actually
patches correctly (I hope).
Here is a console with full autocomplete and calltips. For GRASS 6.5
I've put it on auto to show how it can work, but the autocompletion
could move to control key combinations too.
--Type a grass command. When you get to the ".", it brings up an
autocomplete list of relevant commands. Keep typing (or mouse up/
down)
until you find the one you want and hit return.
--Press <tab> to see full calltips of command syntax for each command
entered (one command per line please)
--As you type the command arguments, hitting "=" and "," following an
"=[string]" combination will bring up context-sensitive lists of
relevant maps or other data sets (e.g. regions where appropriate).
--You can type ctrl-space to bring up a context sensitive list of maps
for raster, vector, etc. at any place in the command.
--Pressing return on the command line will run it.
This will accept shell commands (redirects and pipes don't work but
could), grass commands without arguments (brings up the GUI dialogs),
and grass commands with the short form arguments (r.info mymap) as
well as full grass commands with argument=value format.
****IMPORTANT WARNING***** Turn OFF the preferences/configuration for
default raster color tables. This is causing a bug to affect any
command entered from this console or the existing command prompt.
<
console_example4
.patch><ATT00001.txt><goutput.py><wxgui.py><ATT00002.txt>

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.

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?

Finally, after about 30 seconds I received a warning that d.erase wasn't yet
supported.

I like the idea here, but the speed of rendering is far too slow for standard
usage.

Cheers,
Dylan

[Michael Barton]

Hi Dylan,

Thanks very much for trying this out. A few responses below.

Post by Dylan Beaudette
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.

Post by Dylan Beaudette
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.

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

Post by Dylan Beaudette
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.

Post by Dylan Beaudette
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?

Michael

[Dylan Beaudette]

Post by Michael Barton
Hi Dylan,
Thanks very much for trying this out. A few responses below.

Post by Dylan Beaudette
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!

Post by Michael Barton

Post by Dylan Beaudette
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.

Post by Michael Barton
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...

Post by Michael Barton

Post by Dylan Beaudette
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.

Post by Dylan Beaudette
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

Post by Michael Barton
Michael

[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: [phone]
Fax: [phone]
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu

Post by Dylan Beaudette

Post by Michael Barton
Hi Dylan,
Thanks very much for trying this out. A few responses below.

Post by Dylan Beaudette
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!

Post by Michael Barton

Post by Dylan Beaudette
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.

Post by Michael Barton
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...

Post by Michael Barton

Post by Dylan Beaudette
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.

Post by Dylan Beaudette
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

Post by Michael Barton
Michael

--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341

[Dylan Beaudette]

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

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

Post by Michael Barton
Phone: [phone]
Fax: [phone]
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu

Post by Dylan Beaudette

Post by Michael Barton
Hi Dylan,
Thanks very much for trying this out. A few responses below.

Post by Dylan Beaudette
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!

Post by Michael Barton

Post by Dylan Beaudette
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.

Post by Michael Barton
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...

Post by Michael Barton

Post by Dylan Beaudette
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.

Post by Dylan Beaudette
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

Post by Michael Barton
Michael

--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341

[Michael Barton]

I just committed an advanced command console in develbranch_6 r40053. The changes were too many to do a diff. Please give it a spin.

There are separate input and output widgets. The input widget has all the features described below. It also wraps the command so you can see it all without resizing the window or scrolling. As before, typing commands that return text will produce nice output in the output widget; typing d.* command that display something (i.e., non-interactive ones) will produce something in the display canvas.

There is now a console tab/page with the command input and output widgets, and a layer manager tab/page with display layers you can manipulate with a GUI. Upside: a cleaner, more compact, interface with all command-related controls grouped together (and somewhat easier to code). Previously, entering a command would switch to the output tab/page anyway if it was not already selected. Downside: if you display maps using d.* commands and then want to manage the display layers (drag-and-drop layer organization, change properties), you have to click the tab for the layer manager.

The only thing I'm still having trouble with is sizing the StyledTextCtrl widgets for input and output. I think the input widget should be a little shorter but neither STC's are responding to sizing methods. This should be solvable, but at least you can try out new command entry console in the meantime.

Michael

Post by Michael Barton
For those that ask, here is a set of screenshots showing using the
proposed terminal to enter a simple grass command. Hard to capture the
actual action, but perhaps this series 1-4 conveys it.
http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console1.jpg
http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console2.jpg
http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console3.jpg
http://www.public.asu.edu/~cmbarton/files/grass_screenshots/console4.jpg
Michael

Post by Michael Barton
A quick note. I forgot to mention that there is also command history
as before. Press ctrl-up or ctrl-down.
Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Phone: [phone]
Fax: [phone]
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu

Post by Michael Barton
First, thanks to all who advised me on making a diff that actually
patches correctly (I hope).
Here is a console with full autocomplete and calltips. For GRASS 6.5
I've put it on auto to show how it can work, but the autocompletion
could move to control key combinations too.
--Type a grass command. When you get to the ".", it brings up an
autocomplete list of relevant commands. Keep typing (or mouse up/
down)
until you find the one you want and hit return.
--Press <tab> to see full calltips of command syntax for each command
entered (one command per line please)
--As you type the command arguments, hitting "=" and "," following an
"=[string]" combination will bring up context-sensitive lists of
relevant maps or other data sets (e.g. regions where appropriate).
--You can type ctrl-space to bring up a context sensitive list of maps
for raster, vector, etc. at any place in the command.
--Pressing return on the command line will run it.
This will accept shell commands (redirects and pipes don't work but
could), grass commands without arguments (brings up the GUI dialogs),
and grass commands with the short form arguments (r.info mymap) as
well as full grass commands with argument=value format.
****IMPORTANT WARNING***** Turn OFF the preferences/configuration for
default raster color tables. This is causing a bug to affect any
command entered from this console or the existing command prompt.
<
console_example4
.patch><ATT00001.txt><goutput.py><wxgui.py><ATT00002.txt>

[Martin Landa]

Hi,

Post by Michael Barton
I just committed an advanced command console in develbranch_6 r40053. The changes were too many to do a diff. Please give it a spin.

I reverted this change. Reasons:

* completely breaks wxGUI

File "/usr/local/src/grass6_devel/dist.i686-pc-linux-gnu/etc/wxpython/gui_modules/prompt.py",
line 920

Post by Michael Barton

.r40052

* re-implements GPrompt, please implement GPrompSTC without touching
GPrompt (or GPromptSTC and GPromptPopUp can be subclassed from
GPrompt)

* accidentally reverts my previous changes (apparently you are working
with out-dated code). E.g. [1]

[...]

Martin

[1] http://trac.osgeo.org/grass/changeset/40053#file2 (line 122)

[Michael Barton]

Post by Martin Landa
* completely breaks wxGUI

Please explain how it breaks the GUI. It tested with no issues at all on my system. If there is a bug we can work it out. Reverting without reporting the bug does not help.

Post by Martin Landa
File "/usr/local/src/grass6_devel/dist.i686-pc-linux-gnu/etc/wxpython/gui_modules/prompt.py",
line 920

.r40052

It looks like all that happened was that I missed a conflict marker at the end of the file. If you remove it and try again, it should work fine.

Post by Martin Landa
* re-implements GPrompt, please implement GPrompSTC without touching
GPrompt (or GPromptSTC and GPromptPopUp can be subclassed from
GPrompt)

See below

Post by Martin Landa
* accidentally reverts my previous changes (apparently you are working
with out-dated code). E.g. [1]

Not at all accidental. I needed to rewrite much of prompt.py to do this. Most of the code is no longer needed if we use STC, since most of it is a custom autocompletion code.

With all these changes updating caused a conflict which I had to resolve before committing.

Michael

[Martin Landa]

Hi,

Post by Michael Barton

Post by Martin Landa
* completely breaks wxGUI

Please explain how it breaks the GUI. It tested with no issues at all on my system. If there is a bug we can work it out. Reverting without reporting the bug does not help.

wxGUI didn't start, see error below. You committed file in a conflict.

Post by Michael Barton

Post by Martin Landa
 File "/usr/local/src/grass6_devel/dist.i686-pc-linux-gnu/etc/wxpython/gui_modules/prompt.py",
line 920

.r40052

It looks like all that happened was that I missed a conflict marker at the end of the file. If you remove it and try again, it should work fine.

Yes.

Post by Michael Barton

Post by Martin Landa
* re-implements GPrompt, please implement GPrompSTC without touching
GPrompt (or GPromptSTC and GPromptPopUp can be subclassed from
GPrompt)

See below

Post by Martin Landa
* accidentally reverts my previous changes (apparently you are working
with out-dated code). E.g. [1]

Not at all accidental. I needed to rewrite much of prompt.py to do this. Most of the code is no longer needed if we use STC, since most of it is a custom autocompletion code.

As I mentioned earlier logging classes should go to 'goutput.py'
module, prompt classes to 'prompt.py'. Please implement GPromptSTC
(keep GPrompt untouched) without fundamental rewriting goutput.py.

Martin

[Michael Barton]

What you are seeing is not the correct code. I'll fix this and try again.

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

Phone: [phone]
Fax: [phone]
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu

Post by Martin Landa
Hi,

Post by Michael Barton

Post by Martin Landa
* completely breaks wxGUI

Please explain how it breaks the GUI. It tested with no issues at all on my system. If there is a bug we can work it out. Reverting without reporting the bug does not help.

wxGUI didn't start, see error below. You committed file in a conflict.

Post by Michael Barton

Post by Martin Landa
File "/usr/local/src/grass6_devel/dist.i686-pc-linux-gnu/etc/wxpython/gui_modules/prompt.py",
line 920

.r40052

It looks like all that happened was that I missed a conflict marker at the end of the file. If you remove it and try again, it should work fine.

Yes.

Post by Michael Barton

Post by Martin Landa
* re-implements GPrompt, please implement GPrompSTC without touching
GPrompt (or GPromptSTC and GPromptPopUp can be subclassed from
GPrompt)

See below

Post by Martin Landa
* accidentally reverts my previous changes (apparently you are working
with out-dated code). E.g. [1]

Not at all accidental. I needed to rewrite much of prompt.py to do this. Most of the code is no longer needed if we use STC, since most of it is a custom autocompletion code.

As I mentioned earlier logging classes should go to 'goutput.py'
module, prompt classes to 'prompt.py'. Please implement GPromptSTC
(keep GPrompt untouched) without fundamental rewriting goutput.py.
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

[Martin Landa]

Post by Michael Barton
What you are seeing is not the correct code. I'll fix this and try again.

Sorry, what is not correct?

Martin

[Michael Barton]

I managed to fix my subversion setup and get the changes to prompt.py, goutput.py, and wxgui.py committed properly.

Please test. Should be no conflict issues this time.

Thanks
Michael

Post by Martin Landa

Post by Michael Barton
What you are seeing is not the correct code. I'll fix this and try again.

Sorry, what is not correct?
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

[Martin Landa]

Post by Michael Barton
I managed to fix my subversion setup and get the changes to prompt.py, goutput.py, and wxgui.py committed properly.
Please test. Should be no conflict issues this time.

Beside conflict you just ignored what I was suggesting.

Martin

[Michael Barton]

Output classes are in goutput.py
Input class is still in prompt.py

The other classes in prompt.py were for items superseded by the new autocompletion and calltips built into the one input class. That's why they are gone. Prompt is a clean STC input prompt.

Michael

Post by Martin Landa

Post by Michael Barton
I managed to fix my subversion setup and get the changes to prompt.py, goutput.py, and wxgui.py committed properly.
Please test. Should be no conflict issues this time.

Beside conflict you just ignored what I was suggesting.
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

[Martin Landa]

Post by Michael Barton
Output classes are in goutput.py

well and the output class GConsole includes input class GPrompt. It's
not a good idea. It need to be redone.

Martin

[Martin Landa]

Post by Martin Landa

Post by Michael Barton
Output classes are in goutput.py

well and the output class GConsole includes input class GPrompt. It's
not a good idea. It need to be redone.

Partly done in r40073. Just quick fix, need to rewritten.

Martin

[Michael Barton]

The output class does not contain the input class -- or at least it didn't, since I have no idea where it's at now.

I simply used the layout section of GConsole to fit this instance of GPrompt on the console page. GPrompt remains an independent class that can be used elsewhere if desired.


Michael

Post by Martin Landa

Post by Martin Landa

Post by Michael Barton
Output classes are in goutput.py

well and the output class GConsole includes input class GPrompt. It's
not a good idea. It need to be redone.

Partly done in r40073. Just quick fix, need to rewritten.
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

[Martin Landa]

Post by Michael Barton
The output class does not contain the input class -- or at least it didn't, since I have no idea where it's at now.

your commit

http://trac.osgeo.org/grass/changeset/40068#file0

and added self.cmd_prompt.

Martin

[Tim Michelsen]

Dear Michael,
once again I would like to state how much I appreciate the your works

Post by Michael Barton
The output class does not contain the input class -- or at least it
didn't, since I have no idea where it's at now.
I simply used the layout section of GConsole to fit this instance of
GPrompt on the console page. GPrompt remains an independent class
that can be used elsewhere if desired.

I installed the SVN revion 40083 today on my Ubuntu system as a package
created with checkinstall.

I personally could not see an improvement on earlier designs of the
command line (comparing with revision 39965).
The current console lacks command completion which was present in the
earlier design.

If it is there and I couldn't find it I would suggest that you produce a
short screencast and upload it to a video portal. Then, we could see
what your suggested use of the command line looks like.

Thanks again for all your efforts.

Regards
Timmie

[Tim Michelsen]

Dear Michael,
once again I would like to state how much I appreciate the your works

Post by Michael Barton
The output class does not contain the input class -- or at least it
didn't, since I have no idea where it's at now.
I simply used the layout section of GConsole to fit this instance of
GPrompt on the console page. GPrompt remains an independent class
that can be used elsewhere if desired.

I installed the SVN revion 40083 today on my Ubuntu system as a package
created with checkinstall.

I personally could not see an improvement on earlier designs of the
command line (comparing with revision 39965).
The current console lacks command completion which was present in the
earlier design.

If it is there and I couldn't find it I would suggest that you produce a
short screencast and upload it to a video portal. Then, we could see
what your suggested use of the command line looks like.

Thanks again for all your efforts.

Regards
Timmie

[Michael Barton]

Leave it all reverted for now.

My svn broke on upgrading to OS X 10.6

I need to get that fixed so that I can commit correctly.

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

Phone: [phone]
Fax: [phone]
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu

Post by Martin Landa
Hi,

Post by Michael Barton

Post by Martin Landa
* completely breaks wxGUI

Please explain how it breaks the GUI. It tested with no issues at all on my system. If there is a bug we can work it out. Reverting without reporting the bug does not help.

wxGUI didn't start, see error below. You committed file in a conflict.

Post by Michael Barton

Post by Martin Landa
File "/usr/local/src/grass6_devel/dist.i686-pc-linux-gnu/etc/wxpython/gui_modules/prompt.py",
line 920

.r40052

It looks like all that happened was that I missed a conflict marker at the end of the file. If you remove it and try again, it should work fine.

Yes.

Post by Michael Barton

Post by Martin Landa
* re-implements GPrompt, please implement GPrompSTC without touching
GPrompt (or GPromptSTC and GPromptPopUp can be subclassed from
GPrompt)

See below

Post by Martin Landa
* accidentally reverts my previous changes (apparently you are working
with out-dated code). E.g. [1]

Not at all accidental. I needed to rewrite much of prompt.py to do this. Most of the code is no longer needed if we use STC, since most of it is a custom autocompletion code.

As I mentioned earlier logging classes should go to 'goutput.py'
module, prompt classes to 'prompt.py'. Please implement GPromptSTC
(keep GPrompt untouched) without fundamental rewriting goutput.py.
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

[Hamish]

Post by Dylan Beaudette
All commands seem to have a delay-- even executing g.region
causes the CPU to jump to 100% for about 15 seconds.

time enough to run `top` and see what's the hog..


H

[Michael Barton]

If d.erase were implemented in the GUI console, how should it work?

1) remove all maps and other displays from the layer tree
2) turn off all maps and other displays from the layer tree

#1 is what it did in an xmon, but that may not be the desired behavior in the current environment.

Michael

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

Phone: [phone]
Fax: [phone]
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu

Post by Hamish

Post by Dylan Beaudette
All commands seem to have a delay-- even executing g.region
causes the CPU to jump to 100% for about 15 seconds.

time enough to run `top` and see what's the hog..
H

[Glynn Clements]

Post by Michael Barton
If d.erase were implemented in the GUI console, how should it work?
1) remove all maps and other displays from the layer tree
2) turn off all maps and other displays from the layer tree
#1 is what it did in an xmon, but that may not be the desired behavior in the current environment.

d.erase still exists, and works with direct rendering. The result a
blank image.

This may not be a great deal of use within the GUI, but it does work.
It is useful in other contexts (e.g. creating the initial image if you
intend to use GRASS_PNG_READ=TRUE for subsequent commands).

[Martin Landa]

Hi,

Post by Michael Barton
--Type a grass command. When you get to the ".", it brings up an
autocomplete list of relevant commands. Keep typing (or mouse up/down) until
you find the one you want and hit return.
--Press <tab> to see full calltips of command syntax for each command
entered (one command per line please)
--As you type the command arguments, hitting "=" and "," following an
"=[string]" combination will bring up context-sensitive lists of relevant
maps or other data sets (e.g. regions where appropriate).
--You can type ctrl-space to bring up a context sensitive list of maps for
raster, vector, etc. at any place in the command.
--Pressing return on the command line will run it.
This will accept shell commands (redirects and pipes don't work but could),
grass commands without arguments (brings up the GUI dialogs), and grass
commands with the short form arguments (r.info mymap) as well as full grass
commands with argument=value format.

Most of the things are already implemented in GPrompt! Better would be
to make working GPrompt class on Mac.

Martin

[Michael Barton]

Post by Martin Landa
Hi,

Post by Michael Barton
--Type a grass command. When you get to the ".", it brings up an
autocomplete list of relevant commands. Keep typing (or mouse up/down) until
you find the one you want and hit return.
--Press <tab> to see full calltips of command syntax for each command
entered (one command per line please)
--As you type the command arguments, hitting "=" and "," following an
"=[string]" combination will bring up context-sensitive lists of relevant
maps or other data sets (e.g. regions where appropriate).
--You can type ctrl-space to bring up a context sensitive list of maps for
raster, vector, etc. at any place in the command.
--Pressing return on the command line will run it.
This will accept shell commands (redirects and pipes don't work but could),
grass commands without arguments (brings up the GUI dialogs), and grass
commands with the short form arguments (r.info mymap) as well as full grass
commands with argument=value format.

Most of the things are already implemented in GPrompt! Better would be
to make working GPrompt class on Mac.
Martin

Hi Martin,

GPrompt won't work on the Mac because it uses a the PopupWindow control that does not exist for Mac. To make it work, it would be necessary to custom code an equivalent popup window.

If we use the separate command entry window interface, I think the better way to go is to change it to a StyledTextCtrl. This was a very good idea of yours to make the output window a StyledTextCtrl.

If the input window is changed to a STC, then we can make use of its built-in autocomplete and calltip functions. I realize that you did a lot of coding to create a custom autocomplete in GPrompt, but I think we are ultimately better off to use wxPython built-in functions as much as possible when they are available. They are often more robust over time and easier for another person to understand--and others than you and I may well need to debug and maintain this in the future. I've seen a lot of old custom widget code for the TclTk GUI and it is very difficult to deal with. If we create a custom popup that works on Mac, we add even more custom code for an autocomplete feature.

In this case, the STC autocomplete and calltip functions work very well and we only need to create the relevant lists of informatoin (commands, maps, etc) that go into them and the specify the keystrokes that call them. I've done that and we can make use of and enhance that code (e.g., change the keystrokes if desired). We don't need to code list controls, the ability to type and search, popup windows, getting the list into the popup, and the proper placement of the windows.

I personally don't mind separate input and output windows. Many people who use terminals are accustomed to having input and output in the same window, and using the STC, it is minimal effort to have this kind of interface. But maybe command line users like the idea of separate input and output windows. We probably can also visually merge the 2 windows so that the input acts more like a command line prompt that never scrolls up. I guess I'd recommend whichever way terminal users are most comfortable with in this regard.

Michael

[Martin Landa]

Hi,

Post by Michael Barton
GPrompt won't work on the Mac because it uses a the PopupWindow control that does not exist for Mac. To make it work, it would be necessary to custom code an equivalent popup window.

right, this what I was suggesting from the beginning. Feel free to
implement GPromptSTC. My personal meaning is that most of GUIs use
different widgets for input area (when you type commands) and log
area.

Martin

[Glynn Clements]

Post by Michael Barton
I personally don't mind separate input and output windows. Many people
who use terminals are accustomed to having input and output in the same
window, and using the STC, it is minimal effort to have this kind of
interface. But maybe command line users like the idea of separate input
and output windows. We probably can also visually merge the 2 windows
so that the input acts more like a command line prompt that never
scrolls up. I guess I'd recommend whichever way terminal users are most
comfortable with in this regard.

I think that separate windows make more sense, but it's worth allowing
the input window to be a multi-line field with line-wrap and vertical
scrolling, rather than a single-line field with horizontal scrolling.
The latter can be annoying when entering long commands.

[Martin Landa]

Hi,

Post by Glynn Clements

Post by Michael Barton
I personally don't mind separate input and output windows. Many people
who use terminals are accustomed to having input and output in the same
window, and using the STC, it is minimal effort to have this kind of
interface. But maybe command line users like the idea of separate input
and output windows.  We probably can also visually merge the 2 windows
so that the input acts more like a command line prompt that never
scrolls up. I guess I'd recommend whichever way terminal users are most
comfortable with in this regard.

I think that separate windows make more sense, but it's worth allowing
the input window to be a multi-line field with line-wrap and vertical
scrolling, rather than a single-line field with horizontal scrolling.
The latter can be annoying when entering long commands.

I agree, GPrompt should be improved in this way...

Martin

[Martin Landa]

Post by Glynn Clements
I think that separate windows make more sense, but it's worth allowing
the input window to be a multi-line field with line-wrap and vertical

sorry do you mean separate windows or widgets (in the sense of SDI)?

Martin

[Glynn Clements]

Post by Martin Landa

Post by Glynn Clements
I think that separate windows make more sense, but it's worth allowing
the input window to be a multi-line field with line-wrap and vertical

sorry do you mean separate windows or widgets (in the sense of SDI)?

Widgets. I.e. typing into a different area of the GUI to where the
output appears. There isn't much reason for them to use the same
widget. Terminal emulators have to emulate terminals (which are used
for e.g. curses applications as well as shells), but there's no reason
for a dedicated GUI command-line to behave that way.

[Martin Landa]

Hi,

Post by Glynn Clements

Post by Martin Landa

Post by Glynn Clements
I think that separate windows make more sense, but it's worth allowing
the input window to be a multi-line field with line-wrap and vertical

sorry do you mean separate windows or widgets (in the sense of SDI)?

Widgets. I.e. typing into a different area of the GUI to where the
output appears. There isn't much reason for them to use the same
widget. Terminal emulators have to emulate terminals (which are used
for e.g. curses applications as well as shells), but there's no reason
for a dedicated GUI command-line to behave that way.

I agree.

Martin

[Martin Landa]

Hi,

2009/12/16 Martin Landa <***@gmail.com>:

[...]

Post by Martin Landa
I agree, GPrompt should be improved in this way...

some screenshots how GPrompt works

Loading Image...

right arrow to get list of parameters

Loading Image...

choose parameters, press Enter

Loading Image...

choose raster map, Enter

and so on.

Sure, GPrompt is buggy and untested. Anyway I still thinks that
GOutput should completely separated from GPrompt*.

Martin

[Tim Michelsen]

Post by Glynn Clements

Post by Michael Barton
I personally don't mind separate input and output windows.

-1
I would like to see:
1 Tab for the layer manager, 2dn tab for the command window.

Maybe there could be the option to optionally redirect the output into a
text file in
/tmp/grass.log?

Post by Glynn Clements
I think that separate windows make more sense, but it's worth allowing
the input window to be a multi-line field with line-wrap and vertical
scrolling, rather than a single-line field with horizontal scrolling.
The latter can be annoying when entering long commands.

+1

[Martin Landa]

Hi,

Post by Tim Michelsen

Post by Glynn Clements

Post by Michael Barton
I personally don't mind separate input and output windows.

-1
1 Tab for the layer manager, 2dn tab for the command window.
Maybe there could be the option to optionally redirect the output into a
text file in
/tmp/grass.log?

Post by Glynn Clements
I think that separate windows make more sense, but it's worth allowing
the input window to be a multi-line field with line-wrap and vertical
scrolling, rather than a single-line field with horizontal scrolling.
The latter can be annoying when entering long commands.

+1

wxGUI should support also MDI [1]. More then two windows in SDI could
be too many...

+1 add support for MDI
+1 keep two windows (Map Display and Layer Manager) in SDI (sure you
can open more Map Displays)
+1 keep separated command prompt and log area as different widgets

Martin

[1] http://grass.osgeo.org/wiki/WxGUI#General_GUI_Design

[Dylan Beaudette]

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: [phone]
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

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: [phone]
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

Post by Dylan Beaudette

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

Hi,
No obvious issues, however the GUI does take about 20 seconds to load.
OS is Debian/Unstable.
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

Post by Michael Barton
Phone: [phone]
Fax: [phone]
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu

Post by Dylan Beaudette

Post by Michael Barton
Hi Dylan,
Thanks very much for trying this out. A few responses below.

Post by Dylan Beaudette
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!

Post by Michael Barton

Post by Dylan Beaudette
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.

Post by Michael Barton
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...

Post by Michael Barton

Post by Dylan Beaudette
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.

Post by Dylan Beaudette
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

Post by Michael Barton
Michael

[Michael Barton]

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: [phone]
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

Post by Dylan Beaudette

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: [phone]
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

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: [phone]
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

Post by Dylan Beaudette

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

Hi,
No obvious issues, however the GUI does take about 20 seconds to load.
OS is Debian/Unstable.
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

Post by Michael Barton
Phone: [phone]
Fax: [phone]
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu

Post by Dylan Beaudette

Post by Michael Barton
Hi Dylan,
Thanks very much for trying this out. A few responses below.

Post by Dylan Beaudette
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!

Post by Michael Barton

Post by Dylan Beaudette
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.

Post by Michael Barton
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...

Post by Michael Barton

Post by Dylan Beaudette
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.

Post by Dylan Beaudette
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

Post by Michael Barton
Michael

[Tim Michelsen]

Hello Michael,
I really like your developments. Taking all users, beginers and power
users to GRASS level 7!

For test I would suggest that you may upload your changes to a DVCS site
such as Launchpad, Bitbucket, Sourceforge or Github.

We could safely try out your improvements without breaking our
production installation.

What you say?

With the bazaar plugin bzr-svn you can import from the main SVN and
apply your changes and then push all to Launchpad.

Regards,
Timmie

[Hamish]

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.

could be. I'm not sure what else could python be up to?

just to note: the first time you start it everything (including python and
libraries) have to be read from the disk which takes a little while. The
second time it is likely to still be cached in memory so cpu or ram bound,
not disk i/o bound.


also, for installed versions it's important that the .pyc byte compiled
binaries are created at build time, as once installed the user starting
grass probably won't have write permission to $GISBASE.

I just rebuilt to confirm if that's happening -- yep, they get built.

[If they weren't you'd have to start grass once as root to get the .pyc
files actually written to disk, but a "make check" no-op could be run as
part of the build process to create them before 'make install' or the
package installation. AFAIK they are portable (within reason).]

I've got no idea how to test if the installed versions are up-to-date
& so not rebuilt even though on disk. maybe run as root and see if the
timestamp on the installed ones update?? anyway if you have modified
wxgui.py and don't have write permission to $GISBASE then you may have
to wait for it each time.


Hamish