date:20140210

On Thu, Feb 6, 2014 at 5:57 PM, Markus Neteler nete...@osgeo.org wrote:
 On Thu, Feb 6, 2014 at 1:14 PM, Blumentrath, Stefan
 stefan.blumentr...@nina.no wrote:
 Dear all,

 I am testing, trying, learning GRASS 7`s hydrology moduls at the moment. And
 I am very, very satisfied with the available tools. r.watershed managed to
 process a really big elevation model (150,000 x 120,000 pixels), which is
 amazing.

 Wow! Please consider to add a note to
 http://grasswiki.osgeo.org/wiki/GRASS_GIS_Performance#Large_raster_data_processing

 (or in a blog entry or the like)

 However, when I use r.hydrodem addon on the same big grid with 150,000 x
 120,000 pixels (with the memory option) I get the following warning (and
 finally error) message:

 r.hydrodem input=dem_10m memory=1 output=dem_10m _hydro
 ...
 WARNING: segment_format(fd,1,-221837149,1,262144,16): illegal value(s)

 This is an integer overflow of ncols etc:

 [neteler@pgis_north r.hydrodem]$ grep nrows seg.c
 seg_open(SSEG *sseg, int nrows, int ncols, int row_in_seg, int col_in_seg,

 In r.watershed it is defined differently:

 [neteler@pgis_north r.watershed]$ grep nrows seg/sseg_open.c
 seg_open(SSEG * sseg, GW_LARGE_INT nrows, GW_LARGE_INT ncols, int
 row_in_seg, int col_in_seg,
 if (0  (errflag = segment_format(fd, nrows, ncols,

 I suppose that this is an easy fix given the experience of r.watershed.
 To not interfere, I'll leave the change to the module author.

The fix would be relatively easy, I will do it as soon as time permits...

Note that r.hydrodem and r.watershed use the same mechanism, therefore
r.hydrodem can not improve a DEM for r.watershed. The r.hydrodem
module is meant to perform hydrological conditioning (sink removal) of
a DEM when the DEM is used with other modules or other software.
However, to my knowledge no other software exists that is able to
perform surface flow accumulation on such a large raster. Two examples
for sophisticated hydrological modelling packages are TauDEM and
WhiteBox (formerly TAS). The last time I checked, both were not able
to process DEMs with more than 2 billion grid cells. Even r.terraflow,
designed for massive grids, can not process a 150,000 x 120,000 DEM.

Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2192: v.centerpoint: line centers get all cat values from 1 to respective line

2014-02-10 Thread GRASS GIS

#2192: v.centerpoint: line centers get all cat values from 1 to respective line
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.4
Component:  Default  | Version:  unspecified  
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by mmetz):

 Replying to [ticket:2192 mlennert]:
  Using v.centerpoint on lines with the output= parameter, resulting lines
 have many cat values, corresponding to all the cat values from 1 to the
 one of the respective line.

 Fixed in r58975.

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/2192#comment:1
GRASS GIS http://grass.osgeo.org

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

Glynn Clements wrote:

 Markus Metz wrote:

  Other projects such as gimp or libreoffice are AFAICT reasonably
  bundled with Python, without a Python installer.
 
  They aren't attempting to support Python scripts as stand-alone
  programs (i.e. something which can be run from the command prompt,
  batch files, etc).

 GRASS scripts, just like GRASS C modules, only run as stand-alone
 programs if the GRASS environment is set properly and if a valid GRASS
 session has been established.

 This is a matter of creating a file and setting some environment
 variables.

 It's also not that specific to GRASS. As the Windows filesystem layout
 groups files by origin (i.e. .../Program Files/vendor/package)
 rather than by function (.../bin, .../lib, etc), it's fairly typical
 to have to at least modify PATH for anything which is meant to be used
 from the command line.

This is the fundamental difference and the reason why using a
system-wide Python can only cause trouble on Windows. On Windows, a
software package typically includes everything it needs to run,
embedding any script interpreters, while Linux, Unix, BSD systems use
package managers. The fact that ArcGIS installs a system-wide Python
is maybe a curiosity coming from the origins of ArcInfo as a Unix
application.


 But you can't configure interpreters on a per-process basis on Windows.
 You can only do it on Unix because we use the #!/usr/bin/env python
 hack (which was originally invented to deal with Python being either
 in /usr/bin or /usr/local/bin).

 Thus, GRASS modules do not run from any
 command prompt, neither from the native Windows command prompt nor
 from a *NIX shell, without setting the GRASS environment first. Real
 stand-alone programs are for example the GDAL utilities, but not GRASS
 modules.

 It's fairly trivial to set a valid GRASS environment globally, so that
 commands are usable in any shell. That's how I've had it on Linux
 since roughly forever; I don't run the grass70 script unless I'm
 testing it.

At the very least, GRASS needs to clean up temporary files on exit.

 FWIW, I want to make that the default mode of operation.

 I.e. on Unix, set the environment variables in /etc/profile.d/grass7
 or whatever a given distribution uses, so that you only need to
 explicitly start GRASS sessions if you want multiple, independent
 sessions.

I have multiple, independent sessions running pretty much every day.

  A compiled program which embeds Python (links against the Python
  DSO/DLL) to use Python for internal scripting is a much simpler
  case. And much less useful.

 Why much less useful? As far as GRASS modules are concerned, users
 should not be bothered and should not care if a GRASS module is a C
 module or a shell script or a python script. First of all, a GRASS
 module must behave like a GRASS module, independent of the language in
 which it is written.

 This is my entire point. But that cannot be achieved if you're relying
 upon hard-coded special treatment for Python scripts. If Python
 scripts cannot simply be executed (via system() or subprocess.Popen()
 or whatever) in the same manner as executables or other scripts, the
 user will have to be bothered with whether something is an executable
 or a Python script.

We use hard-coded special treatment for shell scripts and still they
behave like a GRASS module. I don't see how users are bothered whether
a module is an executable or a shell script. Internally, GRASS can
always use system() or subprocess.Popen() for executables and .bat
files, but not for shell or Python scripts, Therefore we need
hard-coded special treatment for shell and Python scripts in order to
make sure that the correct interpreter is used.

IMHO, the argument to have GRASS as a GIS processing engine in the
background (e.g. for Sextante) that includes everything it needs and
does not interfere with other software packages is a pretty strong
argument.

 Attempting to side-step the system's execution mechanism will *always*
 be an incomplete solution.

I disagree because there is no default system execution mechanism for
Python scripts: Python is not part of the Windows OS.
The recommended Python version as of today would be Python 3.3 64 bit.

Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-02-10 Thread Moritz Lennert


On 10/02/14 09:57, Markus Metz wrote:

Glynn Clements wrote:

This is my entire point. But that cannot be achieved if you're relying
upon hard-coded special treatment for Python scripts. If Python
scripts cannot simply be executed (via system() or subprocess.Popen()
or whatever) in the same manner as executables or other scripts, the
user will have to be bothered with whether something is an executable
or a Python script.


We use hard-coded special treatment for shell scripts and still they
behave like a GRASS module. I don't see how users are bothered whether
a module is an executable or a shell script. Internally, GRASS can
always use system() or subprocess.Popen() for executables and .bat
files, but not for shell or Python scripts, Therefore we need
hard-coded special treatment for shell and Python scripts in order to
make sure that the correct interpreter is used.


Just for my understanding: When you say hard-coded special treatment for 
shell scripts, are you speaking about the .bat files ?


Moritz

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-02-10 Thread Helmut Kudrnovsky

Therefore we need
 hard-coded special treatment for shell and Python scripts in order to
 make sure that the correct interpreter is used.

Just for my understanding: When you say hard-coded special treatment for
shell scripts, are you speaking about the .bat files ? 

I think yes.



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Handling-of-Python-scripts-on-MS-Windows-tp5081335p5102860.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Change/update Python requirements for grass70?

2014-02-10 Thread Pietro

Dear developers,

Reading the GRASS7 requirements:

http://grass.osgeo.org/grass70/source/snapshot/REQUIREMENTS.html

In theory, we are still supporting python 2.4.

What do you think if we abandon the support for:
- python 2.4 (last release: December 19, 2008),
- python 2.5  (last release: May 26, 2011),

and may be:

- python 2.6 (last release: October 29, 2013), About this version the
python website [0] says: With the 2.6.9 release, and five years after
its first release, the Python 2.6 series is now officially retired.
All official maintenance for Python 2.6, including security patches,
has ended.. Perhaps we should/could drop the support for this release
too.

I would like to start to support python3, and if we have to support
also the release 2.4 and 2.5 it is more difficult.

So are you agree to change the requirements for grass70 from Python =
2.4 to Python = 2.7 or Python = 2.6?

Best regards.

Pietro

[0] http://www.python.org/getit/releases/2.6.9/
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2192: v.centerpoint: line centers get all cat values from 1 to respective line

2014-02-10 Thread GRASS GIS

#2192: v.centerpoint: line centers get all cat values from 1 to respective line
--+-
  Reporter:  mlennert |   Owner:  grass-dev@…  
  Type:  defect   |  Status:  closed   
  Priority:  normal   |   Milestone:  7.0.0
 Component:  Default  | Version:  unspecified  
Resolution:  fixed|Keywords:   
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Changes (by mlennert):

  * milestone:  6.4.4 = 7.0.0


-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/2192#comment:3
GRASS GIS http://grass.osgeo.org

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Change/update Python requirements for grass70?

2014-02-10 Thread Martin Landa

Hi,

2014-02-10 11:39 GMT+01:00 Pietro peter.z...@gmail.com:
 So are you agree to change the requirements for grass70 from Python =
 2.4 to Python = 2.7 or Python = 2.6?

personally I would keep support for Python 2.6 at this point if possible. Martin

-- 
Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/gwiki/Landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2192: v.centerpoint: line centers get all cat values from 1 to respective line

2014-02-10 Thread GRASS GIS

#2192: v.centerpoint: line centers get all cat values from 1 to respective line
--+-
  Reporter:  mlennert |   Owner:  grass-dev@…  
  Type:  defect   |  Status:  closed   
  Priority:  normal   |   Milestone:  6.4.4
 Component:  Default  | Version:  unspecified  
Resolution:  fixed|Keywords:   
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Changes (by mlennert):

  * status:  new = closed
  * resolution:  = fixed


Comment:

 Replying to [comment:1 mmetz]:
  Replying to [ticket:2192 mlennert]:
   Using v.centerpoint on lines with the output= parameter, resulting
 lines have many cat values, corresponding to all the cat values from 1 to
 the one of the respective line.
 
  Fixed in r58975.

 Works perfectly, now. Thanks !

 Moritz

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/2192#comment:2
GRASS GIS http://grass.osgeo.org

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

On Mon, Feb 10, 2014 at 11:26 AM, Helmut Kudrnovsky hel...@web.de wrote:
Therefore we need
 hard-coded special treatment for shell and Python scripts in order to
 make sure that the correct interpreter is used.

Just for my understanding: When you say hard-coded special treatment for
shell scripts, are you speaking about the .bat files ?

 I think yes.

Or more generally, any mechanism explicitly using %GRASS_PYTHON% script.py.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Change/update Python requirements for grass70?

2014-02-10 Thread Pietro

On Mon, Feb 10, 2014 at 10:43 AM, Martin Landa landa.mar...@gmail.com wrote:
 2014-02-10 11:39 GMT+01:00 Pietro peter.z...@gmail.com:
 So are you agree to change the requirements for grass70 from Python =
 2.4 to Python = 2.7 or Python = 2.6?

 personally I would keep support for Python 2.6 at this point if possible. 
 Martin

Yes, I think we should be able to keep Python = 2.6.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-02-10 Thread Moritz Lennert


On 10/02/14 11:46, Markus Metz wrote:

On Mon, Feb 10, 2014 at 11:26 AM, Helmut Kudrnovsky hel...@web.de wrote:

Therefore we need
hard-coded special treatment for shell and Python scripts in order to
make sure that the correct interpreter is used.



Just for my understanding: When you say hard-coded special treatment for
shell scripts, are you speaking about the .bat files ?


I think yes.


Or more generally, any mechanism explicitly using %GRASS_PYTHON% script.py.


But as far as I've seen, this might not be sufficient since this only 
indicates which Python executable to use for launching the Python 
script, but any library calls linked to that execution will involve the 
system-wide installed Python. Which is different from bash scripts, 
where this is not an issue.


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Change/update Python requirements for grass70?

2014-02-10 Thread Volker Fröhlich

On 02/10/2014 11:52 AM, Pietro wrote:
 On Mon, Feb 10, 2014 at 10:43 AM, Martin Landa landa.mar...@gmail.com wrote:
 2014-02-10 11:39 GMT+01:00 Pietro peter.z...@gmail.com:
 So are you agree to change the requirements for grass70 from Python =
 2.4 to Python = 2.7 or Python = 2.6?

 personally I would keep support for Python 2.6 at this point if possible. 
 Martin
 
 Yes, I think we should be able to keep Python = 2.6.

2.6 is good because it allows for EL6 builds too!

Volker
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

On Mon, Feb 10, 2014 at 12:04 PM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
 On 10/02/14 11:46, Markus Metz wrote:

 On Mon, Feb 10, 2014 at 11:26 AM, Helmut Kudrnovsky hel...@web.de wrote:

 Therefore we need
 hard-coded special treatment for shell and Python scripts in order to
 make sure that the correct interpreter is used.


 Just for my understanding: When you say hard-coded special treatment for
 shell scripts, are you speaking about the .bat files ?


 I think yes.


 Or more generally, any mechanism explicitly using %GRASS_PYTHON%
 script.py.


 But as far as I've seen, this might not be sufficient since this only
 indicates which Python executable to use for launching the Python script,
 but any library calls linked to that execution will involve the system-wide
 installed Python. Which is different from bash scripts, where this is not an
 issue.

GRASS Python scripts are currently executed using the system-wide
installed Python if it exists. No attempt has been made to explicitly
use GRASS_PYTHON, therefore it is not possible to say if the system's
Python would really be completely ignored.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] wxGUI: Search modules tab is lacking import/export

Hi,

(surprisingly) the Search modules tab does not have any content from
the File menu, i.e it is lacking import/export etc.
Is there a reason for that? It is a bit misleading...

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

On Mon, Feb 10, 2014 at 8:41 AM, Markus Metz
markus.metz.gisw...@gmail.comwrote:

 On Mon, Feb 10, 2014 at 12:04 PM, Moritz Lennert
 mlenn...@club.worldonline.be wrote:
  On 10/02/14 11:46, Markus Metz wrote:
 
  On Mon, Feb 10, 2014 at 11:26 AM, Helmut Kudrnovsky hel...@web.de
 wrote:
 
  Therefore we need
  hard-coded special treatment for shell and Python scripts in order to
  make sure that the correct interpreter is used.
 
 
  Just for my understanding: When you say hard-coded special treatment
 for
  shell scripts, are you speaking about the .bat files ?
 
 
  I think yes.
 
 
  Or more generally, any mechanism explicitly using %GRASS_PYTHON%
  script.py.
 
 
  But as far as I've seen, this might not be sufficient since this only
  indicates which Python executable to use for launching the Python script,
  but any library calls linked to that execution will involve the
 system-wide
  installed Python. Which is different from bash scripts, where this is
 not an
  issue.

 GRASS Python scripts are currently executed using the system-wide
 installed Python if it exists. No attempt has been made to explicitly
 use GRASS_PYTHON, therefore it is not possible to say if the system's
 Python would really be completely ignored.


If I remember correctly, Python scripts were not working from Python
scripts, they were working from command line. And we were not able to
explain why the right Python (or Python DLL) is used at one point but not
the other. If there wouldn't be shell=True [1], I would say that we need to
add it.

[1]
http://trac.osgeo.org/grass/browser/grass/trunk/lib/python/script/core.py?rev=58952#L52



 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-02-10 Thread Helmut Kudrnovsky

GRASS Python scripts are currently executed using the system-wide
installed Python if it exists. No attempt has been made to explicitly
use GRASS_PYTHON, therefore it is not possible to say if the system's
Python would really be completely ignored. 

it is (partly) implemented ( and tested on Win7 with a system-wide
ArcGIS-python) at least for python-addons for winGRASS6.4.svn/6.5.svn:

see

http://trac.osgeo.org/grass/ticket/2138#comment:8

and some local tests here shows (see
http://trac.osgeo.org/grass/ticket/2138):

the python script (which invokes two other python scripts) finishes now.

how to test if the system's Python would really be completely ignored?



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Handling-of-Python-scripts-on-MS-Windows-tp5081335p5103005.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] wxGUI: Search modules tab is lacking import/export

On Mon, Feb 10, 2014 at 12:33 PM, Markus Neteler nete...@osgeo.org wrote:

 Hi,

 (surprisingly) the Search modules tab does not have any content from
 the File menu, i.e it is lacking import/export etc.
 Is there a reason for that? It is a bit misleading...

 Hi, this is known issue [1]. The thing which is need to decide is what
will be the layout of this part of the tree. Certainly we don't want the
whole File menu in the tree. We want just the import/export separately.
Post your ideas here. Adding the actual items to the tree should be easy.

Vaclav

[1]
http://trac.osgeo.org/grass/wiki/wxGUIDevelopment/Toolboxes#Whichtoolboxescouldbecreated

Markus
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-02-10 Thread Helmut Kudrnovsky

wenzeslaus wrote
 If I remember correctly, Python scripts were not working from Python
 scripts, they were working from command line. And we were not able to
 explain why the right Python (or Python DLL) is used at one point but not
 the other. If there wouldn't be shell=True [1], I would say that we need
 to
 add it.
 
 [1]
 http://trac.osgeo.org/grass/browser/grass/trunk/lib/python/script/core.py?rev=58952#L52

please see
http://lists.osgeo.org/pipermail/grass-dev/2014-February/067307.html and 
http://trac.osgeo.org/grass/ticket/2138

Python scripts _are_ working from Python scripts, if e.g. in a related
bat-file GRASS_PYTHON is defined.



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Handling-of-Python-scripts-on-MS-Windows-tp5081335p5103009.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] wxGUI: add color selector drop-down list to Settings?

Hi,

in wxGUI - Settings - Preferences - Layer tab
there is the Default color table text color list, could this be
switched to the nice graphical one as used/generated here:

case G_OPT_M_COLR:
Opt-key = color;
Opt-key_desc = style;
Opt-type = TYPE_STRING;
Opt-required = NO;
Opt-options = G_color_rules_options();
Opt-description = _(Name of color table);
Opt-descriptions = G_color_rules_descriptions();
Opt-gisprompt = old,colortable,colortable;
break;

(used in r.colors/v.colors)

thanks
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] problem bundling GRASS 6.5 and 6.4 RB

Something else has come up.

I compiled GRASS 7 on one computer Friday. It DID bundle OK (but maybe better
now?). But when I went to run it on a different computer with the same OS,
Python, and wxPython, I hit the following error at startup.

Either of you know what this may be? I don't know if it is a bundling issue or
something else.

GRASS 7.0.svn (nc_spm_08):~ Traceback (most recent call last):
File
/Users/cmbarton/Dropbox/GRASS_dropbox/source/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py,
line 39, in module
from lmgr.frame import GMFrame
File
/Users/cmbarton/Dropbox/GRASS_dropbox/source/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/lmgr/frame.py,
line 68, in module
from modules.extensionsimport InstallExtensionWindow,
UninstallExtensionWindow
ImportError: cannot import name UninstallExtensionWindow
GRASS 7.0.svn (nc_spm_08):~

Michael

C. Michael Barton
Director, Center for Social Dynamics Complexity
Professor of Anthropology, School of Human Evolution Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Feb 7, 2014, at 5:39 PM, William Kyngesburye wokl...@kyngchaos.com wrote:

Woops. I deleted too much when I killed the modbuild stuff a few weeks ago.
Should be working now.

On Feb 7, 2014, at 6:19 PM, Michael Barton wrote:

William,

I just recompiled GRASS 7 and bundled it for distribution. It went fine.

But when I went to do the same for GRASS 6.5 and 6.4 RB I ran into an odd
error.

Compilation went fine. No errors in either. But bundling bombed with the
following error:

…
cp -Rf /Library/Python/2.7/site-packages/pyparsing.py
/Users/cmbarton/Dropbox/GRASS_dropbox/source/grass64_rb/macosx/dist/GRASS-6.4.app/Contents/MacOS/etc/python
sed -i '' -e 's/^GRASS_WXBUNDLED=.*/GRASS_WXBUNDLED=1/'
/Users/cmbarton/Dropbox/GRASS_dropbox/source/grass64_rb/macosx/dist/GRASS-6.4.app/Contents/MacOS/grass.sh
sed:
/Users/cmbarton/Dropbox/GRASS_dropbox/source/grass64_rb/macosx/dist/GRASS-6.4.app/Contents/MacOS/grass.sh:
No such file or directory

Is there no longer a grass.sh for GRASS 6.x? If not, what do we use to start
it?

The same line does not cause an error for GRASS 7.

Michael
__
C. Michael Barton
Director, Center for Social Dynamics Complexity
Professor of Anthropology, School of Human Evolution Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
Tempe, AZ 85287-2402
USA

voice:
480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www:
http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] wxGUI command line: changed into @ while typing

On Mon, Feb 10, 2014 at 7:53 PM, Vaclav Petras wenzesl...@gmail.com wrote:



 On Mon, Feb 10, 2014 at 1:19 PM, Markus Neteler nete...@osgeo.org wrote:

 Hi,

 I noticed on Linux that while type

 v.extract input=lakes out=anything where=@

 and a map name list pops up...

 Is this happening to anyone else?

 If I understand correctly, you type  character but it is changed to @
 character. This does not happen to me with EN and CS keyboard layouts.

The  character is changed to @ for me too on a DE keyboard layout.


 GRASS version: 7.0.svn
 GRASS SVN Revision: 58850M
 Build Date: 2014-01-03
 GDAL/OGR: 1.10.0
 PROJ.4: 4.8.0
 GEOS: 3.3.8
 SQLite: 3.7.9
 Python: 2.7.3
 wxPython: 2.8.12.1
 Platform: Linux-3.2.0-58-generic-pae-i686-with-Ubuntu-12.04-precise


 I use
 GRASS version: 7.0.svn
 GRASS SVN Revision: 58873M
 Build Date: 2014-01-04
 GDAL/OGR: 1.10.1
 PROJ.4: 4.8.0
 GEOS:
 SQLite: 3.8.2
 Python: 2.7.5
 wxPython: 2.8.12.0
 Platform: Linux-3.12.9-301.fc20.x86_64-x86_64-with-fedora-20-Heisenbug

 (Un)related: on Windows this seems to work but retrieving the command
 from the wxGUI history by scrolling eats the quotes.

 thanks
 Markus
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev



 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

On Mon, Feb 10, 2014 at 2:17 PM, Markus Metz
markus.metz.gisw...@gmail.comwrote:

 On Mon, Feb 10, 2014 at 6:44 PM, Vaclav Petras wenzesl...@gmail.com
 wrote:
 
 
 
  On Mon, Feb 10, 2014 at 8:41 AM, Markus Metz 
 markus.metz.gisw...@gmail.com
  wrote:
 
  On Mon, Feb 10, 2014 at 12:04 PM, Moritz Lennert
  mlenn...@club.worldonline.be wrote:
   On 10/02/14 11:46, Markus Metz wrote:
  
   On Mon, Feb 10, 2014 at 11:26 AM, Helmut Kudrnovsky hel...@web.de
   wrote:
  
   Therefore we need
   hard-coded special treatment for shell and Python scripts in order
   to
   make sure that the correct interpreter is used.
  
  
   Just for my understanding: When you say hard-coded special
 treatment
   for
   shell scripts, are you speaking about the .bat files ?
  
  
   I think yes.
  
  
   Or more generally, any mechanism explicitly using %GRASS_PYTHON%
   script.py.
  
  
   But as far as I've seen, this might not be sufficient since this only
   indicates which Python executable to use for launching the Python
   script,
   but any library calls linked to that execution will involve the
   system-wide
   installed Python. Which is different from bash scripts, where this is
   not an
   issue.
 
  GRASS Python scripts are currently executed using the system-wide
  installed Python if it exists. No attempt has been made to explicitly
  use GRASS_PYTHON, therefore it is not possible to say if the system's
  Python would really be completely ignored.
 
 
  If I remember correctly, Python scripts were not working from Python
  scripts, they were working from command line.

 Which command line? If you used the msys command line, it should work
 because within msys, the embedded GRASS_PYTHON version is readily
 available:

 GRASS 7.0.svn which python
 /c/Programme/GRASS GIS 7.0.svn/extrabin/python.exe

  And we were not able to
  explain why the right Python (or Python DLL) is used at one point but not
  the other.

 If you used the GUI, you are outside the msys shell and the system's
 Python is used. Scripts invoke other GRASS modules with
 grass.run_command() which uses the system's script interpreter if the
 module is a script.

 So, msys is able to configure our Python in the way that it is usable
without interference with the system Python.

Markus M

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Change/update Python requirements for grass70?

On Mon, Feb 10, 2014 at 12:55 PM, Volker Fröhlich volke...@gmx.at wrote:
 On 02/10/2014 11:52 AM, Pietro wrote:
 On Mon, Feb 10, 2014 at 10:43 AM, Martin Landa landa.mar...@gmail.com 
 wrote:
 2014-02-10 11:39 GMT+01:00 Pietro peter.z...@gmail.com:
 So are you agree to change the requirements for grass70 from Python =
 2.4 to Python = 2.7 or Python = 2.6?

 personally I would keep support for Python 2.6 at this point if possible. 
 Martin

 Yes, I think we should be able to keep Python = 2.6.

 2.6 is good because it allows for EL6 builds too!

+1
EL6 and its clones will be around for quite some time, and they are
rather important distros because they are used on various production
systems (workstations, cluster computers).

Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

On Mon, Feb 10, 2014 at 8:29 PM, Vaclav Petras wenzesl...@gmail.com wrote:



 On Mon, Feb 10, 2014 at 2:17 PM, Markus Metz markus.metz.gisw...@gmail.com
 wrote:

 On Mon, Feb 10, 2014 at 6:44 PM, Vaclav Petras wenzesl...@gmail.com
 wrote:
 
 
 
  On Mon, Feb 10, 2014 at 8:41 AM, Markus Metz
  markus.metz.gisw...@gmail.com
  wrote:
 
  On Mon, Feb 10, 2014 at 12:04 PM, Moritz Lennert
  mlenn...@club.worldonline.be wrote:
   On 10/02/14 11:46, Markus Metz wrote:
  
   On Mon, Feb 10, 2014 at 11:26 AM, Helmut Kudrnovsky hel...@web.de
   wrote:
  
   Therefore we need
   hard-coded special treatment for shell and Python scripts in
   order
   to
   make sure that the correct interpreter is used.
  
  
   Just for my understanding: When you say hard-coded special
   treatment
   for
   shell scripts, are you speaking about the .bat files ?
  
  
   I think yes.
  
  
   Or more generally, any mechanism explicitly using %GRASS_PYTHON%
   script.py.
  
  
   But as far as I've seen, this might not be sufficient since this only
   indicates which Python executable to use for launching the Python
   script,
   but any library calls linked to that execution will involve the
   system-wide
   installed Python. Which is different from bash scripts, where this is
   not an
   issue.
 
  GRASS Python scripts are currently executed using the system-wide
  installed Python if it exists. No attempt has been made to explicitly
  use GRASS_PYTHON, therefore it is not possible to say if the system's
  Python would really be completely ignored.
 
 
  If I remember correctly, Python scripts were not working from Python
  scripts, they were working from command line.

 Which command line? If you used the msys command line, it should work
 because within msys, the embedded GRASS_PYTHON version is readily
 available:

 GRASS 7.0.svn which python
 /c/Programme/GRASS GIS 7.0.svn/extrabin/python.exe

  And we were not able to
  explain why the right Python (or Python DLL) is used at one point but
  not
  the other.

 If you used the GUI, you are outside the msys shell and the system's
 Python is used. Scripts invoke other GRASS modules with
 grass.run_command() which uses the system's script interpreter if the
 module is a script.

 So, msys is able to configure our Python in the way that it is usable
 without interference with the system Python.

Maybe, but I did not test it thoroughly. Anyway, G7 is supposed to run
without the msys console which is optional.

Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] wxGUI command line: changed into @ while typing

On Mon, Feb 10, 2014 at 2:28 PM, Markus Metz
markus.metz.gisw...@gmail.comwrote:

 On Mon, Feb 10, 2014 at 7:53 PM, Vaclav Petras wenzesl...@gmail.com
 wrote:
 
 
 
  On Mon, Feb 10, 2014 at 1:19 PM, Markus Neteler nete...@osgeo.org
 wrote:
 
  Hi,
 
  I noticed on Linux that while type
 
  v.extract input=lakes out=anything where=@
 
  and a map name list pops up...
 
  Is this happening to anyone else?
 
  If I understand correctly, you type  character but it is changed to @
  character. This does not happen to me with EN and CS keyboard layouts.

 The  character is changed to @ for me too on a DE keyboard layout.


Could someone test the attached diff please?

Anna



 
  GRASS version: 7.0.svn
  GRASS SVN Revision: 58850M
  Build Date: 2014-01-03
  GDAL/OGR: 1.10.0
  PROJ.4: 4.8.0
  GEOS: 3.3.8
  SQLite: 3.7.9
  Python: 2.7.3
  wxPython: 2.8.12.1
  Platform: Linux-3.2.0-58-generic-pae-i686-with-Ubuntu-12.04-precise
 
 
  I use
  GRASS version: 7.0.svn
  GRASS SVN Revision: 58873M
  Build Date: 2014-01-04
  GDAL/OGR: 1.10.1
  PROJ.4: 4.8.0
  GEOS:
  SQLite: 3.8.2
  Python: 2.7.5
  wxPython: 2.8.12.0
  Platform: Linux-3.12.9-301.fc20.x86_64-x86_64-with-fedora-20-Heisenbug
 
  (Un)related: on Windows this seems to work but retrieving the command
  from the wxGUI history by scrolling eats the quotes.
 
  thanks
  Markus
  ___
  grass-dev mailing list
  grass-dev@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/grass-dev
 
 
 
  ___
  grass-dev mailing list
  grass-dev@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/grass-dev
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev

Index: gui/wxpython/gui_core/prompt.py
===
--- gui/wxpython/gui_core/prompt.py (revision 58980)
+++ gui/wxpython/gui_core/prompt.py (working copy)
@@ -175,6 +175,7 @@
 # bindings
 #
 self.Bind(wx.EVT_WINDOW_DESTROY, self.OnDestroy)
+self.Bind(wx.EVT_CHAR, self.OnChar)
 self.Bind(wx.EVT_KEY_DOWN, self.OnKeyPressed)
 self.Bind(wx.stc.EVT_STC_AUTOCOMP_SELECTION, self.OnItemSelected)
 self.Bind(wx.EVT_LIST_ITEM_SELECTED, self.OnItemChanged)
@@ -375,16 +376,38 @@
 if len(self.autoCompList)  0:
 self.autoCompList.sort()
 self.AutoCompShow(lenEntered = 0, itemList = ' 
'.join(self.autoCompList))
-
+
 def OnKeyPressed(self, event):
-!Key press capture for autocompletion, calltips, and command history
+!Key pressed capture special treatment for tabulator to show help
+pos = self.GetCurrentPos()
+if event.GetKeyCode() == wx.WXK_TAB:
+# show GRASS command calltips (to hide press 'ESC')
+entry = self.GetTextLeft()
+try:
+cmd = entry.split()[0].strip()
+except IndexError:
+cmd = ''
 
+if cmd not in globalvar.grassCmd:
+return
+
+info = gtask.command_info(GetRealCmd(cmd))
+
+self.CallTipSetBackground(#f4f4d1)
+self.CallTipSetForeground(BLACK)
+self.CallTipShow(pos, info['usage'] + '\n\n' + info['description'])
+else:
+event.Skip()
+
+def OnChar(self, event):
+!Key char capture for autocompletion, calltips, and command history
+
 @todo event.ControlDown() for manual autocomplete
 
 # keycodes used: . = 46, = = 61, - = 45 
 pos = self.GetCurrentPos()
 # complete command after pressing '.'
-if event.GetKeyCode() == 46 and not event.ShiftDown():
+if event.GetKeyCode() == 46:
 self.autoCompList = list()
 entry = self.GetTextLeft()
 self.InsertText(pos, '.')
@@ -405,7 +428,7 @@
 self.ShowList()
 
 # complete flags after pressing '-'
-elif (event.GetKeyCode() == 45 and not event.ShiftDown()) \
+elif (event.GetKeyCode() == 45) \
 or event.GetKeyCode() == wx.WXK_NUMPAD_SUBTRACT \
 or event.GetKeyCode() == wx.WXK_SUBTRACT:
 self.autoCompList = list()
@@ -425,7 +448,7 @@
 self.ShowList()
 
 # complete map or values after parameter
-elif event.GetKeyCode() == 61 and not event.ShiftDown():
+elif event.GetKeyCode() == 61:
 self.autoCompList = list()
 self.InsertText(pos, '=')
 self.CharRight()
@@ -440,7 +463,7 @@
 self.ShowList()
 
 # complete mapset ('@')
-elif event.GetKeyCode() == 50 and event.ShiftDown():
+elif event.GetKeyCode() == 64:
 self.autoCompList = list()
 self.InsertText(pos, '@')
 self.CharRight()
@@ -511,24 +534,6 @@

Re: [GRASS-dev] problem bundling GRASS 6.5 and 6.4 RB

I did my normal make distclean followed by svn up. I can delete it all and have
it add it all back in if you think that will help.

One thing is that it works fine on the machine I compile on, but bombs on a
different machine.

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On Feb 10, 2014, at 11:51 AM, Anna Petrášová
kratocha...@gmail.commailto:kratocha...@gmail.com wrote:

On Mon, Feb 10, 2014 at 1:24 PM, Michael Barton
michael.bar...@asu.edumailto:michael.bar...@asu.edu wrote:
Something else has come up.

Either of you know what this may be? I don't know if it is a bundling issue or
something else.

There was a recent change in GUI related to extensions but it's working for me.
Have you updated properly? There shouldn't be any UninstallExtensionWindow now,
it's renamed to ManageExtensionWindow.

Anna

Michael

voice: 480-965-6262tel:480-965-6262 (SHESC),
480-965-8130tel:480-965-8130/727-9746 (CSDC)
fax: 480-965-7671tel:480-965-7671 (SHESC),
480-727-0709tel:480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton,
http://csdc.asu.eduhttp://csdc.asu.edu/

On Feb 7, 2014, at 5:39 PM, William Kyngesburye
wokl...@kyngchaos.commailto:wokl...@kyngchaos.com wrote:

Woops. I deleted too much when I killed the modbuild stuff a few weeks ago.
Should be working now.

On Feb 7, 2014, at 6:19 PM, Michael Barton wrote:

William,

I just recompiled GRASS 7 and bundled it for distribution. It went fine.

But when I went to do the same for GRASS 6.5 and 6.4 RB I ran into an odd
error.

Compilation went fine. No errors in either. But bundling bombed with the
following error:

Is there no longer a grass.sh for GRASS 6.x? If not, what do we use to start
it?

The same line does not cause an error for GRASS 7.

voice:
480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www:
http://csdc.asu.eduhttp://csdc.asu.edu/,
http://shesc.asu.eduhttp://shesc.asu.edu/
http://www.public.asu.edu/~cmbarton

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Change/update Python requirements for grass70?

1+ for me too. 2.6 was the standard for the last several Mac versions and it 
switched to 2.7 in the version before the current one.

Michael
__
C. Michael Barton
Director, Center for Social Dynamics  Complexity
Professor of Anthropology, School of Human Evolution  Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
Tempe, AZ  85287-2402
USA

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
www:  http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On Feb 10, 2014, at 1:00 PM, 
grass-dev-requ...@lists.osgeo.orgmailto:grass-dev-requ...@lists.osgeo.org 
grass-dev-requ...@lists.osgeo.orgmailto:grass-dev-requ...@lists.osgeo.org 
wrote:

Send grass-dev mailing list submissions to
grass-dev@lists.osgeo.orgmailto:grass-dev@lists.osgeo.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.osgeo.org/mailman/listinfo/grass-dev
or, via email, send a message with subject or body 'help' to
grass-dev-requ...@lists.osgeo.org

You can reach the person managing the list at
grass-dev-ow...@lists.osgeo.org

When replying, please edit your Subject line so it is more specific
than Re: Contents of grass-dev digest...
Today's Topics:

  1. Re: Change/update Python requirements for grass70? (Markus Metz)

From: Markus Metz markus.metz.gisw...@gmail.com
Subject: Re: [GRASS-dev] Change/update Python requirements for grass70?
Date: February 10, 2014 at 12:32:16 PM MST
To: Volker Fröhlich volke...@gmx.at
Cc: GRASS developers list grass-dev@lists.osgeo.org


On Mon, Feb 10, 2014 at 12:55 PM, Volker Fröhlich volke...@gmx.at wrote:
On 02/10/2014 11:52 AM, Pietro wrote:
On Mon, Feb 10, 2014 at 10:43 AM, Martin Landa landa.mar...@gmail.com wrote:
2014-02-10 11:39 GMT+01:00 Pietro peter.z...@gmail.com:
So are you agree to change the requirements for grass70 from Python =
2.4 to Python = 2.7 or Python = 2.6?

personally I would keep support for Python 2.6 at this point if possible. Martin

Yes, I think we should be able to keep Python = 2.6.

2.6 is good because it allows for EL6 builds too!

+1
EL6 and its clones will be around for quite some time, and they are
rather important distros because they are used on various production
systems (workstations, cluster computers).

Markus M



___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] wxGUI command line: changed into @ while typing

On Mon, Feb 10, 2014 at 3:25 PM, Anna Petrášová kratocha...@gmail.comwrote:




 On Mon, Feb 10, 2014 at 2:28 PM, Markus Metz 
 markus.metz.gisw...@gmail.com wrote:

 On Mon, Feb 10, 2014 at 7:53 PM, Vaclav Petras wenzesl...@gmail.com
 wrote:
 
 
 
  On Mon, Feb 10, 2014 at 1:19 PM, Markus Neteler nete...@osgeo.org
 wrote:
 
  Hi,
 
  I noticed on Linux that while type
 
  v.extract input=lakes out=anything where=@
 
  and a map name list pops up...
 
  Is this happening to anyone else?
 
  If I understand correctly, you type  character but it is changed to @
  character. This does not happen to me with EN and CS keyboard layouts.

 The  character is changed to @ for me too on a DE keyboard layout.


 Could someone test the attached diff please?


Sorry, new better diff attached.


 Anna



 
  GRASS version: 7.0.svn
  GRASS SVN Revision: 58850M
  Build Date: 2014-01-03
  GDAL/OGR: 1.10.0
  PROJ.4: 4.8.0
  GEOS: 3.3.8
  SQLite: 3.7.9
  Python: 2.7.3
  wxPython: 2.8.12.1
  Platform: Linux-3.2.0-58-generic-pae-i686-with-Ubuntu-12.04-precise
 
 
  I use
  GRASS version: 7.0.svn
  GRASS SVN Revision: 58873M
  Build Date: 2014-01-04
  GDAL/OGR: 1.10.1
  PROJ.4: 4.8.0
  GEOS:
  SQLite: 3.8.2
  Python: 2.7.5
  wxPython: 2.8.12.0
  Platform: Linux-3.12.9-301.fc20.x86_64-x86_64-with-fedora-20-Heisenbug
 
  (Un)related: on Windows this seems to work but retrieving the command
  from the wxGUI history by scrolling eats the quotes.
 
  thanks
  Markus
  ___
  grass-dev mailing list
  grass-dev@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/grass-dev
 
 
 
  ___
  grass-dev mailing list
  grass-dev@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/grass-dev
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev



Index: gui/wxpython/gui_core/prompt.py
===
--- gui/wxpython/gui_core/prompt.py (revision 58980)
+++ gui/wxpython/gui_core/prompt.py (working copy)
@@ -175,6 +175,7 @@
 # bindings
 #
 self.Bind(wx.EVT_WINDOW_DESTROY, self.OnDestroy)
+self.Bind(wx.EVT_CHAR, self.OnChar)
 self.Bind(wx.EVT_KEY_DOWN, self.OnKeyPressed)
 self.Bind(wx.stc.EVT_STC_AUTOCOMP_SELECTION, self.OnItemSelected)
 self.Bind(wx.EVT_LIST_ITEM_SELECTED, self.OnItemChanged)
@@ -375,16 +376,73 @@
 if len(self.autoCompList)  0:
 self.autoCompList.sort()
 self.AutoCompShow(lenEntered = 0, itemList = ' 
'.join(self.autoCompList))
-
+
 def OnKeyPressed(self, event):
-!Key press capture for autocompletion, calltips, and command history
+!Key pressed capture special treatment for tabulator to show help
+pos = self.GetCurrentPos()
+if event.GetKeyCode() == wx.WXK_TAB:
+# show GRASS command calltips (to hide press 'ESC')
+entry = self.GetTextLeft()
+try:
+cmd = entry.split()[0].strip()
+except IndexError:
+cmd = ''
 
+if cmd not in globalvar.grassCmd:
+return
+
+info = gtask.command_info(GetRealCmd(cmd))
+
+self.CallTipSetBackground(#f4f4d1)
+self.CallTipSetForeground(BLACK)
+self.CallTipShow(pos, info['usage'] + '\n\n' + info['description'])
+elif event.GetKeyCode() in (wx.WXK_RETURN, wx.WXK_NUMPAD_ENTER) and \
+not self.AutoCompActive():
+# run command on line when return is pressed
+self._runCmd(self.GetCurLine()[0].strip())
+elif event.GetKeyCode() in [wx.WXK_UP, wx.WXK_DOWN] and \
+not self.AutoCompActive():
+# Command history using up and down
+if len(self.cmdbuffer)  1:
+return
+
+self.DocumentEnd()
+
+# move through command history list index values
+if event.GetKeyCode() == wx.WXK_UP:
+self.cmdindex = self.cmdindex - 1
+if event.GetKeyCode() == wx.WXK_DOWN:
+self.cmdindex = self.cmdindex + 1
+if self.cmdindex  0:
+self.cmdindex = 0
+if self.cmdindex  len(self.cmdbuffer) - 1:
+self.cmdindex = len(self.cmdbuffer) - 1
+
+try:
+txt = self.cmdbuffer[self.cmdindex]
+except KeyError:
+txt = ''
+
+# clear current line and insert command history
+self.DelLineLeft()
+self.DelLineRight()
+pos = self.GetCurrentPos()
+self.InsertText(pos, txt)
+self.LineEnd()
+
+self.ShowStatusText('')
+else:
+event.Skip()
+
+def OnChar(self, event):
+!Key char capture for autocompletion, calltips, and

Re: [GRASS-dev] problem bundling GRASS 6.5 and 6.4 RB

On Mon, Feb 10, 2014 at 4:08 PM, Michael Barton michael.bar...@asu.eduwrote:

I did my normal make distclean followed by svn up. I can delete it all
and have it add it all back in if you think that will help.

One thing is that it works fine on the machine I compile on, but bombs
on a different machine.

I double checked and there is no `UninstallExtensionWindow` in source code
now, except for documentation:

./gui/wxpython/wxpythonlib.dox

Your error is at line 68 in lmgr/frame.py, but there is no
`import...UninstallExtensionWindow` now:

http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/lmgr/frame.py?rev=58946#L68

So, try svn diff, svn status, check your lmgr/frame.py file, check your
packaging process... It seems that the older version of the file is
packaged or perhaps imported from different GRASS on that other machine.

Hope this helps,
Vaclav

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On Feb 10, 2014, at 11:51 AM, Anna Petrášová kratocha...@gmail.com
wrote:

On Mon, Feb 10, 2014 at 1:24 PM, Michael Barton michael.bar...@asu.eduwrote:

Something else has come up.

I compiled GRASS 7 on one computer Friday. It DID bundle OK (but maybe
better now?). But when I went to run it on a different computer with the
same OS, Python, and wxPython, I hit the following error at startup.

Either of you know what this may be? I don't know if it is a bundling
issue or something else.

There was a recent change in GUI related to extensions but it's working
for me. Have you updated properly? There shouldn't be any
UninstallExtensionWindow now, it's renamed to ManageExtensionWindow.

Anna

Michael

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Feb 7, 2014, at 5:39 PM, William Kyngesburye wokl...@kyngchaos.com
wrote:

Woops. I deleted too much when I killed the modbuild stuff a few
weeks ago. Should be working now.

On Feb 7, 2014, at 6:19 PM, Michael Barton wrote:

William,

I just recompiled GRASS 7 and bundled it for distribution. It went
fine.

But when I went to do the same for GRASS 6.5 and 6.4 RB I ran into an
odd error.

Compilation went fine. No errors in either. But bundling bombed with
the following error:

Is there no longer a grass.sh for GRASS 6.x? If not, what do we use to
start it?

The same line does not cause an error for GRASS 7.

voice:
480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www:
http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] wxGUI: add color selector drop-down list to Settings?

Hi,


On Mon, Feb 10, 2014 at 12:56 PM, Markus Neteler nete...@osgeo.org wrote:

 Hi,

 in wxGUI - Settings - Preferences - Layer tab
 there is the Default color table text color list, could this be
 switched to the nice graphical one as used/generated here:

 case G_OPT_M_COLR:
 Opt-key = color;
 Opt-key_desc = style;
 Opt-type = TYPE_STRING;
 Opt-required = NO;
 Opt-options = G_color_rules_options();
 Opt-description = _(Name of color table);
 Opt-descriptions = G_color_rules_descriptions();
 Opt-gisprompt = old,colortable,colortable;
 break;

 (used in r.colors/v.colors)



done in r58981

Anna



 thanks
 Markus
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] wxGUI: add color selector drop-down list to Settings?

On Mon, Feb 10, 2014 at 10:56 PM, Anna Petrášová kratocha...@gmail.com wrote:
 Hi,
 On Mon, Feb 10, 2014 at 12:56 PM, Markus Neteler nete...@osgeo.org wrote:
 in wxGUI - Settings - Preferences - Layer tab
 there is the Default color table text color list, could this be
 switched to the nice graphical one as used/generated here:

 case G_OPT_M_COLR:
 Opt-key = color;
 Opt-key_desc = style;
 Opt-type = TYPE_STRING;
 Opt-required = NO;
 Opt-options = G_color_rules_options();
 Opt-description = _(Name of color table);
 Opt-descriptions = G_color_rules_descriptions();
 Opt-gisprompt = old,colortable,colortable;
 break;

 (used in r.colors/v.colors)

 done in r58981

Wonderful, works nicely.
Thanks for the real-time enhancement, Anna.

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] wxGUI command line: changed into @ while typing

On Mon, Feb 10, 2014 at 10:49 PM, Anna Petrášová kratocha...@gmail.com wrote:
 On Mon, Feb 10, 2014 at 3:25 PM, Anna Petrášová kratocha...@gmail.com
 wrote:




 On Mon, Feb 10, 2014 at 2:28 PM, Markus Metz
 markus.metz.gisw...@gmail.com wrote:

 On Mon, Feb 10, 2014 at 7:53 PM, Vaclav Petras wenzesl...@gmail.com
 wrote:
 
 
 
  On Mon, Feb 10, 2014 at 1:19 PM, Markus Neteler nete...@osgeo.org
  wrote:
 
  Hi,
 
  I noticed on Linux that while type
 
  v.extract input=lakes out=anything where=@
 
  and a map name list pops up...
 
  Is this happening to anyone else?
 
  If I understand correctly, you type  character but it is changed to @
  character. This does not happen to me with EN and CS keyboard layouts.

 The  character is changed to @ for me too on a DE keyboard layout.


 Could someone test the attached diff please?


 Sorry, new better diff attached.

Locally applied, it helps and the  is generated as expected.
Only scrolling back and forth in the wxGUI cmd line history eats the 
up but that probably unrelated.

markusN
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] A new error in GRASS 6.4 release branch

I just tried to compile GRASS 6.4 a few minutes ago. A new error has cropped up 
over the weekend. I’m compiling with a completely new copy of the source code. 
It is missing a PNG file

GRASS GIS compilation log
-
Started compilation: Mon Feb 10 14:46:41 MST 2014
--
Errors in:
/Users/cmbarton/Dropbox/GRASS_dropbox/source/grass64_rb/general/g.parser
--
In case of errors please change into the directory with error and run 'make'.
If you get multiple errors, you need to deal with them in the order they
appear in the error log. If you get an error building a library, you will
also get errors from anything which uses the library.
--
Finished compilation: Mon Feb 10 15:00:19 MST 2014
make: *** [default] Error 1
cmb-shesc-imac:grass64_rb cmbarton$ cd 
/Users/cmbarton/Dropbox/GRASS_dropbox/source/grass64_rb/general/g.parser
cmb-shesc-imac:g.parser cmbarton$ make
Makefile:20: warning: overriding commands for target `htmlcmd'
../../include/Make/Html.make:45: warning: ignoring old commands for target 
`htmlcmd'
/Applications/Xcode.app/Contents/Developer/usr/bin/make htmlcmd
Makefile:20: warning: overriding commands for target `htmlcmd'
../../include/Make/Html.make:45: warning: ignoring old commands for target 
`htmlcmd'
/Applications/Xcode.app/Contents/Developer/usr/bin/make 
/Users/cmbarton/Dropbox/GRASS_dropbox/source/grass64_rb/dist.x86_64-apple-darwin13.0.0/docs/html/g.parser.html
 HTMLSRC=
Makefile:20: warning: overriding commands for target `htmlcmd'
../../include/Make/Html.make:45: warning: ignoring old commands for target 
`htmlcmd'
make[2]: 
`/Users/cmbarton/Dropbox/GRASS_dropbox/source/grass64_rb/dist.x86_64-apple-darwin13.0.0/docs/html/g.parser.html'
 is up to date.
