Re: [GRASS-dev] GRASS 7.1 trunk still will not compile on Mac

[Michael Barton]

Anna,

OK.I will post it so it can be tried. In quick tests, the only issue I ran into 
was that the display window menu button bar did not refresh properly when going 
from 3D back to 2D, and clicking one of the messed up buttons caused the GUI to 
crash. There may well be other things, but they should be all GUI related.

I will also try one more time to compile 7.1 using the config string that 
worked in December 2015 and this week with v.7.0.4RC1. If I can get it to work, 
I will post that too. But I've failed several times on that front. 

Cheers
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 Apr 21, 2016, at 5:53 PM, Anna Petrášová  wrote:
> 
> On Thu, Apr 21, 2016 at 7:15 PM, Michael Barton  
> wrote:
>> I tried today to compile GRASS 7.1 on the Mac using ONLY 64 bit
>> architecture, instead of the dual 32/64 bit hack I've been using for the
>> past several years. It compiled fine. But it requires using 64bit wxPython
>> 3.0.2.0. This wxPython 3 GUI mostly works but still has some glitches.
>> 
>> So here are a few questions.
>> 
>> 1. Was there some change so that GRASS 7.1 now only compiles 64 bit? It
>> compiled with dual architecture in early December 2015 but I have been
>> unable to get to compile with the same config string since then.
>> 
> no changes I know of
> 
>> 2. If it is only 64 bit now, it seems that there needs to be some tweaking
>> on the GUI. Are we ready to move to wxPython 3.x and deal with that? If so,
>> I can easily start to compile 7.0 in 64 bit when those are ironed out.
> 
> It seems we don't have much choice, we can't use 2.8 forever,
> especially if it's causing so much troubles for compilation. If you
> find a reproducible error, please create a ticket for it.
> 
>> 
>> 3. If the answer to #1 is yes, I can go ahead and post a 64bit wxPython 3
>> version to the Mac site so that people can try it out and report bugs to
>> fix. Should I do that?
> 
> I think so.
> 
> Best,
> 
> Anna
> 
> 
>> 
>> Thanks
>> 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 Apr 20, 2016, at 5:35 PM, Michael Barton  wrote:
>> 
>> After compiling 7.0.4RC1, I tried again to compile 7.1. Previously, several
>> modules would not compile. I did an svn update and got the same result. So I
>> deleted all files and updated to a clean copy of trunk. Now nothing will
>> compile. An example error is below. It seems to relate to 64 bit
>> architecture.
>> 
>> Any suggestions?
>> 
>> [Important note: I am compiling binaries for the Mac community, not for
>> myself. So that means not using HomeBrew or other package manager like
>> systems for Mac]
>> 
>> Michael
>> 
>> 
>> 
>> make: *** [default] Error 1
>> cmb-imaccsdc:grass_trunk cmbarton$ cd
>> /Users/cmbarton/grass_source/grass_trunk/lib/gis
>> cmb-imaccsdc:gis cmbarton$ make
>> cc -dynamiclib -compatibility_version 7.1 -current_version 7.1 -install_name
>> /Applications/GRASS-7.1.app/Contents/MacOS/lib/libgrass_gis.7.1.svn.dylib -o
>> /Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.5.0/lib/libgrass_gis.7.1.svn.dylib
>> -L/Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.5.0/lib
>> -L/Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.5.0/lib
>> -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.8.sdk
>> -L/usr/local/lib   OBJ.x86_64-apple-darwin14.5.0/adj_cellhd.o
>> OBJ.x86_64-apple-darwin14.5.0/alloc.o OBJ.x86_64-apple-darwin14.5.0/area.o
>> OBJ.x86_64-apple-darwin14.5.0/area_ellipse.o
>> OBJ.x86_64-apple-darwin14.5.0/area_poly1.o
>> OBJ.x86_64-apple-darwin14.5.0/area_poly2.o
>> OBJ.x86_64-apple-darwin14.5.0/area_sphere.o
>> OBJ.x86_64-apple-darwin14.5.0/ascii_chk.o
>> OBJ.x86_64-apple-darwin14.5.0/asprintf.o
>> OBJ.x86_64-apple-darwin14.5.0/basename.o
>> OBJ.x86_64-apple-darwin14.5.0/bres_line.o
>> OBJ.x86_64-apple-darwin14.5.0/clicker.o
>> OBJ.x86_64-apple-darwin14.5.0/cmprbzip.o
>> OBJ.x86_64-apple-darwin14.5.0/cmprlz4.o
>> OBJ.x86_64-apple-darwin14.5.0/cmprrle.o
>> OBJ.x86_64-apple-darwin14.5.0/cmprzlib.o
>> OBJ.x86_64-apple-darwin14.5.0/color_rules.o
>> 

Re: [GRASS-dev] GRASS 7.1 trunk still will not compile on Mac

[Anna Petrášová]

On Thu, Apr 21, 2016 at 7:15 PM, Michael Barton  wrote:
> I tried today to compile GRASS 7.1 on the Mac using ONLY 64 bit
> architecture, instead of the dual 32/64 bit hack I've been using for the
> past several years. It compiled fine. But it requires using 64bit wxPython
> 3.0.2.0. This wxPython 3 GUI mostly works but still has some glitches.
>
> So here are a few questions.
>
> 1. Was there some change so that GRASS 7.1 now only compiles 64 bit? It
> compiled with dual architecture in early December 2015 but I have been
> unable to get to compile with the same config string since then.
>
no changes I know of

