subject:"\\\\\\\[GRASS\\\\\\\-dev\\\\\\\] New attempt to update GRASS for Mac"

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-20 Thread Michael Barton

I just tried this patch and it made no difference.

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 Aug 19, 2017, at 9:15 AM, Markus Neteler 
> wrote:

Hi Michael,

On Wed, Aug 16, 2017 at 12:10 AM, Eric Hutton 
> wrote:
Hi Michael

It's hard for me to say without seeing which tests are failing but I think
at least some of those errors are probably due to DYLD_LIBRARY_PATH not
being set correctly. As far as I can tell, when grass is being tested during
the make process the tests are run within an environment that has the
necessary environment variables set (PATH, DYLD_LIBRARY_PATH, GISRC, etc. -
this is the run_grass command defined in Rules.make). It seems that the
tests are run in a new environment that doesn't inherit your
DYLD_LIBRARY_PATH (even if you've exported it). It seems like this might a
bug? I'm not certain.

To fix some of these errors I manually added $PREFIX/lib to
DYLD_LIBRARY_PATH for the run_grass command. I did this in Rules.make (line
40, for me),

$(LD_LIBRARY_PATH_VAR)="$(BIN):$(GISBASE)/bin:$(GISBASE)/scripts:$(ARCH_LIBD
IR):$(BASE_LIBDIR):$(PREFIX)/lib:$($(LD_LIBRARY_PATH_VAR))"

Or have a look at the attached patch file. Note that for me all of my
dependencies were installed in $PREFIX/lib.

Eric

Did Eric's patch actually help?

Markus

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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-19 Thread Michael Barton

Markus and Eric,

I have not had a chance to try these things out because of the chaos of the 
beginning of semester. That's why I'd hoped to get further along when in 
Boulder. Once things calm down next week (I hope), I'll try these out.

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 Aug 19, 2017, at 9:15 AM, Markus Neteler 
> wrote:

Hi Michael,

On Wed, Aug 16, 2017 at 12:10 AM, Eric Hutton 
> wrote:
Hi Michael

It's hard for me to say without seeing which tests are failing but I think
at least some of those errors are probably due to DYLD_LIBRARY_PATH not
being set correctly. As far as I can tell, when grass is being tested during
the make process the tests are run within an environment that has the
necessary environment variables set (PATH, DYLD_LIBRARY_PATH, GISRC, etc. -
this is the run_grass command defined in Rules.make). It seems that the
tests are run in a new environment that doesn't inherit your
DYLD_LIBRARY_PATH (even if you've exported it). It seems like this might a
bug? I'm not certain.

To fix some of these errors I manually added $PREFIX/lib to
DYLD_LIBRARY_PATH for the run_grass command. I did this in Rules.make (line
40, for me),

$(LD_LIBRARY_PATH_VAR)="$(BIN):$(GISBASE)/bin:$(GISBASE)/scripts:$(ARCH_LIBD
IR):$(BASE_LIBDIR):$(PREFIX)/lib:$($(LD_LIBRARY_PATH_VAR))"

Or have a look at the attached patch file. Note that for me all of my
dependencies were installed in $PREFIX/lib.

Eric

Did Eric's patch actually help?

Markus

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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-19 Thread Markus Neteler

Hi Michael,

On Wed, Aug 16, 2017 at 12:10 AM, Eric Hutton  wrote:
> Hi Michael
>
> It's hard for me to say without seeing which tests are failing but I think
> at least some of those errors are probably due to DYLD_LIBRARY_PATH not
> being set correctly. As far as I can tell, when grass is being tested during
> the make process the tests are run within an environment that has the
> necessary environment variables set (PATH, DYLD_LIBRARY_PATH, GISRC, etc. -
> this is the run_grass command defined in Rules.make). It seems that the
> tests are run in a new environment that doesn't inherit your
> DYLD_LIBRARY_PATH (even if you've exported it). It seems like this might a
> bug? I'm not certain.
>
> To fix some of these errors I manually added $PREFIX/lib to
> DYLD_LIBRARY_PATH for the run_grass command. I did this in Rules.make (line
> 40, for me),
>
>
> $(LD_LIBRARY_PATH_VAR)="$(BIN):$(GISBASE)/bin:$(GISBASE)/scripts:$(ARCH_LIBD
> IR):$(BASE_LIBDIR):$(PREFIX)/lib:$($(LD_LIBRARY_PATH_VAR))"
>
> Or have a look at the attached patch file. Note that for me all of my
> dependencies were installed in $PREFIX/lib.
>
> Eric


Did Eric's patch actually help?

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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-08 Thread Michael Barton

Very frustrating.

I can no longer get GRASS 7.2 or trunk to compile using anaconda dependencies, 
even without cairo or freetype. I have tried everything I can think of but 
cannot get it to compile like it did last week. Perhaps someone can offer 
advice.

I have errors in all or nearly all of the non-python grass modules. They are 
all of the variety listed below:

dyld: Library not loaded: @rpath/libgdal.20.dylib
  Referenced from: 
/Users/cmbarton/grass_source/trunk/dist.x86_64-apple-darwin16.7.0/lib/libgrass_raster.7.3.svn.dylib
  Reason: image not found

dyld: Library not loaded: @rpath/libpng16.16.dylib
  Referenced from: 
/Users/cmbarton/grass_source/trunk/dist.x86_64-apple-darwin16.7.0/lib/libgrass_pngdriver.7.3.svn.dylib
  Reason: image not found

dyld: Library not loaded: @rpath/libgeos-3.5.1.dylib
  Referenced from: 
/Users/cmbarton/grass_source/trunk/dist.x86_64-apple-darwin16.7.0/lib/libgrass_vector.7.3.svn.dylib
  Reason: image not found

dyld: Library not loaded: @rpath/libproj.12.dylib
  Referenced from: 
/Users/cmbarton/grass_source/trunk/dist.x86_64-apple-darwin16.7.0/bin/g.region
  Reason: image not found

My gdal/libgdal is 2.1.0
libgeos is 3.5.0
libpng 1.6.27
proj 4.9.2

Before configuring, I run make clean and have the environment set up as I did 
last week:

export NAD2BIN=/Applications/anaconda/bin/nad2bin
export CS2CS=/Applications/anaconda/bin/cs2cs
export GEOD=/Applications/anaconda/bin/geod
export CXX=g++
export MACOSX_DEPLOYMENT_TARGET=10.8

I've tried setting LD_LIBRARY_PATH  to

export LD_LIBRARY_PATH="/Applications/anaconda/lib:$LD_LIBRARY_PATH"

and to

export LD_LIBRARY_PATH="/Applications/anaconda/env/grassconda/lib"

(for using an anaconda virtual environment)

My configure string is the one that worked before:

./configure 
--with-macosx-sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
 --libdir=/Applications/anaconda/lib 
--includedir=/Applications/anaconda/include 
--with-gdal=/Applications/anaconda/bin/gdal-config 
--with-gdal-libs=/Applications/anaconda/lib 
--with-proj=/Applications/anaconda/bin/proj 
--with-proj-includes=/Applications/anaconda/include 
--with-proj-libs=/Applications/anaconda/lib 
--with-proj-share=/Applications/anaconda/share/proj 
--with-geos=/Applications/anaconda/bin/geos-config 
--with-png-includes=/Applications/anaconda/include 
--with-png-libs=/Applications/anaconda/lib 
--with-tiff-includes=/Applications/anaconda/include 
--with-tiff-libs=/Applications/anaconda/lib 
--with-jpeg-includes=/Applications/anaconda/include 
--with-jpeg-libs=/Applications/anaconda/lib --without-freetype --without-cairo 
--with-fftw-includes=/Applications/anaconda/include 
--with-fftw-libs=/Applications/anaconda/lib 
--with-sqlite-libs=/Applications/anaconda/lib 
--with-sqlite-includes=/Applications/anaconda/include --with-opengl=aqua 
--without-postgres --without-mysql --without-readline --prefix=/Applications 
--enable-macosx-app --enable-64bit

I've done this from the normal shell and from an anaconda virtual environment. 
Same results. Maybe a fresh set of eyes can see what I am missing here. Any 
help would be appreciated.

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 Aug 6, 2017, at 2:05 PM, Michael Barton 
> wrote:

Fixed the nviz/3D issue by resetting GRASS_PYTHON to 
/Applications/anaconda/bin/pythonw

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 Aug 6, 2017, at 2:02 PM, Michael Barton 
> wrote:

I have built both GRASS 7.3 and 7.2svn without errors using Anaconda 
dependencies if I configure --without-cairo and --without-freetype.

When I install GRASS and launch it, first it hangs and time outs at

Rebuilding Addon HTML manual pages index...
Rebuilding Addon menu...

Then the GUI crashes badly (with most GRASS functions unavailable from the 
command line also). However, I discovered that if I manually set

export LD_LIBRARY_PATH="/Applications/anaconda/lib:$LD_LIBRARY_PATH"

in the GRASS terminal, and relaunch the GUI, it works--although without Cairo 
and Freetype. Also, 3D crashes with the

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-07 Thread Michael Barton

Does setting

--enable-shared

in configure make any difference for Mac compiling?

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 Aug 6, 2017, at 2:05 PM, Michael Barton 
> wrote:

Fixed the nviz/3D issue by resetting GRASS_PYTHON to 
/Applications/anaconda/bin/pythonw

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 Aug 6, 2017, at 2:02 PM, Michael Barton 
> wrote:

I have built both GRASS 7.3 and 7.2svn without errors using Anaconda 
dependencies if I configure --without-cairo and --without-freetype.

When I install GRASS and launch it, first it hangs and time outs at

Rebuilding Addon HTML manual pages index...
Rebuilding Addon menu...

Then the GUI crashes badly (with most GRASS functions unavailable from the 
command line also). However, I discovered that if I manually set

export LD_LIBRARY_PATH="/Applications/anaconda/lib:$LD_LIBRARY_PATH"

in the GRASS terminal, and relaunch the GUI, it works--although without Cairo 
and Freetype. Also, 3D crashes with the following message:

/Applications/anaconda/bin/pythonw: line 3: 13209 Segmentation fault: 11  
/Applications/anaconda/python.app/Contents/MacOS/python "$@"

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 Aug 5, 2017, at 8:25 PM, Michael Barton 
> wrote:

To GRASS devs:

When I configure with paths to anaconda cairo and freetype dependencies, I get 
no errors (see below).

But when I check the configure.log, I see the same error I'm getting at the end 
of a failed build:

Undefined symbols for architecture x86_64:
  "_iconv", referenced from:
  _main in conftest-6b4e8e.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
configure: failed program was:
#line 4775 "configure"

It seems that configure output is not correct?

Indeed the checking for iconv begins at line 4775. Unfortunately, I cannot 
decipher what it is doing or which version of iconv it is checking (the Mac 
system one in /usr/lib or the one in anaconda).

Additionally, AFAICT, both versions of iconv that I have are 64bit. How can I 
"use -v to see invocation"?

Thanks
Michael

 configure output to shell ==

checking host system type... x86_64-apple-darwin16.7.0
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for Cygwin environment... no
checking for mingw32 environment... no
checking for executable suffix... no
checking for full floating-point support... yes
checking for pwd... /bin/pwd
checking for source directory... /Users/cmbarton/grass_source/trunk
checking for build directory... /Users/cmbarton/grass_source/trunk
checking for svnversion... /opt/subversion/bin/svnversion
checking for MacOSX App... yes
checking for MacOSX architectures... no
checking for MacOSX SDK... checking for 
/Developer/SDKs/MacOSX10.8.sdk/SDKSettings.plist... yes
checking how to build libraries... shared
checking for additional include dirs...
checking for additional library dirs...
checking for a BSD compatible install... /usr/bin/install -c
checking for flex... flex
checking for yywrap in -lfl... no
checking for bison... bison -y
checking for ranlib... ranlib
checking for ar... ar
checking for env... env
checking for perl... /usr/bin/perl
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for limits.h... yes
checking for termio.h... no
checking for termios.h... yes
checking for unistd.h... yes
checking for values.h... no

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-06 Thread Michael Barton

Fixed the nviz/3D issue by resetting GRASS_PYTHON to 
/Applications/anaconda/bin/pythonw

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 Aug 6, 2017, at 2:02 PM, Michael Barton 
> wrote:

I have built both GRASS 7.3 and 7.2svn without errors using Anaconda 
dependencies if I configure --without-cairo and --without-freetype.

When I install GRASS and launch it, first it hangs and time outs at

Rebuilding Addon HTML manual pages index...
Rebuilding Addon menu...

Then the GUI crashes badly (with most GRASS functions unavailable from the 
command line also). However, I discovered that if I manually set

export LD_LIBRARY_PATH="/Applications/anaconda/lib:$LD_LIBRARY_PATH"

in the GRASS terminal, and relaunch the GUI, it works--although without Cairo 
and Freetype. Also, 3D crashes with the following message:

/Applications/anaconda/bin/pythonw: line 3: 13209 Segmentation fault: 11  
/Applications/anaconda/python.app/Contents/MacOS/python "$@"

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 Aug 5, 2017, at 8:25 PM, Michael Barton 
> wrote:

To GRASS devs:

When I configure with paths to anaconda cairo and freetype dependencies, I get 
no errors (see below).

But when I check the configure.log, I see the same error I'm getting at the end 
of a failed build:

Undefined symbols for architecture x86_64:
  "_iconv", referenced from:
  _main in conftest-6b4e8e.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
configure: failed program was:
#line 4775 "configure"

It seems that configure output is not correct?

Indeed the checking for iconv begins at line 4775. Unfortunately, I cannot 
decipher what it is doing or which version of iconv it is checking (the Mac 
system one in /usr/lib or the one in anaconda).

Additionally, AFAICT, both versions of iconv that I have are 64bit. How can I 
"use -v to see invocation"?

Thanks
Michael

 configure output to shell ==

checking host system type... x86_64-apple-darwin16.7.0
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for Cygwin environment... no
checking for mingw32 environment... no
checking for executable suffix... no
checking for full floating-point support... yes
checking for pwd... /bin/pwd
checking for source directory... /Users/cmbarton/grass_source/trunk
checking for build directory... /Users/cmbarton/grass_source/trunk
checking for svnversion... /opt/subversion/bin/svnversion
checking for MacOSX App... yes
checking for MacOSX architectures... no
checking for MacOSX SDK... checking for 
/Developer/SDKs/MacOSX10.8.sdk/SDKSettings.plist... yes
checking how to build libraries... shared
checking for additional include dirs...
checking for additional library dirs...
checking for a BSD compatible install... /usr/bin/install -c
checking for flex... flex
checking for yywrap in -lfl... no
checking for bison... bison -y
checking for ranlib... ranlib
checking for ar... ar
checking for env... env
checking for perl... /usr/bin/perl
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for limits.h... yes
checking for termio.h... no
checking for termios.h... yes
checking for unistd.h... yes
checking for values.h... no
checking for f2c.h... no
checking for g2c.h... no
checking for sys/ioctl.h... yes
checking for sys/mtio.h... no
checking for sys/resource.h... yes
checking for sys/time.h... yes
checking for sys/timeb.h... yes
checking for sys/types.h... yes
checking for sys/utsname.h... yes
checking for libintl.h... yes
checking for iconv.h... yes
checking for langinfo.h... yes
checking whether time.h and sys/time.h may both be included... yes
checking for off_t... yes
checking for uid_t in sys/types.h... yes
checking return type of signal handlers... void
checking for Cygwin environment... no
checking for ftime... yes
checking for gethostname... yes
checking

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-06 Thread Michael Barton

