date:20140210

Re: [GRASS-dev] r.hydrodem addon fails on very big rasters (150, 000 x 120, 000 pixels)

2014-02-10 Thread Markus Metz

On Thu, Feb 6, 2014 at 5:57 PM, Markus Neteler  wrote:
> On Thu, Feb 6, 2014 at 1:14 PM, Blumentrath, Stefan
>  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: 
GRASS GIS 

___
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 Markus Metz

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//)
> 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: 
GRASS GIS 

___
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 :
> 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  * 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: 
GRASS GIS 

___
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 Markus Metz

On Mon, Feb 10, 2014 at 11:26 AM, Helmut Kudrnovsky  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  wrote:
> 2014-02-10 11:39 GMT+01:00 Pietro :
>> 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  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  wrote:
>> 2014-02-10 11:39 GMT+01:00 Pietro :
>>> 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

2014-02-10 Thread Markus Metz

On Mon, Feb 10, 2014 at 12:04 PM, Moritz Lennert
 wrote:
> On 10/02/14 11:46, Markus Metz wrote:
>>
>> On Mon, Feb 10, 2014 at 11:26 AM, Helmut Kudrnovsky  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

2014-02-10 Thread Markus Neteler

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

2014-02-10 Thread Vaclav Petras

On Mon, Feb 10, 2014 at 8:41 AM, Markus Metz
wrote:

> On Mon, Feb 10, 2014 at 12:04 PM, Moritz Lennert
>  wrote:
> > On 10/02/14 11:46, Markus Metz wrote:
> >>
> >> On Mon, Feb 10, 2014 at 11:26 AM, Helmut Kudrnovsky 
> 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

2014-02-10 Thread Vaclav Petras

On Mon, Feb 10, 2014 at 12:33 PM, Markus Neteler  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?

2014-02-10 Thread Markus Neteler

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] Handling of Python scripts on MS Windows

2014-02-10 Thread Helmut Kudrnovsky

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

it's maybe a path issue (?).

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/path.mspx?mfr=true

"The operating system always searches in the current directory first, before
it searches the directories in the command path."



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Handling-of-Python-scripts-on-MS-Windows-tp5081335p5103011.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 command line: " changed into @ while typing

2014-02-10 Thread Markus Neteler

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?

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

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

2014-02-10 Thread Michael Barton

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 
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 
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  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] problem bundling GRASS 6.5 and 6.4 RB

2014-02-10 Thread Anna Petrášová

On Mon, Feb 10, 2014 at 1:24 PM, Michael Barton wrote:

> 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


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

2014-02-10 Thread Vaclav Petras

On Mon, Feb 10, 2014 at 1:19 PM, Markus Neteler  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.

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

Re: [GRASS-dev] [GRASS GIS] #2088: G7: digitizer python error

2014-02-10 Thread GRASS GIS

#2088: G7: digitizer python error
---+
 Reporter:  neteler|   Owner:  martinl  
 Type:  defect |  Status:  assigned 
 Priority:  normal |   Milestone:  7.0.0
Component:  wxGUI  | Version:  svn-trunk
 Keywords:  digitizer, python  |Platform:  Linux
  Cpu:  x86-64 |  
---+

Comment(by wenzeslaus):

 Replying to [comment:6 martinl]:
 > Replying to [comment:5 wenzeslaus]:
 >
 > > This hiding of layers (not showing rendered layers in map window)
 happens a lot, especially with vectors. I have no idea what's behind.
 >
 > I discovered that `CheckItem()` callled in `AddLayer()`
 source:grass/trunk/gui/wxpython/lmgr/layertree.py#L1103 causes that
 `Map.layers` appears to be empty (even there are maps in layer tree). I
 really have no idea why. Anyway `wx.CallAfter()` avoids it (at least it
 seems to)

 So, r58939 fixed the problem I had which occurred when you used `d.vect`
 from Command console in GUI or when vector map was output of some module
 (and map was added automatically). Thanks.

 I agree that `wx.CallAfter()` is probably workaround for some problem but
 there is no other option now.

 How about the original reported issue? Can we close the ticket?