> 2. If it is only 64 bit now, it seems that there needs to be some tweaking
> on the GUI. Are we ready to move to wxPython 3.x and deal with that? If so,
> I can easily start to compile 7.0 in 64 bit when those are ironed out.

It seems we don't have much choice, we can't use 2.8 forever,
especially if it's causing so much troubles for compilation. If you
find a reproducible error, please create a ticket for it.

>
> 3. If the answer to #1 is yes, I can go ahead and post a 64bit wxPython 3
> version to the Mac site so that people can try it out and report bugs to
> fix. Should I do that?

I think so.

Best,

Anna


>
> Thanks
> 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 Apr 20, 2016, at 5:35 PM, Michael Barton  wrote:
>
> After compiling 7.0.4RC1, I tried again to compile 7.1. Previously, several
> modules would not compile. I did an svn update and got the same result. So I
> deleted all files and updated to a clean copy of trunk. Now nothing will
> compile. An example error is below. It seems to relate to 64 bit
> architecture.
>
> Any suggestions?
>
> [Important note: I am compiling binaries for the Mac community, not for
> myself. So that means not using HomeBrew or other package manager like
> systems for Mac]
>
> Michael
>
>
>
> make: *** [default] Error 1
> cmb-imaccsdc:grass_trunk cmbarton$ cd
> /Users/cmbarton/grass_source/grass_trunk/lib/gis
> cmb-imaccsdc:gis cmbarton$ make
> cc -dynamiclib -compatibility_version 7.1 -current_version 7.1 -install_name
> /Applications/GRASS-7.1.app/Contents/MacOS/lib/libgrass_gis.7.1.svn.dylib -o
> /Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.5.0/lib/libgrass_gis.7.1.svn.dylib
> -L/Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.5.0/lib
> -L/Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.5.0/lib
> -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.8.sdk
> -L/usr/local/lib   OBJ.x86_64-apple-darwin14.5.0/adj_cellhd.o
> OBJ.x86_64-apple-darwin14.5.0/alloc.o OBJ.x86_64-apple-darwin14.5.0/area.o
> OBJ.x86_64-apple-darwin14.5.0/area_ellipse.o
> OBJ.x86_64-apple-darwin14.5.0/area_poly1.o
> OBJ.x86_64-apple-darwin14.5.0/area_poly2.o
> OBJ.x86_64-apple-darwin14.5.0/area_sphere.o
> OBJ.x86_64-apple-darwin14.5.0/ascii_chk.o
> OBJ.x86_64-apple-darwin14.5.0/asprintf.o
> OBJ.x86_64-apple-darwin14.5.0/basename.o
> OBJ.x86_64-apple-darwin14.5.0/bres_line.o
> OBJ.x86_64-apple-darwin14.5.0/clicker.o
> OBJ.x86_64-apple-darwin14.5.0/cmprbzip.o
> OBJ.x86_64-apple-darwin14.5.0/cmprlz4.o
> OBJ.x86_64-apple-darwin14.5.0/cmprrle.o
> OBJ.x86_64-apple-darwin14.5.0/cmprzlib.o
> OBJ.x86_64-apple-darwin14.5.0/color_rules.o
> OBJ.x86_64-apple-darwin14.5.0/color_str.o
> OBJ.x86_64-apple-darwin14.5.0/commas.o
> OBJ.x86_64-apple-darwin14.5.0/compress.o
> OBJ.x86_64-apple-darwin14.5.0/copy_dir.o
> OBJ.x86_64-apple-darwin14.5.0/copy_file.o
> OBJ.x86_64-apple-darwin14.5.0/counter.o OBJ.x86_64-apple-darwin14.5.0/date.o
> OBJ.x86_64-apple-darwin14.5.0/datum.o OBJ.x86_64-apple-darwin14.5.0/debug.o
> OBJ.x86_64-apple-darwin14.5.0/distance.o
> OBJ.x86_64-apple-darwin14.5.0/done_msg.o
> OBJ.x86_64-apple-darwin14.5.0/endian.o OBJ.x86_64-apple-darwin14.5.0/env.o
> OBJ.x86_64-apple-darwin14.5.0/error.o
> OBJ.x86_64-apple-darwin14.5.0/file_name.o
> OBJ.x86_64-apple-darwin14.5.0/find_etc.o
> OBJ.x86_64-apple-darwin14.5.0/find_file.o
> OBJ.x86_64-apple-darwin14.5.0/find_rast.o
> OBJ.x86_64-apple-darwin14.5.0/find_rast3d.o
> OBJ.x86_64-apple-darwin14.5.0/find_vect.o
> OBJ.x86_64-apple-darwin14.5.0/geodesic.o
> OBJ.x86_64-apple-darwin14.5.0/geodist.o
> OBJ.x86_64-apple-darwin14.5.0/get_ellipse.o
> OBJ.x86_64-apple-darwin14.5.0/get_projinfo.o
> OBJ.x86_64-apple-darwin14.5.0/get_window.o
> OBJ.x86_64-apple-darwin14.5.0/getl.o OBJ.x86_64-apple-darwin14.5.0/gisbase.o
> OBJ.x86_64-apple-darwin14.5.0/gisdbase.o
> OBJ.x86_64-apple-darwin14.5.0/gisinit.o
> 

