date:20130610

Re: [GRASS-dev] GRASS 7 crashes on startup on Mac

2013-06-10 Thread William Kyngesburye

I'm not sure what the status is with GRASS GUI and wxpython 2.8 vs. 2.9.

I'm not sure what the status of wxpython 2.8 (carbon) is on Mt Lion.  I expect 
things to break because of the deprecation of Carbon on Mt Lion, though 
existing carbon-based software should still work.  I'm guessing that you can't 
compile wxpython, or anything else, yourself based on Carbon, so if you want to 
compile something that needs Carbon you must do it on Lion or Snow.  It should 
run on Mt Lion.

I do know that to get a complete 64bit-only build of GRASS 7 on any version of 
OS X (Snow - Mt Lion), you must use cocoa APIs, and to do that you need 
wxpython 2.9.

On Jun 10, 2013, at 4:52 PM, Michael Barton wrote:

> To clarify, I was ONLY installing wxPython 2.9 carbon for Python 2.6. Other 
> than that, I have only wxPython 2.8 for Python 2.6.
> 
> On Mt. Lion, does this NOT work? If not, do I need wxPython 2.9 carbon for 
> Python 2.7, wxPython 2.9 cocoa for Python 2.7 or will either of these 2 work?
> 
> Thanks
> Michael
> __
> C. Michael Barton 
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Arizona State University
> Tempe, AZ  85287-2402
> USA
> 
> voice:480-965-6262 (SHESC), 480-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 Jun 10, 2013, at 2:41 PM, William Kyngesburye 
> wrote:
> 
>> I think we're probably at a point of not being able to do a single binary 
>> package for both Snow and Lion+ - too many differences.  It's not quite 
>> possible to install both 2.9 carbon for Python 2.6 and 2.9 cocoa for Python 
>> 2.7 - while the python parts are separate, the C library parts of one will 
>> overwrite the other, and they are probably not compatible.
>> 
>> The way I handle it is to compile wxpython myself.  I can install each in 
>> completely separate locations and reference whichever I need for Snow or 
>> Lion builds.  BUT, I haven't tried this yet for 2.9 carbon ON lion, I may 
>> have to also compile wxpython 2.9 carbon on Snow (and maybe even GRASS).
>> 
>> On Jun 10, 2013, at 4:21 PM, Michael Barton wrote:
>> 
>>> I just installed wxPython 2.9.0.4 for Python 2.6 (for backward 
>>> compatibility with Snow Leopard). It razed an error on configuration. In 
>>> checking, here is what I get.
>>> 
>>> /usr/local/lib/wxPython-2.9.4.0/bin/wx-config --list
>>> 
>>>  Default config is osx_carbon-unicode-2.9
>>> 
>>>No config found to match: 
>>> /usr/local/lib/wxPython-2.9.4.0/bin/wx-config --list
>>>in /usr/local/lib/wxPython-2.9.4.0/lib/wx/config
>>> 
>>>Please install the desired library build, or specify a different
>>>prefix where it may be found.  If the library is not installed
>>>you may call its wx-config directly by specifying its full path.
>>> 
>>> 
>>> Also available in /usr/local/lib/wxPython-2.9.4.0:
>>>  osx_carbon-unicode-2.9
>>> 
>>> 
>>> Any idea what is wrong? 
>>> 
>>> MUST I use wxPython 2.9 ONLY with Python 2.7??? That means no more Snow 
>>> Leopard compatibility.
>>> 
>>> Michael
>>> __
>>> C. Michael Barton 
>>> Director, Center for Social Dynamics & Complexity
>>> Professor of Anthropology, School of Human Evolution & Social Change
>>> Arizona State University
>>> Tempe, AZ  85287-2402
>>> USA
>>> 
>>> voice:  480-965-6262 (SHESC), 480-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 Jun 7, 2013, at 8:39 PM, William Kyngesburye  
>>> wrote:
>>> 
 I just compiled trunk, no compile errors, and GUI runs fine.
 
 OSX 10.7 Lion, Xcode 4.6.2 command line tools, wxPython 2.9.4
 
 I'm a bit lost now - what is the status of this, what is the current 
 problem?
 
 On Jun 7, 2013, at 10:28 AM, Michael Barton wrote:
 
> Maybe it is PYTHONPATH
> 
> BUT...
> 
> Python and the GUI is compiling and working just fine otherwise. And 
> Python runs with no problem in the terminal.
> 
> The bogus errors for compiling mapswipe, composer, etc first appeared 
> with what I think was the introduction of a new window class for these 
> modules. I have not seen the toolbox, but it may reuse the same code. If 
> I knew what this new code is, I might be able to troubleshoot it. But I 
> don't have time to try to reverse engineer it without guidance as to 
> where to look. The error on importing wx is misleading as to what the 
> real error is. 
> 
> I can't say for sure that these are all related (and the error is indeed 
> somewhat different for the toolbox compilation). But it seems a 
> reasonable place to start.
> 
> If it IS a PYTHONPATH pro

Re: [GRASS-dev] GRASS 7 crashes on startup on Mac

2013-06-10 Thread Michael Barton

To clarify, I was ONLY installing wxPython 2.9 carbon for Python 2.6. Other 
than that, I have only wxPython 2.8 for Python 2.6.

On Mt. Lion, does this NOT work? If not, do I need wxPython 2.9 carbon for 
Python 2.7, wxPython 2.9 cocoa for Python 2.7 or will either of these 2 work?

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

voice:  480-965-6262 (SHESC), 480-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 Jun 10, 2013, at 2:41 PM, William Kyngesburye 
 wrote:

