[GRASS-dev] parallelizing GRASS modules
I lost the previous thread but wanted to respond to your question about which modules might benefit from speedup. In our recursive landscape evolution module (r.landscape.evol.py), the two GRASS modules that take the most time are r.watershed, r.stats, and r.walk, especially r.watershed and r.stats since we need to run these every model cycle. The speedup of r.watershed of a few years back made an enormous difference in our model run times. But it is still time consuming on landscapes with large numbers of cells. If parallelization could speed this up, it would be great. I'm not sure that r.stats can be parallelized or not, but speedup would be helpful. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-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 http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] color for each cell?
Is there a way to find out the color value for every cat value in a raster map? Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-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 http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #1248: r.thin may be broken
Thanks. I'll give it a try. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Jan 4, 2011, at 6:49 AM, GRASS GIS wrote: #1248: r.thin may be broken --+- Reporter: cmbarton | Owner: grass-...@… Type: defect | Status: reopened Priority: normal | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Resolution: |Keywords: r.thin Platform: Unspecified | Cpu: Unspecified --+- Comment(by mmetz): Replying to [comment:7 cmbarton]: Replying to [comment:6 hamish]: Markus M suggested keeping this open, at least as an enhancement, because he didn't feel that this was a proper fix. It should be properly fixed in r44866. Zero is now a valid number, all non-NULL cells are treated as lines. Markus M -- Ticket URL: https://trac.osgeo.org/grass/ticket/1248#comment:9 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GRASS 6.4.1 testing - v.digit
Just did an update from the svn release branch this morning and am testing GRASS 6.4.1 There is a piece of left over testing code in toolbox.tcl from v.digit (line 55) that puts the button number to the screen. Can I just remove it and commit or do I need to do something special with respect to RC1? Also, it seems like the tcltk digitizer is not making areas. I can create the boundary and add a centroid, but it does not turn into an area when saved. Perhaps I'm missing something here and someone else might want to test this. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-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 http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] recent updates to Vlib break vectors in GRASS 7
Will this be difficult to fix? Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Dec 29, 2010, at 4:32 PM, Glynn Clements wrote: William Kyngesburye wrote: I suspect it's because r44722 added gprojects.h to Vlib, in particular that open_ogr.c where Michael got the error. Erm, yeah. That's sounds like the most likely explanation. There are a lot sources in vlib, so I didn't check if any others included gprojects.h indirectly. So, the question then: add PROJINC to VECT_CFLAGS (for all vector stuff) or to the vlib makefile only? Vlib/Makefile only. The reason for VECT_CFLAGS is that vector.h includes geos_c.h and vect/dig_structs.h includes ogr_api.h, so *anything* which uses those headers needs the appropriate -I switches or an error will occur, even if the module doesn't actually use the structure or function declarations which use the OGR/GEOS types. But simply including the vector headers doesn't pull in the PROJ headers, so there's no need for VECT_CFLAGS to contain $(PROJINC). Ideally, -I switches (and to a lesser extent, -L switches) should be kept to a minimum; the more directories in a search path, the greater the chance of encountering conflicting file names. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] recent updates to Vlib break vectors in GRASS 7
It compiled without errors. Thanks! Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Jan 2, 2011, at 5:57 PM, William Kyngesburye wrote: Try it now. On Jan 2, 2011, at 6:16 PM, Barton Michael wrote: Will this be difficult to fix? Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Dec 29, 2010, at 4:32 PM, Glynn Clements wrote: William Kyngesburye wrote: I suspect it's because r44722 added gprojects.h to Vlib, in particular that open_ogr.c where Michael got the error. Erm, yeah. That's sounds like the most likely explanation. There are a lot sources in vlib, so I didn't check if any others included gprojects.h indirectly. So, the question then: add PROJINC to VECT_CFLAGS (for all vector stuff) or to the vlib makefile only? Vlib/Makefile only. The reason for VECT_CFLAGS is that vector.h includes geos_c.h and vect/dig_structs.h includes ogr_api.h, so *anything* which uses those headers needs the appropriate -I switches or an error will occur, even if the module doesn't actually use the structure or function declarations which use the OGR/GEOS types. But simply including the vector headers doesn't pull in the PROJ headers, so there's no need for VECT_CFLAGS to contain $(PROJINC). Ideally, -I switches (and to a lesser extent, -L switches) should be kept to a minimum; the more directories in a search path, the greater the chance of encountering conflicting file names. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ The equator is so long, it could encircle the earth completely once. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] recent updates to Vlib break vectors in GRASS 7
Thanks for finding the problem William. How can this be fixed? Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Dec 28, 2010, at 7:29 AM, William Kyngesburye wrote: On Dec 28, 2010, at 1:20 AM, Markus Neteler wrote: On Tue, Dec 28, 2010 at 6:51 AM, Hamish hamis...@yahoo.com wrote: Michael wrote: gcc -g -O2 -arch i386 -arch x86_64 -fno-common -I/Users/Shared/grass_dev/grass70_dev/dist.i386-apple-darwin10.5.0/include -I/Users/Shared/grass_dev/grass70_dev/dist.i386-apple-darwin10.5.0/include -D_FILE_OFFSET_BITS=64 -I/Library/Frameworks/GDAL.framework/Versions/1.7/Headers -I/Library/Frameworks/GEOS.framework/Versions/3/unix/include -DPACKAGE=\grasslibs\ -I/Users/Shared/grass_dev/grass70_dev/dist.i386-apple-darwin10.5.0/include -I/Users/Shared/grass_dev/grass70_dev/dist.i386-apple-darwin10.5.0/include -o OBJ.i386-apple-darwin10.5.0/open_ogr.o -c open_ogr.c In file included from open_ogr.c:26: /Users/Shared/grass_dev/grass70_dev/dist.i386-apple-darwin10.5.0/include/grass/gprojects.h:21:22: error: proj_api.h: No such file or directory it's not finding the proj4 includes. On Linux 64bit I have no problems to compile. It needs the PROJ include dir in the compile command. It'll work on Linux since all includes are in /usr/[local/]include. On OS X it's a separate PROJ framework. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Those people who most want to rule people are, ipso-facto, those least suited to do it. - A rule of the universe, from the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GRASS 7 - r3.in.ascii not compiling on Mac
I just updated from trunk today and tried to compile GRASS 7. r3.in.ascii failed to compile with the following error. Michael cmb-MBP:r3.in.ascii cmbarton$ make : gcc -L/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.4.0/lib -L/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.4.0/lib -arch i386 -arch x86_64 -o /Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.4.0/bin/r3.in.ascii OBJ.i386-apple-darwin10.4.0/main.o-lgrass_g3d.7.0.svn -lgrass_gis.7.0.svn Undefined symbols for architecture i386: _Rast_set_history, referenced from: _main in main.o ld: symbol(s) not found for architecture i386 collect2: ld returned 1 exit status Undefined symbols for architecture x86_64: _Rast_set_history, referenced from: _main in main.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status lipo: can't open input file: /var/folders/AK/AKpYwDw1EoWI+fFF02nvRk+++TI/-Tmp-//cc8l3PD2.out (No such file or directory) make: *** [/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.4.0/bin/r3.in.ascii] Error 1 cmb-MBP:r3.in.ascii cmbarton$ cd .. C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] wxnviz and wxdigit problems
I just updated from trunk and tried GRASS 7 and am getting some ugly errors.
On launching a lot of garbage is being dumped to the terminal--Python
dictionaries for wxnviz and wxdigit (e.g., modeler data). This output also is
dumped to the terminal and console when any command is run.
Also, when I try wxnviz it does not work at all.
Here are some of the errors I get...
Running a command:
===
(Sat Jul 10 07:36:21 2010)
r.info map=geol...@permanent
{'profile': {'raster2': {'pstyle': 'solid', 'pwidth': 1, 'pcolor': (0, 255, 0,
255)}, 'raster0': {'pstyle': 'solid', 'pwidth': 1, 'pcolor': (0, 0, 255, 255)},
'raster1': {'pstyle': 'solid', 'pwidth': 1, 'pcolor': (255, 0, 0, 255)},
'x-axis': {'max': 0, 'type': 'auto', 'log': False, 'min': 0}, 'y-axis': {'max':
0, 'type': 'auto', 'log': False, 'min': 0}, 'grid': {'color': (200, 200, 200,
255), 'enabled': True}, 'marker': {'color': (0, 0, 0, 255), 'fill':
'transparent', 'type': 'triangle', 'legend': u'Segment break', 'size': 2},
'font': {'axisSize': 11, 'legendSize': 10, 'titleSize': 12}, 'legend':
{'enabled': True}}, 'georect': {'symbol': {'color': (0, 0, 255, 255), 'width':
2}}, 'cmd': {'showType': {'point': {'enabled': True}, 'area': {'enabled':
True}, 'face': {'enabled': True}, 'centroid': {'enabled': True}, 'line':
{'enabled': True}, 'boundary': {'enabled': True}}, 'rasterColorTable':
{'selection': 'rainbow', 'enabled': False}, 'verbosity': {'selection':
'grassenv'}, 'addNewLayer': {'enabled': True}, 'rasterOpaque': {'enabled':
False}, 'closeDlg': {'enabled': False}, 'overwrite': {'enabled': False}},
'projection': {'statusbar': {'epsg': '', 'proj4': '', 'projFile':
'/Library/Frameworks/PROJ.framework/Resources/proj/epsg'}, 'format': {'ll':
'DMS', 'precision': 2}}, 'display': {'outputfont': {'type': 'Courier New',
'size': '10'}, 'statusbarMode': {'selection': 0}, 'autoZooming': {'enabled':
False}, 'driver': {'type': 'cairo'}, 'autoRendering': {'enabled': True},
'bgcolor': {'color': (255, 255, 255, 255)}, 'compResolution': {'enabled':
False}, 'font': {'type': '', 'encoding': 'ISO-8859-1'}}, 'nviz': {'light':
{'color': (255, 255, 255, 255), 'bright': 80, 'pos': {'y': 0.68005,
'x': 0.68005, 'z': 80}, 'ambient': 20}, 'fringe': {'color': (128,
128, 128, 255), 'elev': 55}, 'surface': {'shine': {'map': False, 'value':
60.0}, 'color': {'map': True, 'value': (0, 0, 0, 255)}, 'draw': {'res-coarse':
9, 'style': 1, 'wire-color': (136, 136, 136, 255), 'mode': 1, 'shading': 1,
'res-fine': 6}, 'position': {'y': 0, 'x': 0, 'z': 0}}, 'volume': {'color':
{'map': True, 'value': (0, 0, 0, 255)}, 'shine': {'map': False, 'value': 60.0},
'draw': {'shading': 1, 'resolution': 3, 'mode': 0}}, 'vector': {'points':
{'show': False, 'color': (0, 0, 255, 255), 'height': 0, 'width': 2, 'marker':
2, 'size': 100}, 'lines': {'color': (0, 0, 255, 255), 'width': 2, 'show':
False, 'flat': False, 'height': 0}}, 'view': {'persp': {'step': 5, 'value':
20}, 'pos': {'y': 0.16, 'x': 0.83997}, 'height': {'step': 100},
'twist': {'step': 5, 'value': 0}, 'background': {'color': (255, 255, 255,
255)}, 'z-exag': {'step': 1}}}, 'atm': {'leftDbClick': {'selection': 1},
'highlight': {'color': (255, 255, 0, 255), 'width': 2}, 'askOnDeleteRec':
{'enabled': True}, 'keycolumn': {'value': 'cat'}, 'encoding': {'value': ''}},
'general': {'defWindowPos': {'dim': '', 'enabled': False}, 'elementListExpand':
{'selection': 0}}, 'manager': {'askOnQuit': {'enabled': True},
'askOnRemoveLayer': {'enabled': True}, 'changeOpacityLevel': {'enabled':
False}}, 'vdigit': {'category': {'value': 1}, 'layer': {'value': 1},
'queryLength': {'than-selection': 0, 'thresh': 0}, 'breakLines': {'enabled':
False}, 'selectThresh': {'units': 'screen pixels', 'value': 10},
'snapToVertex': {'enabled': False}, 'selectType': {'line': {'enabled': True},
'centroid': {'enabled': True}, 'boundary': {'enabled': True}, 'point':
{'enabled': True}}, 'snapping': {'units': 'screen pixels', 'value': 10},
'delRecord': {'enabled': True}, 'addRecord': {'enabled': True}, 'selectInside':
{'enabled': False}, 'categoryMode': {'selection': 0}, 'saveOnExit': {'enabled':
False}, 'query': {'box': True, 'selection': 0}, 'addCentroid': {'enabled':
False}, 'lineWidth': {'units': 'screen pixels', 'value': 2}, 'checkForDupl':
{'enabled': False}, 'symbol': {'highlightDupl': {'color': (255, 72, 0, 255),
'enabled': None}, 'boundaryOne': {'color': (0, 255, 0, 255), 'enabled': True},
'direction': {'color': (255, 0, 0, 255), 'enabled': False}, 'point': {'color':
(0, 0, 0, 255), 'enabled': True}, 'area': {'color': (217, 255, 217, 255),
'enabled': False}, 'vertex': {'color': (255, 20, 147, 255), 'enabled': False},
'boundaryNo': {'color': (126, 126, 126, 255), 'enabled': True}, 'highlight':
{'color': (255, 255, 0, 255), 'enabled': None}, 'centroidOut':
Re: [GRASS-dev] 6.4.0 blocker bugs
Greetings from remote parts of China. I agree with all about releasing 6.4. As it stands now 6.4 is much more stable and usable than 6.2.3. wxnviz and wxdigit are experimental for this release, so we shouldn't worry about them too much. The TclTk versions of both work well. 1+ for release as quickly as possible. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Jul 6, 2010, at 10:34 AM, grass-dev-requ...@lists.osgeo.org wrote: Date: Mon, 5 Jul 2010 22:34:23 -0400 From: Helena Mitasova hmit...@unity.ncsu.edu Subject: Re: [GRASS-dev] 6.4.0 blocker bugs To: Glynn Clements gl...@gclements.plus.com Cc: Markus Metz markus.metz.gisw...@googlemail.com, Martin Landa landa.mar...@gmail.com, GRASS developers list grass-dev@lists.osgeo.org Message-ID: bba240b3-11dc-40ab-b670-d58a8063e...@unity.ncsu.edu Content-Type: text/plain; charset=us-ascii On Jul 5, 2010, at 5:11 PM, Glynn Clements wrote: Markus Neteler wrote: time to get out 6.4.0final :-) Please... one huge +1 ... I learned that we should await the ctypes port to get rid of SWIG? SWIG is only used within GRASS for the wxGUI vdigit and nviz modules. It's also used to generate wrappers for programmers who wish to access the libraries directly, but these aren't used by any part of GRASS. I suggest disabling all of this in the final release. The vdigit and nviz modules don't work on Windows, and aren't particularly robust on other platforms (and being loaded in-process means that any problems affect the GUI as a whole, not just the vdigit/nviz modules). Glynn, I assume you are talking about wxnviz here, not the TclTk based nviz which runs on windows just fine? I agree that it is really important to get 6.4 final released, especially given that FOSS4G in Barcelona is coming soon Helena The SWIG wrappers for the libraries are barely usable and are planned to be replaced, so we shouldn't be encouraging their use. IOW: 1. The swig directory should be removed from DIRS in the top-level Makefile, so it isn't built (unless the user builds it manually). 2. Official binaries shouldn't use --with-python; this will prevent the vdigit and nviz modules from being built. 3. Optionally back-port the ctypes wrappers (lib/python/ctypes). Even if this doesn't work (fails to build or generates broken wrappers), it shouldn't break anything which would otherwise work. 4. Optionally back-port the ctypes-based nviz module (wxnviz.py). This has most of the same issues as nviz/vdigit (i.e. the GRASS libraries are being accessed directly from the GUI process, so a segfault or G_fatal_error() will kill the GUI), but not all of them. 4b. Alternatively, back-port the changes but not wxnviz.py itself. The result is equivalent to just building --without-python (i.e. the GUI will try to import the wxnviz module, fail, and warn that it's disabled), except that the user can drop in wxnviz.py from SVN if they want to try it out. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] problem with r.mapcalc in GRASS 7
On Jun 25, 2010, at 10:07 PM, William Kyngesburye wrote: On Jun 25, 2010, at 10:59 PM, Barton Michael wrote: I tried this and got the same error. make clean first? - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ I just did an svn update, make distclean, and make GDAL_DYNAMIC= There has been an update to r.mapcalc Now I get a different error GRASS 7.0.svn (Spearfish60_test):~ r.mapcalc newmap2 = elevation.dem*2 ERROR 1: TIFFOpen:/Users/Shared/grassdata/Spearfish60_test/PERMANENT/gdal/newmap2: Not a directory ERROR: Unable to create newmap2 dataset using GTiff driver Michael___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] problem with r.mapcalc in GRASS 7
On Jun 26, 2010, at 4:23 PM, Glynn Clements wrote: Now I get a different error GRASS 7.0.svn (Spearfish60_test):~ r.mapcalc newmap2 = elevation.dem*2 ERROR 1: TIFFOpen:/Users/Shared/grassdata/Spearfish60_test/PERMANENT/gdal/newmap2: Not a directory ERROR: Unable to create newmap2 dataset using GTiff driver The error indicates that you have have enabled output via GDAL (r.external.out). Use r.external.out -r to revert to native output, or use r.external.out -p to check your settings. If you want TIFF output, you should probably set the extension to .tif or .tiff (r.external.out ... extension=.tif). That did the trick. I didn't know r.external.out was enabled. I must have enabled it in previous versions to test. But apparently it was not working correctly. Maybe I need to try it again and check the settings. Michael___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] wxnviz not compiling in GRASS 6.5 svn
I just updated from the CVS, did a make distclean, and compiled. wxnviz failed to compile with the error below. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu == compile error = Errors in: /Users/cmbarton/grass_dev/grass65_dev/gui/wxpython/nviz -- In case of errors please change into the directory with error and run 'make'. If you get multiple errors, you need to deal with them in the order they appear in the error log. If you get an error building a library, you will also get errors from anything which uses the library. -- Finished compilation: Fri Jun 25 12:18:45 MST 2010 make: *** [default] Error 1 cmb-MBP:grass65_dev cmbarton$ cd /Users/cmbarton/grass_dev/grass65_dev/gui/wxpython/nviz cmb-MBP:nviz cmbarton$ make python setup.py build_ext --swig=/usr/bin/swig --swig-opts=-c++ --build-lib=OBJ.i386-apple-darwin10.4.0 --build-temp=OBJ.i386-apple-darwin10.4.0 running build_ext building '_grass6_wxnviz' extension swigging grass6_wxnviz.i to grass6_wxnviz_wrap.cpp /usr/bin/swig -python -c++ -o grass6_wxnviz_wrap.cpp grass6_wxnviz.i gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -arch i386 -arch ppc -arch x86_64 -pipe -DPACKAGE=grasslibs -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXMAC__ -I/Users/cmbarton/grass_dev/grass65_dev/dist.i386-apple-darwin10.4.0/include -I/Library/Frameworks/GDAL.framework/Versions/1.7/Headers -I/usr/local/lib/wxPython-unicode-2.8.10.1/lib/wx/include/mac-unicode-debug-2.8 -I/usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8 -I/System/Library/Frameworks/OpenGL.framework/Headers -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c change_view.cpp -o OBJ.i386-apple-darwin10.4.0/change_view.o cc1plus: warning: command line option -Wstrict-prototypes is valid for C/ObjC but not for C++ In file included from /usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/mac/glcanvas.h:4, from /usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/glcanvas.h:60, from nviz.h:26, from change_view.cpp:15: /usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/mac/carbon/glcanvas.h:49: warning: ‘AGLDrawable’ is deprecated (declared at /System/Library/Frameworks/AGL.framework/Headers/agl.h:48) /usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/mac/carbon/glcanvas.h:53: warning: ‘AGLDrawable’ is deprecated (declared at /System/Library/Frameworks/AGL.framework/Headers/agl.h:48) change_view.cpp: In member function ‘std::vectordouble, std::allocatordouble Nviz::SetViewDefault()’: change_view.cpp:56: error: cannot convert ‘float*’ to ‘double*’ for argument ‘1’ to ‘int Nviz_get_exag_height(double*, double*, double*)’ change_view.cpp: In member function ‘int Nviz::SetView(float, float, float, float, float)’: change_view.cpp:81: error: cannot convert ‘nv_data*’ to ‘double’ for argument ‘1’ to ‘int Nviz_set_viewpoint_height(double)’ change_view.cpp:83: error: cannot convert ‘nv_data*’ to ‘double’ for argument ‘1’ to ‘int Nviz_set_viewpoint_position(double, double)’ change_view.cpp:85: error: invalid conversion from ‘nv_data*’ to ‘int’ /Users/cmbarton/grass_dev/grass65_dev/dist.i386-apple-darwin10.4.0/include/grass/nviz.h:134: error: too many arguments to function ‘int Nviz_set_viewpoint_twist(int)’ change_view.cpp:85: error: at this point in file change_view.cpp:87: error: invalid conversion from ‘nv_data*’ to ‘int’ /Users/cmbarton/grass_dev/grass65_dev/dist.i386-apple-darwin10.4.0/include/grass/nviz.h:133: error: too many arguments to function ‘int Nviz_set_viewpoint_persp(int)’ change_view.cpp:87: error: at this point in file cc1plus: warning: command line option -Wstrict-prototypes is valid for C/ObjC but not for C++ In file included from /usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/mac/glcanvas.h:4, from /usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/glcanvas.h:60, from nviz.h:26, from change_view.cpp:15: /usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/mac/carbon/glcanvas.h:49: warning: ‘AGLDrawable’ is deprecated (declared at /System/Library/Frameworks/AGL.framework/Headers/agl.h:48) /usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/mac/carbon/glcanvas.h:53: warning: ‘AGLDrawable’ is deprecated (declared at /System/Library/Frameworks/AGL.framework/Headers/agl.h:48) change_view.cpp: In member function ‘std::vectordouble, std::allocatordouble Nviz::SetViewDefault()’: change_view.cpp:56: error: cannot convert ‘float*’ to ‘double*’ for argument ‘1’ to ‘int
[GRASS-dev] problem with r.mapcalc in GRASS 7
I'm not sure if this is a general issues or something specific to my OS X 10.6.4 build. I just updated and compiled trunk. When I try to use r.mapcalc, I get the following error: ERROR: Unable to load GDAL library I'm also not sure how to use the new syntax, as the manual is lacking in examples of the use of the expression argument. Old mapcalc: r.mapcalc 'newmap=oldmap*2' New mapcalc: r.mapcalc newmap = oldmap*2 [CORRECT? This gives the gdal error] r.mapcalc file=newmap expression=oldmap*2 [This gives a parse error] Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: grass-dev Digest, Vol 50, Issue 11
I've been tied up with ABM classes and with a dissertation defense Monday. But I'm trying to keep tabs on this and will try to compile again soon. Sounds like there are still problems, but getting closer. Michael On Jun 5, 2010, at 6:00 PM, grass-dev-requ...@lists.osgeo.org wrote: Date: Sat, 5 Jun 2010 10:02:22 -0500 From: William Kyngesburye wokl...@kyngchaos.com Subject: Re: [GRASS-dev] grass7 on mac OSX To: Glynn Clements gl...@gclements.plus.com Cc: grass-dev@lists.osgeo.org list grass-dev@lists.osgeo.org Message-ID: fbdfc367-9f25-4fbc-8650-a825bf3be...@kyngchaos.com Content-Type: text/plain; charset=us-ascii On Jun 5, 2010, at 1:15 AM, Glynn Clements wrote: With, though I get that unknown architecture error in nviz.py. The ctypesgen authors seem to be aware of and patch OSX issues, but maybe they never tried it with system framework headers. But does this prevent the generation of the wrapper? ... There are more similar CF_INLINE definitions earlier, but they are inside a #ifdef CF_INLINE. But do these prevent the wrapper from being generated, or result in it missing necessary definitions? ctypesgen ignores errors from the preprocessor (it doesn't capture stderr and doesn't care about the exit code). Errors only matter insofar as they cause significant declarations to be omitted or malformed. The ValueError is different as that's an exception being raised within ctypesgen itself; r42484 should deal with that. Ah, it's generated. Next error, after that finishes: sed \ -e '/^# End loader$/a\ from ctypes_preamble import *\ from ctypes_preamble import _variadic_function\ from ctypes_loader import *' \ -e '/^# Begin preamble$/,/^# End preamble$/d' \ -e '/^# Begin loader$/,/^# End loader$/d' \ date.py /Users/Shared/src/GRASS/svn/trunk/dist.i386-apple-darwin10.3.1/etc/python/grass/lib/date.py sed: 1: /^# End loader$/afrom c ...: command a expects \ followed by text make[2]: *** [/Users/Shared/src/GRASS/svn/trunk/dist.i386-apple-darwin10.3.1/etc/python/grass/lib/date.py] Error 1 There is only 1 file after this in dist/etc/python/grass/lib: an empty date.py. I never had any luck on OSX with newlines in sed replacement strings in makefiles. It'll work in shell scripts but not makefiles. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass7 on mac OSX
On Jun 5, 2010, at 11:58 PM, grass-dev-requ...@lists.osgeo.org wrote: Date: Sat, 5 Jun 2010 21:14:05 +0200 From: Massimo Di Stefano massimodisa...@gmail.com Subject: Re: [GRASS-dev] grass7 on mac OSX To: William Kyngesburye kyngch...@kyngchaos.com Cc: Glynn Clements gl...@gclements.plus.com, grass-dev@lists.osgeo.org list grass-dev@lists.osgeo.org Message-ID: 57db7e51-5fc6-472a-afb2-8e4bee3bc...@gmail.com Content-Type: text/plain; charset=us-ascii Works!!! :-D GRASS 7.0.svn (spearfish60):~ g.gui GRASS 7.0.svn (spearfish60):~ ipython Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29) Type copyright, credits or license for more information. IPython 0.11.bzr.r1205 -- An enhanced Interactive Python. ? - Introduction and overview of IPython's features. %quickref - Quick reference. help - Python's own help system. object? - Details about 'object'. ?object also works, ?? prints more. In [1]: from grass.lib import raster In [2]: thanks too mutch Guys!!! I'll try to compile and test in the new few days. Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass7 on mac OSX
Once you or others think there is a potential fix for GRASS for OSX, I'm happy
to give it a try.
MIchael
C. Michael Barton
Director, Center for Social Dynamics Complexity
Professor of Anthropology, School of Human Evolution Social Change
Arizona State University
voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu
On Jun 4, 2010, at 7:01 AM, Glynn Clements wrote:
William Kyngesburye wrote:
i applied the patch and tried to rebuild (after make distclean)
File
/Users/Shared/source/grass_trunk/lib/python/ctypes/ctypesgencore/parser/pplexer.py,
line 60, in __new__
value = value[1:-1].decode('string_escape')
ValueError: invalid \x escape
This looks like an issue with Apple's C headers being incompatible
with anything other than Apple's version of gcc.
I think that it's going to need someone with a Mac to investigate the
issues and make the necessary changes to ctypesgen to either support
Apple's enhanced C dialect, or to provide the necessary switches to
disable the enhancements (if such switches exist).
Apple's GCC is GCC. The preprocessor is custom. When I looked into
ctypesgen, it says it uses the preprocessor.
It does (via gcc -E).
Did you take a trunk snapshot of ctypesgen? When? I see a lot of
differences between the current ctypesgen trunk and the copy in GRASS
trunk. The last batch of changes was in March. And there is a OS X
10.6-specific fix in there (adding -U __BLOCKS__ to the parse command).
The version in GRASS is r72 (the version I have installed via Gentoo).
Martin was having problems with the latest trunk version.
What I'm seeing so far is that there are errors in lib/python/ctypes
that are not showing up in the GRASS error log, so Michael and Massimo
might have missed them.
An error building lib/python/ctypes is currently non-fatal, as it
isn't used for anything except wxNVIZ.
Removing the -U __GNUC__ causes even more errors.
So do we remove it or keep it? I can only guess that the #error's were
being triggerd by __GNUC__ being undefined. Is there some other
setting which will work?
Adding the -U
__BLOCKS__ bit that's in trunk removes a couple errors. Using ctypesgen
trunk does no more than adding the -U __BLOCKS__ bit.
I'll add that.
Errors I'm getting (after adding the -U __BLOCKS__ change):
- gprojects.h (from proj.py) can't find proj_api.h or ogr_srs_api.h -
their -I's are not in the ctypesgen preprocessor command
- same for ogr and geos headers in vector.py and vedit.py
Okay; I've added these.
- nviz.py: /usr/include/TargetConditionals.h:284:10: error: #error
TargetConditionals.h: unknown compiler
(probably included from needing AGL and Application Services headers
from the system)
this appears to be caused by undefining __GNUC__, but leaving __GNUC__
defined causes lots of syntax errors in system headers, which spill into
grass headers. I don't know how this can be fixed.
The question is whether the errors are recoverable. I don't think
we'll know that until we deal with the ValueError issue.
proj.py, vector.py and vedit.py still get created, though I don't know
if they work. nviz.py has a ValueError: invalid \x escape, and doesn't
get created
Can you provide more details? It should be possible to modify
ctypesgen to recover from this.
(make error, yet it doesn't get caught by the grass error
log).
An error in the ctypes subdirectory should now be logged.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass7 on mac OSX
It is not a wxPython 2.9 problem--or should not be. I think it is something else in the build system. Others are having the same problem with the current version. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Jun 2, 2010, at 2:34 AM, Massimo Di Stefano wrote: I succesfull build wxpython on snow leopard to be 32+64 bit against wx2.9 (svn version) - is the only way to have wx with no bitwise problems on osx then i installed ctypesgen tring to build grass70 i got the error in wxpython gui code re-running make inside its directory the error is not fixed. i suppose this is related to wx version (2.9) instead of (2.8) so it shouldn't be a grass related problem ... this is the log : http://www.geofemengineering.it/data/grass_wxgui_log.txt i wonder if it's possible to adapt grass-gui code to run under 2.9 too :-/ i'm now recompiling ctypsegen on the system python to sede if it fix the grass.lib error Il giorno 01/giu/2010, alle ore 23.53, Martin Landa ha scritto: Hi, 2010/6/1 Massimo Di Stefano massimodisa...@gmail.com: [...] Traceback (most recent call last): File /Applications/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py, line 87, in module import gui_modules.nviz_tools as nviz_tools File /Users/Shared/source/grass_trunk/dist.i386-apple-darwin10.3.0/etc/gui/wxpython/gui_modules/nviz_tools.py, line 36, in module from nviz_mapdisp import wxUpdateView as wxUpdateView File /Users/Shared/source/grass_trunk/dist.i386-apple-darwin10.3.0/etc/gui/wxpython/gui_modules/nviz_mapdisp.py, line 41, in module import wxnviz File /Users/Shared/source/grass_trunk/dist.i386-apple-darwin10.3.0/etc/gui/wxpython/gui_modules/wxnviz.py, line 24, in module from grass.lib.grass import * ImportError: No module named lib.grass ctypes grass.lib (lib/python/ctypes) is missing in your installation (ctypesgen required). wxGUI failure fixed in r42430. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass7 on mac OSX
When the switch to ctypes started, I compiled ctypes as directed. Could this be a problem now? Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Jun 2, 2010, at 4:54 AM, Glynn Clements wrote: Barton Michael wrote: I just compiled GRASS 7 a couple days ago, before leaving for Spain. Wx digitizer and nviz don't compile. The gui/wxpython/nviz directory is no longer built; it has been superseded by gui/wxpython/gui_modules/wxnviz.py. The ctypes/SWIG changes don't touch the vdigit module. Also others can't even open my binaries. Is there a new configure switch for ctypes? No. I added a local copy of ctypesgen to the source tree, so there are no external dependencies. ctypes itself is part of the standard library in Python 2.5 and 2.6. Are we supposed to no longer use the python switch? --with-python should only be required for vdigit. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