Re: [GRASS-dev] GRASS 7.1 trunk still will not compile on Mac

[Michael Barton]

I tried today to compile GRASS 7.1 on the Mac using ONLY 64 bit architecture, 
instead of the dual 32/64 bit hack I've been using for the past several years. 
It compiled fine. But it requires using 64bit wxPython 3.0.2.0. This wxPython 3 
GUI mostly works but still has some glitches.

So here are a few questions.

1. Was there some change so that GRASS 7.1 now only compiles 64 bit? It 
compiled with dual architecture in early December 2015 but I have been unable 
to get to compile with the same config string since then.

2. If it is only 64 bit now, it seems that there needs to be some tweaking on 
the GUI. Are we ready to move to wxPython 3.x and deal with that? If so, I can 
easily start to compile 7.0 in 64 bit when those are ironed out.

3. If the answer to #1 is yes, I can go ahead and post a 64bit wxPython 3 
version to the Mac site so that people can try it out and report bugs to fix. 
Should I do that?

Thanks
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 Apr 20, 2016, at 5:35 PM, Michael Barton 
> wrote:

After compiling 7.0.4RC1, I tried again to compile 7.1. Previously, several 
modules would not compile. I did an svn update and got the same result. So I 
deleted all files and updated to a clean copy of trunk. Now nothing will 
compile. An example error is below. It seems to relate to 64 bit architecture.

Any suggestions?

[Important note: I am compiling binaries for the Mac community, not for myself. 
So that means not using HomeBrew or other package manager like systems for Mac]

Michael



make: *** [default] Error 1
cmb-imaccsdc:grass_trunk cmbarton$ cd 
/Users/cmbarton/grass_source/grass_trunk/lib/gis
cmb-imaccsdc:gis cmbarton$ make
cc -dynamiclib -compatibility_version 7.1 -current_version 7.1 -install_name 
/Applications/GRASS-7.1.app/Contents/MacOS/lib/libgrass_gis.7.1.svn.dylib -o 
/Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.5.0/lib/libgrass_gis.7.1.svn.dylib
 -L/Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.5.0/lib 
-L/Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.5.0/lib 
-arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.8.sdk   
-L/usr/local/lib   OBJ.x86_64-apple-darwin14.5.0/adj_cellhd.o 
OBJ.x86_64-apple-darwin14.5.0/alloc.o OBJ.x86_64-apple-darwin14.5.0/area.o 
OBJ.x86_64-apple-darwin14.5.0/area_ellipse.o 
OBJ.x86_64-apple-darwin14.5.0/area_poly1.o 
OBJ.x86_64-apple-darwin14.5.0/area_poly2.o 
OBJ.x86_64-apple-darwin14.5.0/area_sphere.o 
OBJ.x86_64-apple-darwin14.5.0/ascii_chk.o 
OBJ.x86_64-apple-darwin14.5.0/asprintf.o 
OBJ.x86_64-apple-darwin14.5.0/basename.o 
OBJ.x86_64-apple-darwin14.5.0/bres_line.o 
OBJ.x86_64-apple-darwin14.5.0/clicker.o 
OBJ.x86_64-apple-darwin14.5.0/cmprbzip.o 
OBJ.x86_64-apple-darwin14.5.0/cmprlz4.o OBJ.x86_64-apple-darwin14.5.0/cmprrle.o 
OBJ.x86_64-apple-darwin14.5.0/cmprzlib.o 
OBJ.x86_64-apple-darwin14.5.0/color_rules.o 
OBJ.x86_64-apple-darwin14.5.0/color_str.o 
OBJ.x86_64-apple-darwin14.5.0/commas.o OBJ.x86_64-apple-darwin14.5.0/compress.o 
OBJ.x86_64-apple-darwin14.5.0/copy_dir.o 
OBJ.x86_64-apple-darwin14.5.0/copy_file.o 
OBJ.x86_64-apple-darwin14.5.0/counter.o OBJ.x86_64-apple-darwin14.5.0/date.o 
OBJ.x86_64-apple-darwin14.5.0/datum.o OBJ.x86_64-apple-darwin14.5.0/debug.o 
OBJ.x86_64-apple-darwin14.5.0/distance.o 
OBJ.x86_64-apple-darwin14.5.0/done_msg.o OBJ.x86_64-apple-darwin14.5.0/endian.o 
OBJ.x86_64-apple-darwin14.5.0/env.o OBJ.x86_64-apple-darwin14.5.0/error.o 
OBJ.x86_64-apple-darwin14.5.0/file_name.o 
OBJ.x86_64-apple-darwin14.5.0/find_etc.o 
OBJ.x86_64-apple-darwin14.5.0/find_file.o 
OBJ.x86_64-apple-darwin14.5.0/find_rast.o 
OBJ.x86_64-apple-darwin14.5.0/find_rast3d.o 
OBJ.x86_64-apple-darwin14.5.0/find_vect.o 
OBJ.x86_64-apple-darwin14.5.0/geodesic.o 
OBJ.x86_64-apple-darwin14.5.0/geodist.o 
OBJ.x86_64-apple-darwin14.5.0/get_ellipse.o 
OBJ.x86_64-apple-darwin14.5.0/get_projinfo.o 
OBJ.x86_64-apple-darwin14.5.0/get_window.o OBJ.x86_64-apple-darwin14.5.0/getl.o 
OBJ.x86_64-apple-darwin14.5.0/gisbase.o 
OBJ.x86_64-apple-darwin14.5.0/gisdbase.o 
OBJ.x86_64-apple-darwin14.5.0/gisinit.o OBJ.x86_64-apple-darwin14.5.0/handler.o 
OBJ.x86_64-apple-darwin14.5.0/home.o OBJ.x86_64-apple-darwin14.5.0/ilist.o 
OBJ.x86_64-apple-darwin14.5.0/intersect.o OBJ.x86_64-apple-darwin14.5.0/is.o 
OBJ.x86_64-apple-darwin14.5.0/key_value1.o 
OBJ.x86_64-apple-darwin14.5.0/key_value2.o 
OBJ.x86_64-apple-darwin14.5.0/key_value3.o 
OBJ.x86_64-apple-darwin14.5.0/key_value4.o 
OBJ.x86_64-apple-darwin14.5.0/legal_name.o 