> I think we're probably at a point of not being able to do a single binary 
> package for both Snow and Lion+ - too many differences.  It's not quite 
> possible to install both 2.9 carbon for Python 2.6 and 2.9 cocoa for Python 
> 2.7 - while the python parts are separate, the C library parts of one will 
> overwrite the other, and they are probably not compatible.
> 
> The way I handle it is to compile wxpython myself.  I can install each in 
> completely separate locations and reference whichever I need for Snow or Lion 
> builds.  BUT, I haven't tried this yet for 2.9 carbon ON lion, I may have to 
> also compile wxpython 2.9 carbon on Snow (and maybe even GRASS).
> 
> On Jun 10, 2013, at 4:21 PM, Michael Barton wrote:
> 
>> I just installed wxPython 2.9.0.4 for Python 2.6 (for backward compatibility 
>> with Snow Leopard). It razed an error on configuration. In checking, here is 
>> what I get.
>> 
>> /usr/local/lib/wxPython-2.9.4.0/bin/wx-config --list
>> 
>>   Default config is osx_carbon-unicode-2.9
>> 
>> No config found to match: 
>> /usr/local/lib/wxPython-2.9.4.0/bin/wx-config --list
>> in /usr/local/lib/wxPython-2.9.4.0/lib/wx/config
>> 
>> Please install the desired library build, or specify a different
>> prefix where it may be found.  If the library is not installed
>> you may call its wx-config directly by specifying its full path.
>> 
>> 
>> Also available in /usr/local/lib/wxPython-2.9.4.0:
>>   osx_carbon-unicode-2.9
>> 
>> 
>> Any idea what is wrong? 
>> 
>> MUST I use wxPython 2.9 ONLY with Python 2.7??? That means no more Snow 
>> Leopard compatibility.
>> 
>> Michael
>> __
>> C. Michael Barton 
>> Director, Center for Social Dynamics & Complexity
>> Professor of Anthropology, School of Human Evolution & Social Change
>> Arizona State University
>> Tempe, AZ  85287-2402
>> USA
>> 
>> voice:   480-965-6262 (SHESC), 480-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 Jun 7, 2013, at 8:39 PM, William Kyngesburye  
>> wrote:
>> 
>>> I just compiled trunk, no compile errors, and GUI runs fine.
>>> 
>>> OSX 10.7 Lion, Xcode 4.6.2 command line tools, wxPython 2.9.4
>>> 
>>> I'm a bit lost now - what is the status of this, what is the current 
>>> problem?
>>> 
>>> On Jun 7, 2013, at 10:28 AM, Michael Barton wrote:
>>> 
 Maybe it is PYTHONPATH

 BUT...

 Python and the GUI is compiling and working just fine otherwise. And 
 Python runs with no problem in the terminal.

 The bogus errors for compiling mapswipe, composer, etc first appeared with 
 what I think was the introduction of a new window class for these modules. 
 I have not seen the toolbox, but it may reuse the same code. If I knew 
 what this new code is, I might be able to troubleshoot it. But I don't 
 have time to try to reverse engineer it without guidance as to where to 
 look. The error on importing wx is misleading as to what the real error 
 is. 

 I can't say for sure that these are all related (and the error is indeed 
 somewhat different for the toolbox compilation). But it seems a reasonable 
 place to start.

 If it IS a PYTHONPATH problem, then the code for building the toolbox is 
 somehow ignoring PYTHONPATH because this is set properly otherwise.

>>> 
> On Thu, Jun 6, 2013 at 7:16 PM, Michael Barton  
> wrote:
> Anna,
> 
> This is from the log. It looks to me like a path problem during 
> compilation
> 
> Traceback (most recent call last):
> File "tools/build_modules_xml.py", line 85, in 
>  sys.exit(main())
> File "tools/build_modules_xml.py", line 77, in main
>  header(fh)
> File "tools/build_modules_xml.py", line 58, in header
>  import grass.script.core as grass
> ImportError: No module named grass.script.core
> make[1]: *** 
> [/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.3.0/etc/gui/wxpython/xml/module_items.xml]
>  Error 1
> make: [defa

Re: [GRASS-dev] GRASS 7 crashes on startup on Mac

2013-06-10 Thread Michael Barton

I'm still not sure why we need wxPython 2.9 for the toolbox. Is it coded with a 
wxPython 2.9 specific code?

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

voice:  480-965-6262 (SHESC), 480-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 Jun 10, 2013, at 2:41 PM, William Kyngesburye 
 wrote:

> I think we're probably at a point of not being able to do a single binary 
> package for both Snow and Lion+ - too many differences.  It's not quite 
> possible to install both 2.9 carbon for Python 2.6 and 2.9 cocoa for Python 
> 2.7 - while the python parts are separate, the C library parts of one will 
> overwrite the other, and they are probably not compatible.
> 
> The way I handle it is to compile wxpython myself.  I can install each in 
> completely separate locations and reference whichever I need for Snow or Lion 
> builds.  BUT, I haven't tried this yet for 2.9 carbon ON lion, I may have to 
> also compile wxpython 2.9 carbon on Snow (and maybe even GRASS).
> 
> On Jun 10, 2013, at 4:21 PM, Michael Barton wrote:
> 
>> I just installed wxPython 2.9.0.4 for Python 2.6 (for backward compatibility 
>> with Snow Leopard). It razed an error on configuration. In checking, here is 
>> what I get.
>> 
>> /usr/local/lib/wxPython-2.9.4.0/bin/wx-config --list
>> 
>>   Default config is osx_carbon-unicode-2.9
>> 
>> No config found to match: 
>> /usr/local/lib/wxPython-2.9.4.0/bin/wx-config --list
>> in /usr/local/lib/wxPython-2.9.4.0/lib/wx/config
>> 
>> Please install the desired library build, or specify a different
>> prefix where it may be found.  If the library is not installed
>> you may call its wx-config directly by specifying its full path.
>> 
>> 
>> Also available in /usr/local/lib/wxPython-2.9.4.0:
>>   osx_carbon-unicode-2.9
>> 
>> 
>> Any idea what is wrong? 
>> 
>> MUST I use wxPython 2.9 ONLY with Python 2.7??? That means no more Snow 
>> Leopard compatibility.
>> 
>> Michael
>> __
>> C. Michael Barton 
>> Director, Center for Social Dynamics & Complexity
>> Professor of Anthropology, School of Human Evolution & Social Change
>> Arizona State University
>> Tempe, AZ  85287-2402
>> USA
>> 
>> voice:   480-965-6262 (SHESC), 480-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 Jun 7, 2013, at 8:39 PM, William Kyngesburye  
>> wrote:
>> 
>>> I just compiled trunk, no compile errors, and GUI runs fine.
>>> 
>>> OSX 10.7 Lion, Xcode 4.6.2 command line tools, wxPython 2.9.4
>>> 
>>> I'm a bit lost now - what is the status of this, what is the current 
>>> problem?
>>> 
>>> On Jun 7, 2013, at 10:28 AM, Michael Barton wrote:
>>> 
 Maybe it is PYTHONPATH
 
 BUT...
 
 Python and the GUI is compiling and working just fine otherwise. And 
 Python runs with no problem in the terminal.
 
 The bogus errors for compiling mapswipe, composer, etc first appeared with 
 what I think was the introduction of a new window class for these modules. 
 I have not seen the toolbox, but it may reuse the same code. If I knew 
 what this new code is, I might be able to troubleshoot it. But I don't 
 have time to try to reverse engineer it without guidance as to where to 
 look. The error on importing wx is misleading as to what the real error 
 is. 
 
 I can't say for sure that these are all related (and the error is indeed 
 somewhat different for the toolbox compilation). But it seems a reasonable 
 place to start.
 
 If it IS a PYTHONPATH problem, then the code for building the toolbox is 
 somehow ignoring PYTHONPATH because this is set properly otherwise.
 