-- 
Ticket URL: 
GRASS GIS 

___
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 Markus Metz

On Mon, Feb 10, 2014 at 6:44 PM, Vaclav Petras  wrote:
>
>
>
> On Mon, Feb 10, 2014 at 8:41 AM, Markus Metz 
> wrote:
>>
>> On Mon, Feb 10, 2014 at 12:04 PM, Moritz Lennert
>>  wrote:
>> > On 10/02/14 11:46, Markus Metz wrote:
>> >>
>> >> On Mon, Feb 10, 2014 at 11:26 AM, Helmut Kudrnovsky 
>> >> 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.

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

2014-02-10 Thread Markus Metz

On Mon, Feb 10, 2014 at 7:53 PM, Vaclav Petras  wrote:
>
>
>
> On Mon, Feb 10, 2014 at 1:19 PM, Markus Neteler  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

2014-02-10 Thread Vaclav Petras

On Mon, Feb 10, 2014 at 2:17 PM, Markus Metz
wrote:

> On Mon, Feb 10, 2014 at 6:44 PM, Vaclav Petras 
> 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
> >>  wrote:
> >> > On 10/02/14 11:46, Markus Metz wrote:
> >> >>
> >> >> On Mon, Feb 10, 2014 at 11:26 AM, Helmut Kudrnovsky 
> >> >> 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?

2014-02-10 Thread Markus Metz

On Mon, Feb 10, 2014 at 12:55 PM, Volker Fröhlich  wrote:
> On 02/10/2014 11:52 AM, Pietro wrote:
>> On Mon, Feb 10, 2014 at 10:43 AM, Martin Landa  
>> wrote:
>>> 2014-02-10 11:39 GMT+01:00 Pietro :
 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

2014-02-10 Thread Markus Metz

On Mon, Feb 10, 2014 at 8:29 PM, Vaclav Petras  wrote:
>
>
>
> On Mon, Feb 10, 2014 at 2:17 PM, Markus Metz 
> wrote:
>>
>> On Mon, Feb 10, 2014 at 6:44 PM, Vaclav Petras 
>> wrote:
>> >
>> >
>> >
>> > On Mon, Feb 10, 2014 at 8:41 AM, Markus Metz
>> > 
>> > wrote:
>> >>
>> >> On Mon, Feb 10, 2014 at 12:04 PM, Moritz Lennert
>> >>  wrote:
>> >> > On 10/02/14 11:46, Markus Metz wrote:
>> >> >>
>> >> >> On Mon, Feb 10, 2014 at 11:26 AM, Helmut Kudrnovsky 
>> >> >> 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

2014-02-10 Thread Anna Petrášová

On Mon, Feb 10, 2014 at 2:28 PM, Markus Metz
wrote:

> On Mon, Feb 10, 2014 at 7:53 PM, Vaclav Petras 
> wrote:
> >
> >
> >
> > On Mon, Feb 10, 2014 at 1:19 PM, Markus Neteler 
> 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:

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

2014-02-10 Thread Michael Barton

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.

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 11:51 AM, Anna Petrášová 
mailto:kratocha...@gmail.com>> wrote:

On Mon, Feb 10, 2014 at 1:24 PM, Michael Barton 
mailto:michael.bar...@asu.edu>> wrote:
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

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 
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 
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 
mailto: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] Change/update Python requirements for grass70?

2014-02-10 Thread Michael Barton

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, 
mailto:grass-dev-requ...@lists.osgeo.org>> 
mailto:grass-dev-requ...@lists.osgeo.org>> 
wrote:

Send grass-dev mailing list submissions to
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 
Subject: Re: [GRASS-dev] Change/update Python requirements for grass70?
Date: February 10, 2014 at 12:32:16 PM MST
To: Volker Fröhlich 
Cc: GRASS developers list 