Re: [GRASS-dev] GRASS 7.1 trunk still will not compile on Mac

[Michael Barton]

I recompiled this morning using only 64bit architecture and it compiled without 
errors. Does that mean that we can no-longer use dual architecture to compile 
GRASS 7.1?

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 Apr 20, 2016, at 5:35 PM, Michael Barton 
> wrote:

After compiling 7.0.4RC1, I tried again to compile 7.1. Previously, several 
modules would not compile. I did an svn update and got the same result. So I 
deleted all files and updated to a clean copy of trunk. Now nothing will 
compile. An example error is below. It seems to relate to 64 bit architecture.

Any suggestions?

[Important note: I am compiling binaries for the Mac community, not for myself. 
So that means not using HomeBrew or other package manager like systems for Mac]

Michael



make: *** [default] Error 1
cmb-imaccsdc:grass_trunk cmbarton$ cd 
/Users/cmbarton/grass_source/grass_trunk/lib/gis
cmb-imaccsdc:gis cmbarton$ make
cc -dynamiclib -compatibility_version 7.1 -current_version 7.1 -install_name 
/Applications/GRASS-7.1.app/Contents/MacOS/lib/libgrass_gis.7.1.svn.dylib -o 
/Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.5.0/lib/libgrass_gis.7.1.svn.dylib
 -L/Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.5.0/lib 