>>> 
> On Thu, Jun 6, 2013 at 7:16 PM, Michael Barton  
> wrote:
> Anna,
> 
> This is from the log. It looks to me like a path problem during 
> compilation
> 
> Traceback (most recent call last):
> File "tools/build_modules_xml.py", line 85, in 
>  sys.exit(main())
> File "tools/build_modules_xml.py", line 77, in main
>  header(fh)
> File "tools/build_modules_xml.py", line 58, in header
>  import grass.script.core as grass
> ImportError: No module named grass.script.core
> make[1]: *** 
> [/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.3.0/etc/gui/wxpython/xml/module_items.xml]
>  Error 1
> make: [default] Error 2 (ignored)
> make xml/menudata.xml
> make[1]: `xml/menudata.xml' is up to date.
> make menustrings.py
> 
> The other bogus errors on "No module named

Re: [GRASS-dev] GRASS 7 crashes on startup on Mac

2013-06-10 Thread Michael Barton

Is GRASS 7 running for you with wxPython 2.9 for Python 2.7?

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

voice:  480-965-6262 (SHESC), 480-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 Jun 10, 2013, at 2:41 PM, William Kyngesburye 
 wrote:

> I think we're probably at a point of not being able to do a single binary 
> package for both Snow and Lion+ - too many differences.  It's not quite 
> possible to install both 2.9 carbon for Python 2.6 and 2.9 cocoa for Python 
> 2.7 - while the python parts are separate, the C library parts of one will 
> overwrite the other, and they are probably not compatible.
> 
> The way I handle it is to compile wxpython myself.  I can install each in 
> completely separate locations and reference whichever I need for Snow or Lion 
> builds.  BUT, I haven't tried this yet for 2.9 carbon ON lion, I may have to 
> also compile wxpython 2.9 carbon on Snow (and maybe even GRASS).
> 
> On Jun 10, 2013, at 4:21 PM, Michael Barton wrote:
> 
>> I just installed wxPython 2.9.0.4 for Python 2.6 (for backward compatibility 
>> with Snow Leopard). It razed an error on configuration. In checking, here is 
>> what I get.
>> 
>> /usr/local/lib/wxPython-2.9.4.0/bin/wx-config --list
>> 
>>   Default config is osx_carbon-unicode-2.9
>> 
>> No config found to match: 
>> /usr/local/lib/wxPython-2.9.4.0/bin/wx-config --list
>> in /usr/local/lib/wxPython-2.9.4.0/lib/wx/config
>> 
>> Please install the desired library build, or specify a different
>> prefix where it may be found.  If the library is not installed
>> you may call its wx-config directly by specifying its full path.
>> 
>> 
>> Also available in /usr/local/lib/wxPython-2.9.4.0:
>>   osx_carbon-unicode-2.9
>> 
>> 
>> Any idea what is wrong? 
>> 
>> MUST I use wxPython 2.9 ONLY with Python 2.7??? That means no more Snow 
>> Leopard compatibility.
>> 
>> Michael
>> __
>> C. Michael Barton 
>> Director, Center for Social Dynamics & Complexity
>> Professor of Anthropology, School of Human Evolution & Social Change
>> Arizona State University
>> Tempe, AZ  85287-2402
>> USA
>> 
>> voice:   480-965-6262 (SHESC), 480-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 Jun 7, 2013, at 8:39 PM, William Kyngesburye  
>> wrote:
>> 
>>> I just compiled trunk, no compile errors, and GUI runs fine.
>>> 
>>> OSX 10.7 Lion, Xcode 4.6.2 command line tools, wxPython 2.9.4
>>> 
>>> I'm a bit lost now - what is the status of this, what is the current 
>>> problem?
>>> 
>>> On Jun 7, 2013, at 10:28 AM, Michael Barton wrote:
>>> 
 Maybe it is PYTHONPATH
 
 BUT...
 
 Python and the GUI is compiling and working just fine otherwise. And 
 Python runs with no problem in the terminal.
 
 The bogus errors for compiling mapswipe, composer, etc first appeared with 
 what I think was the introduction of a new window class for these modules. 
 I have not seen the toolbox, but it may reuse the same code. If I knew 
 what this new code is, I might be able to troubleshoot it. But I don't 
 have time to try to reverse engineer it without guidance as to where to 
 look. The error on importing wx is misleading as to what the real error 
 is. 
 
 I can't say for sure that these are all related (and the error is indeed 
 somewhat different for the toolbox compilation). But it seems a reasonable 
 place to start.
 
 If it IS a PYTHONPATH problem, then the code for building the toolbox is 
 somehow ignoring PYTHONPATH because this is set properly otherwise.
 
>>> 
> On Thu, Jun 6, 2013 at 7:16 PM, Michael Barton  
> wrote:
> Anna,
> 
> This is from the log. It looks to me like a path problem during 
> compilation
> 
> Traceback (most recent call last):
> File "tools/build_modules_xml.py", line 85, in 
>  sys.exit(main())
> File "tools/build_modules_xml.py", line 77, in main
>  header(fh)
> File "tools/build_modules_xml.py", line 58, in header
>  import grass.script.core as grass
> ImportError: No module named grass.script.core
> make[1]: *** 
> [/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.3.0/etc/gui/wxpython/xml/module_items.xml]
>  Error 1
> make: [default] Error 2 (ignored)
> make xml/menudata.xml
> make[1]: `xml/menudata.xml' is up to date.
> make menustrings.py
> 
> The other bogus errors on "No module named wx" also seems like a path 
> problem.
>