/Applications/Xcode.app/Contents/Developer/usr/bin/make mancmd
Makefile:20: warning: overriding commands for target `htmlcmd'
../../include/Make/Html.make:45: warning: ignoring old commands for target 
`htmlcmd'
/Applications/Xcode.app/Contents/Developer/usr/bin/make 
/Users/cmbarton/Dropbox/GRASS_dropbox/source/grass64_rb/dist.x86_64-apple-darwin13.0.0/man/man1/g.parser.1
 
MANSRC=/Users/cmbarton/Dropbox/GRASS_dropbox/source/grass64_rb/dist.x86_64-apple-darwin13.0.0/docs/html/g.parser.html
Makefile:20: warning: overriding commands for target `htmlcmd'
../../include/Make/Html.make:45: warning: ignoring old commands for target 
`htmlcmd'
make[2]: 
`/Users/cmbarton/Dropbox/GRASS_dropbox/source/grass64_rb/dist.x86_64-apple-darwin13.0.0/man/man1/g.parser.1'
 is up to date.
/usr/bin/install -c  -m 644 g_parser_test.png 
/Users/cmbarton/Dropbox/GRASS_dropbox/source/grass64_rb/dist.x86_64-apple-darwin13.0.0/docs/html/g_parser_test.png
install: g_parser_test.png: No such file or directory
make: *** [default] Error 71



__
C. Michael Barton
Director, Center for Social Dynamics  Complexity
Professor of Anthropology, School of Human Evolution  Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
Tempe, AZ  85287-2402
USA

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
www:  http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] A new error in GRASS 6.4 release branch

On Mon, Feb 10, 2014 at 11:16 PM, Michael Barton michael.bar...@asu.edu wrote:
 I just tried to compile GRASS 6.4 a few minutes ago. A new error has cropped
 up over the weekend. I'm compiling with a completely new copy of the source
 code. It is missing a PNG file

Did it get deleted on your system?
I have it on my machine, as well as in SVN:

[neteler@oboe grass64]$ svn info general/g.parser/g_parser_test.png
Path: general/g.parser/g_parser_test.png
Name: g_parser_test.png
Working Copy Root Path: /home/neteler/software/grass64
URL: 
https://svn.osgeo.org/grass/grass/branches/releasebranch_6_4/general/g.parser/g_parser_test.png
Relative URL: 
^/grass/branches/releasebranch_6_4/general/g.parser/g_parser_test.png
Repository Root: https://svn.osgeo.org/grass
Repository UUID: 15284696-431f-4ddb-bdfa-cd5b030d7da7
Revision: 58981
Node Kind: file
Schedule: normal
Last Changed Author: neteler
Last Changed Rev: 58319
Last Changed Date: 2013-11-27 21:59:34 +0100 (Wed, 27 Nov 2013)
Text Last Updated: 2013-12-03 19:05:11 +0100 (Tue, 03 Dec 2013)
Checksum: ddf83851e8fbb586163ae88a9d1f14666f53c8c9

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] problem bundling GRASS 6.5 and 6.4 RB

I’m starting from a clean update of GRASS 7 source from the SVN. I’ll let you
know.

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On Feb 10, 2014, at 2:56 PM, Vaclav Petras
wenzesl...@gmail.commailto:wenzesl...@gmail.com wrote:

On Mon, Feb 10, 2014 at 4:08 PM, Michael Barton
michael.bar...@asu.edumailto:michael.bar...@asu.edu wrote:
I did my normal make distclean followed by svn up. I can delete it all and have
it add it all back in if you think that will help.

One thing is that it works fine on the machine I compile on, but bombs on a
different machine.

I double checked and there is no `UninstallExtensionWindow` in source code now,
except for documentation:

./gui/wxpython/wxpythonlib.dox

Your error is at line 68 in lmgr/frame.py, but there is no
`import...UninstallExtensionWindow` now:

http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/lmgr/frame.py?rev=58946#L68

So, try svn diff, svn status, check your lmgr/frame.py file, check your
packaging process... It seems that the older version of the file is packaged or
perhaps imported from different GRASS on that other machine.

Hope this helps,
Vaclav

voice: 480-965-6262tel:480-965-6262 (SHESC),
480-965-8130tel:480-965-8130/727-9746 (CSDC)
fax: 480-965-7671tel:480-965-7671(SHESC),
480-727-0709tel:480-727-0709 (CSDC)
www: http://csdc.asu.eduhttp://csdc.asu.edu/,
http://shesc.asu.eduhttp://shesc.asu.edu/
http://www.public.asu.edu/~cmbarton

On Feb 10, 2014, at 11:51 AM, Anna Petrášová
kratocha...@gmail.commailto:kratocha...@gmail.com wrote:

On Mon, Feb 10, 2014 at 1:24 PM, Michael Barton
michael.bar...@asu.edumailto:michael.bar...@asu.edu wrote:
Something else has come up.

Either of you know what this may be? I don't know if it is a bundling issue or
something else.

There was a recent change in GUI related to extensions but it's working for me.
Have you updated properly? There shouldn't be any UninstallExtensionWindow now,
it's renamed to ManageExtensionWindow.

Anna

Michael

On Feb 7, 2014, at 5:39 PM, William Kyngesburye
wokl...@kyngchaos.commailto:wokl...@kyngchaos.com wrote:

Woops. I deleted too much when I killed the modbuild stuff a few weeks ago.
Should be working now.

On Feb 7, 2014, at 6:19 PM, Michael Barton wrote:

William,

I just recompiled GRASS 7 and bundled it for distribution. It went fine.

But when I went to do the same for GRASS 6.5 and 6.4 RB I ran into an odd
error.

Compilation went fine. No errors in either. But bundling bombed with the
following error:

Re: [GRASS-dev] A new error in GRASS 6.4 release branch

I deleted everything and did an svn up to restore it all—and only restore 
things in the current svn.

Where should it live in the source code?

Michael
__
C. Michael Barton 
Director, Center for Social Dynamics  Complexity
Professor of Anthropology, School of Human Evolution  Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
Tempe, AZ  85287-2402
USA

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
www:http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On Feb 10, 2014, at 3:28 PM, Markus Neteler nete...@osgeo.org wrote:

 On Mon, Feb 10, 2014 at 11:16 PM, Michael Barton michael.bar...@asu.edu 
 wrote:
 I just tried to compile GRASS 6.4 a few minutes ago. A new error has cropped
 up over the weekend. I'm compiling with a completely new copy of the source
 code. It is missing a PNG file
 
 Did it get deleted on your system?
 I have it on my machine, as well as in SVN:
 
 [neteler@oboe grass64]$ svn info general/g.parser/g_parser_test.png
 Path: general/g.parser/g_parser_test.png
 Name: g_parser_test.png
 Working Copy Root Path: /home/neteler/software/grass64
 URL: 
 https://svn.osgeo.org/grass/grass/branches/releasebranch_6_4/general/g.parser/g_parser_test.png
 Relative URL: 
 ^/grass/branches/releasebranch_6_4/general/g.parser/g_parser_test.png
 Repository Root: https://svn.osgeo.org/grass
 Repository UUID: 15284696-431f-4ddb-bdfa-cd5b030d7da7
 Revision: 58981
 Node Kind: file
 Schedule: normal
 Last Changed Author: neteler
 Last Changed Rev: 58319
 Last Changed Date: 2013-11-27 21:59:34 +0100 (Wed, 27 Nov 2013)
 Text Last Updated: 2013-12-03 19:05:11 +0100 (Tue, 03 Dec 2013)
 Checksum: ddf83851e8fbb586163ae88a9d1f14666f53c8c9
 
 Markus

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] A new error in GRASS 6.4 release branch

On Mon, Feb 10, 2014 at 11:32 PM, Michael Barton michael.bar...@asu.edu wrote:
 I deleted everything and did an svn up to restore it all--and only restore 
 things in the current svn.

 Where should it live in the source code?

It should be here:
general/g.parser/g_parser_test.png

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] A new error in GRASS 6.4 release branch

It is in GRASS 7 but not in GRASS 6.4 release branch

Michael
__
C. Michael Barton 
Director, Center for Social Dynamics  Complexity
Professor of Anthropology, School of Human Evolution  Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
Tempe, AZ  85287-2402
USA

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
www:http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On Feb 10, 2014, at 3:50 PM, Markus Neteler nete...@osgeo.org wrote:

 On Mon, Feb 10, 2014 at 11:32 PM, Michael Barton michael.bar...@asu.edu 
 wrote:
 I deleted everything and did an svn up to restore it all--and only restore 
 things in the current svn.
 
 Where should it live in the source code?
 
 It should be here:
 general/g.parser/g_parser_test.png
 
 Markus

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] wxGUI command line: changed into @ while typing