-L/Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.5.0/lib 
-arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.8.sdk   
-L/usr/local/lib   OBJ.x86_64-apple-darwin14.5.0/adj_cellhd.o 
OBJ.x86_64-apple-darwin14.5.0/alloc.o OBJ.x86_64-apple-darwin14.5.0/area.o 
OBJ.x86_64-apple-darwin14.5.0/area_ellipse.o 
OBJ.x86_64-apple-darwin14.5.0/area_poly1.o 
OBJ.x86_64-apple-darwin14.5.0/area_poly2.o 
OBJ.x86_64-apple-darwin14.5.0/area_sphere.o 
OBJ.x86_64-apple-darwin14.5.0/ascii_chk.o 
OBJ.x86_64-apple-darwin14.5.0/asprintf.o 
OBJ.x86_64-apple-darwin14.5.0/basename.o 
OBJ.x86_64-apple-darwin14.5.0/bres_line.o 
OBJ.x86_64-apple-darwin14.5.0/clicker.o 
OBJ.x86_64-apple-darwin14.5.0/cmprbzip.o 
OBJ.x86_64-apple-darwin14.5.0/cmprlz4.o OBJ.x86_64-apple-darwin14.5.0/cmprrle.o 
OBJ.x86_64-apple-darwin14.5.0/cmprzlib.o 
OBJ.x86_64-apple-darwin14.5.0/color_rules.o 
OBJ.x86_64-apple-darwin14.5.0/color_str.o 
OBJ.x86_64-apple-darwin14.5.0/commas.o OBJ.x86_64-apple-darwin14.5.0/compress.o 
OBJ.x86_64-apple-darwin14.5.0/copy_dir.o 
OBJ.x86_64-apple-darwin14.5.0/copy_file.o 
OBJ.x86_64-apple-darwin14.5.0/counter.o OBJ.x86_64-apple-darwin14.5.0/date.o 
OBJ.x86_64-apple-darwin14.5.0/datum.o OBJ.x86_64-apple-darwin14.5.0/debug.o 
OBJ.x86_64-apple-darwin14.5.0/distance.o 
OBJ.x86_64-apple-darwin14.5.0/done_msg.o OBJ.x86_64-apple-darwin14.5.0/endian.o 
OBJ.x86_64-apple-darwin14.5.0/env.o OBJ.x86_64-apple-darwin14.5.0/error.o 
OBJ.x86_64-apple-darwin14.5.0/file_name.o 
OBJ.x86_64-apple-darwin14.5.0/find_etc.o 
OBJ.x86_64-apple-darwin14.5.0/find_file.o 
OBJ.x86_64-apple-darwin14.5.0/find_rast.o 
OBJ.x86_64-apple-darwin14.5.0/find_rast3d.o 
OBJ.x86_64-apple-darwin14.5.0/find_vect.o 
OBJ.x86_64-apple-darwin14.5.0/geodesic.o 
OBJ.x86_64-apple-darwin14.5.0/geodist.o 
OBJ.x86_64-apple-darwin14.5.0/get_ellipse.o 
OBJ.x86_64-apple-darwin14.5.0/get_projinfo.o 
OBJ.x86_64-apple-darwin14.5.0/get_window.o OBJ.x86_64-apple-darwin14.5.0/getl.o 
OBJ.x86_64-apple-darwin14.5.0/gisbase.o 
OBJ.x86_64-apple-darwin14.5.0/gisdbase.o 
OBJ.x86_64-apple-darwin14.5.0/gisinit.o OBJ.x86_64-apple-darwin14.5.0/handler.o 
OBJ.x86_64-apple-darwin14.5.0/home.o OBJ.x86_64-apple-darwin14.5.0/ilist.o 
OBJ.x86_64-apple-darwin14.5.0/intersect.o OBJ.x86_64-apple-darwin14.5.0/is.o 
OBJ.x86_64-apple-darwin14.5.0/key_value1.o 
OBJ.x86_64-apple-darwin14.5.0/key_value2.o 
OBJ.x86_64-apple-darwin14.5.0/key_value3.o 
OBJ.x86_64-apple-darwin14.5.0/key_value4.o 
OBJ.x86_64-apple-darwin14.5.0/legal_name.o 
OBJ.x86_64-apple-darwin14.5.0/line_dist.o OBJ.x86_64-apple-darwin14.5.0/list.o 
OBJ.x86_64-apple-darwin14.5.0/ll_format.o 
OBJ.x86_64-apple-darwin14.5.0/ll_scan.o OBJ.x86_64-apple-darwin14.5.0/locale.o 
OBJ.x86_64-apple-darwin14.5.0/location.o 
OBJ.x86_64-apple-darwin14.5.0/lrand48.o OBJ.x86_64-apple-darwin14.5.0/ls.o 
OBJ.x86_64-apple-darwin14.5.0/ls_filter.o OBJ.x86_64-apple-darwin14.5.0/lz4.o 
OBJ.x86_64-apple-darwin14.5.0/mach_name.o 
OBJ.x86_64-apple-darwin14.5.0/make_loc.o 
OBJ.x86_64-apple-darwin14.5.0/make_mapset.o 
OBJ.x86_64-apple-darwin14.5.0/mapcase.o OBJ.x86_64-apple-darwin14.5.0/mapset.o 
OBJ.x86_64-apple-darwin14.5.0/mapset_msc.o 
OBJ.x86_64-apple-darwin14.5.0/mapset_nme.o 
OBJ.x86_64-apple-darwin14.5.0/mkstemp.o OBJ.x86_64-apple-darwin14.5.0/myname.o 

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  blocker |  Milestone:  7.0.4
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by martinl):

 Replying to [comment:5 wenzeslaus]:
 > Replying to [comment:4 martinl]:
 > > well, it depends when it will be fixed. In my eyes it's not blocker
 whole GRASS release.
 >
 > Well, the question is what

 liblas package in osgeo4w. It's not our deal.

 > > We can always build fixed Windows package with updated liblas.
 >
 > We've already tried that for 7.0.3 by mistake. libLAS modules and C++
 were broken. It created a lot of questions. There was no way of
 downloading installer of a stable version which does

 C++ modules are now fixed, so? Another reason why to not wait with 7.0.4
 release.

--
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] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  blocker |  Milestone:  7.0.4
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by wenzeslaus):

 Replying to [comment:4 martinl]:
 > well, it depends when it will be fixed. In my eyes it's not blocker
 whole GRASS release.

 Well, the question is what

 > We can always build fixed Windows package with updated liblas.

 We've already tried that for 7.0.3 by mistake. libLAS modules and C++ were
 broken. It created a lot of questions. There was no way of downloading
 installer of a stable version which does what the previous one did (libLAS
 and C++ modules). Now, we would have to provide 7.0.3 alongside with 7.0.4
 unless we don't want users to download 6.4. We would also have to tell
 users before download that they should not download 7.0.4 if they want to
 use these and these modules.

--
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] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  blocker |  Milestone:  7.0.4
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by martinl):

 Replying to [comment:3 wenzeslaus]:

 > I'm not sure. We should not release without the OSGeo4W 493 issue fixed.

 well, it depends when it will be fixed. In my eyes it's not blocker whole
 GRASS release.

--
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] #2997: python editor refuses to run script with UI after closing GUI dialog (was: python editor refuses to run script with UI after closing multiple times)

[GRASS GIS]

#2997: python editor refuses to run script with UI after closing GUI dialog
--+
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.1.0
 Component:  wxGUI|Version:  unspecified