Re: [GRASS-dev] GRASS 7 crashes on startup on Mac

2013-06-10 Thread William Kyngesburye

I think we're probably at a point of not being able to do a single binary 
package for both Snow and Lion+ - too many differences.  It's not quite 
possible to install both 2.9 carbon for Python 2.6 and 2.9 cocoa for Python 2.7 
- while the python parts are separate, the C library parts of one will 
overwrite the other, and they are probably not compatible.

The way I handle it is to compile wxpython myself.  I can install each in 
completely separate locations and reference whichever I need for Snow or Lion 
builds.  BUT, I haven't tried this yet for 2.9 carbon ON lion, I may have to 
also compile wxpython 2.9 carbon on Snow (and maybe even GRASS).

On Jun 10, 2013, at 4:21 PM, Michael Barton wrote:

> I just installed wxPython 2.9.0.4 for Python 2.6 (for backward compatibility 
> with Snow Leopard). It razed an error on configuration. In checking, here is 
> what I get.
> 
> /usr/local/lib/wxPython-2.9.4.0/bin/wx-config --list
> 
>Default config is osx_carbon-unicode-2.9
> 
>  No config found to match: 
> /usr/local/lib/wxPython-2.9.4.0/bin/wx-config --list
>  in /usr/local/lib/wxPython-2.9.4.0/lib/wx/config
> 
>  Please install the desired library build, or specify a different
>  prefix where it may be found.  If the library is not installed
>  you may call its wx-config directly by specifying its full path.
> 
> 
>  Also available in /usr/local/lib/wxPython-2.9.4.0:
>osx_carbon-unicode-2.9
> 
> 
> Any idea what is wrong? 
> 
> MUST I use wxPython 2.9 ONLY with Python 2.7??? That means no more Snow 
> Leopard compatibility.
> 
> Michael
> __
> C. Michael Barton 
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Arizona State University
> Tempe, AZ  85287-2402
> USA
> 
> voice:480-965-6262 (SHESC), 480-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 Jun 7, 2013, at 8:39 PM, William Kyngesburye  wrote:
> 
>> I just compiled trunk, no compile errors, and GUI runs fine.
>> 
>> OSX 10.7 Lion, Xcode 4.6.2 command line tools, wxPython 2.9.4
>> 
>> I'm a bit lost now - what is the status of this, what is the current problem?
>> 
>> On Jun 7, 2013, at 10:28 AM, Michael Barton wrote:
>> 
>>> Maybe it is PYTHONPATH
>>> 
>>> BUT...
>>> 
>>> Python and the GUI is compiling and working just fine otherwise. And Python 
>>> runs with no problem in the terminal.
>>> 
>>> The bogus errors for compiling mapswipe, composer, etc first appeared with 
>>> what I think was the introduction of a new window class for these modules. 
>>> I have not seen the toolbox, but it may reuse the same code. If I knew what 
>>> this new code is, I might be able to troubleshoot it. But I don't have time 
>>> to try to reverse engineer it without guidance as to where to look. The 
>>> error on importing wx is misleading as to what the real error is. 
>>> 
>>> I can't say for sure that these are all related (and the error is indeed 
>>> somewhat different for the toolbox compilation). But it seems a reasonable 
>>> place to start.
>>> 
>>> If it IS a PYTHONPATH problem, then the code for building the toolbox is 
>>> somehow ignoring PYTHONPATH because this is set properly otherwise.
>>> 
>> 
 On Thu, Jun 6, 2013 at 7:16 PM, Michael Barton  
 wrote:
 Anna,
 
 This is from the log. It looks to me like a path problem during compilation
 
 Traceback (most recent call last):
 File "tools/build_modules_xml.py", line 85, in 
   sys.exit(main())
 File "tools/build_modules_xml.py", line 77, in main
   header(fh)
 File "tools/build_modules_xml.py", line 58, in header
   import grass.script.core as grass
 ImportError: No module named grass.script.core
 make[1]: *** 
 [/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.3.0/etc/gui/wxpython/xml/module_items.xml]
  Error 1
 make: [default] Error 2 (ignored)
 make xml/menudata.xml
 make[1]: `xml/menudata.xml' is up to date.
 make menustrings.py
 
 The other bogus errors on "No module named wx" also seems like a path 
 problem.
 
 yes, problem might be in PYTHONPATH. Could you ask about this William? I 
 have currently no time and I am probably not able to solve this.
 
 Regards,
 
 Anna 
>> 
 On Jun 6, 2013, at 2:39 AM, Anna Petrášová  wrote:
 
> Hi, Michael,
> 
> 
> On Wed, Jun 5, 2013 at 11:45 PM, Michael Barton  
> wrote:
> OK. I did this remotely but hopefully it is what you need.
> 
> yes, perfect, thanks. Could you try the compilation again with the change 
> William did recently (demolocation probem, [1])? It might be related 
> because from the errors in the log it seems that the virtual grass 
> session is not there. If the pro

Re: [GRASS-dev] Unexpected EVI range from "i.vi"

2013-06-10 Thread Markus Neteler

Hi Nikos,

if you have a i.landsat.toar corrected scene, please extract the values for

- water pixel
- green vegetation
- asphalt

... all bands except for TIR.

I want then to synthetic channels of one pixel to do
the i.vi testing:

# prepare comp. region
g.region rast=lsat7_2002_10 rows=1 cols=1 -p

# create synthetic channels (for the letters, we need your values)
r.mapcalc "water_b7 = aa"
r.mapcalc "water_b5 = bb"
r.mapcalc "water_b4 = cc"
r.mapcalc "water_b3 = dd"
r.mapcalc "water_b2 = ee"
r.mapcalc "water_b1 = ff"

Likewise for the other "landuses". This allows us to create a tiny test
environment to check the output. I am just lacking a prepared Landsat
scene (and the time to process it). Since you already have it, you may
extract the values easily with r.what or the wxGUI.

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

Re: [GRASS-dev] GRASS 7 crashes on startup on Mac

2013-06-10 Thread Michael Barton

I just installed wxPython 2.9.0.4 for Python 2.6 (for backward compatibility 
with Snow Leopard). It razed an error on configuration. In checking, here is 
what I get.

/usr/local/lib/wxPython-2.9.4.0/bin/wx-config --list

Default config is osx_carbon-unicode-2.9

  No config found to match: 
/usr/local/lib/wxPython-2.9.4.0/bin/wx-config --list
  in /usr/local/lib/wxPython-2.9.4.0/lib/wx/config

  Please install the desired library build, or specify a different
  prefix where it may be found.  If the library is not installed
  you may call its wx-config directly by specifying its full path.


  Also available in /usr/local/lib/wxPython-2.9.4.0:
osx_carbon-unicode-2.9


Any idea what is wrong? 

MUST I use wxPython 2.9 ONLY with Python 2.7??? That means no more Snow Leopard 
compatibility.

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

voice:  480-965-6262 (SHESC), 480-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 Jun 7, 2013, at 8:39 PM, William Kyngesburye  wrote:

> I just compiled trunk, no compile errors, and GUI runs fine.
> 
> OSX 10.7 Lion, Xcode 4.6.2 command line tools, wxPython 2.9.4
> 
> I'm a bit lost now - what is the status of this, what is the current problem?
> 
> On Jun 7, 2013, at 10:28 AM, Michael Barton wrote:
> 
>> Maybe it is PYTHONPATH
>> 
>> BUT...
>> 
>> Python and the GUI is compiling and working just fine otherwise. And Python 
>> runs with no problem in the terminal.
>> 
>> The bogus errors for compiling mapswipe, composer, etc first appeared with 
>> what I think was the introduction of a new window class for these modules. I 
>> have not seen the toolbox, but it may reuse the same code. If I knew what 
>> this new code is, I might be able to troubleshoot it. But I don't have time 
>> to try to reverse engineer it without guidance as to where to look. The 
>> error on importing wx is misleading as to what the real error is. 
>> 
>> I can't say for sure that these are all related (and the error is indeed 
>> somewhat different for the toolbox compilation). But it seems a reasonable 
>> place to start.
>> 
>> If it IS a PYTHONPATH problem, then the code for building the toolbox is 
>> somehow ignoring PYTHONPATH because this is set properly otherwise.
>> 
> 
>>> On Thu, Jun 6, 2013 at 7:16 PM, Michael Barton  
>>> wrote:
>>> Anna,
>>> 
>>> This is from the log. It looks to me like a path problem during compilation
>>> 
>>> Traceback (most recent call last):
>>>  File "tools/build_modules_xml.py", line 85, in 
>>>sys.exit(main())
>>>  File "tools/build_modules_xml.py", line 77, in main
>>>header(fh)
>>>  File "tools/build_modules_xml.py", line 58, in header
>>>import grass.script.core as grass
>>> ImportError: No module named grass.script.core
>>> make[1]: *** 
>>> [/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.3.0/etc/gui/wxpython/xml/module_items.xml]
>>>  Error 1
>>> make: [default] Error 2 (ignored)
>>> make xml/menudata.xml
>>> make[1]: `xml/menudata.xml' is up to date.
>>> make menustrings.py
>>> 
>>> The other bogus errors on "No module named wx" also seems like a path 
>>> problem.
>>> 
>>> yes, problem might be in PYTHONPATH. Could you ask about this William? I 
>>> have currently no time and I am probably not able to solve this.
>>> 
>>> Regards,
>>> 
>>> Anna 
> 
>>> On Jun 6, 2013, at 2:39 AM, Anna Petrášová  wrote:
>>> 
 Hi, Michael,
 
 
 On Wed, Jun 5, 2013 at 11:45 PM, Michael Barton  
 wrote:
 OK. I did this remotely but hopefully it is what you need.
 
 yes, perfect, thanks. Could you try the compilation again with the change 
 William did recently (demolocation probem, [1])? It might be related 
 because from the errors in the log it seems that the virtual grass session 
 is not there. If the problem is still there, please send me updated 
 compilation log.
 
 Thanks,
 Anna
 
 
 [1] https://trac.osgeo.org/grass/changeset/56621 
 