I have built both GRASS 7.3 and 7.2svn without errors using Anaconda 
dependencies if I configure --without-cairo and --without-freetype.

When I install GRASS and launch it, first it hangs and time outs at

Rebuilding Addon HTML manual pages index...
Rebuilding Addon menu...

Then the GUI crashes badly (with most GRASS functions unavailable from the 
command line also). However, I discovered that if I manually set

export LD_LIBRARY_PATH="/Applications/anaconda/lib:$LD_LIBRARY_PATH"

in the GRASS terminal, and relaunch the GUI, it works--although without Cairo 
and Freetype. Also, 3D crashes with the following message:

/Applications/anaconda/bin/pythonw: line 3: 13209 Segmentation fault: 11  
/Applications/anaconda/python.app/Contents/MacOS/python "$@"


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 Aug 5, 2017, at 8:25 PM, Michael Barton 
> wrote:

To GRASS devs:

When I configure with paths to anaconda cairo and freetype dependencies, I get 
no errors (see below).


But when I check the configure.log, I see the same error I'm getting at the end 
of a failed build:

Undefined symbols for architecture x86_64:
  "_iconv", referenced from:
  _main in conftest-6b4e8e.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
configure: failed program was:
#line 4775 "configure"


It seems that configure output is not correct?

Indeed the checking for iconv begins at line 4775. Unfortunately, I cannot 
decipher what it is doing or which version of iconv it is checking (the Mac 
system one in /usr/lib or the one in anaconda).

Additionally, AFAICT, both versions of iconv that I have are 64bit. How can I 
"use -v to see invocation"?

Thanks
Michael


 configure output to shell ==

checking host system type... x86_64-apple-darwin16.7.0
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for Cygwin environment... no
checking for mingw32 environment... no
checking for executable suffix... no
checking for full floating-point support... yes
checking for pwd... /bin/pwd
checking for source directory... /Users/cmbarton/grass_source/trunk
checking for build directory... /Users/cmbarton/grass_source/trunk
checking for svnversion... /opt/subversion/bin/svnversion
checking for MacOSX App... yes
checking for MacOSX architectures... no
checking for MacOSX SDK... checking for 
/Developer/SDKs/MacOSX10.8.sdk/SDKSettings.plist... yes
checking how to build libraries... shared
checking for additional include dirs...
checking for additional library dirs...
checking for a BSD compatible install... /usr/bin/install -c
checking for flex... flex
checking for yywrap in -lfl... no
checking for bison... bison -y
checking for ranlib... ranlib
checking for ar... ar
checking for env... env
checking for perl... /usr/bin/perl
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for limits.h... yes
checking for termio.h... no
checking for termios.h... yes
checking for unistd.h... yes
checking for values.h... no
checking for f2c.h... no
checking for g2c.h... no
checking for sys/ioctl.h... yes
checking for sys/mtio.h... no
checking for sys/resource.h... yes
checking for sys/time.h... yes
checking for sys/timeb.h... yes
checking for sys/types.h... yes
checking for sys/utsname.h... yes
checking for libintl.h... yes
checking for iconv.h... yes
checking for langinfo.h... yes
checking whether time.h and sys/time.h may both be included... yes
checking for off_t... yes
checking for uid_t in sys/types.h... yes
checking return type of signal handlers... void
checking for Cygwin environment... no
checking for ftime... yes
checking for gethostname... yes
checking for gettimeofday... yes
checking for lseek... yes
checking for nice... yes
checking for time... yes
checking for uname... yes
checking for seteuid... yes
checking for setpriority... yes
checking for setreuid... yes
checking for setruid... yes
checking for drand48... yes
checking for putenv... yes
checking for setenv... yes
checking for nanosleep... yes
checking whether setpgrp takes no argument... yes
checking for long long int... yes
checking for W11... no
checking for X... no
checking for library containing cuserid... no
checking for asprintf... yes
checking for atan... yes
checking for dlsym... yes
checking for iconv... no
checking for iconv in

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-06 Thread Helmut Kudrnovsky