Resolution:   |   Keywords:  python, editor
   CPU:  Unspecified  |   Platform:  Unspecified
--+

--
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] #2997: python editor refuses to run script with UI after closing multiple times

[GRASS GIS]

#2997: python editor refuses to run script with UI after closing multiple times
--+
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.1.0
 Component:  wxGUI|Version:  unspecified
Resolution:   |   Keywords:  python, editor
   CPU:  Unspecified  |   Platform:  Unspecified
--+
Description changed by martinl:

Old description:

> Steps to reproduce:
>
> # open simple python editor
> # load GRASS module example
> # run -> GUI is shown
> # close dialog
> # run -> nothing happens
>
> Reason: `self.running` is still True

New description:

 Steps to reproduce:

  1. open simple python editor
  2. load GRASS module example
  3. run -> GUI is shown
  4. close dialog
  5. run -> nothing happens

 Reason: `self.running` is still True

--

--
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] #2997: python editor refuses to run script with UI after closing multiple times

[GRASS GIS]

#2997: python editor refuses to run script with UI after closing multiple times
+-
 Reporter:  martinl |  Owner:  grass-dev@…
 Type:  defect  | Status:  new
 Priority:  normal  |  Milestone:  7.1.0
Component:  wxGUI   |Version:  unspecified
 Keywords:  python, editor  |CPU:  Unspecified
 Platform:  Unspecified |
+-
 Steps to reproduce:

 # open simple python editor
 # load GRASS module example
 # run -> GUI is shown
 # close dialog
 # run -> nothing happens

 Reason: `self.running` is still True

--
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] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  blocker |  Milestone:  7.0.4
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by wenzeslaus):

 Replying to [comment:2 martinl]:
 > I suggest to report this issue in osgeo4w trac

 Done in:

 https://trac.osgeo.org/osgeo4w/ticket/493

 >  close this bugreport.

 I'm not sure. We should not release without the OSGeo4W 493 issue fixed.

--
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] #2995: wxGUI start fails with charmap codec can't decode byte from g.version

[GRASS GIS]

#2995: wxGUI start fails with charmap codec can't decode byte from g.version
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  blocker |  Milestone:  7.0.4
 Component:  wxGUI   |Version:  svn-releasebranch70
Resolution:  fixed   |   Keywords:  g.version, version, packaging,
 |  wxGUI, compilation, locales, encoding
   CPU:  x86-32  |   Platform:  MSWindows 8
-+-

Comment (by martinl):

 I have also updated https://grass.osgeo.org/news/55/15/GRASS-
 GIS-7-0-4RC1-released/

--
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] #2995: wxGUI start fails with charmap codec can't decode byte from g.version

[GRASS GIS]

#2995: wxGUI start fails with charmap codec can't decode byte from g.version
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  blocker |  Milestone:  7.0.4
 Component:  wxGUI   |Version:  svn-releasebranch70
Resolution:  fixed   |   Keywords:  g.version, version, packaging,
 |  wxGUI, compilation, locales, encoding
   CPU:  x86-32  |   Platform:  MSWindows 8
-+-
Changes (by wenzeslaus):

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


Comment:

 Thanks. Both 32 and 64bit builds of RC2 are working now. I'm closing this
 as fixed, although there is still the question about how to handle the
 encoding properly but there is probably no simple way on MS Win since the
 text was written in Windows-1250 encoding but the reading was done with
 Windows-1252 encoding.

--
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] #2994: wxGUI start fails with module object has no attribute GRIORA_NearestNeighbour

[GRASS GIS]

#2994: wxGUI start fails with module object has no attribute
GRIORA_NearestNeighbour
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  blocker |  Milestone:  7.0.4
 Component:  wxGUI   |Version:  svn-releasebranch70
Resolution:  invalid |   Keywords:  gdal, Python, WMS, rendering,
 |  packaging, wxGUI
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by wenzeslaus):

 Just for the record:

 Replying to [comment:3 martinl]:
 > What contains your `...\osgeo\gdalconst.py`?

 {{{
 GRIORA_NearestNeighbour = _gdalconst.GRIORA_NearestNeighbour
 }}}

 The import message suggests that the symbol/attribute is missing in the
 `_gdalconst` module which is a C module I suppose. Likely this was some
 DLL glitch.

--
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] #2994: wxGUI start fails with module object has no attribute GRIORA_NearestNeighbour

[GRASS GIS]

#2994: wxGUI start fails with module object has no attribute
GRIORA_NearestNeighbour
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  blocker |  Milestone:  7.0.4
 Component:  wxGUI   |Version:  svn-releasebranch70
Resolution:  invalid |   Keywords:  gdal, Python, WMS, rendering,
 |  packaging, wxGUI
   CPU:  x86-64  |   Platform:  Unspecified
-+-
Changes (by wenzeslaus):

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