> 
> -
> William Kyngesburye 
> http://www.kyngchaos.com/
> 
> "The beast is actively interested only in now, and, as it is always now and 
> always shall be, there is an eternity of time for the accomplishment of 
> objects."
> 
> - the wisdom of Tarzan
> 
> 
> 
> 
> 

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

Re: [GRASS-dev] [GRASS GIS] #943: wxpython gui hangs after switching to cairo display driver

2013-06-10 Thread GRASS GIS

#943: wxpython gui hangs after switching to cairo display driver
--+-
 Reporter:  epatton   |   Owner:  grass-dev@…   
   
 Type:  defect|  Status:  new   
   
 Priority:  critical  |   Milestone:  6.4.3 
   
Component:  wxGUI | Version:  svn-develbranch6  
   
 Keywords:  cairo, driver, gui, wxpython  |Platform:  Linux 
   
  Cpu:  All   |  
--+-

Comment(by hamish):

 it looks like the fix will need to be in d.mon. That's not something I
 want to risk breaking just before release, as it's too critical a
 component.

 cairo driver support from the wxGUI commented out in 6.4svn r56679 so we
 can move forward with the release. Will continue to try and get it working
 in devbr6.


 tbc,
 Hamish

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] bug in vector network analysis node costs

2013-06-10 Thread Štěpán Turek