>checking for cairo.h... yes
>Package cairo was not found in the pkg-config search path.
>Perhaps you should add the directory containing `cairo.pc'
>to the PKG_CONFIG_PATH environment variable
>No package 'cairo' found
>checking for location of cairo library..

Does the suggestion? 



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/New-attempt-to-update-GRASS-for-Mac-tp5328294p5330603.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-05 Thread Michael Barton

To GRASS devs:

When I configure with paths to anaconda cairo and freetype dependencies, I get 
no errors (see below).


But when I check the configure.log, I see the same error I'm getting at the end 
of a failed build:

Undefined symbols for architecture x86_64:
  "_iconv", referenced from:
  _main in conftest-6b4e8e.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
configure: failed program was:
#line 4775 "configure"


It seems that configure output is not correct?

Indeed the checking for iconv begins at line 4775. Unfortunately, I cannot 
decipher what it is doing or which version of iconv it is checking (the Mac 
system one in /usr/lib or the one in anaconda).

Additionally, AFAICT, both versions of iconv that I have are 64bit. How can I 
"use -v to see invocation"?

Thanks
Michael


 configure output to shell ==

checking host system type... x86_64-apple-darwin16.7.0
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for Cygwin environment... no
checking for mingw32 environment... no
checking for executable suffix... no
checking for full floating-point support... yes
checking for pwd... /bin/pwd
checking for source directory... /Users/cmbarton/grass_source/trunk
checking for build directory... /Users/cmbarton/grass_source/trunk
checking for svnversion... /opt/subversion/bin/svnversion
checking for MacOSX App... yes
checking for MacOSX architectures... no
checking for MacOSX SDK... checking for 
/Developer/SDKs/MacOSX10.8.sdk/SDKSettings.plist... yes
checking how to build libraries... shared
checking for additional include dirs...
checking for additional library dirs...
checking for a BSD compatible install... /usr/bin/install -c
checking for flex... flex
checking for yywrap in -lfl... no
checking for bison... bison -y
checking for ranlib... ranlib
checking for ar... ar
checking for env... env
checking for perl... /usr/bin/perl
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for limits.h... yes
checking for termio.h... no
checking for termios.h... yes
checking for unistd.h... yes
checking for values.h... no
checking for f2c.h... no
checking for g2c.h... no
checking for sys/ioctl.h... yes
checking for sys/mtio.h... no
checking for sys/resource.h... yes
checking for sys/time.h... yes
checking for sys/timeb.h... yes
checking for sys/types.h... yes
checking for sys/utsname.h... yes
checking for libintl.h... yes
checking for iconv.h... yes
checking for langinfo.h... yes
checking whether time.h and sys/time.h may both be included... yes
checking for off_t... yes
checking for uid_t in sys/types.h... yes
checking return type of signal handlers... void
checking for Cygwin environment... no
checking for ftime... yes
checking for gethostname... yes
checking for gettimeofday... yes
checking for lseek... yes
checking for nice... yes
checking for time... yes
checking for uname... yes
checking for seteuid... yes
checking for setpriority... yes
checking for setreuid... yes
checking for setruid... yes
checking for drand48... yes
checking for putenv... yes
checking for setenv... yes
checking for nanosleep... yes
checking whether setpgrp takes no argument... yes
checking for long long int... yes
checking for W11... no
checking for X... no
checking for library containing cuserid... no
checking for asprintf... yes
checking for atan... yes
checking for dlsym... yes
checking for iconv... no
checking for iconv in -liconv... yes
checking for socket... yes
checking for location of zlib includes...
checking for zlib.h... yes
checking for location of zlib library...
checking for deflate in -lz... yes
checking whether to use bzlib... no
checking for location of External PROJ.4 includes... 
/Applications/anaconda/include
checking for proj_api.h... yes
checking External PROJ.4 version... 492
checking for location of External PROJ.4 library... /Applications/anaconda/lib
checking for pj_get_def in -lproj... yes
checking for location of External PROJ.4 data files... 
/Applications/anaconda/share/proj
checking for /Applications/anaconda/share/proj/epsg... yes
checking for nad2bin... /Applications/anaconda/bin/nad2bin
checking whether to use regex... yes
checking for location of regex includes...
checking for regex.h... yes
checking for location of regex library...
checking for regcomp... yes
checking whether to use Readline... no
checking whether to use GDAL... yes
checking for gdal-config... /Applications/anaconda/bin/gdal-config
rm: conftest.dSYM: is a directory
checking whether to use libLAS... no
checking whether to use PDAL... no
checking whether to use NetCDF... no
checking whether to use GEOS... yes
checking for geos-config... /Applications/anaconda/bin/geos-config
checking for geos_c.h... yes
checking

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-05 Thread Michael Barton

I figured you are working towards an anaconda build. I'm trying something
simpler. What did you change in platform.make?

Michael Barton
School of Human Evolution Change
Center for Social Dynamics & Complexity
Arizona State University

...Sent from my iPad

On Aug 5, 2017, at 11:05 AM, Eric Hutton
> wrote:

Michael,

Those were the sorts of files I was making changes in.

Also, I just realized that I am building things slightly differently than you
and so the stuff I wrote about the temporary folder doesn't apply to you. I'm
building GRASS with conda-build so that it can be a conda installable package.

Eric
On Sat, Aug 5, 2017 at 10:39 AM Michael Barton
> wrote:
Is the place to fix this in ../include/make/Platform.make?

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 Aug 4, 2017, at 3:50 PM, Eric Hutton
> wrote:

Hi Michael

I found that if I manually add linker flags (like "-L$PREFIX/lib -liconv") I
was able to get rid of these errors. I also notice that I had to append them to
the end of the compile command (or at least after things like
"-lgrass_gis.7.2.0" - I guess it has to do with the order that the compiler
looks at libraries to resolve sysbols). Then, at runtime $PREFIX/lib needed to
appear in the LD_LIBRARY_PATH_VAR when running the tests.

I'm not sure of the best way to fix this within the grass build system (simply
adding the link flags to LDFLAGS didn't do the trick). Perhaps tweaking
Rules.make and the like would do the trick? I think the basic problem is that
conda does the entire build within a temporary folder that contains
installations of all the dependencies and that this temporary folder is not
added to all the necessary places.

Eric

On Fri, Aug 4, 2017 at 3:05 PM Michael Barton
> wrote:
After a tedious set of tests, I can say that GRASS will not build with ANY
dependency from Anaconda except SQLite. That is, I went through the
dependencies one-by-one and replaced the path to a Framework version with an
Anaconda version in my configure string. I did a make clean between each build
attempt.

All the versions are close (secondary or tertiary version number) or identical
between William's framework builds and those in Anaconda.

For FreeType and Cairo, the errors of the type I posted yesterday

ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

For the other dependencies, the errors are that the appropriate library cannot
be found, like the following for fftw:

dyld: Library not loaded: @rpath/libfftw3.3.dylib
Referenced from:
/Users/cmbarton/grass_source/trunk/dist.x86_64-apple-darwin16.7.0/lib/libgrass_gmath.7.3.svn.dylib
Reason: image not found

It seems to me like there has to be some kind of systematic reason for this not
to work. Something hardwired in a key makefile or something. The Anaconda
packages are all current builds of normal dependencies.

I am even doing it in an environment in which /Applications/anaconda/bin is
first in my PATH (which works fine if the dependencies are Frameworks).

Any thoughts on this?

Michael

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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-05 Thread Michael Barton

Is the place to fix this in ../include/make/Platform.make?

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 Aug 4, 2017, at 3:50 PM, Eric Hutton 
> wrote:

Hi Michael

I found that if I manually add linker flags (like "-L$PREFIX/lib -liconv") I 
was able to get rid of these errors. I also notice that I had to append them to 
the end of the compile command (or at least after things like 
"-lgrass_gis.7.2.0" - I guess it has to do with the order that the compiler 
looks at libraries to resolve sysbols). Then, at runtime $PREFIX/lib needed to 
appear in the LD_LIBRARY_PATH_VAR when running the tests.

I'm not sure of the best way to fix this within the grass build system (simply 
adding the link flags to LDFLAGS didn't do the trick). Perhaps tweaking 
Rules.make and the like would do the trick? I think the basic problem is that 
conda does the entire build within a temporary folder that contains 
installations of all the dependencies and that this temporary folder is not 
added to all the necessary places.

Eric

On Fri, Aug 4, 2017 at 3:05 PM Michael Barton 
> wrote:
After a tedious set of tests, I can say that GRASS will not build with ANY 
dependency from Anaconda except SQLite. That is, I went through the 
dependencies one-by-one and replaced the path to a Framework version with an 
Anaconda version in my configure string. I did a make clean between each build 
attempt.

All the versions are close (secondary or tertiary version number) or identical 
between William's framework builds and those in Anaconda.

For FreeType and Cairo, the errors of the type I posted yesterday

ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

For the other dependencies, the errors are that the appropriate library cannot 
be found, like the following for fftw:

dyld: Library not loaded: @rpath/libfftw3.3.dylib
  Referenced from: 
/Users/cmbarton/grass_source/trunk/dist.x86_64-apple-darwin16.7.0/lib/libgrass_gmath.7.3.svn.dylib
  Reason: image not found

It seems to me like there has to be some kind of systematic reason for this not 
to work. Something hardwired in a key makefile or something. The Anaconda 
packages are all current builds of normal dependencies.

I am even doing it in an environment in which /Applications/anaconda/bin is 
first in my PATH (which works fine if the dependencies are Frameworks).

Any thoughts on this?

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 Aug 4, 2017, at 12:56 AM, Moritz Lennert 
> wrote:

On 04/08/17 00:33, Vaclav Petras wrote:
Well, the error (below) suggests that wrong library is either linked or 
included. You need to go through the -L and -I paths and see if you need to set 
one of these differently or add additional one for iconv. I don't see how to 
set this through ./configure (I don't see any --with-iconv-includes= or 
--with-iconv-libs=), but you can start by editing the Makefiles or the command 
itself and changing -L and -I directly.
Undefined symbols for architecture x86_64:
  "_iconv", referenced from:
  _draw_main in text3.o
  "_iconv_close", referenced from:
  _draw_main in text3.o
  "_iconv_open", referenced from:
  _draw_main in text3.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Just guessing: Could the error be linked to the use of clang ? Have you tried 
with

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-04 Thread Michael Barton

This made a big difference.

By setting:

export LD_LIBRARY_PATH="/Applications/anaconda/lib:$LD_LIBRARY_PATH

in my terminal before configure, I could successfully build GRASS with all
dependencies in anaconda except FreeType and Cairo.

I tried linking in the --with-cairo-ldflags argument

--with-cairo-ldflags="-lcairo -L$/Applications/anaconda/lib -liconv"

This still gave an error on building, but a different from the clang one.

In file included from text.c:19:
/Applications/anaconda/include/cairo/cairo-ft.h:50:10: fatal error:
'fontconfig/fontconfig.h' file not found
#include

It should be searching in /Applications/anaconda/include/fontconfig

This is definitely closer.

Michael

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

On Aug 4, 2017, at 3:50 PM, Eric Hutton
> wrote:

Hi Michael

Eric

All the versions are close (secondary or tertiary version number) or identical
between William's framework builds and those in Anaconda.

For FreeType and Cairo, the errors of the type I posted yesterday

ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

For the other dependencies, the errors are that the appropriate library cannot
be found, like the following for fftw:

dyld: Library not loaded: @rpath/libfftw3.3.dylib
Referenced from:
/Users/cmbarton/grass_source/trunk/dist.x86_64-apple-darwin16.7.0/lib/libgrass_gmath.7.3.svn.dylib
Reason: image not found

I am even doing it in an environment in which /Applications/anaconda/bin is
first in my PATH (which works fine if the dependencies are Frameworks).

Any thoughts on this?

Michael

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

http://csdc.asu.edu

On Aug 4, 2017, at 12:56 AM, Moritz Lennert
> wrote:

On 04/08/17 00:33, Vaclav Petras wrote:
Well, the error (below) suggests that wrong library is either linked or
included. You need to go through the -L and -I paths and see if you need to set
one of these differently or add additional one for iconv. I don't see how

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-04 Thread Michael Barton

I'm very glad you've found a way forward. Perhaps someone else on this thread
can suggest how it might be incorporated into the GRASS build system. I have
several questions below, that are a result of my spotty understanding (or
ignorance) of the details of build systems.

Michael

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

On Aug 4, 2017, at 3:50 PM, Eric Hutton
> wrote:

Hi Michael

I found that if I manually add linker flags (like "-L$PREFIX/lib -liconv") I
was able to get rid of these errors.

Where do you add these? In every GRASS module? Or someplace more general?

I also notice that I had to append them to the end of the compile command (or
at least after things like "-lgrass_gis.7.2.0" - I guess it has to do with the
order that the compiler looks at libraries to resolve sysbols).

Again, where does this go?

Then, at runtime $PREFIX/lib needed to appear in the LD_LIBRARY_PATH_VAR when
running the tests.

Can I just add this to my .profile or run this the shell I've opened to compile
GRASS prior to configure?

When you say that "conda does the entire build...", are you referring to
building/installing the dependencies? Or are you referring to building GRASS?
So far, I've been trying to build GRASS from the shell, like I've done it
before, but giving the conda paths to dependencies instead of
/System/Frameworks/...

Michael

Eric

All the versions are close (secondary or tertiary version number) or identical
between William's framework builds and those in Anaconda.

For FreeType and Cairo, the errors of the type I posted yesterday

ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

For the other dependencies, the errors are that the appropriate library cannot
be found, like the following for fftw:

dyld: Library not loaded: @rpath/libfftw3.3.dylib
Referenced from:
/Users/cmbarton/grass_source/trunk/dist.x86_64-apple-darwin16.7.0/lib/libgrass_gmath.7.3.svn.dylib
Reason: image not found

I am even doing it in an environment in which /Applications/anaconda/bin is
first in my PATH (which works fine if the dependencies are Frameworks).

Any thoughts on this?

Michael

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

http://csdc.asu.edu

On Aug 4, 2017, at 12:56 AM, Moritz Lennert
> wrote:

On 04/08/17 00:33, Vaclav Petras wrote:
Well, the error (below) suggests that wrong library is either linked or
included. You need to go through the -L and -I

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-04 Thread Michael Barton

After a tedious set of tests, I can say that GRASS will not build with ANY 
dependency from Anaconda except SQLite. That is, I went through the 
dependencies one-by-one and replaced the path to a Framework version with an 
Anaconda version in my configure string. I did a make clean between each build 
attempt.

All the versions are close (secondary or tertiary version number) or identical 
between William's framework builds and those in Anaconda.

For FreeType and Cairo, the errors of the type I posted yesterday

ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

For the other dependencies, the errors are that the appropriate library cannot 
be found, like the following for fftw:

dyld: Library not loaded: @rpath/libfftw3.3.dylib
  Referenced from: 
/Users/cmbarton/grass_source/trunk/dist.x86_64-apple-darwin16.7.0/lib/libgrass_gmath.7.3.svn.dylib
  Reason: image not found

It seems to me like there has to be some kind of systematic reason for this not 
to work. Something hardwired in a key makefile or something. The Anaconda 
packages are all current builds of normal dependencies.

I am even doing it in an environment in which /Applications/anaconda/bin is 
first in my PATH (which works fine if the dependencies are Frameworks).

Any thoughts on this?

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 Aug 4, 2017, at 12:56 AM, Moritz Lennert 
> wrote:

On 04/08/17 00:33, Vaclav Petras wrote:
Well, the error (below) suggests that wrong library is either linked or 
included. You need to go through the -L and -I paths and see if you need to set 
one of these differently or add additional one for iconv. I don't see how to 
set this through ./configure (I don't see any --with-iconv-includes= or 
--with-iconv-libs=), but you can start by editing the Makefiles or the command 
itself and changing -L and -I directly.
Undefined symbols for architecture x86_64:
  "_iconv", referenced from:
  _draw_main in text3.o
  "_iconv_close", referenced from:
  _draw_main in text3.o
  "_iconv_open", referenced from:
  _draw_main in text3.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Just guessing: Could the error be linked to the use of clang ? Have you tried 
with gcc ?

Moritz

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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-04 Thread Moritz Lennert


On 04/08/17 00:33, Vaclav Petras wrote:
Well, the error (below) suggests that wrong library is either linked or 
included. You need to go through the -L and -I paths and see if you need 
to set one of these differently or add additional one for iconv. I don't 
see how to set this through ./configure (I don't see any 
--with-iconv-includes= or --with-iconv-libs=), but you can start by 
editing the Makefiles or the command itself and changing -L and -I directly.



Undefined symbols for architecture x86_64:
   "_iconv", referenced from:
   _draw_main in text3.o
   "_iconv_close", referenced from:
   _draw_main in text3.o
   "_iconv_open", referenced from:
   _draw_main in text3.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see 
invocation)




Just guessing: Could the error be linked to the use of clang ? Have you 
tried with gcc ?


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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-03 Thread Vaclav Petras

Well, the error (below) suggests that wrong library is either linked or
included. You need to go through the -L and -I paths and see if you need to
set one of these differently or add additional one for iconv. I don't see
how to set this through ./configure (I don't see any --with-iconv-includes=
or --with-iconv-libs=), but you can start by editing the Makefiles or the
command itself and changing -L and -I directly.


Undefined symbols for architecture x86_64:
  "_iconv", referenced from:
  _draw_main in text3.o
  "_iconv_close", referenced from:
  _draw_main in text3.o
  "_iconv_open", referenced from:
  _draw_main in text3.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-03 Thread Michael Barton

Here is a little bit from one of the discussions on an error like we have 
reported:

-

Usually the programmer hasn't observed case-sensitivity or something wasn't 
added to the target.

The error is issued by the linker (ld) because it can't resolve a reference to 
a symbol.

-

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 Aug 3, 2017, at 4:19 PM, Michael Barton 
> wrote:

Understood.

Currently, we very much need new Mac binaries. So in this case, I think it will 
be more useful to find out how to fix this on the Mac and then get on a Linux 
box and generalize it for Anaconda, so it can be even more widely available.

So I'm hoping for some input on this error if anyone out there has a thought.

I've googled it and it seems to show up under a number of circumstances. The 
discussion has not been particularly clear, but seems to suggest issues in 
linking--maybe that could be solved by a minor change in the make file. But 
nothing I've read so far seems directly relevant to the GRASS case.

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 Aug 3, 2017, at 3:43 PM, Vaclav Petras 
> wrote:

On Thu, Aug 3, 2017 at 4:23 PM, Michael Barton 
> wrote:

Doing this in Docker is another step after we work this out. One step at a time.

The goal at the moment is to do this on and for the Mac. So we might or might 
not get the same results on Linux, but it would not be relevant to issues on 
the Mac.

My point is that if you do it in Docker other people can test it, i.e. Docker 
as means to an end. For that, you need to do it on Linux rather than Mac, but 
it would be still Anaconda. Once you get that working, you can test if that 
works on Mac or you need to do additional changes. However, it is possible that 
sharing the development through Docker does not have enough benefits 
considering the possible differences between Anaconda on Linux and on Mac.

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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-03 Thread Michael Barton

Understood.

Currently, we very much need new Mac binaries. So in this case, I think it will 
be more useful to find out how to fix this on the Mac and then get on a Linux 
box and generalize it for Anaconda, so it can be even more widely available.

So I'm hoping for some input on this error if anyone out there has a thought.

I've googled it and it seems to show up under a number of circumstances. The 
discussion has not been particularly clear, but seems to suggest issues in 
linking--maybe that could be solved by a minor change in the make file. But 
nothing I've read so far seems directly relevant to the GRASS case.

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 Aug 3, 2017, at 3:43 PM, Vaclav Petras 
> wrote:

On Thu, Aug 3, 2017 at 4:23 PM, Michael Barton 
> wrote:

Doing this in Docker is another step after we work this out. One step at a time.

The goal at the moment is to do this on and for the Mac. So we might or might 
not get the same results on Linux, but it would not be relevant to issues on 
the Mac.

My point is that if you do it in Docker other people can test it, i.e. Docker 
as means to an end. For that, you need to do it on Linux rather than Mac, but 
it would be still Anaconda. Once you get that working, you can test if that 
works on Mac or you need to do additional changes. However, it is possible that 
sharing the development through Docker does not have enough benefits 
considering the possible differences between Anaconda on Linux and on Mac.

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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-03 Thread Vaclav Petras

On Thu, Aug 3, 2017 at 4:23 PM, Michael Barton 
wrote:

>
> Doing this in Docker is another step after we work this out. One step at a
> time.
>
> The goal at the moment is to do this on and for the Mac. So we might or
> might not get the same results on Linux, but it would not be relevant to
> issues on the Mac.
>

My point is that if you do it in Docker other people can test it, i.e.
Docker as means to an end. For that, you need to do it on Linux rather than
Mac, but it would be still Anaconda. Once you get that working, you can
test if that works on Mac or you need to do additional changes. However, it
is possible that sharing the development through Docker does not have
enough benefits considering the possible differences between Anaconda on
Linux and on Mac.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-03 Thread Michael Barton

Thanks Vaclav,

Doing this in Docker is another step after we work this out. One step at a time.

The goal at the moment is to do this on and for the Mac. So we might or might 
not get the same results on Linux, but it would not be relevant to issues on 
the Mac.

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 Aug 3, 2017, at 1:53 PM, Vaclav Petras 
> wrote:

On Thu, Aug 3, 2017 at 3:39 PM, Michael Barton 
> wrote:
Working with a very helpful software engineer at CSDMS here in Boulder, we've 
decided that a good way to work out a new and more sustainable way to create 
binaries would be to compile GRASS under Anaconda. We could then more easily 
package GRASS and all dependencies, and subsequently make it into an Anaconda 
package for those who'd like to install it that way.

Glad to hear that you are moving forward. Sounds like a promising solution for 
Mac and there already were people suggesting Anaconda in general.

So far, we've successfully installed all dependencies AFAICT and successfully 
configured it. But we have not yet been able to compile without errors.
...

I can send config string and full build output if helpful, but thought I'd 
start here.

Is there any way you can do reproduce your Anaconda experiments using a Linux 
machine in Docker and share the Dockerfile?

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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-03 Thread Vaclav Petras

On Thu, Aug 3, 2017 at 3:39 PM, Michael Barton 
wrote:

> Working with a very helpful software engineer at CSDMS here in Boulder,
> we've decided that a good way to work out a new and more sustainable way to
> create binaries would be to compile GRASS under Anaconda. We could then
> more easily package GRASS and all dependencies, and subsequently make it
> into an Anaconda package for those who'd like to install it that way.
>
>
Glad to hear that you are moving forward. Sounds like a promising solution
for Mac and there already were people suggesting Anaconda in general.


> So far, we've successfully installed all dependencies AFAICT and
> successfully configured it. But we have not yet been able to compile
> without errors.
>
...
>
> I can send config string and full build output if helpful, but thought I'd
> start here.
>

Is there any way you can do reproduce your Anaconda experiments using a
Linux machine in Docker and share the Dockerfile?
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-03 Thread Michael Barton

Working with a very helpful software engineer at CSDMS here in Boulder, we've 
decided that a good way to work out a new and more sustainable way to create 
binaries would be to compile GRASS under Anaconda. We could then more easily 
package GRASS and all dependencies, and subsequently make it into an Anaconda 
package for those who'd like to install it that way.

So far, we've successfully installed all dependencies AFAICT and successfully 
configured it. But we have not yet been able to compile without errors. It sort 
of looks like libiconv is the problem, but of course that could be a red 
herring.

We get errors in many modules at the end. Here is what shows up in the 
../lib/driver section. Does anyone recognize this?

I can send config string and full build output if helpful, but thought I'd 
start here.

Thanks
Michael


CMB-MacBook-Pro:~ cmbarton$ cd /Users/cmbarton/grass_source/trunk/lib/driver
CMB-MacBook-Pro:driver cmbarton$ make
cc -dynamiclib -compatibility_version 7.3 -current_version 7.3 -install_name 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libgrass_driver.7.3.svn.dylib -o 
/Users/cmbarton/grass_source/trunk/dist.x86_64-apple-darwin16.7.0/lib/libgrass_driver.7.3.svn.dylib
 -L/Users/cmbarton/grass_source/trunk/dist.x86_64-apple-darwin16.7.0/lib 
-L/Users/cmbarton/grass_source/trunk/dist.x86_64-apple-darwin16.7.0/lib 
-isysroot /Developer/SDKs/MacOSX10.8.sdkOBJ.x86_64-apple-darwin16.7.0/box.o 
OBJ.x86_64-apple-darwin16.7.0/color.o OBJ.x86_64-apple-darwin16.7.0/draw.o 
OBJ.x86_64-apple-darwin16.7.0/erase.o OBJ.x86_64-apple-darwin16.7.0/font.o 
OBJ.x86_64-apple-darwin16.7.0/font2.o 
OBJ.x86_64-apple-darwin16.7.0/font_freetype.o 
OBJ.x86_64-apple-darwin16.7.0/get_t_box.o OBJ.x86_64-apple-darwin16.7.0/graph.o 
OBJ.x86_64-apple-darwin16.7.0/init.o OBJ.x86_64-apple-darwin16.7.0/line_width.o 
OBJ.x86_64-apple-darwin16.7.0/move.o 
OBJ.x86_64-apple-darwin16.7.0/parse_ftcap.o 
OBJ.x86_64-apple-darwin16.7.0/path.o OBJ.x86_64-apple-darwin16.7.0/raster.o 
OBJ.x86_64-apple-darwin16.7.0/set_window.o OBJ.x86_64-apple-darwin16.7.0/text.o 
OBJ.x86_64-apple-darwin16.7.0/text2.o OBJ.x86_64-apple-darwin16.7.0/text3.o 
OBJ.x86_64-apple-darwin16.7.0/text_size.o  -lgrass_gis.7.3.svn 
-L/Applications/anaconda/lib -lfreetype  -liconv
Undefined symbols for architecture x86_64:
  "_iconv", referenced from:
  _draw_main in text3.o
  "_iconv_close", referenced from:
  _draw_main in text3.o
  "_iconv_open", referenced from:
  _draw_main in text3.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** 
[/Users/cmbarton/grass_source/trunk/dist.x86_64-apple-darwin16.7.0/lib/libgrass_driver.7.3.svn.dylib]
 Error 1

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


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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-29 Thread William Kyngesburye

Yeah, it doesn't really look at wxpython at runtime, it's (GRASS_WX64BIT) 
hardwired from compilation.

GRASS_WXBUNDLED is (was? maybe it's been stripped out?) meant to tell the GUI 
code somewhere that wxpython is bundled, there was a problem where wxpython 
wouldn't work, maybe it's fixed now.  GRASS_WXBUNDLED is set in custom bundling 
scripts (not in source).

> On Jul 28, 2017, at 5:24 PM, Michael Barton  wrote:
> 
> A bit more information.
> 
> The grass.sh.in script tries to find a pythonw file to use for Python. It 
> checks the setting of GRASS_PYTHON, then it looks in standard places for 
> system Python. 
> 
> The script also seems to set GRASS_PYTHONWX to the value of GRASS_PYTHON 
> after it searches for a useable Python. It says it is trying to find the 
> Python needed by wxPython, but I can see no code that actually checks 
> wxPython. It simply sets GRASS_PYTHONWX to whatever Python it has found, with 
> "pythonw" as a default. 
> 
> And then after all this, it resets GRASS_PYTHON on lines 203 and 204
> 
> GRASS_PYTHON="python"
> export GRASS_PYTHON
> 
> So all of the prior code is pretty much moot as far as the GRASS_PYTHON 
> environmental variable is concerned. Unless there is some program flow that 
> I'm missing something in the program flow, this default should be set only if 
> no other Python is found. 
> 
> There is also a setting in this script:
> 
> GRASS_WXBUNDLED=
> export GRASS_WXBUNDLED
> 
> This seems potentially useful, but does not seem to be used elsewhere.
> 
> 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 Jul 28, 2017, at 4:02 PM, Michael Barton  wrote:
>> 
>> I was able to track this down. 
>> 
>> I was setting GRASS_PYTHON to ../anaconda/bin/python
>> 
>> The grass.sh.in script for Mac OS is set up to only accept "pythonw" for the 
>> path to python, not "python".
>> 
>> Once I changed my .profile to include the line:
>> 
>> export GRASS_PYTHON="/Applications/anaconda/bin/python"
>> 
>> Grass launches with this as the default. 
>> 
>> Still trying to figure out how GRASS_PYTHONWX works in this script.
>> 
>> 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 Jul 28, 2017, at 1:49 PM, Michael Barton  wrote:
>>> 
>>> ARGGH!
>>> 
>>> Set up and activated virtual environment in conda
>>> Ensured that Anaconda Python is default
>>> Ensured that Anaconda wxPython 4 is default
>>> Compiled GRASS trunk in this environment
>>> Launched the app created and...
>>> 
>>> Launching  GUI in the background, please wait...
>>> GRASS 7.3.svn (nc_spm_08_grass7):~ > python
>>> Python 2.7.10 (default, Feb  7 2017, 00:08:15) 
>>> [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> >>> import wx
>>> >>> import wxversion
>>> >>> wx.VERSION_STRING
>>> '3.0.2.0'
>>> >>> 
>>> 
>>> Using my system Python and system wxPython
>>> 
>>> 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 Jul 28, 2017, at 12:09 PM, Michael Barton  
 wrote:
 
 Previously, we needed to set this path to compile GRASS so that it worked 
 with wxPython wrappers for wxWidgets. I will do a new compile without this 
 argument and see what happens. 
 
 In any case, I need to be able to make sure that GRASS uses the wxPython 
 that is bundled with it by default to avoid differences in versions and 
 SIP issues. 
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics &

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-28 Thread Michael Barton

A bit more information.

The grass.sh.in script tries to find a pythonw file to use for Python. It 
checks the setting of GRASS_PYTHON, then it looks in standard places for system 
Python.

The script also seems to set GRASS_PYTHONWX to the value of GRASS_PYTHON after 
it searches for a useable Python. It says it is trying to find the Python 
needed by wxPython, but I can see no code that actually checks wxPython. It 
simply sets GRASS_PYTHONWX to whatever Python it has found, with "pythonw" as a 
default.

And then after all this, it resets GRASS_PYTHON on lines 203 and 204

GRASS_PYTHON="python"
export GRASS_PYTHON

So all of the prior code is pretty much moot as far as the GRASS_PYTHON 
environmental variable is concerned. Unless there is some program flow that I'm 
missing something in the program flow, this default should be set only if no 
other Python is found.

There is also a setting in this script:

GRASS_WXBUNDLED=
export GRASS_WXBUNDLED

This seems potentially useful, but does not seem to be used elsewhere.

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 Jul 28, 2017, at 4:02 PM, Michael Barton 
> wrote:

I was able to track this down.

I was setting GRASS_PYTHON to ../anaconda/bin/python

The grass.sh.in script for Mac OS is set up to only accept "pythonw" for the 
path to python, not "python".

Once I changed my .profile to include the line:

export GRASS_PYTHON="/Applications/anaconda/bin/python"

Grass launches with this as the default.

Still trying to figure out how GRASS_PYTHONWX works in this script.

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 Jul 28, 2017, at 1:49 PM, Michael Barton 
> wrote:

ARGGH!

Set up and activated virtual environment in conda
Ensured that Anaconda Python is default
Ensured that Anaconda wxPython 4 is default
Compiled GRASS trunk in this environment
Launched the app created and...

Launching  GUI in the background, please wait...
GRASS 7.3.svn (nc_spm_08_grass7):~ > python
Python 2.7.10 (default, Feb  7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import wx
>>> import wxversion
>>> wx.VERSION_STRING
'3.0.2.0'
>>>

Using my system Python and system wxPython

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 Jul 28, 2017, at 12:09 PM, Michael Barton 
> wrote:

Previously, we needed to set this path to compile GRASS so that it worked with 
wxPython wrappers for wxWidgets. I will do a new compile without this argument 
and see what happens.

In any case, I need to be able to make sure that GRASS uses the wxPython that 
is bundled with it by default to avoid differences in versions and SIP issues.

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 Jul 28, 2017, at 7:56 AM, Vaclav Petras 
> wrote:

On Thu, Jul 27, 2017 at 11:52 PM, Michael Barton 
> wrote:
>
> The other issue I'm hitting is that the configure argument to enable 
> wxPython, '-with-wxwidgets=' expects a path to a wx_config file. AFAICT, 
> wxPython 4 does not have such a file. And I can't yet find anything that 
> seems to serve

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-28 Thread Michael Barton

I was able to track this down.

I was setting GRASS_PYTHON to ../anaconda/bin/python

The grass.sh.in script for Mac OS is set up to only accept "pythonw" for the 
path to python, not "python".

Once I changed my .profile to include the line:

export GRASS_PYTHON="/Applications/anaconda/bin/python"

Grass launches with this as the default.

Still trying to figure out how GRASS_PYTHONWX works in this script.

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 Jul 28, 2017, at 1:49 PM, Michael Barton 
> wrote:

ARGGH!

Set up and activated virtual environment in conda
Ensured that Anaconda Python is default
Ensured that Anaconda wxPython 4 is default
Compiled GRASS trunk in this environment
Launched the app created and...

Launching  GUI in the background, please wait...
GRASS 7.3.svn (nc_spm_08_grass7):~ > python
Python 2.7.10 (default, Feb  7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import wx
>>> import wxversion
>>> wx.VERSION_STRING
'3.0.2.0'
>>>

Using my system Python and system wxPython

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 Jul 28, 2017, at 12:09 PM, Michael Barton 
> wrote:

Previously, we needed to set this path to compile GRASS so that it worked with 
wxPython wrappers for wxWidgets. I will do a new compile without this argument 
and see what happens.

In any case, I need to be able to make sure that GRASS uses the wxPython that 
is bundled with it by default to avoid differences in versions and SIP issues.

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 Jul 28, 2017, at 7:56 AM, Vaclav Petras 
> wrote:

On Thu, Jul 27, 2017 at 11:52 PM, Michael Barton 
> wrote:
>
> The other issue I'm hitting is that the configure argument to enable 
> wxPython, '-with-wxwidgets=' expects a path to a wx_config file. AFAICT, 
> wxPython 4 does not have such a file. And I can't yet find anything that 
> seems to serve the same function. I can put in a path to the folder/directory 
> where the wxPython 4 files live. While this compiles without error, I don't 
> think it is using wxPython 4.
>

--with-wxwidgets= is for wxWidgets (C++ library), not wxPython (its Python 
wrapper), so you don't need to use at all. wxPython must be part of the Python 
installation you are using.

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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-28 Thread Michael Barton

Hi William,

That would indeed be useful, especially to make sure a specific version of 
Python and wxPython are used. But it doesn't seem to do anything. Does anyone 
know if this is used anywhere?

Related to this, is there a way to set the Python used at launch?

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 Jul 28, 2017, at 2:19 PM, William Kyngesburye 
> wrote:

I think the intent was to be able to customize python and pythonw separately, 
if only to have that possibility, I don't remember if there was a specific 
reason.

On Jul 28, 2017, at 3:13 PM, Michael Barton 
> wrote:

I had to hack python_wrapper to the following:

if [ -z "$GISBASE" ] ; then
echo "You must be in GRASS GIS to run this program." >&2
exit 1
fi

SYSARCH=`uname -p`
SYSVER=`uname -r | cut -d . -f 1`

if [ ! "$GRASS_PYTHONWX" ] ; then
GRASS_PYTHONWX="pythonw"
fi

exec "$GRASS_PYTHONWX" "$@"

I don't know what GRASS_PYTHONWX does that GRASS_PYTHON does not do.

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 Jul 28, 2017, at 2:06 PM, William Kyngesburye 
> wrote:

Maybe it's the python wrapper - it does 2 things: force python to run 32bit if 
wxpython is 32bit, and run pythonw that wxpython needs.  There is a 2nd env var 
to set pythonw (I think it's only used here): GRASS_PYTHONWX.

On Jul 28, 2017, at 2:49 PM, Michael Barton 
> wrote:

ARGGH!

Set up and activated virtual environment in conda
Ensured that Anaconda Python is default
Ensured that Anaconda wxPython 4 is default
Compiled GRASS trunk in this environment
Launched the app created and...

Launching  GUI in the background, please wait...
GRASS 7.3.svn (nc_spm_08_grass7):~ > python
Python 2.7.10 (default, Feb  7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import wx
>>> import wxversion
>>> wx.VERSION_STRING
'3.0.2.0'
>>>

Using my system Python and system wxPython

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 Jul 28, 2017, at 12:09 PM, Michael Barton 
> wrote:

Previously, we needed to set this path to compile GRASS so that it worked with 
wxPython wrappers for wxWidgets. I will do a new compile without this argument 
and see what happens.

In any case, I need to be able to make sure that GRASS uses the wxPython that 
is bundled with it by default to avoid differences in versions and SIP issues.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-28 Thread Michael Barton

Here is the error and its cause

From the GRASS terminal, I set the environment so that it defaults to Anaconda 
Python and wxPython (the environment of compilation).

GRASS 7.3.svn (nc_spm_08_grass7):~ >  export 
PATH="/Applications/anaconda/bin:$PATH"

Test the environment.

GRASS 7.3.svn (nc_spm_08_grass7):~ > python
Python 2.7.13 |Anaconda custom (x86_64)| (default, Dec 20 2016, 23:05:08)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out: http://continuum.io/thanks and https://anaconda.org
>>> import wx
>>> wx.VERSION_STRING
'4.0.0b1'
>>>

Yes. Defaulting to Anaconda Python and wxPython 4.

Relaunch the GUI. Note the Mac specific error message.

GRASS 7.3.svn (nc_spm_08_grass7):~ > g.gui
Launching  GUI in the background, please wait...
This program needs access to the screen.
Please run with a Framework build of python, and only when you are
logged in on the main display of your Mac.

Tried setting GRASS_PYTHON

GRASS 7.3.svn (nc_spm_08_grass7):~ > export 
GRASS_PYTHON="/Applications/anaconda/bin/pythonw"
GRASS 7.3.svn (nc_spm_08_grass7):~ > g.gui
Launching  GUI in the background, please wait...

This works (note that  export GRASS_PYTHON="/Applications/anaconda/bin/python" 
does NOT work).
AFAICT, it is running with wxPython 4 beta 1 now. At least that is what comes 
up if I launch python from the GRASS terminal, import wx, and then run 
wx.VERSION_STRING. If so, it looks just like wxPython 3, and has all the same 
issues--and no new ones that I can see.

Also, I eliminated the '--with_wxwidgets=' argument and trunk compiles the same 
as with it.

So far so good. I still need to make sure that when I create the app bundle 
with Python and wxPython, GRASS Mac will use those versions and now what is on 
the system.

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 Jul 27, 2017, at 6:34 PM, Anna Petrášová 
> wrote:

On Thu, Jul 27, 2017 at 8:13 PM, Michael Barton 
> wrote:
It seems that GRASS (at least GRASS for Mac) will only use the system
Python. If I set up an environment in which Anaconda python is default,
GRASS will not start and gives an error message that it will only run with
the system Python. I don't know where this is coming from. It doesn't seem
to be from the python_wrapper script. This will need to be changed if I am
to package Python with GRASS.

What exactly is the error? I know I was able to use GRASS_PYTHON
variable previously to set the python I needed.

Anna

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: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=DwIFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=ejnQRWolrucufjW07P5RKvDkaAo__J6-niGuF5D7eNg=97LlCjf7C4a6iG9wGSVOYu1lQuVXSps_-yEnDAGKWIE=
 , 
https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=DwIFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=ejnQRWolrucufjW07P5RKvDkaAo__J6-niGuF5D7eNg=-IglMTXE4z0Ek6alARnfLbHdyXb7iyo7bg3-Gf0Uyb8=

On Jul 27, 2017, at 1:33 PM, Anna Petrášová 
> wrote:

On Thu, Jul 27, 2017 at 3:03 PM, Michael Barton 
>
wrote:

On Jul 27, 2017, at 12:46 PM, Anna Petrášová 
> wrote:

I think you can use pip to install it with whatever Python you use, at
least that's what works on Linux.

How do you specify which Python in pip?

It uses whichever Python is first on the path, you can find out with

which python

probably you can use also something like this:

https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com_a_4910393_1058453=DwIFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=MCkZA0y-uOGAo8gOeYPoP_uqc1lzXM6XCXuCQayAyS0=_vBpVdLmTTjrHrftXdNANYEvTAotd9_enwM-I1H_YFQ=

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-28 Thread William Kyngesburye

I think the intent was to be able to customize python and pythonw separately, 
if only to have that possibility, I don't remember if there was a specific 
reason.

> On Jul 28, 2017, at 3:13 PM, Michael Barton  wrote:
> 
> I had to hack python_wrapper to the following:
> 
> if [ -z "$GISBASE" ] ; then
> echo "You must be in GRASS GIS to run this program." >&2
> exit 1
> fi
> 
> SYSARCH=`uname -p`
> SYSVER=`uname -r | cut -d . -f 1`
> 
> if [ ! "$GRASS_PYTHONWX" ] ; then
> GRASS_PYTHONWX="pythonw"
> fi
> 
> exec "$GRASS_PYTHONWX" "$@"
> 
> 
> I don't know what GRASS_PYTHONWX does that GRASS_PYTHON does not do.
> 
> 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 Jul 28, 2017, at 2:06 PM, William Kyngesburye > > wrote:
>> 
>> Maybe it's the python wrapper - it does 2 things: force python to run 32bit 
>> if wxpython is 32bit, and run pythonw that wxpython needs.  There is a 2nd 
>> env var to set pythonw (I think it's only used here): GRASS_PYTHONWX.
>> 
>>> On Jul 28, 2017, at 2:49 PM, Michael Barton >> > wrote:
>>> 
>>> ARGGH!
>>> 
>>> Set up and activated virtual environment in conda
>>> Ensured that Anaconda Python is default
>>> Ensured that Anaconda wxPython 4 is default
>>> Compiled GRASS trunk in this environment
>>> Launched the app created and...
>>> 
>>> Launching  GUI in the background, please wait...
>>> GRASS 7.3.svn (nc_spm_08_grass7):~ > python
>>> Python 2.7.10 (default, Feb  7 2017, 00:08:15) 
>>> [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> >>> import wx
>>> >>> import wxversion
>>> >>> wx.VERSION_STRING
>>> '3.0.2.0'
>>> >>> 
>>> 
>>> Using my system Python and system wxPython
>>> 
>>> 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 Jul 28, 2017, at 12:09 PM, Michael Barton > wrote:
 
 Previously, we needed to set this path to compile GRASS so that it worked 
 with wxPython wrappers for wxWidgets. I will do a new compile without this 
 argument and see what happens. 
 
 In any case, I need to be able to make sure that GRASS uses the wxPython 
 that is bundled with it by default to avoid differences in versions and 
 SIP issues. 
 
 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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-28 Thread Michael Barton

I had to hack python_wrapper to the following:

if [ -z "$GISBASE" ] ; then
echo "You must be in GRASS GIS to run this program." >&2
exit 1
fi

SYSARCH=`uname -p`
SYSVER=`uname -r | cut -d . -f 1`

if [ ! "$GRASS_PYTHONWX" ] ; then
GRASS_PYTHONWX="pythonw"
fi

exec "$GRASS_PYTHONWX" "$@"

I don't know what GRASS_PYTHONWX does that GRASS_PYTHON does not do.

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 Jul 28, 2017, at 2:06 PM, William Kyngesburye 
> wrote:

Maybe it's the python wrapper - it does 2 things: force python to run 32bit if 
wxpython is 32bit, and run pythonw that wxpython needs.  There is a 2nd env var 
to set pythonw (I think it's only used here): GRASS_PYTHONWX.

On Jul 28, 2017, at 2:49 PM, Michael Barton 
> wrote:

ARGGH!

Set up and activated virtual environment in conda
Ensured that Anaconda Python is default
Ensured that Anaconda wxPython 4 is default
Compiled GRASS trunk in this environment
Launched the app created and...

Launching  GUI in the background, please wait...
GRASS 7.3.svn (nc_spm_08_grass7):~ > python
Python 2.7.10 (default, Feb  7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import wx
>>> import wxversion
>>> wx.VERSION_STRING
'3.0.2.0'
>>>

Using my system Python and system wxPython

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 Jul 28, 2017, at 12:09 PM, Michael Barton 
> wrote:

Previously, we needed to set this path to compile GRASS so that it worked with 
wxPython wrappers for wxWidgets. I will do a new compile without this argument 
and see what happens.

In any case, I need to be able to make sure that GRASS uses the wxPython that 
is bundled with it by default to avoid differences in versions and SIP issues.

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 Jul 28, 2017, at 7:56 AM, Vaclav Petras 
> wrote:

On Thu, Jul 27, 2017 at 11:52 PM, Michael Barton 
> wrote:
>
> The other issue I'm hitting is that the configure argument to enable 
> wxPython, '-with-wxwidgets=' expects a path to a wx_config file. AFAICT, 
> wxPython 4 does not have such a file. And I can't yet find anything that 
> seems to serve the same function. I can put in a path to the folder/directory 
> where the wxPython 4 files live. While this compiles without error, I don't 
> think it is using wxPython 4.
>

--with-wxwidgets= is for wxWidgets (C++ library), not wxPython (its Python 
wrapper), so you don't need to use at all. wxPython must

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-28 Thread Vaclav Petras

On Fri, Jul 28, 2017 at 3:49 PM, Michael Barton 
wrote:

>
> Set up and activated virtual environment in conda
> Ensured that Anaconda Python is default
> Ensured that Anaconda wxPython 4 is default
> Compiled GRASS trunk in this environment
> Launched the app created and...
>
> Launching  GUI in the background, please wait...
> GRASS 7.3.svn (nc_spm_08_grass7):~ > python
> Python 2.7.10 (default, Feb  7 2017, 00:08:15)
> [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import wx
> >>> import wxversion
> >>> wx.VERSION_STRING
> '3.0.2.0'
> >>>
>
> Using my system Python and system wxPython
>

These commands my be useful for debugging this:

$ python --version
$ grass72 /your/test/mapset --exec python --version

$ evn
$ grass72 /your/test/mapset --exec env

You can use -c to pass code to Python, so for example:

$ python -c "import wx; import wxversion; print(wx.VERSION_STRING)"
$ grass72 /your/test/mapset --exec python -c "import wx; import wxversion;
print(wx.VERSION_STRING)"

$ python -c "import sys; print(sys.executable)"
$ grass72 /your/test/mapset --exec python -c "import sys;
print(sys.executable)"

$ python -c "import os; print(os.environ['PATH'])"
$ grass72 /your/test/mapset --exec python -c "import os;
print(os.environ['PATH'])"

$ python -c "import os; print(os.environ['GRASS_PYTHON'])"
$ grass72 /your/test/mapset --exec python -c "import os;
print(os.environ['GRASS_PYTHON'])"

$ python -c "import os; print(os.environ['GRASS_PYTHONWX'])"
$ grass72 /your/test/mapset --exec python -c "import os;
print(os.environ['GRASS_PYTHONWX'])"
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-28 Thread William Kyngesburye

Maybe it's the python wrapper - it does 2 things: force python to run 32bit if 
wxpython is 32bit, and run pythonw that wxpython needs.  There is a 2nd env var 
to set pythonw (I think it's only used here): GRASS_PYTHONWX.

> On Jul 28, 2017, at 2:49 PM, Michael Barton  wrote:
> 
> ARGGH!
> 
> Set up and activated virtual environment in conda
> Ensured that Anaconda Python is default
> Ensured that Anaconda wxPython 4 is default
> Compiled GRASS trunk in this environment
> Launched the app created and...
> 
> Launching  GUI in the background, please wait...
> GRASS 7.3.svn (nc_spm_08_grass7):~ > python
> Python 2.7.10 (default, Feb  7 2017, 00:08:15) 
> [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import wx
> >>> import wxversion
> >>> wx.VERSION_STRING
> '3.0.2.0'
> >>> 
> 
> Using my system Python and system wxPython
> 
> 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 Jul 28, 2017, at 12:09 PM, Michael Barton > > wrote:
>> 
>> Previously, we needed to set this path to compile GRASS so that it worked 
>> with wxPython wrappers for wxWidgets. I will do a new compile without this 
>> argument and see what happens. 
>> 
>> In any case, I need to be able to make sure that GRASS uses the wxPython 
>> that is bundled with it by default to avoid differences in versions and SIP 
>> issues. 
>> 
>> 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 Jul 28, 2017, at 7:56 AM, Vaclav Petras >> > wrote:
>>> 
>>> 
>>> 
>>> On Thu, Jul 27, 2017 at 11:52 PM, Michael Barton >> > wrote:
>>> >
>>> > The other issue I'm hitting is that the configure argument to enable 
>>> > wxPython, '-with-wxwidgets=' expects a path to a wx_config file. AFAICT, 
>>> > wxPython 4 does not have such a file. And I can't yet find anything that 
>>> > seems to serve the same function. I can put in a path to the 
>>> > folder/directory where the wxPython 4 files live. While this compiles 
>>> > without error, I don't think it is using wxPython 4.
>>> >
>>> 
>>> --with-wxwidgets= is for wxWidgets (C++ library), not wxPython (its Python 
>>> wrapper), so you don't need to use at all. wxPython must be part of the 
>>> Python installation you are using.
>>> 
>> 
> 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev

-
William Kyngesburye 
http://www.kyngchaos.com/

"We can die but once, and that once we must die.  To be always fearing, then, 
would not avert it, and would make life miserable."

- Tarzan, on death

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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-28 Thread Michael Barton

ARGGH!

Set up and activated virtual environment in conda
Ensured that Anaconda Python is default
Ensured that Anaconda wxPython 4 is default
Compiled GRASS trunk in this environment
Launched the app created and...

Launching  GUI in the background, please wait...
GRASS 7.3.svn (nc_spm_08_grass7):~ > python
Python 2.7.10 (default, Feb  7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import wx
>>> import wxversion
>>> wx.VERSION_STRING
'3.0.2.0'
>>>

Using my system Python and system wxPython

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 Jul 28, 2017, at 12:09 PM, Michael Barton 
> wrote:

Previously, we needed to set this path to compile GRASS so that it worked with 
wxPython wrappers for wxWidgets. I will do a new compile without this argument 
and see what happens.

In any case, I need to be able to make sure that GRASS uses the wxPython that 
is bundled with it by default to avoid differences in versions and SIP issues.

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 Jul 28, 2017, at 7:56 AM, Vaclav Petras 
> wrote:

On Thu, Jul 27, 2017 at 11:52 PM, Michael Barton 
> wrote:
>
> The other issue I'm hitting is that the configure argument to enable 
> wxPython, '-with-wxwidgets=' expects a path to a wx_config file. AFAICT, 
> wxPython 4 does not have such a file. And I can't yet find anything that 
> seems to serve the same function. I can put in a path to the folder/directory 
> where the wxPython 4 files live. While this compiles without error, I don't 
> think it is using wxPython 4.
>

--with-wxwidgets= is for wxWidgets (C++ library), not wxPython (its Python 
wrapper), so you don't need to use at all. wxPython must be part of the Python 
installation you are using.

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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-28 Thread Michael Barton

Most Mac users are running from the GUI and will not be trying to set an 
environmental variable from the terminal before running a command from the 
terminal. We need to be thinking like most Mac users.

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 Jul 28, 2017, at 7:51 AM, Vaclav Petras 
> wrote:

On Thu, Jul 27, 2017 at 11:52 PM, Michael Barton 
> wrote:
> OK. I'll put it into my .profile and see what happens. Thanks.

On Fri, Jul 28, 2017 at 12:19 AM, Michael Barton 
> wrote:
>
> Tried that and it seems to be ignored too. Here is the output from a terminal 
> in the shell (outside GRASS):
>
> Last login: Thu Jul 27 22:04:37 on ttys001
> CMB-MacBook-Pro:~ cmbarton$ echo $GRASS_PYTHON
> /Applications/anaconda/bin/python
>
> This should make anaconda python (2.7.13) the default.
>
> But here is the output from a GRASS terminal:
>
> GRASS 7.3.svn (nc_spm_08_grass7):~ > echo $GRASS_PYTHON
> python
> GRASS 7.3.svn (nc_spm_08_grass7):~ > python
> Python 2.7.10 (default, Feb  7 2017, 00:08:15)
> [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.

Don't add anything into any .profile or .bash_profile. Do it as Moritz 
suggests, use export right before you run the commands. (You can of course put 
these things in some file and then use `source` command.)

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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-28 Thread Michael Barton

Previously, we needed to set this path to compile GRASS so that it worked with 
wxPython wrappers for wxWidgets. I will do a new compile without this argument 
and see what happens.

In any case, I need to be able to make sure that GRASS uses the wxPython that 
is bundled with it by default to avoid differences in versions and SIP issues.

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 Jul 28, 2017, at 7:56 AM, Vaclav Petras 
> wrote:

On Thu, Jul 27, 2017 at 11:52 PM, Michael Barton 
> wrote:
>
> The other issue I'm hitting is that the configure argument to enable 
> wxPython, '-with-wxwidgets=' expects a path to a wx_config file. AFAICT, 
> wxPython 4 does not have such a file. And I can't yet find anything that 
> seems to serve the same function. I can put in a path to the folder/directory 
> where the wxPython 4 files live. While this compiles without error, I don't 
> think it is using wxPython 4.
>

--with-wxwidgets= is for wxWidgets (C++ library), not wxPython (its Python 
wrapper), so you don't need to use at all. wxPython must be part of the Python 
installation you are using.

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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-28 Thread Michael Barton

Sorry if my message was not clear Moritz.

I showed the output of a non-GRASS terminal window, just to show that the 
GRASS_PYTHON environmental variable was indeed set. I set it in .profile, 
sourced .profile, and then launched GRASS because GRASS looks for Python when 
it launches (or at least that is what the start up message indicates).

But GRASS does not recognize GRASS_PYTHON set at the system level. Not sure why 
this is. It seems that setting it at the system level DOES embed it into the 
~/.grass7/rc file. But again, this seems to have no effect on GRASS at launch, 
where the default system Python is hard coded somewhere.

Setting it from the GRASS terminal is not helpful if my goal is to bundle 
Python with GRASS inside the Mac app. The reason for doing this is to ensure a 
clean working environment for all Mac users, without having to download and 
install extra pieces of the correct version, and to avoid the issue where Mac 
SIP keeps GRASS from running.

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 Jul 28, 2017, at 5:27 AM, Moritz Lennert 
> wrote:

On 28/07/17 06:19, Michael Barton wrote:
Tried that and it seems to be ignored too. Here is the output from a terminal 
in the shell (outside GRASS):
Last login: Thu Jul 27 22:04:37 on ttys001
CMB-MacBook-Pro:~ cmbarton$ echo $GRASS_PYTHON
/Applications/anaconda/bin/python
This should make anaconda python (2.7.13) the default.
But here is the output from a GRASS terminal:
GRASS 7.3.svn (nc_spm_08_grass7):~ > echo $GRASS_PYTHON
python

How and where did you set GRASS_PYTHON ? I'm not an expert in MacOSX, but in 
GNU/Linux if I set 'export GRASS_PYTHON=SomeOtherPython' in one terminal, but 
launch GRASS in the second terminal, GRASS_PYTHON is not set at GRASS startup 
and is thus set to 'python' by default.

GRASS 7.3.svn (nc_spm_08_grass7):~ > python
Python 2.7.10 (default, Feb  7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
Also:
GRASS 7.3.svn (nc_spm_08_grass7):~ > echo $GRASS_PYTHONWX
/usr/bin/pythonw2.7
This environmental variable is set inside GRASS somewhere. It does not show up 
in the shell outside GRASS.
It GRASS ignoring the environmental variable setting for some reason. Is there 
something hardwired in that insists on looking for Python in /usr/bin?

Launching the 'python' binary in the command line does not interact in any way 
with the GRASS_PYTHON variable. If you launch 'python', it will launch the 
first python executable found in PATH.

If you want to see if GRASS_PYTHON correctly runs the python you wanted, then 
run '$GRASS_PYTHON'.

For example:

export GRASS_PYTHON=/usr/bin/python3.6
GRASS 7.3.svn (ETRS89_LAEA):/data/home/mlennert > python
Python 2.7.13 (default, Jan 19 2017, 14:48:08)
[GCC 6.3.0 20170118] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
GRASS 7.3.svn (ETRS89_LAEA):/data/home/mlennert > $GRASS_PYTHON
Python 3.6.2 (default, Jul 17 2017, 13:39:29)
[GCC 6.4.0 20170704] on linux
Type "help", "copyright", "credits" or "license" for more information.

There is a difference between calling 'python' from a command line in a 
terminal (even if the GRASS environnement variables are set, i.e. GRASS has 
been "started") and calling python using $GRASS_PYTHON as is done in the GRASS 
code.

Moritz

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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-28 Thread Vaclav Petras

On Thu, Jul 27, 2017 at 11:52 PM, Michael Barton 
wrote:
>
> The other issue I'm hitting is that the configure argument to enable
wxPython, '-with-wxwidgets=' expects a path to a wx_config file. AFAICT,
wxPython 4 does not have such a file. And I can't yet find anything that
seems to serve the same function. I can put in a path to the
folder/directory where the wxPython 4 files live. While this compiles
without error, I don't think it is using wxPython 4.
>

--with-wxwidgets= is for wxWidgets (C++ library), not wxPython (its Python
wrapper), so you don't need to use at all. wxPython must be part of the
Python installation you are using.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-28 Thread Vaclav Petras

On Thu, Jul 27, 2017 at 11:52 PM, Michael Barton 
wrote:
> OK. I'll put it into my .profile and see what happens. Thanks.

On Fri, Jul 28, 2017 at 12:19 AM, Michael Barton 
wrote:
>
> Tried that and it seems to be ignored too. Here is the output from a
terminal in the shell (outside GRASS):
>
> Last login: Thu Jul 27 22:04:37 on ttys001
> CMB-MacBook-Pro:~ cmbarton$ echo $GRASS_PYTHON
> /Applications/anaconda/bin/python
>
> This should make anaconda python (2.7.13) the default.
>
> But here is the output from a GRASS terminal:
>
> GRASS 7.3.svn (nc_spm_08_grass7):~ > echo $GRASS_PYTHON
> python
> GRASS 7.3.svn (nc_spm_08_grass7):~ > python
> Python 2.7.10 (default, Feb  7 2017, 00:08:15)
> [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.

Don't add anything into any .profile or .bash_profile. Do it as Moritz
suggests, use export right before you run the commands. (You can of course
put these things in some file and then use `source` command.)
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-28 Thread Moritz Lennert

On 28/07/17 06:19, Michael Barton wrote:
Tried that and it seems to be ignored too. Here is the output from a 
terminal in the shell (outside GRASS):

Last login: Thu Jul 27 22:04:37 on ttys001
CMB-MacBook-Pro:~ cmbarton$ echo $GRASS_PYTHON
/Applications/anaconda/bin/python

This should make anaconda python (2.7.13) the default.

But here is the output from a GRASS terminal:

GRASS 7.3.svn (nc_spm_08_grass7):~ > echo $GRASS_PYTHON
python

How and where did you set GRASS_PYTHON ? I'm not an expert in MacOSX, 
but in GNU/Linux if I set 'export GRASS_PYTHON=SomeOtherPython' in one 
terminal, but launch GRASS in the second terminal, GRASS_PYTHON is not 
set at GRASS startup and is thus set to 'python' by default.

GRASS 7.3.svn (nc_spm_08_grass7):~ > python
Python 2.7.10 (default, Feb  7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>>

Also:

GRASS 7.3.svn (nc_spm_08_grass7):~ > echo $GRASS_PYTHONWX
/usr/bin/pythonw2.7

This environmental variable is set inside GRASS somewhere. It does not 
show up in the shell outside GRASS.

It GRASS ignoring the environmental variable setting for some reason. Is 
there something hardwired in that insists on looking for Python in /usr/bin?

Launching the 'python' binary in the command line does not interact in 
any way with the GRASS_PYTHON variable. If you launch 'python', it will 
launch the first python executable found in PATH.

If you want to see if GRASS_PYTHON correctly runs the python you wanted, 
then run '$GRASS_PYTHON'.

For example:

export GRASS_PYTHON=/usr/bin/python3.6
GRASS 7.3.svn (ETRS89_LAEA):/data/home/mlennert > python
Python 2.7.13 (default, Jan 19 2017, 14:48:08)
[GCC 6.3.0 20170118] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
GRASS 7.3.svn (ETRS89_LAEA):/data/home/mlennert > $GRASS_PYTHON
Python 3.6.2 (default, Jul 17 2017, 13:39:29)
[GCC 6.4.0 20170704] on linux
Type "help", "copyright", "credits" or "license" for more information.

There is a difference between calling 'python' from a command line in a 
terminal (even if the GRASS environnement variables are set, i.e. GRASS 
has been "started") and calling python using $GRASS_PYTHON as is done in 
the GRASS code.

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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-27 Thread Michael Barton

Tried that and it seems to be ignored too. Here is the output from a terminal 
in the shell (outside GRASS):

Last login: Thu Jul 27 22:04:37 on ttys001
CMB-MacBook-Pro:~ cmbarton$ echo $GRASS_PYTHON
/Applications/anaconda/bin/python

This should make anaconda python (2.7.13) the default.

But here is the output from a GRASS terminal:

GRASS 7.3.svn (nc_spm_08_grass7):~ > echo $GRASS_PYTHON
python
GRASS 7.3.svn (nc_spm_08_grass7):~ > python
Python 2.7.10 (default, Feb  7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

Also:

GRASS 7.3.svn (nc_spm_08_grass7):~ > echo $GRASS_PYTHONWX
/usr/bin/pythonw2.7

This environmental variable is set inside GRASS somewhere. It does not show up 
in the shell outside GRASS.

It GRASS ignoring the environmental variable setting for some reason. Is there 
something hardwired in that insists on looking for Python in /usr/bin?

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 Jul 27, 2017, at 9:43 PM, Vaclav Petras 
> wrote:

On Thu, Jul 27, 2017 at 11:13 PM, Michael Barton 
> wrote:
I don't remember the exact wording. I had set up a conda virtual environment to 
force GRASS to compile and run with Anaconda Python and wxPython 4. When I 
launched GRASS (trunk), I got an error message that it would only run with a 
system Python. I thought that is weird.

Anyway, I tried setting GRASS_PYTHON to no avail. See below:

 g.gisenv get=GRASS_PYTHON
"/Applications/anaconda/bin/python"GRASS 7.3.svn (nc_spm_08_grass7):~ > python
Python 2.7.10 (default, Feb  7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

GRASS_PYTHON, is set, but it is still using system Python 2.7.10 instead of 
Anaconda Python 2.7.13

GRASS_PYTHON is actually an environmental variable (system driven, not by 
GRASS) , so you need to use:

export GRASS_PYTHON=/.../python  # set value
echo $GRASS_PYTHON  # get value

g.setenv changes the GRASS (environment) variables (aka "GIS env" or "GRASS 
variables").

https://grass.osgeo.org/grass72/manuals/variables.html
https://grass.osgeo.org/grass72/manuals/g.gisenv.html

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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-27 Thread Michael Barton

OK. I'll put it into my .profile and see what happens. Thanks.

The other issue I'm hitting is that the configure argument to enable wxPython, 
'-with-wxwidgets=' expects a path to a wx_config file. AFAICT, wxPython 4 does 
not have such a file. And I can't yet find anything that seems to serve the 
same function. I can put in a path to the folder/directory where the wxPython 4 
files live. While this compiles without error, I don't think it is using 
wxPython 4.

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 Jul 27, 2017, at 9:43 PM, Vaclav Petras 
> wrote:

On Thu, Jul 27, 2017 at 11:13 PM, Michael Barton 
> wrote:
I don't remember the exact wording. I had set up a conda virtual environment to 
force GRASS to compile and run with Anaconda Python and wxPython 4. When I 
launched GRASS (trunk), I got an error message that it would only run with a 
system Python. I thought that is weird.

Anyway, I tried setting GRASS_PYTHON to no avail. See below:

 g.gisenv get=GRASS_PYTHON
"/Applications/anaconda/bin/python"GRASS 7.3.svn (nc_spm_08_grass7):~ > python
Python 2.7.10 (default, Feb  7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

GRASS_PYTHON, is set, but it is still using system Python 2.7.10 instead of 
Anaconda Python 2.7.13

GRASS_PYTHON is actually an environmental variable (system driven, not by 
GRASS) , so you need to use:

export GRASS_PYTHON=/.../python  # set value
echo $GRASS_PYTHON  # get value

g.setenv changes the GRASS (environment) variables (aka "GIS env" or "GRASS 
variables").

https://grass.osgeo.org/grass72/manuals/variables.html
https://grass.osgeo.org/grass72/manuals/g.gisenv.html

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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-27 Thread Vaclav Petras

On Thu, Jul 27, 2017 at 11:13 PM, Michael Barton 
wrote:

> I don't remember the exact wording. I had set up a conda virtual
> environment to force GRASS to compile and run with Anaconda Python and
> wxPython 4. When I launched GRASS (trunk), I got an error message that it
> would only run with a system Python. I thought that is weird.
>
> Anyway, I tried setting GRASS_PYTHON to no avail. See below:
>
>  g.gisenv get=GRASS_PYTHON
> "/Applications/anaconda/bin/python"GRASS 7.3.svn (nc_spm_08_grass7):~ >
> python
> Python 2.7.10 (default, Feb  7 2017, 00:08:15)
> [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>
> GRASS_PYTHON, is set, but it is still using system Python 2.7.10 instead
> of Anaconda Python 2.7.13
>
>

GRASS_PYTHON is actually an environmental variable (system driven, not by
GRASS) , so you need to use:

export GRASS_PYTHON=/.../python  # set value
echo $GRASS_PYTHON  # get value

g.setenv changes the GRASS (environment) variables (aka "GIS env" or "GRASS
variables").

https://grass.osgeo.org/grass72/manuals/variables.html
https://grass.osgeo.org/grass72/manuals/g.gisenv.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-27 Thread Michael Barton

I just discovered something that has probably been giving increasing problems 
lately. Because I've been building binaries, I have not looked at the grass.app 
that is built from just running 'make install' in a long time.

It turns out that whatever creates the *.app automatically bundles some version 
of wxPython. I've been trying to bundle versions made outside of system folders 
to avoid the SIP issue, but there is code that is grabbing wxPython from 
somewhere and putting it into *.app/MacOS/etc/python folder inside the app. 
Hopefully someone reading this can figure out where this is happening and how 
to control it.

It explains why I have not been able to really test wxPython 4, and maybe even 
not wxPython 3. Certainly, it is NOT packaging wxPython 4 files into the app, 
even though I've compiled with explicit paths to the relevant wxPython 4 files.

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 Jul 27, 2017, at 6:34 PM, Anna Petrášová 
> wrote:

On Thu, Jul 27, 2017 at 8:13 PM, Michael Barton 
> wrote:
It seems that GRASS (at least GRASS for Mac) will only use the system
Python. If I set up an environment in which Anaconda python is default,
GRASS will not start and gives an error message that it will only run with
the system Python. I don't know where this is coming from. It doesn't seem
to be from the python_wrapper script. This will need to be changed if I am
to package Python with GRASS.

What exactly is the error? I know I was able to use GRASS_PYTHON
variable previously to set the python I needed.

Anna

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: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=DwIFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=ejnQRWolrucufjW07P5RKvDkaAo__J6-niGuF5D7eNg=97LlCjf7C4a6iG9wGSVOYu1lQuVXSps_-yEnDAGKWIE=
 , 
https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=DwIFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=ejnQRWolrucufjW07P5RKvDkaAo__J6-niGuF5D7eNg=-IglMTXE4z0Ek6alARnfLbHdyXb7iyo7bg3-Gf0Uyb8=

On Jul 27, 2017, at 1:33 PM, Anna Petrášová 
> wrote:

On Thu, Jul 27, 2017 at 3:03 PM, Michael Barton 
>
wrote:

On Jul 27, 2017, at 12:46 PM, Anna Petrášová 
> wrote:

I think you can use pip to install it with whatever Python you use, at
least that's what works on Linux.

How do you specify which Python in pip?

It uses whichever Python is first on the path, you can find out with

which python

probably you can use also something like this:

https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com_a_4910393_1058453=DwIFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=MCkZA0y-uOGAo8gOeYPoP_uqc1lzXM6XCXuCQayAyS0=_vBpVdLmTTjrHrftXdNANYEvTAotd9_enwM-I1H_YFQ=

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:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=DwIFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=MCkZA0y-uOGAo8gOeYPoP_uqc1lzXM6XCXuCQayAyS0=9rsZ1tUV9snbiCH4rN8yrhhd4hDrfvamcPxF7y3cvRE=
,
https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=DwIFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=MCkZA0y-uOGAo8gOeYPoP_uqc1lzXM6XCXuCQayAyS0=8dy6hAPGI8vce9HOn68hYqtyg7hzPG5nT_Nt0fQIGCk=

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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-27 Thread Michael Barton

I don't remember the exact wording. I had set up a conda virtual environment to 
force GRASS to compile and run with Anaconda Python and wxPython 4. When I 
launched GRASS (trunk), I got an error message that it would only run with a 
system Python. I thought that is weird.

Anyway, I tried setting GRASS_PYTHON to no avail. See below:

 g.gisenv get=GRASS_PYTHON
"/Applications/anaconda/bin/python"GRASS 7.3.svn (nc_spm_08_grass7):~ > python
Python 2.7.10 (default, Feb  7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

GRASS_PYTHON, is set, but it is still using system Python 2.7.10 instead of 
Anaconda Python 2.7.13

I went ahead and installed wxPython 4 to my system Python and recompiled. GRASS 
launches and runs fine, looking exactly like it does in wxPython 3, including 
the same bugs. But I'm not sure that it is actually running wxPython 4. When I 
try to test, I get odd errors (see below).

GRASS 7.3.svn (nc_spm_08_grass7):~ > python
Python 2.7.10 (default, Feb  7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import wxversion
>>> import wx
Traceback (most recent call last):
  File "", line 1, in 
  File "/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/__init__.py", 
line 45, in 
from wx._core import *
  File "/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core.py", 
line 4, in 
import _core_
ImportError: 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so: no 
appropriate 64-bit architecture (see "man python" for running in 32-bit mode)
>>>

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 Jul 27, 2017, at 6:34 PM, Anna Petrášová 
> wrote:

On Thu, Jul 27, 2017 at 8:13 PM, Michael Barton 
> wrote:
It seems that GRASS (at least GRASS for Mac) will only use the system
Python. If I set up an environment in which Anaconda python is default,
GRASS will not start and gives an error message that it will only run with
the system Python. I don't know where this is coming from. It doesn't seem
to be from the python_wrapper script. This will need to be changed if I am
to package Python with GRASS.

What exactly is the error? I know I was able to use GRASS_PYTHON
variable previously to set the python I needed.

Anna

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: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=DwIFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=ejnQRWolrucufjW07P5RKvDkaAo__J6-niGuF5D7eNg=97LlCjf7C4a6iG9wGSVOYu1lQuVXSps_-yEnDAGKWIE=
 , 
https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=DwIFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=ejnQRWolrucufjW07P5RKvDkaAo__J6-niGuF5D7eNg=-IglMTXE4z0Ek6alARnfLbHdyXb7iyo7bg3-Gf0Uyb8=

On Jul 27, 2017, at 1:33 PM, Anna Petrášová 
> wrote:

On Thu, Jul 27, 2017 at 3:03 PM, Michael Barton 
>
wrote:

On Jul 27, 2017, at 12:46 PM, Anna Petrášová 
> wrote:

I think you can use pip to install it with whatever Python you use, at
least that's what works on Linux.

How do you specify which Python in pip?

It uses whichever Python is first on the path, you can find out with

which python

probably you can use also something like this:

https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com_a_4910393_1058453=DwIFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=MCkZA0y-uOGAo8gOeYPoP_uqc1lzXM6XCXuCQayAyS0=_vBpVdLmTTjrHrftXdNANYEvTAotd9_enwM-I1H_YFQ=

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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-27 Thread Anna Petrášová

On Thu, Jul 27, 2017 at 8:13 PM, Michael Barton  wrote:
> It seems that GRASS (at least GRASS for Mac) will only use the system
> Python. If I set up an environment in which Anaconda python is default,
> GRASS will not start and gives an error message that it will only run with
> the system Python. I don't know where this is coming from. It doesn't seem
> to be from the python_wrapper script. This will need to be changed if I am
> to package Python with GRASS.

What exactly is the error? I know I was able to use GRASS_PYTHON
variable previously to set the python I needed.

Anna

>
> 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 Jul 27, 2017, at 1:33 PM, Anna Petrášová  wrote:
>
> On Thu, Jul 27, 2017 at 3:03 PM, Michael Barton 
> wrote:
>
>
>
> On Jul 27, 2017, at 12:46 PM, Anna Petrášová  wrote:
>
> I think you can use pip to install it with whatever Python you use, at
> least that's what works on Linux.
>
>
> How do you specify which Python in pip?
>
>
> It uses whichever Python is first on the path, you can find out with
>
> which python
>
> probably you can use also something like this:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com_a_4910393_1058453=DwIFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=MCkZA0y-uOGAo8gOeYPoP_uqc1lzXM6XCXuCQayAyS0=_vBpVdLmTTjrHrftXdNANYEvTAotd9_enwM-I1H_YFQ=
>
>
> 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:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=DwIFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=MCkZA0y-uOGAo8gOeYPoP_uqc1lzXM6XCXuCQayAyS0=9rsZ1tUV9snbiCH4rN8yrhhd4hDrfvamcPxF7y3cvRE=
> ,
> https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=DwIFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=MCkZA0y-uOGAo8gOeYPoP_uqc1lzXM6XCXuCQayAyS0=8dy6hAPGI8vce9HOn68hYqtyg7hzPG5nT_Nt0fQIGCk=
>
>
>
>
>
>
>
>
>
>
>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-27 Thread Michael Barton

It seems that GRASS (at least GRASS for Mac) will only use the system Python. 
If I set up an environment in which Anaconda python is default, GRASS will not 
start and gives an error message that it will only run with the system Python. 
I don't know where this is coming from. It doesn't seem to be from the 
python_wrapper script. This will need to be changed if I am to package Python 
with GRASS.

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 Jul 27, 2017, at 1:33 PM, Anna Petrášová 
> wrote:

On Thu, Jul 27, 2017 at 3:03 PM, Michael Barton 
> wrote:

On Jul 27, 2017, at 12:46 PM, Anna Petrášová 
> wrote:

I think you can use pip to install it with whatever Python you use, at
least that's what works on Linux.

How do you specify which Python in pip?

It uses whichever Python is first on the path, you can find out with

which python

probably you can use also something like this:

https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com_a_4910393_1058453=DwIFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=MCkZA0y-uOGAo8gOeYPoP_uqc1lzXM6XCXuCQayAyS0=_vBpVdLmTTjrHrftXdNANYEvTAotd9_enwM-I1H_YFQ=

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: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=DwIFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=MCkZA0y-uOGAo8gOeYPoP_uqc1lzXM6XCXuCQayAyS0=9rsZ1tUV9snbiCH4rN8yrhhd4hDrfvamcPxF7y3cvRE=
 , 
https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=DwIFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=MCkZA0y-uOGAo8gOeYPoP_uqc1lzXM6XCXuCQayAyS0=8dy6hAPGI8vce9HOn68hYqtyg7hzPG5nT_Nt0fQIGCk=

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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-27 Thread Anna Petrášová

On Thu, Jul 27, 2017 at 3:03 PM, Michael Barton  wrote:
>
>
> On Jul 27, 2017, at 12:46 PM, Anna Petrášová  wrote:
>
> I think you can use pip to install it with whatever Python you use, at
> least that's what works on Linux.
>
>
> How do you specify which Python in pip?

It uses whichever Python is first on the path, you can find out with

which python

probably you can use also something like this:

https://stackoverflow.com/a/4910393/1058453

>
> 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
>
>
>
>
>
>
>
>
>
>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-27 Thread Michael Barton



On Jul 27, 2017, at 12:46 PM, Anna Petrášová 
> wrote:

I think you can use pip to install it with whatever Python you use, at
least that's what works on Linux.

How do you specify which Python in pip?

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












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

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-27 Thread Anna Petrášová

On Thu, Jul 27, 2017 at 2:32 PM, Michael Barton  wrote:
> Anna,
>
> Thanks for the quick response. See below.
>
> 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 Jul 27, 2017, at 12:07 PM, Anna Petrášová  wrote:
>
> On Thu, Jul 27, 2017 at 1:54 PM, Michael Barton 
> wrote:
>
> Here is a report on this effort, including identifying several items that
> will need to be changed by others for this to be successful.
>
> I've successfully compiled GRASS 7 64bit, with wxPython 3.0.2.0 under the
> current OS (Sierra = OS X 10.12.x). I'm using the most current Kyngesburye
> frameworks for GDAL, Numpy, and MatPlotLib.
>
> No binaries or bundled dependencies yet.
>
> Issues that need to be resolved.
>
> 1. the 'python_wrapper' bash script in ../macosx/app needs to be updated to
> allow for full 64bit compiling with wxPython. It currently tries to force
> 32bit Python if wxPython is present. I've done a hack but it is probably not
> the right thing for the long term.
>
> 2. wxGUI needs a several fixes to run correctly with wxPython 3.
>
> 2.1 When switching from 3D to 2D, the 'rotate 3D' and 'airplane' buttons are
> not destroyed. They overprint the zoom to map extents button of 2D mode and
> will crash the GUI if pressed.
>
>
> I know about this one.
>
>
> OK. Probably not too hard I hope.
>
>
>
> 2.2 A custom control needs to be updated or replaced because it does not
> recognize mouse clicks. It is used in a number of different places,
> including in the bivariate histogram tool where it is used to select pairs
> of maps for histogramming. You can navigate this control (a pulldown) with
> arrow keys but not a mouse.
>
> This is hard to solve, I don't think there is a good widget to replace this
> one.
>
>
> I don't see any noticeable difference between this control and the one used
> for r.patch (which works).

Maybe I got confused about this one, I need to look at it then.

>
>
> 2.3 selecting g.gui.iclass will crash the GUI. I cannot get any error to
> come up on the console before the crash, and there is nothing in the
> terminal.
>
>
> I don't know about this one, maybe some ctypes thing, but at least
> it's not a major component.
>
>
> Right. But hopefully someone can figure it out.
>
>
> Another one I know about is the raster digitizer, where I need to
> tweak the toolbar code to not crash, but I didn't get to it yet.
>
>
> Haven't tested that.
>
>
> Could you possibly try wxPython 4 (Phoenix) with trunk? I am wondering
> how that looks like...
>
>
> Sure. Is the configure script similar? My worry with wxPython 4 currently,
> is that it seems like it must be installed into a system folder where it
> might cause SIP problems.

I think you can use pip to install it with whatever Python you use, at
least that's what works on Linux.

Anna

>
> Michael
>
>
> Thanks,
>
> Anna
>
>
> That's all I've hit so far. I hope to start working on bundling for a binary
> next week.
>
> 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:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=DwIBaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=47Q9MXJZRCcL5i9M9PgT2F3tdAlQVBzW92JuJlbxyu8=2nHCPVvo7tAxX8GU1RH1_aM-1_Bgdb9GDAtSEebe1Rc=
> ,
> https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=DwIBaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=47Q9MXJZRCcL5i9M9PgT2F3tdAlQVBzW92JuJlbxyu8=-yI7_BSCJLWbfaDFGLVJN7xdKGL4heYGzAbjoFboEus=
>
>
>
>
>
> On Jul 18, 2017, at 2:26 PM, Michael Barton  wrote:
>
> Yesterday, I sent this message off-list to Anna and Vaclav. Anna asked if I
> could repost to the dev list. So I'm doing so here.
>
> I have some time (I hope) on an upcoming research trip to NCAR, along with
> some promised help of software engineers at the CSDMS NSF facility. So I'm
> going to try again to come up with a new GRASS compiling and binary creation
> protocol.
>
> I think this will involve the following components:
>
> 1. Switch from the outdated PackageMaker.app to the current way of making
> Mac packages. This requires changes to the current binary bundling scripts.
>
> 2. Bundle all

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-27 Thread Michael Barton

Here is a report on this effort, including identifying several items that will 
need to be changed by others for this to be successful.

I've successfully compiled GRASS 7 64bit, with wxPython 3.0.2.0 under the 
current OS (Sierra = OS X 10.12.x). I'm using the most current Kyngesburye 
frameworks for GDAL, Numpy, and MatPlotLib.

No binaries or bundled dependencies yet.

Issues that need to be resolved.

1. the 'python_wrapper' bash script in ../macosx/app needs to be updated to 
allow for full 64bit compiling with wxPython. It currently tries to force 32bit 
Python if wxPython is present. I've done a hack but it is probably not the 
right thing for the long term.

 2. wxGUI needs a several fixes to run correctly with wxPython 3.

2.1 When switching from 3D to 2D, the 'rotate 3D' and 'airplane' buttons are 
not destroyed. They overprint the zoom to map extents button of 2D mode and 
will crash the GUI if pressed.

2.2 A custom control needs to be updated or replaced because it does not 
recognize mouse clicks. It is used in a number of different places, including 
in the bivariate histogram tool where it is used to select pairs of maps for 
histogramming. You can navigate this control (a pulldown) with arrow keys but 
not a mouse.

2.3 selecting g.gui.iclass will crash the GUI. I cannot get any error to come 
up on the console before the crash, and there is nothing in the terminal.

That's all I've hit so far. I hope to start working on bundling for a binary 
next week.

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 Jul 18, 2017, at 2:26 PM, Michael Barton 
> wrote:

Yesterday, I sent this message off-list to Anna and Vaclav. Anna asked if I 
could repost to the dev list. So I'm doing so here.

I have some time (I hope) on an upcoming research trip to NCAR, along with some 
promised help of software engineers at the CSDMS NSF facility. So I'm going to 
try again to come up with a new GRASS compiling and binary creation protocol.

I think this will involve the following components:

1. Switch from the outdated PackageMaker.app to the current way of making Mac 
packages. This requires changes to the current binary bundling scripts.

2. Bundle all dependencies (including the current, separate frameworks) into 
the new package distribution so that everything needed is in the grass7.app Can 
this be done with binary "framework" installations of dependencies or is it 
necessary to compile all from scratch to do this?

3. As part of 2, make sure that all dependencies are compiled outside of the 
/usr folders on the Mac to avoid SIP conflicts

4. To accomplish #2 and #3 for wxPython, we probably need to switch to wxPython 
3 (or the new wxPython Phoenix if it is working correctly). This would also 
permit compiling ALL GRASS 64 bit, alleviating additional issues.

5. Because of recent change to GRASS GUI and a bug in Mac system Python 2.7.10, 
it may be necessary to also bundle an updated Python (2.7.11 or higher) with 
the new grass7.app. This (and #2) would make the installation package 
significantly larger, but would avoid mismatched versions of Python and 
wxPython. It would also avoid potential conflicts between Mac system Python and 
other versions a user might have installed (e.g., with Anaconda).

Last fall, I was stuck on gettext. I will try again with bundline it, but this 
may not be solvable by me because it involves a hard-coded path in the build 
files that point to gettext files in /usr/local and no way to send an alternate 
path (e.g., a configure argument like '--with_gettext_libs='. This will need to 
be fixed by whoever manages the build system. Otherwise, I'll have to drop 
internationalization support for the Mac, which would be a shame.

An additional thing to note. While it may be possible for some to get GRASS 
compiled on the Mac using Homebrew, Macports, etc., the goal here is to create 
a normal DMG binary that any Mac user can download and install, without having 
to compile GRASS--or to install Linux like package managers first.

If anyone has experience in creating Mac DMGs, with bundled dependencies, I'd 
love to hear from you. Any other suggestions are welcome too.


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:

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-27 Thread Anna Petrášová

On Thu, Jul 27, 2017 at 1:54 PM, Michael Barton  wrote:
> Here is a report on this effort, including identifying several items that
> will need to be changed by others for this to be successful.
>
> I've successfully compiled GRASS 7 64bit, with wxPython 3.0.2.0 under the
> current OS (Sierra = OS X 10.12.x). I'm using the most current Kyngesburye
> frameworks for GDAL, Numpy, and MatPlotLib.
>
> No binaries or bundled dependencies yet.
>
> Issues that need to be resolved.
>
> 1. the 'python_wrapper' bash script in ../macosx/app needs to be updated to
> allow for full 64bit compiling with wxPython. It currently tries to force
> 32bit Python if wxPython is present. I've done a hack but it is probably not
> the right thing for the long term.
>
>  2. wxGUI needs a several fixes to run correctly with wxPython 3.
>
> 2.1 When switching from 3D to 2D, the 'rotate 3D' and 'airplane' buttons are
> not destroyed. They overprint the zoom to map extents button of 2D mode and
> will crash the GUI if pressed.

I know about this one.

>
> 2.2 A custom control needs to be updated or replaced because it does not
> recognize mouse clicks. It is used in a number of different places,
> including in the bivariate histogram tool where it is used to select pairs
> of maps for histogramming. You can navigate this control (a pulldown) with
> arrow keys but not a mouse.
>
This is hard to solve, I don't think there is a good widget to replace this one.

> 2.3 selecting g.gui.iclass will crash the GUI. I cannot get any error to
> come up on the console before the crash, and there is nothing in the
> terminal.

I don't know about this one, maybe some ctypes thing, but at least
it's not a major component.

Another one I know about is the raster digitizer, where I need to
tweak the toolbar code to not crash, but I didn't get to it yet.

Could you possibly try wxPython 4 (Phoenix) with trunk? I am wondering
how that looks like...

Thanks,

Anna

>
> That's all I've hit so far. I hope to start working on bundling for a binary
> next week.
>
> 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 Jul 18, 2017, at 2:26 PM, Michael Barton  wrote:
>
> Yesterday, I sent this message off-list to Anna and Vaclav. Anna asked if I
> could repost to the dev list. So I'm doing so here.
>
> I have some time (I hope) on an upcoming research trip to NCAR, along with
> some promised help of software engineers at the CSDMS NSF facility. So I'm
> going to try again to come up with a new GRASS compiling and binary creation
> protocol.
>
> I think this will involve the following components:
>
> 1. Switch from the outdated PackageMaker.app to the current way of making
> Mac packages. This requires changes to the current binary bundling scripts.
>
> 2. Bundle all dependencies (including the current, separate frameworks) into
> the new package distribution so that everything needed is in the grass7.app
> Can this be done with binary "framework" installations of dependencies or is
> it necessary to compile all from scratch to do this?
>
> 3. As part of 2, make sure that all dependencies are compiled outside of the
> /usr folders on the Mac to avoid SIP conflicts
>
> 4. To accomplish #2 and #3 for wxPython, we probably need to switch to
> wxPython 3 (or the new wxPython Phoenix if it is working correctly). This
> would also permit compiling ALL GRASS 64 bit, alleviating additional issues.
>
> 5. Because of recent change to GRASS GUI and a bug in Mac system Python
> 2.7.10, it may be necessary to also bundle an updated Python (2.7.11 or
> higher) with the new grass7.app. This (and #2) would make the installation
> package significantly larger, but would avoid mismatched versions of Python
> and wxPython. It would also avoid potential conflicts between Mac system
> Python and other versions a user might have installed (e.g., with Anaconda).
>
> Last fall, I was stuck on gettext. I will try again with bundline it, but
> this may not be solvable by me because it involves a hard-coded path in the
> build files that point to gettext files in /usr/local and no way to send an
> alternate path (e.g., a configure argument like '--with_gettext_libs='. This
> will need to be fixed by whoever manages the build system. Otherwise, I'll
> have to drop internationalization support for the Mac, which would be a
> shame.
>
> An additional thing to note. While it may be possible for some to get GRASS
> compiled on the Mac using Homebrew, Macports, etc., the goal here is to
> create a normal DMG binary that any Mac user can download and

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-20 Thread Vaclav Petras

On Thu, Jul 20, 2017 at 3:34 AM, Rainer Krug  wrote:

> On 19 Jul 2017, at 21:54, Vaclav Petras  wrote:
>
> On Wed, Jul 19, 2017 at 12:42 PM, Michael Barton 
> wrote:
>
>>
>> My group (CoMSES Net) is looking into Docker as a means of more
>> reproducible research in modeling science. Initial tests have gone OK, but
>> show that doing software with a GUI is considerably more complicated than
>> doing code that just runs from the command line. It might ultimately be
>> worthwhile to package GRASS as a Docker image.
>>
>
> We don't have an official GRASS Docker image. Maybe it wouldn't be even
> that advantageous for open science purposes.
>
>
> I disagree here - it would be quite an advantage. See for example the
> suite of rocker R images which are available and also used quite a bit (I
> assume). There is even a spatial one (https://hub.docker.com/r/rock
> er/geospatial/) which was added recentlyI, and I am still planning to
> build on that bundle an image which includes GRASS so that you have one
> Docker image for all your basic spatial GIS needs.
>
> Anyway - I think a  Docker image which is “officially” supported (which
> does not contain the GUI, only the command line) would be a very good
> starting point for further very useful Docker container. At least, there is
> another readable recipe for building GRASS from source (in addition to the
> TravisCI test).
>

I agree. There are two or three different cases. 1) Scientific images like
the R one you mentioned which won't be dedicated GRASS GIS images but
rather bundles where GRASS GIS is only one of the components. 2) Testing
image for build and running tests. The Dockerfile for some basic case can
be directly in the GRASS repository. 3) Dedicated Dockerfile/images for
specific projects, e.g. in the forestfrag3d repository there is a certain
development version with a custom patch (because of a bug). In this case
official image would not work because an that would be a stable release and
binary.

You can look at it also from a perspective of the GRASS code source. 1)
Dockerfile in the GRASS repository should use the code it lives in. 2) Some
software bundle may prefer to use some binary distribution (e.g. Ubuntu
PPAs). 3) Specific projects may need to use specific version of the code
and will download it from the repository.

> Anyway, we have already many Dockerfiles. See for example one from me
> which I created for reproducibility of my recent paper:
>
> https://github.com/wenzeslaus/forestfrag3d/blob/master/Dockerfile
>
> In the case of that repository, the idea is that user can (but does not
> have to) run GRASS GIS or QGIS (with GRASS GIS) natively on the data
> created in the Docker image, but the main outputs are PNG images, so no
> special software is necessary.
>
>
> So you have a GRASS Docker image, data is stored in /data in the native
> system, you run the Docker GRASS to generate data, and you than can use a
> native GRASS to do further work with the data - is this correct?
>

Yes. I provide people with Dockerfile through ZIP from paper or Git/GitHub
(as opposed to image from DockerHub). When running the container (`docker
run`) you specify what local/native directory should be linked to the
/data. All the intermediate and final outputs are stored there and
accessible when the `docker run` is done.

Creating and publishing a Docker image would probably add more stability to
the published work as it is a frozen state with all things included. (And
the repository with Dockerfile providing just the code for cases when
somebody wants to modify it.)

>
>
> In past, I had success in using Docker with SSH (all local). However, for
> future it seems that things like Jupyter Notebook (with its widgets) or a
> general web interface to GRASS GIS are a way how to get a GUI while using a
> Docker image.
>
>
> Yes - a web GUI would be perfect - either as a standalone app which
> connects to a GRASS session via e.g. ssh (which could be a local GRASS
> Docker image) our local GRASS, or via a server which is in the  Docker
> image installed (as is with the RStudio images at
> https://hub.docker.com/r/rocker/rstudio/.
>

What is the web GUI, i.e. how to get it to the web browser seems to be the
critical part here. But SSH may be a sufficient solution for now (e.g.
MobaXterm seem to work well for MS Win users - although I didn't see it
with Docker).

>
> A Jupyter Notebook (never used it, but using RStudio Notebooks - I assume
> very similar?) would be like literal programming - correct? And the results
> (e.g. results) would be embedded in the resulting document?
>

Yes, they are similar. Code, text, results - all in one document. Jupyter
Notebook can also do widgets, i.e. you can have sliders or input boxes, so
the user doesn't have to change the code, it is enough to fiddle to a
dedicated minimalistic GUI. (Connecting this with GRASS parser and modules
may make it quite general

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-07-19 Thread Michael Barton

Thanks Rainer,

If we can make GRASS install as much like a normal app as possible, it will be 
accessible to more users. So that has been my goal. I will probably drop back 
from the added things I was packaging previously (e.g., LAS support) to just 
get a new system working if it can be done.

My group (CoMSES Net) is looking into Docker as a means of more reproducible 
research in modeling science. Initial tests have gone OK, but show that doing 
software with a GUI is considerably more complicated than doing code that just 
runs from the command line. It might ultimately be worthwhile to package GRASS 
as a Docker image. But then people would have to install and deal with Docker 
to run it.

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 Jul 19, 2017, at 12:28 AM, Rainer Krug 
> wrote:

Dear Michael,

On 18 Jul 2017, at 22:26, Michael Barton 
> wrote:

Yesterday, I sent this message off-list to Anna and Vaclav. Anna asked if I 
could repost to the dev list. So I'm doing so here.

I have some time (I hope) on an upcoming research trip to NCAR, along with some 
promised help of software engineers at the CSDMS NSF facility. So I'm going to 
try again to come up with a new GRASS compiling and binary creation protocol.

I think this will involve the following components:

1. Switch from the outdated PackageMaker.app to the current way of making Mac 
packages. This requires changes to the current binary bundling scripts.

2. Bundle all dependencies (including the current, separate frameworks) into 
the new package distribution so that everything needed is in the grass7.app Can 
this be done with binary "framework" installations of dependencies or is it 
necessary to compile all from scratch to do this?

3. As part of 2, make sure that all dependencies are compiled outside of the 
/usr folders on the Mac to avoid SIP conflicts

4. To accomplish #2 and #3 for wxPython, we probably need to switch to wxPython 
3 (or the new wxPython Phoenix if it is working correctly). This would also 
permit compiling ALL GRASS 64 bit, alleviating additional issues.

5. Because of recent change to GRASS GUI and a bug in Mac system Python 2.7.10, 
it may be necessary to also bundle an updated Python (2.7.11 or higher) with 
the new grass7.app. This (and #2) would make the installation package 
significantly larger, but would avoid mismatched versions of Python and 
wxPython. It would also avoid potential conflicts between Mac system Python and 
other versions a user might have installed (e.g., with Anaconda).

Last fall, I was stuck on gettext. I will try again with bundline it, but this 
may not be solvable by me because it involves a hard-coded path in the build 
files that point to gettext files in /usr/local and no way to send an alternate 
path (e.g., a configure argument like '--with_gettext_libs='. This will need to 
be fixed by whoever manages the build system. Otherwise, I'll have to drop 
internationalization support for the Mac, which would be a shame.

An additional thing to note. While it may be possible for some to get GRASS 
compiled on the Mac using Homebrew, Macports, etc., the goal here is to create 
a normal DMG binary that any Mac user can download and install, without having 
to compile GRASS--or to install Linux like package managers first.

This sounds like a good plan and would be a valuable addition to the home-brew 
/ Macports way of installing grass.

Just to clarify one point concerning homebrew: homebrew aims at providing 
pre-compiled binaries (so called “bottles”) which are used normally, and the 
normal installation of grass on home-brew on sierra does not require grass to 
be compiled locally.

I see all three ways (actually four - docker should be included as well!) of 
installing and using grass as equivalent and geared for different users / usage 
scenarios / workflows. So each of them has it’s merits and should be provided.

If anyone has experience in creating Mac DMGs, with bundled dependencies, I'd 
love to hear from you. Any other suggestions are welcome too.

Unfortunately no experiences, but I assume you know, you can Parallels Light is 
available for free, and allows you to run linux and Mac virtual machines on a 
mac - perfect for testing?

Cheers,

Rainer

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

[GRASS-dev] New attempt to update GRASS for Mac

2017-07-18 Thread Michael Barton

Yesterday, I sent this message off-list to Anna and Vaclav. Anna asked if I 
could repost to the dev list. So I'm doing so here.

I have some time (I hope) on an upcoming research trip to NCAR, along with some 
promised help of software engineers at the CSDMS NSF facility. So I'm going to 
try again to come up with a new GRASS compiling and binary creation protocol.

I think this will involve the following components:

1. Switch from the outdated PackageMaker.app to the current way of making Mac 
packages. This requires changes to the current binary bundling scripts.

2. Bundle all dependencies (including the current, separate frameworks) into 
the new package distribution so that everything needed is in the grass7.app Can 
this be done with binary "framework" installations of dependencies or is it 
necessary to compile all from scratch to do this?

3. As part of 2, make sure that all dependencies are compiled outside of the 
/usr folders on the Mac to avoid SIP conflicts

4. To accomplish #2 and #3 for wxPython, we probably need to switch to wxPython 
3 (or the new wxPython Phoenix if it is working correctly). This would also 
permit compiling ALL GRASS 64 bit, alleviating additional issues.

5. Because of recent change to GRASS GUI and a bug in Mac system Python 2.7.10, 
it may be necessary to also bundle an updated Python (2.7.11 or higher) with 
the new grass7.app. This (and #2) would make the installation package 
significantly larger, but would avoid mismatched versions of Python and 
wxPython. It would also avoid potential conflicts between Mac system Python and 
other versions a user might have installed (e.g., with Anaconda).

Last fall, I was stuck on gettext. I will try again with bundline it, but this 
may not be solvable by me because it involves a hard-coded path in the build 
files that point to gettext files in /usr/local and no way to send an alternate 
path (e.g., a configure argument like '--with_gettext_libs='. This will need to 
be fixed by whoever manages the build system. Otherwise, I'll have to drop 
internationalization support for the Mac, which would be a shame.

An additional thing to note. While it may be possible for some to get GRASS 
compiled on the Mac using Homebrew, Macports, etc., the goal here is to create 
a normal DMG binary that any Mac user can download and install, without having 
to compile GRASS--or to install Linux like package managers first.

If anyone has experience in creating Mac DMGs, with bundled dependencies, I'd 
love to hear from you. Any other suggestions are welcome too.


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















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

53 matches

Mail list logo