Comment:

 I can't reproduce it anymore with newly downloaded build from today, Apr
 21 (which is still r68280). Closing as invalid. We can reopen if needed.
 The following 7.0.4svn 32bit and 64bit worked:

 {{{
 System Info
 GRASS version: 7.0.4svn
 GRASS SVN Revision: 68280
 Build Date: 2016-04-21
 Build Platform: x86_64-w64-mingw32
 GDAL/OGR: 2.0.2
 PROJ.4: 4.9.2
 GEOS: 3.5.0
 SQLite: 3.7.17
 Python: 2.7.5
 wxPython: 2.8.12.1
 Platform: Windows-8-6.2.9200

 > g.version -re
 GRASS 7.0.4svn (2016)
 libgis Revision: 67364
 libgis Date: 2015-12-24 16:07:44 +0100 (Thu, 24 Dec 2015)
 PROJ.4: 4.9.2
 GDAL/OGR: 2.0.2
 GEOS: 3.5.0
 SQLite: 3.7.17
 }}}

 {{{
 System Info
 GRASS version: 7.0.4svn
 GRASS SVN Revision: 68280
 Build Date: 2016-04-21
 Build Platform: i386-w64-mingw32
 GDAL/OGR: 2.0.2
 PROJ.4: 4.9.2
 GEOS: 3.5.0
 SQLite: 3.7.17
 Python: 2.7.4
 wxPython: 2.8.12.1
 Platform: Windows-8-6.2.9200

 > g.version -re
 GRASS 7.0.4svn (2016)
 libgis Revision: 67364
 libgis Date: 2015-12-24 16:07:44 +0100 (Thu, 24 Dec 2015)
 PROJ.4: 4.9.2
 GDAL/OGR: 2.0.2
 GEOS: 3.5.0
 SQLite: 3.7.17
 }}}

--
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] #2986: r.mapcalc with same variable on LHS and RHS

[GRASS GIS]

#2986: r.mapcalc with same variable on LHS and RHS
--+-
  Reporter:  mankoff  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  major|  Milestone:  7.0.4
 Component:  Docs |Version:  7.0.3
Resolution:  fixed|   Keywords:  r.mapcalc
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mankoff):

 I'm still confused. The specific case of {{{r.mapcalc 'map=map'}}}
 mentioned 2 comments above does seem to work for me in v7.0.3 (see code
 example below). Also, the last comment appears to say that everything on
 the LHS, even if a new unique LHSname, will be a variable and not a map
 (I'm not even sure what "variables" are in GRASS). But the documentation
 says that, //"result is the name of a raster map layer"//, and I thought
 the whole point of {{{r.mapcalc}}} was to produce new raster maps.

 Finally, there is no evidence, at least from {{{r.info}}}, of results
 changing type. See for example results from,

 {{{
 grass70 -text ./nc_spm_08_grass7/PERMANENT
 r.mapcalc "LHS = 1" --o
 r.info LHS > rinfo.1
 r.mapcalc "LHS = LHS" --o
 r.info LHS > rinfo.2
 r.mapcalc "LHS = LHS * 2" --o
 r.info LHS > rinfo.3
 diff3 rinfo.1 rinfo.2 rinfo.3
 }}}

 Finally, would it be possible to change this behavior, so that
 {{{r.mapcalc 'map = map * 2'}}} is valid syntax? It seems like it would be
 incredibly useful to support this standard programming syntax. If it isn't
 a major code issue, I'll open a ticket with this feature request.

--
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] #2986: r.mapcalc with same variable on LHS and RHS

[GRASS GIS]

#2986: r.mapcalc with same variable on LHS and RHS
--+-
  Reporter:  mankoff  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  major|  Milestone:  7.0.4
 Component:  Docs |Version:  7.0.3
Resolution:  fixed|   Keywords:  r.mapcalc
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by glynn):

 Replying to [comment:6 glynn]:
 > Replying to [comment:5 mankoff]:
 > > Just to be clear, {{{LHS = RHS}}} **does** work.

 Something else which doesn't quite work as expected is that once a name
 appears on the LHS of an assignment, it's marked as being a variable
 rather than a map. Which means that you can't use any modifiers on it
 (whether the neighbourhood modifier, the category modifier or any colour
 channel modifiers), as those can only be used on maps, not variables.

--
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] #2986: r.mapcalc with same variable on LHS and RHS

[GRASS GIS]

#2986: r.mapcalc with same variable on LHS and RHS
--+-
  Reporter:  mankoff  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  major|  Milestone:  7.0.4
 Component:  Docs |Version:  7.0.3
Resolution:  fixed|   Keywords:  r.mapcalc
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by glynn):

 Replying to [comment:5 mankoff]:
 > Just to be clear, {{{LHS = RHS}}} **does** work. I've never actually had
 it crash or return NULL or what appears to be invalid data when I've done
 this. But perhaps it isn't guaranteed to work...
 It works by coincidence rather than by design.

 The data (cell/fcell) file and null bitmap are written to temporary files,
 which are renamed into place when the map is closed. The metadata files
 (cellhd, quant, histogram, categoriess, colour table, history, etc), are
 stored in memory and written when the map is closed. So the output map
 shouldn't change while it's being read.

 A specific case which won't quite work is "r.mapcalc 'map = map'", because
 that copies the categories, colour table and history from the input to the
 output, but closing the output map will delete or replace those before the
 copy occurs. If the logic is ever extended to cover more cases, those will
 similarly fail.

 Actually, I'm not sure that it will work on Windows, because at the point
 that the data and null files are renamed, the original files are still
 open for read (r.mapcalc never actually closes the input maps). That
 should be easy to fix, though (call close_maps() from within execute()
 before the loop which closes the output maps).