Hi all,




Probably I found bug in nodes cost in vector network analysis (tested in G7,
probably it affects all branches). Problem is in lib/vector/Vlib/net.c:




int cost;

...

(* dglInt32_t)(dglInt32_t) & cost





int cost is cast into dglInt32_t pointer. DGLib dglInt32_t is long.  I am 
relatively new to C so I do not understand the way it is casted and I can 
miss something. I am reading it as cast address of  cost int to  dglInt32_t 
and then to pointer to dglInt32_t. It does not make sense to me but it 
compiles :-) 




The problem is when you have on your system different size of long and int, 
it is probably also the reason why it was not noticed so far (on 32 bit 
usually sizeof(int) == sizeof(long)). Because it seems that during this cast
there are added bytes to be same size as long. However these bytes have 
random values and therefore results costs do not make sense. 




If this change is made everything seems ok:




dglInt32_t dgl_cost;

...

dgl_cost = cost;


dglNodeSet_Attr(gr, dglGetNode(gr, (dglInt32_t) cat),


& dgl_cost);







Now there is:





dglNodeSet_Attr(gr, dglGetNode(gr, (dglInt32_t) cat),


(* dglInt32_t)(dglInt32_t) & cost);





I have attached also patch.




Best

Stepan


nodes_costs.diff
Description: Binary data
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] trouble compiling v.in.ogr + math.h (all branches)

2013-06-10 Thread Markus Metz

On Mon, Jun 10, 2013 at 3:11 PM, Glynn Clements
 wrote:
>
> I'd suggest using:
>
> int exp;
> new_snap = frexp(xmax, &exp);
> exp -= 52;
> new_snap = ldexp(new_snap, exp);
>
> frexp() and ldexp() are C89, don't introduce rounding errors, and
> handle zero correctly (they're also likely to be more efficient, but
> that's a trivial detail).

Thanks for the suggestion, done in all branches.

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

Re: [GRASS-dev] compilation of grass on AIX 7.1

2013-06-10 Thread Markus Neteler

Hi,

some news:
- install-sh update done in r56675, working

- diglib test updated in lib/vector/diglib/
--> still failing there, we try to understand

- ps/ps.map/ done by Hamish

- SQLite I have recompiled like this, now accepted ok!
./configure \
  --prefix=$PREFIX \
  --disable-shared \
  --disable-threadsafe \
  --disable-tcl

> /gpfs/home/neteler/software/grass-7.0.svn/lib/rst/interp_float
> /gpfs/home/neteler/software/grass-7.0.svn/raster/r.resamp.rst
> /gpfs/home/neteler/software/grass-7.0.svn/vector/v.surf.rst
> /gpfs/home/neteler/software/grass-7.0.svn/vector/v.vol.rst
--> AIX namespace pollution to be investigated

> /gpfs/home/neteler/software/grass-7.0.svn/db/drivers/ogr
...
--> the missing -lstdc++ to be understood...

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

Re: [GRASS-dev] compilation of grass on AIX 7.1

2013-06-10 Thread Markus Neteler

On Mon, Jun 10, 2013 at 3:41 PM, Glynn Clements
 wrote:
...
> I suspect that GDALLIBS should include -lstdc++. That's arguably a bug
> in the gdal-config script. In practice it will only matter if GDAL is
> a static library; shared libraries record their dependencies.


checking for gdal-config... /gpfs/home/neteler/bin//bin/gdal-config
configure: error: *** Unable to locate GDAL library.

config.log:
configure:6079: checking for gdal-config
configure:6141: gcc -o conftest -g -O2
-I/gpfs/home/neteler/bin/includeconftest.c  -lc
-L/gpfs/home/neteler/bin/lib -lgdal 1>&5
configure: In function 'main':
configure:6137:9: warning: ignoring return value of 'GDALOpen',
declared with attribute warn_unused_result [-Wunused-result]
ld: 0711-224 WARNING: Duplicate symbol: .strndup
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
ld: 0711-317 ERROR: Undefined symbol: vtable for
__cxxabiv1::__si_class_type_info
ld: 0711-317 ERROR: Undefined symbol: vtable for __cxxabiv1::__class_type_info
ld: 0711-317 ERROR: Undefined symbol: __gxx_personality_v0
ld: 0711-317 ERROR: Undefined symbol: __cxa_pure_virtual
ld: 0711-317 ERROR: Undefined symbol: .operator delete(void*)
ld: 0711-317 ERROR: Undefined symbol: std::basic_string, std::allocator
>::_Rep::_S_empty_rep_storage
ld: 0711-317 ERROR: Undefined symbol: .std::basic_string, std::allocator
>::_Rep::_M_destroy(std::allocator const&)
ld: 0711-317 ERROR: Undefined symbol: .std::basic_string, std::allocator >::~basic_string()
ld: 0711-317 ERROR: Undefined symbol: .std::basic_string, std::allocator >::_M_leak_hard()
ld: 0711-317 ERROR: Undefined symbol: .std::basic_string, std::allocator >::basic_string(char
const*, std::allocator
...

I configured GDAL like this:
export LIBICONV=/opt/freeware
export CC="gcc"
export CXX="g++"
PREFIX=$HOME/bin
CFLAGS='-DHAVE_INTTYPES_H=0' ./configure \
 --prefix=$PREFIX --with-libz=internal --with-threads=no
--with-geotiff=internal --with-libtiff=internal

ls ~/bin/lib/
gdalpluginslibgdal.a  libgdal.la libproj.a  libproj.la
libsqlite3.a   libsqlite3.la  pkgconfig

So it is all static on AIX.

No idea how to get -lstdc++ in here/GRASS.

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

[GRASS-dev] sample implimentation for upcoming OGC geopackage standard

2013-06-10 Thread Newcomb, Doug

Hi Folks,
One of the entities working on the proposed OGC geopackage standard has
some sample code out under the Apache 2. License.  Uses sqlite.

https://bitbucket.org/luciad/libgpkg




Doug

-- 
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-
The opinions I express are my own and are not representative of the
official policy of the U.S.Fish and Wildlife Service or Dept. of the
Interior.   Life is too short for undocumented, proprietary data formats.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] compilation of grass on AIX 7.1

2013-06-10 Thread Glynn Clements

Markus Neteler wrote:

> diff OBJ.powerpc-ibm-aix7.1.0.0/test.tmp test64.ok
> diff: Missing newline at the end of file OBJ.powerpc-ibm-aix7.1.0.0/test.tmp.
> diff: Missing newline at the end of file test64.ok.

Using cmp (as per r56674) is the right thing to do here.

> cd /gpfs/home/neteler/software/grass-7.0.svn/lib/rst/interp_float/

> point2d.c: In function 'IL_check_at_points_2d':
> point2d.c:54:43: error: expected identifier or '(' before numeric constant

Yet more AIX namespace pollution.

The only long-term solution to this problem is to figure out what else
is required to get GRASS to compile with e.g. -std=c89 or -std=c99. I
thought that we'd solved this already (other than what to do about the
TIOCGWINSZ issue in lib/gis/ls.c).

Renaming variables to avoid conflicts will be a never-ending game of
Whac-a-Mole.

> cd /gpfs/home/neteler/software/grass-7.0.svn/db/drivers/sqlite

> ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_unlock
> ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_trylock
...

Something (probably SQLite) needs -lpthread, but it isn't present in
the link command. I don't know why the configure check succeeded.

> -bash-3.2$ cd /gpfs/home/neteler/software/grass-7.0.svn/db/drivers/ogr

> : && gcc 
> -L/gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/lib

> ld: 0711-317 ERROR: Undefined symbol: vtable for __cxxabiv1::__class_type_info

> --> I see that   -lstdc++ is missing?!

> -bash-3.2$ grep stdc include/Make/Platform.make
> CFLAGS  = -lstdc++

WTF? -l switches don't belong in CFLAGS.

> It also comes up here:
> 
> -bash-3.2$ cd /gpfs/home/neteler/software/grass-7.0.svn/display/d.grid

> ld: 0711-317 ERROR: Undefined symbol: typeinfo for std::exception

> --> I see that   -lstdc++ is missing.

Probably due to GDAL, pulled in by GPROJDEPS.

> The same applies to
...

I suspect that GDALLIBS should include -lstdc++. That's arguably a bug
in the gdal-config script. In practice it will only matter if GDAL is
a static library; shared libraries record their dependencies.

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

Re: [GRASS-dev] trouble compiling v.in.ogr + math.h (all branches)

2013-06-10 Thread Glynn Clements


Hamish wrote:

> when I try to compile a fresh check out of 6.4.3svn on an older
> system (glibc 2.3.6) I get this error from v.in.ogr:
> 
> main.c: In function 'main':
> main.c:1208: error: implicit declaration of function 'log2'
> main.c:1208: warning: incompatible implicit declaration of built-in function 
> 'log2'
> 
> 
> I thought it was because #include  was missing (for pow()
> and log10() too), but after adding that I still get the error.
> 
> It turns out I need to add -std=c99 to the gcc line to get it
> to work, but the glibc man page for log2() has it conforming to
> SVr4, 4.3BSD, C89.

Huh? On my system, the log2 manual page says:

CONFORMING TO
   C99, POSIX.1-2001. The variant returning double also conforms
   to SVr4, 4.3BSD.