On Mon, Feb 10, 2014 at 12:55 PM, Volker Fröhlich  wrote:
On 02/10/2014 11:52 AM, Pietro wrote:
On Mon, Feb 10, 2014 at 10:43 AM, Martin Landa  wrote:
2014-02-10 11:39 GMT+01:00 Pietro :
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

2014-02-10 Thread Anna Petrášová

On Mon, Feb 10, 2014 at 3:25 PM, Anna Petrášová 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 
>> wrote:
>> >
>> >
>> >
>> > On Mon, Feb 10, 2014 at 1:19 PM, Markus Neteler 
>> 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  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)
+

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

2014-02-10 Thread Vaclav Petras

On Mon, Feb 10, 2014 at 4:08 PM, Michael Barton 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

 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 11:51 AM, Anna Petrášová 
> wrote:
>
>
>
>
> On Mon, Feb 10, 2014 at 1:24 PM, Michael Barton wrote:
>
>> 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
>
>
>  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 
>> 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 
>> 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 
>> 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

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

2014-02-10 Thread Anna Petrášová

Hi,


On Mon, Feb 10, 2014 at 12:56 PM, Markus Neteler  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?

2014-02-10 Thread Markus Neteler

On Mon, Feb 10, 2014 at 10:56 PM, Anna Petrášová  wrote:
> Hi,
> On Mon, Feb 10, 2014 at 12:56 PM, Markus Neteler  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

2014-02-10 Thread Markus Neteler

On Mon, Feb 10, 2014 at 10:49 PM, Anna Petrášová  wrote:
> On Mon, Feb 10, 2014 at 3:25 PM, Anna Petrášová 
> wrote:
>>
>>
>>
>>
>> On Mon, Feb 10, 2014 at 2:28 PM, Markus Metz
>>  wrote:
>>>
>>> On Mon, Feb 10, 2014 at 7:53 PM, Vaclav Petras 
>>> wrote:
>>> >
>>> >
>>> >
>>> > On Mon, Feb 10, 2014 at 1:19 PM, Markus Neteler 
>>> > 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

2014-02-10 Thread Michael Barton

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

2014-02-10 Thread Markus Neteler

On Mon, Feb 10, 2014 at 11:16 PM, Michael Barton  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

2014-02-10 Thread Michael Barton

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

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 2:56 PM, Vaclav Petras 
mailto:wenzesl...@gmail.com>> wrote:

On Mon, Feb 10, 2014 at 4:08 PM, Michael Barton 
mailto: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

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 11:51 AM, Anna Petrášová 
mailto:kratocha...@gmail.com>> wrote:

On Mon, Feb 10, 2014 at 1:24 PM, Michael Barton 
mailto:michael.bar...@asu.edu>> wrote:
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

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

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

2014-02-10 Thread Michael Barton

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

> On Mon, Feb 10, 2014 at 11:16 PM, Michael Barton  
> 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

2014-02-10 Thread Markus Neteler

On Mon, Feb 10, 2014 at 11:32 PM, Michael Barton  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

2014-02-10 Thread Michael Barton

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

> On Mon, Feb 10, 2014 at 11:32 PM, Michael Barton  
> 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

2014-02-10 Thread Anna Petrášová

On Mon, Feb 10, 2014 at 5:07 PM, Markus Neteler  wrote:

> On Mon, Feb 10, 2014 at 10:49 PM, Anna Petrášová 
> wrote:
> > On Mon, Feb 10, 2014 at 3:25 PM, Anna Petrášová 
> > wrote:
> >>
> >>
> >>
> >>
> >> On Mon, Feb 10, 2014 at 2:28 PM, Markus Metz
> >>  wrote:
> >>>
> >>> On Mon, Feb 10, 2014 at 7:53 PM, Vaclav Petras 
> >>> wrote:
> >>> >
> >>> >
> >>> >
> >>> > On Mon, Feb 10, 2014 at 1:19 PM, Markus Neteler 
> >>> > 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.
>

yes, that's unrelated, I remember I looked at it once, but I am not really
sure what was the problem...
The quotes issue is fixed in r58984 for GRASS 7 and backported

Anna


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

46 matches

Mail list logo