--
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.info versus print

[Glynn Clements]

Vaclav Petras wrote:

> Perhaps I was not completely clear before. I agree with Glynn.
> grass.script.message() etc. for messages. print()/sys.stdout for text
> output (e.g. tables).

In short: g.message for "messages", print or sys.stdout.write() for
"data".

The reason why Unix has stdout and stderr is so that you can redirect
stdout to a file which having stderr associated with the terminal. So
messages intended for the user don't interfere with parsing the data,
and redirecting the data to the file doesn't hide messages from the
user.

So, assuming that the two streams will be separated should provide
some clues as to which is appropriate for any given case.

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

Re: [GRASS-dev] creating temporary mapsets in a parallelized python script

[Glynn Clements]

Pietro wrote:

> Perhaps we could decorate the function with contextmanager:

That's an option, but it complicates matters in the (probably more
common) case where you just want to use a single temporary region for
the entire script.

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

Re: [GRASS-dev] [GRASS GIS] #2995: wxGUI start fails with charmap codec can't decode byte from g.version

[GRASS GIS]

#2995: wxGUI start fails with charmap codec can't decode byte from g.version
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  blocker |  Milestone:  7.0.4
 Component:  wxGUI   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  g.version, version, packaging,
 |  wxGUI, compilation, locales, encoding
   CPU:  x86-32  |   Platform:  MSWindows 8
-+-

Comment (by martinl):

 or
 
https://grass.osgeo.org/grass70/binary/mswindows/native/x86/WinGRASS-7.0.4RC1-2-Setup-x86.exe

--
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] #2995: wxGUI start fails with charmap codec can't decode byte from g.version

[GRASS GIS]

#2995: wxGUI start fails with charmap codec can't decode byte from g.version
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  blocker |  Milestone:  7.0.4
 Component:  wxGUI   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  g.version, version, packaging,
 |  wxGUI, compilation, locales, encoding
   CPU:  x86-32  |   Platform:  MSWindows 8
-+-

Comment (by martinl):

 Can you try
 
https://grass.osgeo.org/grass70/binary/mswindows/native/x86_64/WinGRASS-7.0.4RC1-2
 -Setup-x86_64.exe?

--
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] #2995: wxGUI start fails with charmap codec can't decode byte from g.version

[GRASS GIS]

#2995: wxGUI start fails with charmap codec can't decode byte from g.version
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  blocker |  Milestone:  7.0.4
 Component:  wxGUI   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  g.version, version, packaging,
 |  wxGUI, compilation, locales, encoding
   CPU:  x86-32  |   Platform:  MSWindows 8
-+-

Comment (by martinl):

 Right, `gis.h` is wrongly checkouted with Czech locales. I fixed that.
 Strangely on the same computer I am getting with `g.version`

 {{{
 libgis_date="2015-12-24 16:07:44 +0100 (Thu, 24 Dec 2015) "
 }}}

 I will create new package for testing.

--
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] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  blocker |  Milestone:  7.0.4
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by martinl):

 I tried to install fresh OSGeo4W64 just with `liblas` cmd package.
 `lasinfo` fails with the same error as described. So it's appearently bug
 in `liblas` osgeo4w packaging. I suggest to report this issue in osgeo4w
 trac and close this bugreport.

--
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] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  blocker |  Milestone:  7.0.4
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by martinl):

 I can confirm this bug. I just wonder whether it's problem of GRASS or
 liblas OSGeo4W package.

--
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] #2994: wxGUI start fails with module object has no attribute GRIORA_NearestNeighbour

[GRASS GIS]

#2994: wxGUI start fails with module object has no attribute
GRIORA_NearestNeighbour
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  blocker |  Milestone:  7.0.4
 Component:  wxGUI   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  gdal, Python, WMS, rendering,
 |  packaging, wxGUI
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by martinl):

 What contains your `C:\Program Files\GRASS GIS 7.0.4svn\Python27\lib\site-
 packages\osgeo\gda
 lconst.py`?

--
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] #2994: wxGUI start fails with module object has no attribute GRIORA_NearestNeighbour

[GRASS GIS]

#2994: wxGUI start fails with module object has no attribute
GRIORA_NearestNeighbour
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  blocker |  Milestone:  7.0.4
 Component:  wxGUI   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  gdal, Python, WMS, rendering,
 |  packaging, wxGUI
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by martinl):

 I cannot reproduce it with

 {{{
 GRASS version: 7.0.4svn
 GRASS SVN Revision: 68280
 Build Date: 2016-04-21
 Build Platform: x86_64-w64-mingw32
 GDAL/OGR: 2.0.2
 PROJ.4: 4.9.2
 GEOS: 3.5.0
 SQLite: 3.7.17
 Python: 2.7.5
 wxPython: 2.8.12.1
 Platform: Windows-7-6.1.7601-SP1
 }}}

 The GUI starts, I can display raster, vector maps...

--
Ticket URL: 
GRASS GIS 

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