> maybe I could replace it with a log()/log() trick, but would
> pow() and log10() also be broken?

pow() and log10() are C89. As is exp2(), FWIW.

But if you're planning on replacing this:

new_snap = log2(xmax) - 52;
new_snap = pow(2, new_snap);

I'd suggest using:

int exp;
new_snap = frexp(xmax, &exp);
exp -= 52;
new_snap = ldexp(new_snap, exp);

frexp() and ldexp() are C89, don't introduce rounding errors, and
handle zero correctly (they're also likely to be more efficient, but
that's a trivial detail).

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

Re: [GRASS-dev] [GRASS GIS] #2002: The ordinal 32 could not be located in the dynamic link library proj.dll

2013-06-10 Thread GRASS GIS

#2002: The ordinal 32 could not be located in the dynamic link library proj.dll
---+
  Reporter:  rezagrass |   Owner:  grass-dev@…  
  Type:  task  |  Status:  closed   
  Priority:  critical  |   Milestone:  6.4.4
 Component:  Python| Version:  6.4.2
Resolution:  invalid   |Keywords:  wingrass 
  Platform:  MSWindows XP  | Cpu:  x86-64   
---+
Changes (by neteler):

  * status:  new => closed
  * resolution:  => invalid


Comment:

 Glad you solved it. I have extended the Wiki page accordingly:
 http://grasswiki.osgeo.org/wiki/WinGRASS_errors

 Closing as invalid since no action item for the GRASS GIS package
 but duplicated DLLs at user side.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2002: The ordinal 32 could not be located in the dynamic link library proj.dll

2013-06-10 Thread GRASS GIS

#2002: The ordinal 32 could not be located in the dynamic link library proj.dll
---+
 Reporter:  rezagrass  |   Owner:  grass-dev@…  
 Type:  task   |  Status:  new  
 Priority:  critical   |   Milestone:  6.4.4
Component:  Python | Version:  6.4.2
 Keywords:  wingrass   |Platform:  MSWindows XP 
  Cpu:  x86-64 |  
---+

Comment(by rezagrass):

 Thanks for the reference to the grasswiki page, where I found the
 suggestion. I tried the same and it worked.

 While I have kept a back up of the old .dll files in my system32
 directory, I am not sure whether or not the updated dll files may affect
 other programs already using them!

 Thanks and regards,
 Reza

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2002: The ordinal 32 could not be located in the dynamic link library proj.dll

2013-06-10 Thread GRASS GIS

#2002: The ordinal 32 could not be located in the dynamic link library proj.dll
---+
 Reporter:  rezagrass  |   Owner:  grass-dev@…  
 Type:  task   |  Status:  new  
 Priority:  critical   |   Milestone:  6.4.4
Component:  Python | Version:  6.4.2
 Keywords:  wingrass   |Platform:  MSWindows XP 
  Cpu:  x86-64 |  
---+
Changes (by neteler):

  * keywords:  => wingrass


Comment:

 This error sounds similar to:

 http://grasswiki.osgeo.org/wiki/WinGRASS_errors

 Q: Error message "The ordinal 63 could not be located in the dynamic link
 libexpat.dll."

 Perhaps a similar solution applies here?

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #2002: The ordinal 32 could not be located in the dynamic link library proj.dll

2013-06-10 Thread GRASS GIS

#2002: The ordinal 32 could not be located in the dynamic link library proj.dll
---+
 Reporter:  rezagrass  |   Owner:  grass-dev@…  
 Type:  task   |  Status:  new  
 Priority:  critical   |   Milestone:  6.4.4
Component:  Python | Version:  6.4.2
 Keywords: |Platform:  MSWindows XP 
  Cpu:  x86-64 |  
---+
 I have successfully installed the GRASS 6.4.2 on my Windows XP SP3.

 I have already a python24 installed. On the 'Welcome to GRASS' box at the
 start up, every time I press 'Start Grass' button, an error message pops
 up reading: "The ordinal 32 could not be located in the dynamic link
 library proj.dll"

 Would you please advise on a solution. It is greatly appreciated.

 Thanks
 Reza

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] GRASS 7 crashes on startup on Mac

Re: [GRASS-dev] GRASS 7 crashes on startup on Mac

Re: [GRASS-dev] GRASS 7 crashes on startup on Mac

Re: [GRASS-dev] GRASS 7 crashes on startup on Mac

Re: [GRASS-dev] GRASS 7 crashes on startup on Mac

Re: [GRASS-dev] Unexpected EVI range from "i.vi"

Re: [GRASS-dev] GRASS 7 crashes on startup on Mac

Re: [GRASS-dev] [GRASS GIS] #943: wxpython gui hangs after switching to cairo display driver

[GRASS-dev] bug in vector network analysis node costs

Re: [GRASS-dev] trouble compiling v.in.ogr + math.h (all branches)

Re: [GRASS-dev] compilation of grass on AIX 7.1

Re: [GRASS-dev] compilation of grass on AIX 7.1

[GRASS-dev] sample implimentation for upcoming OGC geopackage standard

Re: [GRASS-dev] compilation of grass on AIX 7.1

Re: [GRASS-dev] trouble compiling v.in.ogr + math.h (all branches)

Re: [GRASS-dev] [GRASS GIS] #2002: The ordinal 32 could not be located in the dynamic link library proj.dll

Re: [GRASS-dev] [GRASS GIS] #2002: The ordinal 32 could not be located in the dynamic link library proj.dll

Re: [GRASS-dev] [GRASS GIS] #2002: The ordinal 32 could not be located in the dynamic link library proj.dll

[GRASS-dev] [GRASS GIS] #2002: The ordinal 32 could not be located in the dynamic link library proj.dll

19 matches

Site Navigation

Mail list logo

Footer information