[GRASS-dev] display monitor (how to everlay 2 layers)
Hi,
i’m trying to generate a png from python using the the d.mon / d. last / d.vect
commands
in the past (grass70) this code worked fine :
GRASS_TRANSPARENT=TRUE
GRASS_TRUECOLOR=TRUE
GRASS_PNG_COMPRESSION=9
GRASS_PNG_AUTO_WRITE=TRUE
export GRASS_TRANSPARENT GRASS_TRUECOLOR GRASS_PNG_COMPRESSION
GRASS_PNG_AUTO_WRITE
d.mon start=cairo --q output={mapname}.png
g.region rast={mapname} n={n} s={s} w={w} e={e} -a --q
d.rast map={mapname} --q
d.vect map={mapname} color={vcolor} size={vsize} icon={icon} --q
d.mon stop=cairo --q
but now is not generating any png :(
browsing the add ons i saw v.out.png is no more in trunk and i gave it a try :
###
import os
import sys
from grass.script import core as grass
from grass.script import gisenv
from grass.pygrass.modules.shortcuts import display as d
from grass.pygrass.modules.shortcuts import general as g
os.environ['GRASS_RENDER_IMMEDIATE'] = 'png'
os.environ['GRASS_RENDER_FILE'] = 'pfile3.png'
os.environ['GRASS_RENDER_FILE_COMPRESSION'] = '9'
os.environ['GRASS_RENDER_WIDTH'] = '640'
os.environ['GRASS_RENDER_HEIGHT'] = '480'
os.environ['GRASS_RENDER_TRANSPARENT']='TRUE'
monitor_old = None
genv = gisenv()
if 'MONITOR' in genv:
monitor_old = genv['MONITOR']
g.gisenv(unset='MONITOR')
d.vect(map='p')
d.rast(map='basemap')
###
this time the png is generated, but i’m no more able to overlay 2 different
layers to compose my map …
Have you any thoughts on what’s wrong in those procedures ?
I tried on the osgeolive, the first approach works for grass70.
building grass71 and try it again … no png is generated.
Thanks for any advice.
Massimo.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] display monitor (how to everlay 2 layers)
Thank Martin, I tried with this : http://nbviewer.ipython.org/gist/anonymous/e72c4a3b311370ade0db http://nbviewer.ipython.org/gist/anonymous/e72c4a3b311370ade0db but I still have the same behavior Thanks a lot to for looking into this! Massimo. On Mar 3, 2015, at 10:30 AM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2015-03-03 16:23 GMT+01:00 epi massimodisa...@gmail.com: GRASS_TRANSPARENT=TRUE GRASS_TRUECOLOR=TRUE GRASS_PNG_COMPRESSION=9 GRASS_PNG_AUTO_WRITE=TRUE export GRASS_TRANSPARENT GRASS_TRUECOLOR GRASS_PNG_COMPRESSION GRASS_PNG_AUTO_WRITE render-related variables has been renamed to GRASS_RENDER_, see [1]. os.environ['GRASS_RENDER_IMMEDIATE'] = 'png' os.environ['GRASS_RENDER_FILE'] = 'pfile3.png' os.environ['GRASS_RENDER_FILE_COMPRESSION'] = '9' os.environ['GRASS_RENDER_WIDTH'] = '640' os.environ['GRASS_RENDER_HEIGHT'] = '480' os.environ['GRASS_RENDER_TRANSPARENT']='TRUE' monitor_old = None genv = gisenv() if 'MONITOR' in genv: monitor_old = genv['MONITOR'] g.gisenv(unset='MONITOR') d.vect(map='p') d.rast(map='basemap') ### this time the png is generated, but i'm no more able to overlay 2 different layers to compose my map ... You need to define GRASS_RENDER_READ_FILE='TRUE'. Martin [1] http://grass.osgeo.org/grass70/manuals/variables.html#list-of-selected-grass-environment-variables-for-rendering -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] display monitor (how to everlay 2 layers)
Martin, Anna, Thank you so much, it works great. Massimo. On Mar 3, 2015, at 1:53 PM, Martin Landa landa.mar...@gmail.com wrote: 2015-03-03 19:48 GMT+01:00 Anna Petrášová kratocha...@gmail.com: I think it's GRASS_RENDER_FILE_READ, not GRASS_RENDER_READ_FILE. http://grass.osgeo.org/grass71/manuals/cairodriver.html you are right, Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Mac OS X 10.10 , grass71-svn - fail to start
Thanks Anna! it was my fault. a typo in my bash_profile, my GISBASE was pointing to $GISBASE/lib. Massimo. On Feb 5, 2015, at 11:35 PM, Anna Petrášová kratocha...@gmail.com wrote: On Thu, Feb 5, 2015 at 9:04 PM, epi massimodisa...@gmail.com mailto:massimodisa...@gmail.com wrote: Hi Devs, i updated my grass-svn installation, the build ends without errors but trying to start grass i got the following error : epimac:~ epi$ grass71 Cleaning up temporary files... Traceback (most recent call last): File /usr/local/bin/grass71, line 1387, in module clean_temp() File /usr/local/bin/grass71, line 1170, in clean_temp call([gfile(etc, clean_temp)], stdout=nul, stderr=nul) File /usr/local/bin/grass71, line 155, in call return subprocess.call(cmd, **kwargs) File /usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py, line 522, in call return Popen(*popenargs, **kwargs).wait() File /usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py, line 710, in __init__ errread, errwrite) File /usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py, line 1335, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory epimac:~ epi$ it calls binary clean_temp but it can't find it, do you have a file etc/clean_temp? In the source code clean_temp.c is in lib/init. Anna I don’t know what’s going on, it is possible that is my system that’s broken … and not grass thanks for any help in debugging this issue. Massimo. ___ grass-dev mailing list grass-dev@lists.osgeo.org mailto:grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Mac OS X 10.10 , grass71-svn - fail to start
Hi Devs, i updated my grass-svn installation, the build ends without errors but trying to start grass i got the following error : epimac:~ epi$ grass71 Cleaning up temporary files... Traceback (most recent call last): File /usr/local/bin/grass71, line 1387, in module clean_temp() File /usr/local/bin/grass71, line 1170, in clean_temp call([gfile(etc, clean_temp)], stdout=nul, stderr=nul) File /usr/local/bin/grass71, line 155, in call return subprocess.call(cmd, **kwargs) File /usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py, line 522, in call return Popen(*popenargs, **kwargs).wait() File /usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py, line 710, in __init__ errread, errwrite) File /usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py, line 1335, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory epimac:~ epi$ I don’t know what’s going on, it is possible that is my system that’s broken … and not grass thanks for any help in debugging this issue. Massimo. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.mlist not compiling
Exactly same problem here - Debian SID 64 bit - grass_7_trunk - gdal stable, built from source in custom location (no /usr or /usr/local) Massimo. On Jun 28, 2014, at 1:50 PM, Anna Petrášová kratocha...@gmail.com wrote: Hi, even after distclean g.mlist compilation fails: gcc -g -Wall -Werror-implicit-function-declaration -fno-common -Wextra -Wunused -I/usr/local/src/trunk/dist.i686-pc-linux-gnu/include -I/usr/local/src/trunk/dist.i686-pc-linux-gnu/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DPACKAGE=\grassmods\ -I/usr/include/postgresql -I/usr/local/src/trunk/dist.i686-pc-linux-gnu/include -I/usr/local/src/trunk/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/main.o -c main.c In file included from /usr/local/src/trunk/dist.i686-pc-linux-gnu/include/grass/vect/digit.h:3:0, from /usr/local/src/trunk/dist.i686-pc-linux-gnu/include/grass/vector.h:4, from main.c:25: /usr/local/src/trunk/dist.i686-pc-linux-gnu/include/grass/vect/dig_structs.h:27:21: fatal error: ogr_api.h: No such file or directory compilation terminated. make: *** [OBJ.i686-pc-linux-gnu/main.o] Error 1 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r61030 - grass/trunk/general/g.mlist
Hi, just built r61035 It works for me, no more missed ogr headers. Thanks. Massimo. On Jun 28, 2014, at 5:55 PM, Huidae Cho gras...@gmail.com wrote: Can you try r61035? On Sat, Jun 28, 2014 at 5:41 PM, Anna Petrášová kratocha...@gmail.com wrote: Hm, it still doesn't compile. Anyone else has the same problem? On Sat, Jun 28, 2014 at 5:21 PM, Huidae Cho gras...@gmail.com wrote: I'm not sure why I didn't have a compilation problem on my machine. Different installations have different dependencies? On Sat, Jun 28, 2014 at 3:43 PM, Vaclav Petras wenzesl...@gmail.com wrote: Hi Martin, can you please tell me what is the difference between VECT_INC and VECTORDEPS? The former contains PQINCPATH, the later PQLIBPATH and PQLIB. Thanks, Vaclav inlcude/Make/Grass.make: VECT_INC= $(PQINCPATH) VECTORDEPS = $(DBMILIB) $(GRAPHLIB) $(DIG2LIB) $(LINKMLIB) $(RTREELIB) $(GISLIB) $(GEOSLIBS) $(GDALLIBS) $(MATHLIB) $(BTREE2LIB) $(GPROJLIB) $(RASTERLIB) $(PQLIBPATH) $(PQLIB) On Sat, Jun 28, 2014 at 12:22 PM, svn_gr...@osgeo.org wrote: Author: martinl Date: 2014-06-28 09:22:57 -0700 (Sat, 28 Jun 2014) New Revision: 61030 Modified: grass/trunk/general/g.mlist/Makefile Log: g.mlist: fix compilation (missing EXTRA_INC) Modified: grass/trunk/general/g.mlist/Makefile === --- grass/trunk/general/g.mlist/Makefile2014-06-28 15:25:43 UTC (rev 61029) +++ grass/trunk/general/g.mlist/Makefile2014-06-28 16:22:57 UTC (rev 61030) @@ -4,6 +4,7 @@ LIBES = $(MANAGELIB) $(GISLIB) $(RASTERLIB) $(RASTER3DLIB) $(VECTORLIB) DEPENDENCIES = $(MANAGEDEP) $(GISDEP) $(RASTERDEP) $(RASTER3DDEP) $(VECTORDEP) +EXTRA_INC = $(VECT_INC) include $(MODULE_TOPDIR)/include/Make/Module.make ___ grass-commit mailing list grass-com...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-commit ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] problems building grass7_trunk on debian wheezy
Hi, trying to upgrade my grass7 installation i got errors for the following modules : v.kernel, v.net.path, v.to.db, m.measure Attached as gist the full build log for each module : https://gist.github.com/anonymous/cc53f782312fb347ee26 for both v.to.db and m.measure the erros seems to be related to an undefined “G_units_to_meters_*” while v.kernel, v.net.path are pointing to problems in vect.h have you any clue ? Thanks for help. Massimo. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] problems building grass7_trunk on debian wheezy
i already did a make distclean then i posted the log On May 26, 2014, at 8:37 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Mon, May 26, 2014 at 7:46 PM, epi massimodisa...@gmail.com wrote: Hi, trying to upgrade my grass7 installation i got errors for the following modules : v.kernel, v.net.path, v.to.db, m.measure Attached as gist the full build log for each module : https://gist.github.com/anonymous/cc53f782312fb347ee26 for both v.to.db and m.measure the erros seems to be related to an undefined “G_units_to_meters_*” while v.kernel, v.net.path are pointing to problems in vect.h have you any clue ? Try to do make distclean. There were some changes in library. This usually requires distclean. Thanks for help. Massimo. ___ 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] problems building grass7_trunk on debian wheezy
there was a problem with svn up” the trunk was not fully upgraded, because svn found the r.stream.* add ons inside the grass_trunk src directory their presence was generating an svn conflict and aborting the upgrade. I manually removed the add ons from trunk and did a complete svn up. Now the build goes ahead without errors. On May 26, 2014, at 8:41 PM, epi massimodisa...@gmail.com wrote: i already did a make distclean then i posted the log On May 26, 2014, at 8:37 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Mon, May 26, 2014 at 7:46 PM, epi massimodisa...@gmail.com wrote: Hi, trying to upgrade my grass7 installation i got errors for the following modules : v.kernel, v.net.path, v.to.db, m.measure Attached as gist the full build log for each module : https://gist.github.com/anonymous/cc53f782312fb347ee26 for both v.to.db and m.measure the erros seems to be related to an undefined “G_units_to_meters_*” while v.kernel, v.net.path are pointing to problems in vect.h have you any clue ? Try to do make distclean. There were some changes in library. This usually requires distclean. Thanks for help. Massimo. ___ 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] compiling 7.0 on MacOS 10.9
Micha, i use homebrew to satisfy the dependencies for grass7 ./configure \ --with-opengl-includes=/opt/X11/include/ \ --with-opengl-libs=/opt/X11/lib/ \ --with-cairo-includes=/usr/local/Cellar/cairo/1.12.16/include/cairo/ \ --with-cairo-libs=/usr/local/Cellar/cairo/1.12.16/lib/ \ --with-freetype-includes=/usr/local/include/freetype2 \ --with-blas \ --with-geos \ --with-lapack \ --with-netcdf \ --with-odbc \ --with-pthread \ --with-postgres \ --with-sqlite \ --with-wxwidgets=/usr/local/Cellar/wxmac/3.0.0.0/bin/wx-config the build ends with Errors in: /Users/epi/dev/grass7_trunk/lib/nviz /Users/epi/dev/grass7_trunk/misc/m.nviz.image /Users/epi/dev/grass7_trunk/visualization/wximgview The modules are all fully functionals but because i use python from home-brew as well (not the system one) it is 64 bit and is not compatible with wx-2.8 … i have wx3.0 installed (that’s 64bit) but the main gui doesn’t start. This the log from : g.gui gui=wxpython Launching wxpython GUI in the background, please wait... GRASS 7.0.svn (nc_spm_08_grass7):~ Traceback (most recent call last): File /usr/local/grass-7.0.svn/etc/gui/wxpython/wxgui.py, line 143, in module sys.exit(main()) File /usr/local/grass-7.0.svn/etc/gui/wxpython/wxgui.py, line 136, in main app = GMApp(workspaceFile) File /usr/local/grass-7.0.svn/etc/gui/wxpython/wxgui.py, line 50, in __init__ wx.App.__init__(self, False) File /usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx/_core.py, line 8631, in __init__ self._BootstrapApp() File /usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx/_core.py, line 8196, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File /usr/local/grass-7.0.svn/etc/gui/wxpython/wxgui.py, line 84, in OnInit workspace = self.workspaceFile) File /usr/local/grass-7.0.svn/etc/gui/wxpython/lmgr/frame.py, line 109, in __init__ self._menuTreeBuilder = LayerManagerMenuData() File /usr/local/grass-7.0.svn/etc/gui/wxpython/lmgr/menudata.py, line 40, in __init__ MenuTreeModelBuilder.__init__(self, filename, expandAddons=expandAddons) File /usr/local/grass-7.0.svn/etc/gui/wxpython/core/menutree.py, line 69, in __init__ xmlTree = etree.parse(filename) File /usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py, line 1182, in parse tree.parse(source, parser) File /usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py, line 657, in parse self._root = parser.close() File /usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py, line 1654, in close self._raiseerror(v) File /usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py, line 1506, in _raiseerror raise err xml.etree.ElementTree.ParseError: no element found: line 1, column 0 the wx dialog for (most but not all **) the grass modules, works fine. ** command like g.region, r.mask and others do not lunch a gui dialog when type their name in the grass shell. Massimo. On Apr 2, 2014, at 9:48 AM, Micha Silver mi...@arava.co.il wrote: Has anyone compiled GRASS 7.0 on MacOS Mavricks? Any tips? Thanks, -- Micha Silver GIS Consulting 052-3665918 http://www.surfaces.co.il ___ 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] compiling 7.0 on MacOS 10.9
On Apr 2, 2014, at 4:10 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Wed, Apr 2, 2014 at 4:37 AM, epi massimodisa...@gmail.com wrote: the build ends with Errors in: /Users/epi/dev/grass7_trunk/lib/nviz /Users/epi/dev/grass7_trunk/misc/m.nviz.image This looks like a problem to link OpenGL. That’s correct, for some reason seems that it doesn’t detect the right architecture : ### MacBook-Pro-di-Massimo-2:nviz epi$ make cc -dynamiclib -compatibility_version 7.1 -current_version 7.1 -install_name /usr/local/grass-7.1.svn/lib/libgrass_nviz.7.1.svn.dylib -o /Users/epi/dev/grass7_trunk/dist.x86_64-apple-darwin13.1.0/lib/libgrass_nviz.7.1.svn.dylib -L/Users/epi/dev/grass7_trunk/dist.x86_64-apple-darwin13.1.0/lib -L/Users/epi/dev/grass7_trunk/dist.x86_64-apple-darwin13.1.0/lib -L/usr/local/opt/tcl-tk/lib -arch x86_64 OBJ.x86_64-apple-darwin13.1.0/change_view.o OBJ.x86_64-apple-darwin13.1.0/cplanes_obj.o OBJ.x86_64-apple-darwin13.1.0/draw.o OBJ.x86_64-apple-darwin13.1.0/exag.o OBJ.x86_64-apple-darwin13.1.0/lights.o OBJ.x86_64-apple-darwin13.1.0/map_obj.o OBJ.x86_64-apple-darwin13.1.0/nviz.o OBJ.x86_64-apple-darwin13.1.0/position.o OBJ.x86_64-apple-darwin13.1.0/render.o -lgrass_ogsf.7.1.svn -lgrass_gis.7.1.svn -L/opt/X11/lib/ -lGL Undefined symbols for architecture x86_64: _XCloseDisplay, referenced from: _Nviz_destroy_render_window in render.o _XCreatePixmap, referenced from: _Nviz_create_render_window in render.o _XFree, referenced from: _Nviz_create_render_window in render.o _XFreePixmap, referenced from: _Nviz_destroy_render_window in render.o _XOpenDisplay, referenced from: _Nviz_create_render_window in render.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/epi/dev/grass7_trunk/dist.x86_64-apple-darwin13.1.0/lib/libgrass_nviz.7.1.svn.dylib] Error 1 ### MacBook-Pro-di-Massimo-2:~ epi$ file /opt/X11/lib/libGL.dylib /opt/X11/lib/libGL.dylib: Mach-O universal binary with 2 architectures /opt/X11/lib/libGL.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /opt/X11/lib/libGL.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 /Users/epi/dev/grass7_trunk/visualization/wximgview This looks like a problem to link wxWidgets (the C++ library, not the Python binding wxPython). i fixed this adding a sim. link in use/local ln -s /usr/local/Cellar/wxmac/3.0.0.0/lib/libwx_osx_cocoau-3.0.0.0.0.dylib /usr/local/lib/ The modules are all fully functionals but because i use python from home-brew as well (not the system one) it is 64 bit and is not compatible with wx-2.8 … i have wx3.0 installed (that’s 64bit) but the main gui doesn’t start. This the log from : g.gui gui=wxpython Launching wxpython GUI in the background, please wait... GRASS 7.0.svn (nc_spm_08_grass7):~ Traceback (most recent call last): File /usr/local/grass-7.0.svn/etc/gui/wxpython/wxgui.py, line 143, in module ... self._menuTreeBuilder = LayerManagerMenuData() File /usr/local/grass-7.0.svn/etc/gui/wxpython/lmgr/menudata.py, line 40, in __init__ MenuTreeModelBuilder.__init__(self, filename, expandAddons=expandAddons) File /usr/local/grass-7.0.svn/etc/gui/wxpython/core/menutree.py, line 69, in __init__ xmlTree = etree.parse(filename) ... File /usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py, line 1506, in _raiseerror raise err xml.etree.ElementTree.ParseError: no element found: line 1, column 0 This is probably caused by the fact that compilation for gui/wxpython/xml failed. I secretly hoped that this will be improved by r59485, are you using that version? The workaround used before was delete dist.../etc/gui/wxpython/xml and then run compilation of gui/wxpython inside GRASS session. thanks! i followed this procedure, now the gui starts :) and it is usable. a problem witth Wx font already reported previously : http://lists.osgeo.org/pipermail/grass-dev/2013-December/066536.html is still here, i have this log printed in the shell all the time i use the gui : 2014-04-02 23:31:51.720 Python[78021:d07] CoreText performance note: Client called CTFontCreateWithName() using name .Lucida Grande UI and got font with PostScript name .LucidaGrandeUI. For best performance, only use PostScript names when calling this API. i know it is a known problem, http://forums.wxwidgets.org/viewtopic.php?f=23t=38311 i hoped it was a 2.9 bug … while it still here with wx3.0 https://trac.osgeo.org/grass/changeset/59485 (modify Rules.make to fix build_modules_xml.py on Windows (TODO: replace this workaround)) http://lists.osgeo.org/pipermail/grass-dev/2014-March/067876.html (get interface description for python modules on Windows) the wx dialog
Re: [GRASS-dev] GRASS QGIS: the future
Hi, This approach is pretty to what the IPython developers implemented with their HTM5+JS interface to the IPython Kernel. (IPython Notebook) As RPC interface, IPython is using pyzmq (based on zeromq). IPython has a already a QtConsole with “inline plot” that can easily replace the Qgis python shell. This will give us inline plot to implement the ,missed d.* capabilities of grass 5.* and 6.* as well as direct call to grass commands (in IPython any system call can be performed using the prefix “!”) and using the “!” prefix or the %%BASH magic we can call any grass module, if the GRASS envs are properly exported. I’m on a mac osx 64 bit, is almost 3 years i can not use grass GUI because of the WxPython interface that doesn’t support 64 bit on osx, and i found in this approach the only way to let me use GRASS in a productive way(now that tcltk is removed) Recent development in IPYthon enabled the ability to build complex widget based on query or othe r JS libs thanks to the “interact-widget” API I was planning to reuse part of this technologies for the WebGRASS interface, mixing IPython and PyWT. I’m catching a fight right now, this video is almost “old” but shows how the widget interact API works : http://www.frequency.com/video/ipython-attributes-ofsoftware-how-they/135236136/-/5-1851523 i like the RPC approach, and i guess we can reuse the ipython sw to implement this capabilities. please apologize me if i went OFF topic .. Massimo. On Mar 27, 2014, at 11:17 AM, Sören Gebbert soerengebb...@googlemail.com wrote: Hi Paolo, 2014-03-27 11:18 GMT+01:00 Paolo Cavallini cavall...@faunalia.it: Hi all. I learned during dinner that GRASS7 RC1 is due very soon. This opens the issue of its functioning in QGIS. IMHO: * the qgis-grass-plugin might stop working (this has to be tested) Yes, it will stop working, since the API in GRASS7 has changed (Raster API functions have now Rast_ as prefix). Besides of that must the cmake files be modified to detect GRASS7. * some of the module options will be different * new modules will not be available in QGIS. Yes, but this shouldn't be a problem if the module interface description created by the GRASS modules itself was used to generate the module interface in QGIS. New and modified modules will not work if the interfaces are handcrafted. I think we can deal with this in several ways: * dropping the plugin, and concentrate the work on Processing That is IMHO not a good idea. I think to provide the full functionality of GRASS7 to QGIS user, this plugin should be maintained and updated to support the new GRASS7 API. Handling and processing of massive datasets, especially time series, is only meaningful if GRASS is used as data storage as well. The processing interface will add massively overhead in data processing. The temporary location/mapset creation approach is not well suited to process massive data, even though r.external and v.external are used to link external data temporary into GRASS. * upgrading both the plugin and Processing. Yes, that's the way to go. In the first case, we have two major issues: * upgrading Processing GRASS modules * changing the current Processing behaviour, avoiding the import-export phase when piping consecutive GRASS commands; this makes GRASS modules slower than the equivalent commands of other backends. While the first issue can be solved easily by a couple of people in a few days, the second one is more tricky, and requires hard coding skills. In addition, we'll no longer be able to edit GRASS vectors directly. In the second case, we'll have more work, and a not-so-nice duplication. I would like to have an open discussion on this, avoiding things to just happen, with the possible negative consequences. My suggestion would be: Full integration of the GRASS7 into QGIS via C++ or Python plugin. This includes the temporal GIS capabilities as well. The existing plugin is a very good start point, lots its functionality can be reused, especially the vector editing, grass shell and map management. But there is a major problem with the GRASS QGIS plugin: it links directly to the grass libraries and calls plenty of functions that can QGIS cause to crash in case of an error. We face the same problem in GRASS with the vector editing tools. My solution would be to use a RPC (Remote Procedure Call) interface to calls GRASS library functions in a remote process using binary data for inter-process communication. IMHO the best tool for this is apache thrift[1] which allows us to implement a RPC interface in GRASS7 to the needed library functions. IMHO the number of RPC functions is limited since only vector editing, raster map rendering and some map/stds management functions are needed for direct access, all other functionality is provided by GRASS modules. So the first step is to implement an RPC interface in GRASS7, that
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Hi Stefan, about anonymous access, the app can use a demo location that is generated on the fly using cloning a template location. If i well remember, PyWPS does something like that. But you need to be limit the number of available instance running … (has to be a configurable option), to avoid a server overload. how may anonymous users can test the app at the same time is up to the capabilities of your server. Cheers, Massimo. On Mar 9, 2014, at 4:37 PM, Blumentrath, Stefan stefan.blumentr...@nina.no wrote: Hi, Some more user comments: When we installed RStudio server in our company, our network administrator actually only agreed, because we could limit the listening-addresses / the server was not available from the internet and only accessible within the trusted company network. The same would likely be true for a GRASS web-interface too. So like Massimo, I would guess that the “trused-user” approach would be the most popular… In fact, the only use-case I can imagine for an anonymous web access to a GRASS installation would be demonstration / marketing, that people can have a closer look without installing. But that would require, that the web UI is comparable to the desktop solution to give a comparable impression… Would be anonymous www-access be possible at all? I mean, how would one exclude concurrent use of a mapset, i.e. two anonymous users accessing the same mapset at the same time? Cheers Stefan From: grass-dev-boun...@lists.osgeo.org [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of epi Sent: 9. mars 2014 15:28 To: Glynn Clements Cc: grass-dev@lists.osgeo.org Subject: Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI Glynn, I’aware that the security risk handling in a web app is a hard and hot topic, hopefully a lot of project are working on this direction Of course a web-ui for grass will be designed for registered users and not for the anonymous www (password, registration and https can be implemented) The “web-shell” feature is obviously reserved to only “trusted users”. without this assumption application like Rstudio or IPython notebook should not exist. A multi user approach needs to be based IMHO on unix each user has to have its own home and access to filesystem. If this is not enough the application can be restricted to a chroot jail but this is not part of the UI development (is more a sys admin choice) For the authorization protocol it can be implemented using PAM. (i guess is what Rstudio is using) WT has a mature authentication module http://www.webtoolkit.eu/wt/blog/2011/11/29/wt___jwt_3_2_0 http://www.webtoolkit.eu/wt/blog/2013/08/07/security__wt_and_the_new_breach_vulnerability/ The potential user of a web ui for grass, need to be a trusted user in any case and need to go trough a registration process where an admin as to approve it. not anonymous users allowed. I guess the code behind the web-ui has to sanitize each text entry, will be this enough ? A sanitize inspection on all the “input” coming from the web-ui can be performed and this will be part of the UI itself, not of the grass modules. with the aim to avoid people doing something like .. http://xkcd.com/327/ ;) Massimo. On Mar 8, 2014, at 11:42 AM, Glynn Clements gl...@gclements.plus.com wrote: Rashad M wrote: My main concern would be security. You will need to thoroughly sanitise all inputs. You cannot rely upon GRASS modules to do this, as e.g. most string handling uses fixed-size buffers, so you need to explicitly limit the length of any arguments to avoid the possibility of buffer overruns. I am not clear with this. maybe security and web apps are creating me a confusion. If you do not understand the principles of secure programming, you shouldn't attempt to write a web interface to GRASS. GRASS modules typically do not attempt to be secure against invalid input. If you're providing access to untrusted users (users who aren't supposed to have the full privileges of the account under which the modules are executed), you will need to prevent invalid input from reaching the modules. -- 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] GSoC 2014: GRAS GIS Web UI
Glynn, I understood the risk and I agree in toto with you. For the web-ui interface we can define the rules for each kind of entry and publish the rules/restriction on a help page . Then when an invalid input exception is raised the ui will point the user to read the rules page. Massimo. On Mar 10, 2014, at 12:02 PM, Glynn Clements gl...@gclements.plus.com wrote: epi wrote: I guess the code behind the web-ui has to sanitize each text entry, will be this enough ? A sanitize inspection on all the �input� coming from the web-ui can be performed and this will be part of the UI itself, not of the grass modules. with the aim to avoid people doing something like .. http://xkcd.com/327/ ;) That's the main thing. If you allow the user to e.g. provide names for maps, such names should be limited to alphanumeric characters and limited to a reasonable length. If you allow the user to provide a list of inputs, limit both the maximum number of items and the total length of the resulting textual representation. And so on. In short, GRASS modules are designed for use by local users who already have shell access, so there hasn't been any need to program defensively. The OS prevents people from e.g. reading or writing files which they aren't supposed to. -- 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] GSoC 2014: GRAS GIS Web UI
On Mar 11, 2014, at 12:22 AM, Vaclav Petras wenzesl...@gmail.com wrote: On Mon, Mar 10, 2014 at 11:04 PM, epi massimodisa...@gmail.com wrote: Vaclav, Is my understanding that the grass parsing code has to be “less restrictive” for the desktop app while the sanitizer has to be implemented on the web-ui side. Develop the sanitizer on the web-ui code and do not touch the g.parser source code. The sanitizer code will following the guidelines found at the page [thanks] you pointed : “Complete Structure Members Table” but extending the restrictions to what Glynn suggested : size constraint, alphanumeric characters, maximum number of items in a list and more. this restriction will be true for the web-ui but not for the desktop gui hence the need to leave untouched the grass command line parser code. does this make sense for you ? Yes, it does. For example, if module accepts parameter of type string, parser checks nothing in this case. However, web UI (1) should have the information (obtained from `--interface-description` XML) that it is a string and restrict the string to 255 characters (just an example). That’s how we’d like to design the gui modules, using g.parser to generate the module descriptions and then use this information to generate the code to render each module. i Guess wx gui works this way. PyQt does something similar with .ui files generated in designer. In our case the .ui is the module description and is generated by g.parser. (1) Actually, both the web GUI and something which is behind it on server side should have this check. In GUI, you want to tell the user that the input is invalid before sending the data for processing but also once data are at the server they should be checked again for case that somebody is not using the GUI but just sending the data to server side of the application (in order to bypass the GUI check). The web development framework may (or may not) solve these two steps for you at once. I can see your idea of having the gui code to do a first check when the module is filled on the client and a second check server side when the instruction is received. thanks to share it. Essentially any command string received by the server will be parsed and checked for the validity of each entry (in regards of the module being executed) . This make perfectly sense to me. Massimo. Vaclav Massimo. On Mar 10, 2014, at 10:32 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Mon, Mar 10, 2014 at 10:19 PM, epi massimodisa...@gmail.com wrote: Glynn, I understood the risk and I agree in toto with you. For the web-ui interface we can define the rules for each kind of entry and publish the rules/restriction on a help page . Then when an invalid input exception is raised the ui will point the user to read the rules page. This is what GRASS parser system [1] is trying to define, so you should/need to use it for that. However, it might not be sufficient (1). In this case, you should not try to workaround it but suggest and improvement for GRASS parser instead. (1) E.g. standard options [2] are defined in the library and modules are using them but they are not visible in the interface (since they are translated to more basic types), so some information is lost. [1] http://grass.osgeo.org/programming7/gislib_cmdline_parsing.html [2] http://grass.osgeo.org/programming7/parser__standard__options_8c.html Massimo. On Mar 10, 2014, at 12:02 PM, Glynn Clements gl...@gclements.plus.com wrote: epi wrote: I guess the code behind the web-ui has to sanitize each text entry, will be this enough ? A sanitize inspection on all the �input� coming from the web-ui can be performed and this will be part of the UI itself, not of the grass modules. with the aim to avoid people doing something like .. http://xkcd.com/327/ ;) That's the main thing. If you allow the user to e.g. provide names for maps, such names should be limited to alphanumeric characters and limited to a reasonable length. If you allow the user to provide a list of inputs, limit both the maximum number of items and the total length of the resulting textual representation. And so on. In short, GRASS modules are designed for use by local users who already have shell access, so there hasn't been any need to program defensively. The OS prevents people from e.g. reading or writing files which they aren't supposed to. -- 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] GSoC 2014: GRAS GIS Web UI
On Mar 11, 2014, at 12:36 AM, Hamish hamis...@yahoo.com wrote: Massimo wrote: Is my understanding that the grass parsing code has to be “less restrictive” for the desktop app while the sanitizer has to be implemented on the web-ui side. the locally run grass session doesn't have to be more generous in what it can accept, it's just that the local user is trusted already, and so we can get away with not having to harden every possible input. Sure we should clean those up, but there are thousands of them to fix and avoiding giving shell access to users who already have it makes the job more a matter of helping them to avoid crashes than protecting themselves from their own user account. but, even if(/when :) we did think the code was safe from buffer overflows and injection attacks, the web ui should still sanitize inputs as an extra layer of protection, since no software can be trusted to be perfect. gotcha. I personally think of the web-ui user as a trusted user with his own home on the server, but i agree about the need to have an extra layer of security on the web-ui to check user inputs (a web app can be easily victim of malaware etc. enabling the possibility for the user to loose control of the app, but that’s an extreme case) ? Is this not true: Any public http ipython notebook should be running in an isolated per-session chroot jail, much like many ftp servers do, and the ipython server's port should be firewalled off from accepting connections from anything other than localhost. And even in a chroot jail a few big loops could use up all the given RAM or disk space by mistake or on purpose. I see the implementation of the grass-web-shell as a second step in the web-ui development. Most of its security issue depends by the user/admin needs. I have an ipython notebook running on a remote server, it has a password and runs in https with an ssl cert. in my use case each each ipython instance runs on a specific port and use a different ssl cert. (all this settings are stored in the ipytohn notebook profile) … It is not super-secure but is is enough from my needs, we are a small group (4) of trusted and well known users. When the security needs are a high priority, tools like docker [1] , lxc [2] , supervisors [3] will let us to have more control reducing security risk. But this king of thing is isolated from the web-ui development. In any case the IPython-dev team is working hard on this direction, they just released 2.0 and from the roadmap [4] the multiuser interface will be released in the 3.0 version (coming out this summer) [1] https://www.docker.io/ [2] https://linuxcontainers.org/ [3] http://supervisord.org/ [4] https://github.com/ipython/ipython/wiki/Roadmap:-IPython [5] https://github.com/cni/ipython-hydra an old (1year) approach used at the university of standford to allow a multiuser interface to the IPYthon notebook -- As a general thing- GSoC students are by definition still students, and I'm sure that most of us could stand to improve our coding habits too, and would welcome the opportunity. It is the mentors' role to review and teach as much as it is the student's summer job to produce code. The side goal of GSoC is to have a formal avenue to train and grow the future dev team. The more the student knows coming in the better, but we shouldn't expect them to always be experienced vetrans. Somewhere in the middle is a nice balance point. :) regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
googling i found the ulimit should take care of memory usage : https://unix.stackexchange.com/questions/34334/how-to-create-a-user-with-limited-ram-usage http://ss64.com/bash/ulimit.html On Mar 11, 2014, at 1:20 AM, epi massimodisa...@gmail.com wrote: On Mar 11, 2014, at 12:36 AM, Hamish hamis...@yahoo.com wrote: Massimo wrote: Is my understanding that the grass parsing code has to be “less restrictive” for the desktop app while the sanitizer has to be implemented on the web-ui side. the locally run grass session doesn't have to be more generous in what it can accept, it's just that the local user is trusted already, and so we can get away with not having to harden every possible input. Sure we should clean those up, but there are thousands of them to fix and avoiding giving shell access to users who already have it makes the job more a matter of helping them to avoid crashes than protecting themselves from their own user account. but, even if(/when :) we did think the code was safe from buffer overflows and injection attacks, the web ui should still sanitize inputs as an extra layer of protection, since no software can be trusted to be perfect. gotcha. I personally think of the web-ui user as a trusted user with his own home on the server, but i agree about the need to have an extra layer of security on the web-ui to check user inputs (a web app can be easily victim of malaware etc. enabling the possibility for the user to loose control of the app, but that’s an extreme case) ? Is this not true: Any public http ipython notebook should be running in an isolated per-session chroot jail, much like many ftp servers do, and the ipython server's port should be firewalled off from accepting connections from anything other than localhost. And even in a chroot jail a few big loops could use up all the given RAM or disk space by mistake or on purpose. I see the implementation of the grass-web-shell as a second step in the web-ui development. Most of its security issue depends by the user/admin needs. I have an ipython notebook running on a remote server, it has a password and runs in https with an ssl cert. in my use case each each ipython instance runs on a specific port and use a different ssl cert. (all this settings are stored in the ipytohn notebook profile) … It is not super-secure but is is enough from my needs, we are a small group (4) of trusted and well known users. When the security needs are a high priority, tools like docker [1] , lxc [2] , supervisors [3] will let us to have more control reducing security risk. But this king of thing is isolated from the web-ui development. In any case the IPython-dev team is working hard on this direction, they just released 2.0 and from the roadmap [4] the multiuser interface will be released in the 3.0 version (coming out this summer) [1] https://www.docker.io/ [2] https://linuxcontainers.org/ [3] http://supervisord.org/ [4] https://github.com/ipython/ipython/wiki/Roadmap:-IPython [5] https://github.com/cni/ipython-hydra an old (1year) approach used at the university of standford to allow a multiuser interface to the IPYthon notebook -- As a general thing- GSoC students are by definition still students, and I'm sure that most of us could stand to improve our coding habits too, and would welcome the opportunity. It is the mentors' role to review and teach as much as it is the student's summer job to produce code. The side goal of GSoC is to have a formal avenue to train and grow the future dev team. The more the student knows coming in the better, but we shouldn't expect them to always be experienced vetrans. Somewhere in the middle is a nice balance point. :) regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Glynn, I’aware that the security risk handling in a web app is a hard and hot topic, hopefully a lot of project are working on this direction Of course a web-ui for grass will be designed for registered users and not for the anonymous www (password, registration and https can be implemented) The “web-shell” feature is obviously reserved to only “trusted users”. without this assumption application like Rstudio or IPython notebook should not exist. A multi user approach needs to be based IMHO on unix each user has to have its own home and access to filesystem. If this is not enough the application can be restricted to a chroot jail but this is not part of the UI development (is more a sys admin choice) For the authorization protocol it can be implemented using PAM. (i guess is what Rstudio is using) WT has a mature authentication module http://www.webtoolkit.eu/wt/blog/2011/11/29/wt___jwt_3_2_0 http://www.webtoolkit.eu/wt/blog/2013/08/07/security__wt_and_the_new_breach_vulnerability/ The potential user of a web ui for grass, need to be a trusted user in any case and need to go trough a registration process where an admin as to approve it. not anonymous users allowed. I guess the code behind the web-ui has to sanitize each text entry, will be this enough ? A sanitize inspection on all the “input” coming from the web-ui can be performed and this will be part of the UI itself, not of the grass modules. with the aim to avoid people doing something like .. http://xkcd.com/327/ ;) Massimo. On Mar 8, 2014, at 11:42 AM, Glynn Clements gl...@gclements.plus.com wrote: Rashad M wrote: My main concern would be security. You will need to thoroughly sanitise all inputs. You cannot rely upon GRASS modules to do this, as e.g. most string handling uses fixed-size buffers, so you need to explicitly limit the length of any arguments to avoid the possibility of buffer overruns. I am not clear with this. maybe security and web apps are creating me a confusion. If you do not understand the principles of secure programming, you shouldn't attempt to write a web interface to GRASS. GRASS modules typically do not attempt to be secure against invalid input. If you're providing access to untrusted users (users who aren't supposed to have the full privileges of the account under which the modules are executed), you will need to prevent invalid input from reaching the modules. -- 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] (standalone/OSGeo4W)Wingrass-R-integration - which way to go?
That will be great! we do need grass able to talk with R also in osgeo4w. do you have any experience in running rpy2 on windows and within the system python or with osgeo4w python ? .. hope your solution will make this happening! Massimo. On Mar 9, 2014, at 5:57 PM, Helmut Kudrnovsky hel...@web.de wrote: (C) try to include the R-batch-files into OSGeo4W-environment as its own package - a R-GRASS- integration would be then possible for standalone WinGRASS6/7 AND OSGeo4W-WinGRASS6/7 just forgotten to mention, with alternative (C) OSGeo4W and other projects may benefit from a smooth R-integration too. - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/standalone-OSGeo4W-Wingrass-R-integration-which-way-to-go-tp5127931p5127961.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
that!), should we put all the info on the wiki and extend the discussion to the user list as well ? Massimo. Best regards, Stefan From: Rashad M [mailto:mohammedrasha...@gmail.com] Sent: 6. mars 2014 21:32 To: Vaclav Petras Cc: epi; Blumentrath, Stefan; grass-dev@lists.osgeo.org Subject: Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI Hi Vaclav, I think that the web UI has to be based on the GRASS library and has to not depend on WxWidgets or any other Desktop gui toolkit like JavaFX. g.parser is enough to describe the modules interface and can be used to automatize the build of the module form for any modules. I got your idea of running the same on desktop, web, embedded platforms which is theoretically possible but the run into deadend from time to timeas they are started for desktop application. Qt has webkit interface, like you said for JavaFX ( i dont know much about the java). The philosophy of a desktop gui toolkit is entirely different from a web application ui. For example message passing or Qt signals/slots can't be used directly. Infact these people have a different implementation and interpretation of signal and slot when used in web. It is because people had written QtWebkit, Broadway with the same idea in mind as you, now it possible to run these. But they can't used in a many of application sucessfully. For example, rendering a map on Qt and web browser cant be same. We have WMS, WMTS etc.. for rendering imagery and WFS for vector data for this reason. We can't use the everywhere used GDAL for web easily. Boradway or JavaFX and other friends is very much feasible for some projects but not all. For this idea i envision the web gui app based on : - mapset-location wizard - map canvas - toolbar with: pan, query zoom in/out/bbox to-layer to-region - menu bar with same layout of grass desktop Here you can use GDAL, you are not obliged to use WPS, WMS, WFS to deal with your data. of course you can. None will fix the data used by web application and you could just give a try without evening compiling etc.. (these are some view on webgrass we both saying). Regarding the reuse of code. I am planning to use python bindings for wt and core classes will be reused. for parsing description file and the instead of sending boradway or JavaFX etc.. I will use directly a jquery dialog, html button, text and will have direct access to js code such that if i need to render a grass vector i could do it in openlayers or using wt itself to read the grass vector directly using gdal and draw polygons on a HTML5Canvas, SVG, etc.. I could use render module of grass ui to render a ppm or use pygrass numpy to read grass and render as before. For Sharing data is one thing i need to think about and having a shared location like share folders could be explored. For GRASS 3D. its not possible to use opengl on web. you must use webgl. and I dont think the previous GTK broadway could use opengl. Also GRASS is famous for large data processing and i was exploring that too. So the webUI must be behave differently when dealing with large data and should allow you to queue any process. Just thinking for now. And the whole idea of having webgrass will help users and developers as stefan was mentioning to run them on university or a company network without caring of operating system and Wt support Windows, Linux, OS X among other embedded platforms. The demo video of android was from 2012 and since then Wt improved Android support. In 2012 there was not automated apk. But when I checked in 2013 wt build system if configured for android will generate an apk for your application. I would ask you to think webUI as a wrapper like python, java etc.. You can have two gui for GRASS GIS. Remember about grass6.3 and earlier version which uses tcl/tk and was not used now because lack of support and or functionality and I am never saying Wxwidgets is not lacking a functionality for a desktop platform but on web perspective i think it is. Am I right? On Thu, Mar 6, 2014 at 8:42 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Thu, Mar 6, 2014 at 1:38 PM, epi massimodisa...@gmail.com wrote: At the moment i’m having so much fun with IPython Notebook that is my actually my grass interface ... in this idea i can see a little room for it too :) IPython Notebook would be the clear choice of Python command console for a web GUI written from scratch. Similarly, OpenLayers or Leaflet could become a web GRASS GUI map display. The downside of things such as GTK+ Broadway is that these solutions are simply not available. Although they can be always used inside some web view. With this we are getting to the other option I was mentioning: web-based GUI used in a web view(s) on desktop. This would allow us to use all highly interactive Java Script visualization
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Hi Rashad, Vaclav, all that’s a great idea for a GSOC! and I’m willing to apply as student for it :) I’m familiar with the Web GRASS prototype as i was a beta-testing during its early development. and i have experience with grass and python development and and with WT and its python bindings. At the moment i’m having so much fun with IPython Notebook that is my actually my grass interface ... in this idea i can see a little room for it too :) Cheers, Massimo. On Mar 6, 2014, at 12:45 PM, Blumentrath, Stefan stefan.blumentr...@nina.no wrote: Hi Rashad and Vaclav, If you allow me a user comment: The video looks very, very promoising. In our institution we are running GRASS on an Ubuntu Server which users access graphically either through either TightVNC or CYGWin-X. What I like about the Server solution is the “work where your data is” concept (even if server ressources may be smaller when shared by several users, compared to modern single user desktop PCs). I also perceive GRASS`s mapset concept as very useful for multi-user environment and data sharing (maybe except for the ownership check which hampers usage of mapsets by groups of people (I know there are workarounds (e.g. goup users as owners or overriding the ownership check in GRASS 7)). On the same Server we also have an RStudio-Server running which would be comparable to your webGRASS-solution. Our experience with RStudio Server is very positive, so I would appreciate such a solution for GRASS (though TightVNC and CYGWin-X are fine too)… The main advantage is (from my point of view) that users do not have to install additional software… Cheers Stefan From: grass-dev-boun...@lists.osgeo.org [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Rashad M Sent: 6. mars 2014 18:12 To: Vaclav Petras Cc: grass-dev@lists.osgeo.org Subject: Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI Hi Vaclav, On Thu, Mar 6, 2014 at 5:08 PM, Vaclav Petras wenzesl...@gmail.com wrote: Hi Rashad, web GRASS is certainly something we need and I'm very excited about that. But there are several things which should be considered to make this project successful. First, there is already one (desktop) GUI. Do we want to have (an maintain) another GUI? Is there a possibility to share the code between the desktop and web GUI? What about limiting the functionality of the web GUI to minimum, so that there will not much code to maintain and (as defined) nothing to add? This is the rather important part and we do want to reuse the code from core classes. Second, if we would decide to go the way of the full GUI (which resembles current wxGUI), wouldn't be better to use something like GTK+ GDK Broadway (1) to just reuse the desktop GUI on web, or to reuse web GUI on desktop (some web view or browser with local web pages and processes)? Although GTK+ and some wxWidgets applications can run with Broadway backend, wxPython, and especially GRASS is still far from running that way. However, there are some (perhaps even more interesting) alternatives such as Ulteo and noVNC. And I'm wondering what rollapp.com is using. I am interested to use Wt, not because of C++ and its recent Python love, because the idea of Widget centric, security of Wt apps (very much safe than any other web framework), embedded platform support. and so on. The main idea behind the birth of Wt is they want a web application to run on Web browser and embedded platforms (Android and others). The code is written in python or C++, webserver (Wthttp) renders a bunch of AJAX code and compatible with any recent browsers and it takes care of the some browser related stuff like special css prop for webkit and mozilla. And of course there is no code conversion or generation from a c++ to html/js script. Indeed I am allowed to use as much as javascript code. In the demo you can see openlayers widget! When you write: WButton *button = new WButton(); Wt makes the css for Wbutton which it has and provide a very decent and easy access to render it on browsers. I would rather stop here talking about Wt before it turn into a name drop of the toolkit which I dont want to do. Third, the GUI is not the only part. The GUI is supposed to be a part of some server/cloud infrastructure. You need to upload data, sign in users... And also we are not sure what are the security issues of using GRASS on server with unlimited access (i.e. you can run anything you want as opposed to predefined processes in WPS). IIUC, you mean security of the data right?. WebGRASS project is not about providing server infrastructure to preserve the data. Of course it wont allow to get other users data and in my plan users will have access to their own location rather than anyone can use everyone's data. And sensitivity of data uploaded is a question and you never publish such kind
Re: [GRASS-dev] m.nviz.image - Bad server connection
Markus, Hamish, thank you so much! starting my SSH session with: ssh -Y -C -C -l username my.server.host works perfect when i start grass from the SSH shell. but my “real-use case is a bit different I’m used to run grass from inside an IPython notebook to have grass loaded in the notebook session, i make a simple bash script : ‘ ipython_GRASS.sh ‘ that looks like : PREFIX=/home/$USER/Envs/env1 export LD_LIBRARY_PATH=$PREFIX/lib:$PREFIX/grass-7.0.svn/lib:$PREFIX/lib/R/lib/:$LD_LIBRARY_PATH export PYTHONPATH=$PREFIX/grass-7.0.svn/etc/python:$PYTHONPATH export GISBASE=$PREFIX/grass-7.0.svn/ export PATH=$PREFIX/bin/:$GISBASE/bin:$GISBASE/scripts:$PATH export GIS_LOCK=$$ mkdir -p /home/$USER/Envs/grass7data mkdir -p /home/$USER/Envs/.grass7 export GISRC=/home/$USER/Envs/.grass7/rc export GISDBASE=/home/$USER/Envs/grass7data export GRASS_TRANSPARENT=TRUE export GRASS_TRUECOLOR=TRUE export GRASS_PNG_COMPRESSION=9 export GRASS_PNG_AUTO_WRITE=TRUE ipython notebook —ip=xxx.xxx.xxx in this way i can start the notebook server from the SSH shell with : nohup sh ipython_GRASS.sh and all works fine. of course if i quit the SSH shell i will loose all the “ X support ” from my local machine. Do you have any hints on how to export the X support inside the ipython_GRASS.sh in order to tell grass to use the server X ? I’m asking because i’m using the script in a crontab file that is loaded at each reboot : @reboot nohup sh ipython_GRASS.sh so to have the notebook server always up and running without the needs to login into ssh all the time It works .. but except for the bad server connection. Thanks for any hints! Massimo. On Feb 7, 2014, at 10:11 PM, Hamish hamis...@yahoo.com wrote: epi wrote: i'm tring to generate a 3d image with m.nviz.image, the following command works fine form a 'standard' GRASS session in text mode on my laptop but if try to run the same command on a sever while i'm connected via SSH i got the error : Bad server connection MarkusN: Many grass power users work like this, so that's well tested in general. I was doing it with m.nviz.image last weekend actually. Note wrt running remotely on a server, m.nviz.image is special. Have you any clue on how to fix this ? is there any environment var that needs to be exported in order to have m.nviz.image running during an SSH session ? GRASS 7.0.svn (nc_spm_08_grass7):~ m.nviz.image \ elevation_map=elevation \ output=elevation_3d \ perspective=15 \ height=2000 \ color_map=elevation \ resolution_fine=1 \ resolution_coarse=1 \ format=tif ERROR: Bad server connection Did you redirect the Display stream? ssh -Y yourserver Perhaps that solving the issue. Depending on if it's a local gigabit network or if you are calling in from home, I'd strongly suggest to use 'ssh -C' as well, since m.nviz.image will want to do about half of its processing on the *local* X server, not the remote computer, and that's a lot of network traffic! Last weekend's task was running m.nviz.image many times in a loop for an animation, and trying to do it remotely from my netbook via a GNU Screen session. But the network connection out at the farm wasn't that good and the several years old netbook's graphics hardware is pretty poor compared to the graphics card in the remote workstation. It took ~10 times as long running it remotely, but it did get there. m.nviz.image didn't work (entirely from the command line) when the DISPLAY enviro var wasn't set correctly in GNU Screen though, I had to reestablish the session to fix that first. good luck, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] m.nviz.image - Bad server connection
Hi, i’m tring to generate a 3d image with m.nviz.image, the following command works fine form a ’standard’ GRASS session in text mode on my laptop but if try to run the same command on a sever while i’m connected via SSH i got the error : Bad server connection Have you any clue on how to fix this ? is there any environment var that needs to be exported in order to have m.nviz.image running during an SSH session ? GRASS 7.0.svn (nc_spm_08_grass7):~ m.nviz.image \ elevation_map=elevation \ output=elevation_3d \ perspective=15 \ height=2000 \ color_map=elevation \ resolution_fine=1 \ resolution_coarse=1 \ format=tif ERROR: Bad server connection GRASS 7.0.svn (nc_spm_08_grass7):~ Thanks for you help! Massimo. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] segfault on 'r.stream.extract' - debian armh
Sorry for the delay in answering, i was out of town. i tried gdal directly on the grass dataset, but this custom built gdal doesn’t have grass-plugin enabled. tring to build the grass-pluginn with gdal 1.10.1 and grass7 : cd gdal/frmts/grass make dist tar -zxvf gdal-grass-1.10.1.tar.gz cd tar -zxvf gdal-grass-1.10.1 ./configure --with-gdal=/home/epi/Envs/env1/bin/gdal-config --with-grass=/home/epi/Envs/env1/grass-7.0.svn/ can’t find the grass libs : checking for G_asprintf in -lgrass_gis... no checking for G_putenv in -lgrass_gis.7.0.svn... no configure: error: --with-grass=/home/epi/Envs/env1/grass-7.0.svn/ requested, but libraries not found! Perhaps you need to set LD_LIBRARY_PATH to include /home/epi/Envs/env1/grass-7.0.svn//lib? i also tried : export LD_LIBRARY_PATH=/home/epi/Envs/env1/grass-7.0.svn/lib:$LD_LIBRARY_PATH or adding : /home/epi/Envs/env1/grass-7.0.svn/lib in /etc/ld.so.conf.d/grass.conf but i got the same log, i think to remember tahat gdal-grass is not compatible with grass70. in any case I just tried gdalinfo on a standard geotiff (i used the the GTiff from the grass dataset) and it works fine : epi@udoo:~$ which gdalinfo /home/epi/Envs/env1/bin/gdalinfo epi@udoo:~$ cd epi@udoo:~$ gdalinfo basin_50K.tif Driver: GTiff/GeoTIFF Files: basin_50K.tif Size is 1500, 1350 Coordinate System is: PROJCS[Lambert Conformal Conic, GEOGCS[NAD83, DATUM[North_American_Datum_1983, SPHEROID[GRS 1980,6378137,298.2572221010002, AUTHORITY[EPSG,7019]], AUTHORITY[EPSG,6269]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4269]], PROJECTION[Lambert_Conformal_Conic_2SP], PARAMETER[standard_parallel_1,36.16], PARAMETER[standard_parallel_2,34.34], PARAMETER[latitude_of_origin,33.75], PARAMETER[central_meridian,-79], PARAMETER[false_easting,609601.22], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]]] Origin = (63.000,228500.000) Pixel Size = (10.000,-10.000) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 63.000, 228500.000) ( 78d46'27.41W, 35d48'34.59N) Lower Left ( 63.000, 215000.000) ( 78d46'28.63W, 35d41'16.54N) Upper Right ( 645000.000, 228500.000) ( 78d36'29.89W, 35d48'33.08N) Lower Right ( 645000.000, 215000.000) ( 78d36'32.01W, 35d41'15.03N) Center ( 637500.000, 221750.000) ( 78d41'29.49W, 35d44'54.91N) Band 1 Block=1500x1 Type=Int32, ColorInterp=Gray NoData Value=- epi@udoo:~$ On Dec 10, 2013, at 11:22 AM, Glynn Clements gl...@gclements.plus.com wrote: epi wrote: thanks for the detailed explanation! is there something i can try ? Does GDAL itself work? Try running one of its utilities, e.g. gdalinfo. -- 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] segfault on 'r.stream.extract' - debian armh
i tried this way : valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --track-fds=yes --track-origins=yes r.stream.extract elevation=elevation50m@PERMANENT accumulation=accum threshold=40 stream_rast=stream_network stream_vect=streams —o this the log : https://gist.github.com/27f7666de4eb0cf058b2 On Dec 8, 2013, at 10:46 AM, Maris Nartiss maris@gmail.com wrote: As Glynn is pointing to a possible memory problem, I would suggest to try to run module under valgrind to see any bad fiddling with memory. No help form me, Maris. 2013/12/8 epi massimodisa...@gmail.com: I tried to build gdal from source , without-pt support and rebuild grass (without-pg) and pointing it to the newly built gdal. i had the same problem, same log :( should i try to rebuild libcripto ? any help in how to debug this problem is greatly appreciated. Also if you think that other modules (not just r.stream.extract) are potentially subject of segfault, let me know and ill try to run them on the NC tests dataset. Thanks, Massimo. On Dec 7, 2013, at 1:15 PM, epi massimodisa...@gmail.com wrote: Hi Glynn, thanks for the detailed explanation! is there something i can try ? perhaps, build gdal from src and disabling postgresql support ? Thanks a lot! Massimo. this a copy of the gdb-backtrace : (gdb) exec-file r.stream.extract elevation=elevation50m@PERMANENT accumulation=accum threshold=40 stream_rast=stream_network stream_vect=streams --o (gdb) r Starting program: /home/epi/Envs/env1/grass-7.0.svn/bin/r.stream.extract [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/arm-linux-gnueabihf/libthread_db.so.1. Program received signal SIGILL, Illegal instruction. 0x2c99fe68 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 (gdb) bt #0 0x2c99fe68 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 Cannot access memory at address 0x0 #1 0x2c99db2c in OPENSSL_cpuid_setup () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 #2 0x2aab60d6 in call_init (env=0x7efff35c, argv=0x7efff354, argc=1, l=optimized out) at dl-init.c:84 #3 call_init (l=optimized out, argc=1, argv=0x7efff354, env=0x7efff35c) at dl-init.c:34 #4 0x2aab6158 in _dl_init (main_map=0x2aaca958, argc=1, argv=0x7efff354, env=0x7efff35c) at dl-init.c:133 #5 0x2aaabc62 in _dl_start_user () from /lib/ld-linux-armhf.so.3 #6 0x2aaabc62 in _dl_start_user () from /lib/ld-linux-armhf.so.3 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) On Dec 6, 2013, at 7:24 PM, Glynn Clements gl...@gclements.plus.com wrote: epi wrote: googling � is it possible that in : http://svn.osgeo.org/grass/grass/trunk/raster/r.stream.extract/ there may be some assembly code that gets executed which won't work under armhf ? GRASS doesn't use assembly. And the SIGILL is reported as occurring in libcrypto, not in the GRASS code. The libcrypto dependency typically exists because GDAL links to libpq (PostgreSQL client library) which uses libcrypto for certain authentication methods. libcrypto probably isn't even being used in this situation, so I suspect that a bug is causing either a function pointer or a return address to be corrupted, resulting in a jump to a random memory location which just happens to be inside libcrypto. As r.stream.extract is relatively new, it's possible that it hasn't seen significant testing on platforms other than x86 and x86-64. Apart from anything else, alignment bugs won't show up on those platforms (x86 supports unaligned access, ARM doesn't AFAIK). -- 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] segfault on 'r.stream.extract' - debian armh
Hi Maris, this is the bt : (gdb) exec-file r.stream.extract elevation=elevation50m@PERMANENT accumulation=accum threshold=40 stream_rast=stream_network stream_vect=streams --o (gdb) r Starting program: /home/epi/Envs/env1/grass-7.0.svn/bin/r.stream.extract [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/arm-linux-gnueabihf/libthread_db.so.1. Program received signal SIGILL, Illegal instruction. 0x2c99fe68 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 (gdb) bt #0 0x2c99fe68 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 Cannot access memory at address 0x0 #1 0x2c99db2c in OPENSSL_cpuid_setup () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 #2 0x2aab60d6 in call_init (env=0x7efff35c, argv=0x7efff354, argc=1, l=optimized out) at dl-init.c:84 #3 call_init (l=optimized out, argc=1, argv=0x7efff354, env=0x7efff35c) at dl-init.c:34 #4 0x2aab6158 in _dl_init (main_map=0x2aaca958, argc=1, argv=0x7efff354, env=0x7efff35c) at dl-init.c:133 #5 0x2aaabc62 in _dl_start_user () from /lib/ld-linux-armhf.so.3 #6 0x2aaabc62 in _dl_start_user () from /lib/ld-linux-armhf.so.3 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) rebuilding with : gcc -g -Wall -O0 gave me no worning in r.stream.extract On Dec 6, 2013, at 6:36 PM, Maris Nartiss maris@gmail.com wrote: Any warnings during compilation? Try to compile with -g and -O0 to get slow but debugging-friendly version. When program gets stopped by SIGILL in gdb, issue bt command to get backtrace. No help form me, but more info never hurts ;) Maris. 2013/12/6 epi massimodisa...@gmail.com: Hi ! this the output of gdb : Starting program: /home/epi/Envs/env1/grass-7.0.svn/bin/r.stream.extract .stream.extract elevation=elevation50m@PERMANENT accumulation=accum threshold=40 stream_rast=stream_network stream_vect=streams --o [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/arm-linux-gnueabihf/libthread_db.so.1. Program received signal SIGILL, Illegal instruction. 0x2c966e68 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 (gdb) Thanks for your help! Massimo. On Dec 6, 2013, at 4:16 PM, Rashad M mohammedrasha...@gmail.com wrote: Hello Massimo, A gdb output could be more helpful for a segfault On Fri, Dec 6, 2013 at 7:06 PM, epi massimodisa...@gmail.com wrote: Hi, i’m trying to run “r.stream.extract” on a little linux machine, i got got grass up and running on a small quad-core Arm 1gb ram OS : Debian SID ArmHF. the command i’m using is : r.stream.extract elevation=elevation@PERMANENT accumulation=accum threshold=40 stream_rast=stream_network stream_vect=streams --o --q location : nc_spm_08_grass7/PERMANENT/ i set the debug level to 5, this the segfault log : https://gist.github.com/epifanio/7829206 if helpful, this is the log of make clean and make : https://gist.github.com/epifanio/7829256 On other platform (same grass and r.stream.extract version it wks just fine) Have you any idea on what’s wrong ? Thanks, Massimo. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Regards, Rashad ___ 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] segfault on 'r.stream.extract' - debian armh
Hi Glynn, thanks for the detailed explanation! is there something i can try ? perhaps, build gdal from src and disabling postgresql support ? Thanks a lot! Massimo. this a copy of the gdb-backtrace : (gdb) exec-file r.stream.extract elevation=elevation50m@PERMANENT accumulation=accum threshold=40 stream_rast=stream_network stream_vect=streams --o (gdb) r Starting program: /home/epi/Envs/env1/grass-7.0.svn/bin/r.stream.extract [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/arm-linux-gnueabihf/libthread_db.so.1. Program received signal SIGILL, Illegal instruction. 0x2c99fe68 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 (gdb) bt #0 0x2c99fe68 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 Cannot access memory at address 0x0 #1 0x2c99db2c in OPENSSL_cpuid_setup () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 #2 0x2aab60d6 in call_init (env=0x7efff35c, argv=0x7efff354, argc=1, l=optimized out) at dl-init.c:84 #3 call_init (l=optimized out, argc=1, argv=0x7efff354, env=0x7efff35c) at dl-init.c:34 #4 0x2aab6158 in _dl_init (main_map=0x2aaca958, argc=1, argv=0x7efff354, env=0x7efff35c) at dl-init.c:133 #5 0x2aaabc62 in _dl_start_user () from /lib/ld-linux-armhf.so.3 #6 0x2aaabc62 in _dl_start_user () from /lib/ld-linux-armhf.so.3 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) On Dec 6, 2013, at 7:24 PM, Glynn Clements gl...@gclements.plus.com wrote: epi wrote: googling � is it possible that in : http://svn.osgeo.org/grass/grass/trunk/raster/r.stream.extract/ there may be some assembly code that gets executed which won't work under armhf ? GRASS doesn't use assembly. And the SIGILL is reported as occurring in libcrypto, not in the GRASS code. The libcrypto dependency typically exists because GDAL links to libpq (PostgreSQL client library) which uses libcrypto for certain authentication methods. libcrypto probably isn't even being used in this situation, so I suspect that a bug is causing either a function pointer or a return address to be corrupted, resulting in a jump to a random memory location which just happens to be inside libcrypto. As r.stream.extract is relatively new, it's possible that it hasn't seen significant testing on platforms other than x86 and x86-64. Apart from anything else, alignment bugs won't show up on those platforms (x86 supports unaligned access, ARM doesn't AFAIK). -- 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] segfault on 'r.stream.extract' - debian armh
I tried to build gdal from source , without-pt support and rebuild grass (without-pg) and pointing it to the newly built gdal. i had the same problem, same log :( should i try to rebuild libcripto ? any help in how to debug this problem is greatly appreciated. Also if you think that other modules (not just r.stream.extract) are potentially subject of segfault, let me know and ill try to run them on the NC tests dataset. Thanks, Massimo. On Dec 7, 2013, at 1:15 PM, epi massimodisa...@gmail.com wrote: Hi Glynn, thanks for the detailed explanation! is there something i can try ? perhaps, build gdal from src and disabling postgresql support ? Thanks a lot! Massimo. this a copy of the gdb-backtrace : (gdb) exec-file r.stream.extract elevation=elevation50m@PERMANENT accumulation=accum threshold=40 stream_rast=stream_network stream_vect=streams --o (gdb) r Starting program: /home/epi/Envs/env1/grass-7.0.svn/bin/r.stream.extract [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/arm-linux-gnueabihf/libthread_db.so.1. Program received signal SIGILL, Illegal instruction. 0x2c99fe68 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 (gdb) bt #0 0x2c99fe68 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 Cannot access memory at address 0x0 #1 0x2c99db2c in OPENSSL_cpuid_setup () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 #2 0x2aab60d6 in call_init (env=0x7efff35c, argv=0x7efff354, argc=1, l=optimized out) at dl-init.c:84 #3 call_init (l=optimized out, argc=1, argv=0x7efff354, env=0x7efff35c) at dl-init.c:34 #4 0x2aab6158 in _dl_init (main_map=0x2aaca958, argc=1, argv=0x7efff354, env=0x7efff35c) at dl-init.c:133 #5 0x2aaabc62 in _dl_start_user () from /lib/ld-linux-armhf.so.3 #6 0x2aaabc62 in _dl_start_user () from /lib/ld-linux-armhf.so.3 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) On Dec 6, 2013, at 7:24 PM, Glynn Clements gl...@gclements.plus.com wrote: epi wrote: googling � is it possible that in : http://svn.osgeo.org/grass/grass/trunk/raster/r.stream.extract/ there may be some assembly code that gets executed which won't work under armhf ? GRASS doesn't use assembly. And the SIGILL is reported as occurring in libcrypto, not in the GRASS code. The libcrypto dependency typically exists because GDAL links to libpq (PostgreSQL client library) which uses libcrypto for certain authentication methods. libcrypto probably isn't even being used in this situation, so I suspect that a bug is causing either a function pointer or a return address to be corrupted, resulting in a jump to a random memory location which just happens to be inside libcrypto. As r.stream.extract is relatively new, it's possible that it hasn't seen significant testing on platforms other than x86 and x86-64. Apart from anything else, alignment bugs won't show up on those platforms (x86 supports unaligned access, ARM doesn't AFAIK). -- 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] segfault on 'r.stream.extract' - debian armh
Hi, i’m trying to run “r.stream.extract” on a little linux machine, i got got grass up and running on a small quad-core Arm 1gb ram OS : Debian SID ArmHF. the command i’m using is : r.stream.extract elevation=elevation@PERMANENT accumulation=accum threshold=40 stream_rast=stream_network stream_vect=streams --o --q location : nc_spm_08_grass7/PERMANENT/ i set the debug level to 5, this the segfault log : https://gist.github.com/epifanio/7829206 if helpful, this is the log of make clean and make : https://gist.github.com/epifanio/7829256 On other platform (same grass and r.stream.extract version it wks just fine) Have you any idea on what’s wrong ? Thanks, Massimo.___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] segfault on 'r.stream.extract' - debian armh
i tried to add : handle SIGILL nostop to have more debug .. i can’t understand the log :/ (gdb) handle SIGILL nostop SignalStop Print Pass to program Description SIGILLNoYes Yes Illegal instruction (gdb) (gdb) exec-file r.stream.extract elevation=elevation@PERMANENT accumulation=accum threshold=20 stream_rast=stream_network stream_vect=streams --o (gdb) r Starting program: /home/epi/Envs/env1/grass-7.0.svn/bin/r.stream.extract .stream.extract elevation=elevation50m@PERMANENT accumulation=accum threshold=40 stream_rast=stream_network stream_vect=streams --o [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/arm-linux-gnueabihf/libthread_db.so.1. Program received signal SIGILL, Illegal instruction. D2/5: G_file_name(): path = /home/epi/Envs/grass7data/nc_spm_08_grass7/PERMANENT Description: Performs stream network extraction. Keywords: raster, hydrology, stream network Usage: r.stream.extract elevation=name [accumulation=name] [depression=name] threshold=value [d8cut=value] [mexp=value] [stream_length=value] [memory=value] [stream_rast=name] [stream_vect=name] [direction=name] [--overwrite] [--verbose] [--quiet] Flags: --o Allow output files to overwrite existing files --v Verbose module output --q Quiet module output Parameters: elevation Name of input elevation raster map accumulation Name of input accumulation raster map Stream extraction will use provided accumulation instead of calculating it a new depression Name of raster map with real depressions Streams will not be routed out of real depressions threshold Minimum flow accumulation for streams Must be 0 d8cut Use SFD above this threshold If accumulation is larger than d8cut, SFD is used instead of MFD. Applies only if no accumulation map is given. default: infinity mexp Montgomery exponent for slope, disabled with 0 Montgomery: accumulation is multiplied with pow(slope,mexp) and then compared with threshold. default: 0 stream_length Delete stream segments shorter than stream_length cells. Applies only to first-order stream segments (springs/stream heads). default: 0 memory Maximum memory to be used in MB default: 300 stream_rast Name for output raster map with unique stream ids stream_vect Name for output vector map with unique stream ids direction Name for output raster map with flow direction ERROR: Option elevation does not accept multiple answers [Inferior 1 (process 7565) exited with code 01] (gdb) On Dec 6, 2013, at 4:32 PM, epi massimodisa...@gmail.com wrote: Hi ! this the output of gdb : Starting program: /home/epi/Envs/env1/grass-7.0.svn/bin/r.stream.extract .stream.extract elevation=elevation50m@PERMANENT accumulation=accum threshold=40 stream_rast=stream_network stream_vect=streams --o [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/arm-linux-gnueabihf/libthread_db.so.1. Program received signal SIGILL, Illegal instruction. 0x2c966e68 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 (gdb) Thanks for your help! Massimo. On Dec 6, 2013, at 4:16 PM, Rashad M mohammedrasha...@gmail.com wrote: Hello Massimo, A gdb output could be more helpful for a segfault On Fri, Dec 6, 2013 at 7:06 PM, epi massimodisa...@gmail.com wrote: Hi, i’m trying to run “r.stream.extract” on a little linux machine, i got got grass up and running on a small quad-core Arm 1gb ram OS : Debian SID ArmHF. the command i’m using is : r.stream.extract elevation=elevation@PERMANENT accumulation=accum threshold=40 stream_rast=stream_network stream_vect=streams --o --q location : nc_spm_08_grass7/PERMANENT/ i set the debug level to 5, this the segfault log : https://gist.github.com/epifanio/7829206 if helpful, this is the log of make clean and make : https://gist.github.com/epifanio/7829256 On other platform (same grass and r.stream.extract version it wks just fine) Have you any idea on what’s wrong ? Thanks, Massimo. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Regards, Rashad ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] segfault on 'r.stream.extract' - debian armh
googling … is it possible that in : http://svn.osgeo.org/grass/grass/trunk/raster/r.stream.extract/ there may be some assembly code that gets executed which won't work under armhf ? Massimo. On Dec 6, 2013, at 4:37 PM, epi massimodisa...@gmail.com wrote: i tried to add : handle SIGILL nostop to have more debug .. i can’t understand the log :/ (gdb) handle SIGILL nostop SignalStopPrint Pass to program Description SIGILLNo Yes Yes Illegal instruction (gdb) (gdb) exec-file r.stream.extract elevation=elevation@PERMANENT accumulation=accum threshold=20 stream_rast=stream_network stream_vect=streams --o (gdb) r Starting program: /home/epi/Envs/env1/grass-7.0.svn/bin/r.stream.extract .stream.extract elevation=elevation50m@PERMANENT accumulation=accum threshold=40 stream_rast=stream_network stream_vect=streams --o [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/arm-linux-gnueabihf/libthread_db.so.1. Program received signal SIGILL, Illegal instruction. D2/5: G_file_name(): path = /home/epi/Envs/grass7data/nc_spm_08_grass7/PERMANENT Description: Performs stream network extraction. Keywords: raster, hydrology, stream network Usage: r.stream.extract elevation=name [accumulation=name] [depression=name] threshold=value [d8cut=value] [mexp=value] [stream_length=value] [memory=value] [stream_rast=name] [stream_vect=name] [direction=name] [--overwrite] [--verbose] [--quiet] Flags: --o Allow output files to overwrite existing files --v Verbose module output --q Quiet module output Parameters: elevation Name of input elevation raster map accumulation Name of input accumulation raster map Stream extraction will use provided accumulation instead of calculating it a new depression Name of raster map with real depressions Streams will not be routed out of real depressions threshold Minimum flow accumulation for streams Must be 0 d8cut Use SFD above this threshold If accumulation is larger than d8cut, SFD is used instead of MFD. Applies only if no accumulation map is given. default: infinity mexp Montgomery exponent for slope, disabled with 0 Montgomery: accumulation is multiplied with pow(slope,mexp) and then compared with threshold. default: 0 stream_length Delete stream segments shorter than stream_length cells. Applies only to first-order stream segments (springs/stream heads). default: 0 memory Maximum memory to be used in MB default: 300 stream_rast Name for output raster map with unique stream ids stream_vect Name for output vector map with unique stream ids direction Name for output raster map with flow direction ERROR: Option elevation does not accept multiple answers [Inferior 1 (process 7565) exited with code 01] (gdb) On Dec 6, 2013, at 4:32 PM, epi massimodisa...@gmail.com wrote: Hi ! this the output of gdb : Starting program: /home/epi/Envs/env1/grass-7.0.svn/bin/r.stream.extract .stream.extract elevation=elevation50m@PERMANENT accumulation=accum threshold=40 stream_rast=stream_network stream_vect=streams --o [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/arm-linux-gnueabihf/libthread_db.so.1. Program received signal SIGILL, Illegal instruction. 0x2c966e68 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 (gdb) Thanks for your help! Massimo. On Dec 6, 2013, at 4:16 PM, Rashad M mohammedrasha...@gmail.com wrote: Hello Massimo, A gdb output could be more helpful for a segfault On Fri, Dec 6, 2013 at 7:06 PM, epi massimodisa...@gmail.com wrote: Hi, i’m trying to run “r.stream.extract” on a little linux machine, i got got grass up and running on a small quad-core Arm 1gb ram OS : Debian SID ArmHF. the command i’m using is : r.stream.extract elevation=elevation@PERMANENT accumulation=accum threshold=40 stream_rast=stream_network stream_vect=streams --o --q location : nc_spm_08_grass7/PERMANENT/ i set the debug level to 5, this the segfault log : https://gist.github.com/epifanio/7829206 if helpful, this is the log of make clean and make : https://gist.github.com/epifanio/7829256 On other platform (same grass and r.stream.extract version it wks just fine) Have you any idea on what’s wrong ? Thanks, Massimo. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Regards, Rashad ___ grass-dev mailing list grass-dev@lists.osgeo.org http
Re: [GRASS-dev] trying to compile GRASS 7 on Mavericks
got this warning once: /Users/cmbarton/Dropbox/GRASS_dropbox/source/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/gui_core/goutput.py:234: wxPyDeprecationWarning: Call to deprecated item 'SetVirtualSizeHints’. This is harmless, I could probably remove the calls of SetVirtualSizeHints, but I am not sure if it is needed in the older wxPython versions. I assume this is a function of wxPython 2.9 SetVirtualSizeHints is used in wxPython 2.8, in 2.9 it's not needed, that's why the depreciation warning. That's what I figured. The digitizer is acting funny. When I called my new test vector “delete”, it crashed the GUI. When I tried it again, with “testdelete1” it is OK. But now it is giving me an error that the cat number is duplicated with my first area. It is locked up and I can’t get out of some kind of loop with the dialog to create a table entry. But this may be problems with the digitizer in general rather than the new compilation. I had the GUI lock up earlier but it seems to be working OK now, if a bit sluggish. Tearoff menus are fine. The vector graphics look much nicer. I think that Cairo is displaying better with this wxPython. Please report the issues (via trac) related to the wxPython 2.9, I already tried to fix some of these but there will be more of them. I need the issues to be reproducible. I am wondering if I should revert to wxPython 2.8. This requires some hacks to it runs 32bit I think. But it is what I was using before. Well, we will have to run it with new wxPython anyway ... I agree. But then 2.9 is the dev release. I assume that there is a 2.10 stable somewhere in the near future. It sort of seems unstable. So maybe it is still premature to move to 2.9 after a successful build the gui doesn’t start and shows an error : AccessInit: hash collision: 3 for both 1 and 1. looking here : http://jaredforsyth.com/blog/2010/apr/28/accessinit-hash-collision-3-both-1-and-1/ i fixed it changing in grass7_trunk/visualization/xganim/Users/epi/dev/grass7_trunk/gui/wxpython/psmap/utils.py from : ## try: import Image as PILImage havePILImage = True except ImportError: havePILImage = False ## to : ## try : import PIL.Image sys.modules['Image'] = PIL.Image from PIL import Image as PILImage except ImportError: havePILImage = False ## Michael, do you have instructions on how to enable OpenCL support ? using home-brew i didn’t had issue with odbc. Massimo. 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-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 Anna Michael Anna Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www:http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Dec 4, 2013, at 3:54 PM, Michael Barton michael.bar...@asu.edu wrote: Forgot to mention that r.terraflow and r.viewshed do not compile. I assume this is a C++ issue. Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice:480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www: http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Dec 4, 2013, at 3:50 PM, Michael Barton michael.bar...@asu.edu wrote: I was able to compile and open GRASS 7 under Mavericks. Here is what I’ve done so far. 1. I had to uninstall and reinstall Xcode and the CommandLineTools. You may or may not have to do this. If you have not yet updated Xcode, you should delete your existing Xcode before doing so. There are several approaches to doing this depending on how you installed it. There are references to using an Uninstall_Devtools utility that supposedly lives in /Library/Developer. I’ve never had this. If you installed from the app store, you need to open the launch pad and delete Xcode from there. AFAIK, there is no way to delete the CommandLineTools (unless you want to do it one by one). I also installed the AuxTools because I had these before. I don’t know that I need them though. 2. I also installed wxPython
Re: [GRASS-dev] ogsf, nviz, m.nviz.image build errors -- ticket #1423 ?
i'm on ubuntu 13.04 as well grass_trunk configured with : ./configure --with-freetype-includes=/usr/include/freetype2 --with-blas --with-netcdf --with-geos --with-lapack --with-odbc --with-pthread --with-readline --with-sqlite --with-wxwidgets --with-postgres-includes=/usr/include/postgresql --with-postgres wx is 2.8 : wx-config --version-full 2.8.12.1 i do not have errors to build ogsf/nviz/m.nviz.image the only error i got are in wximgview/xganim i guess because of wx-2.8 attached the log : https://gist.github.com/5793126 Massimo. Il giorno 16/giu/2013, alle ore 13:35, Nikos Alexandris n...@nikosalexandris.net ha scritto: On Sunday 16 of June 2013 20:21:12 Nikos Alexandris wrote: Hi! In Ubuntu 13.04, as you probably know, ogsf, nviz and m.nviz.image (still) wont compile. This all is related to ticket https://trac.osgeo.org/grass/ticket/1423 I guess. --%--- GRASS GIS 7.0.svn 56732 compilation log -- Started compilation: Sun Jun 16 19:13:04 EEST 2013 -- Errors in: /geo/osgeo/src/grass_trunk/lib/ogsf /geo/osgeo/src/grass_trunk/lib/nviz /geo/osgeo/src/grass_trunk/misc/m.nviz.image -- 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: Sun Jun 16 19:31:30 EEST 2013 make: *** [default] Error 1 ---%-- Same (almost) for grass64: --%--- -- GRASS GIS compilation log - Started compilation: Sun Jun 16 20:24:02 EEST 2013 -- Errors in: /geo/osgeo/src/grass64_release/lib/ogsf /geo/osgeo/src/grass64_release/lib/nviz /geo/osgeo/src/grass64_release/misc/m.nviz.image /geo/osgeo/src/grass64_release/visualization/xganim /geo/osgeo/src/grass64_release/visualization/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: Sun Jun 16 20:32:53 EEST 2013 make: *** [default] Error 1 ---%-- Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.3 release planning
i can provide feedback in testing 6.4.x running with wx2.9, if you have any kind of patch that i can apply and test i'll be happy to try it thanks! Il giorno 05/giu/2013, alle ore 06:16, Hamish hamis...@yahoo.com ha scritto: status update time, the main two remaining from my perspective are GRASS_PYTHON in env.bat and the d.mon Cairo lockup from wxGUI. i.e. not much. perhaps wx2.9 + Mac if there is movement on it, if stalled go without it. #1428: still some missing some dlls We'll have to wait and see how many people complain about missing msvcr80.dll and msvcr90.dll, and direct them to the .NET Frameworks package. But it should be fewer than before.. Users stuck behind a proxy server may still have a bad time trying to download the MS runtimes. NSIS expert needed to solve that one. (a real issue for students at my univ., but not a general blocker IMO) moving on, #943: selecting cairo rendering locks up the wxGUI After the gui code runs 'd.mon start=cairo' it locks up and you need to use `xkill` to recover. I suspect it's some simple waiting for a pipe to close after a stderr message or so in the wxGUI's custom RunCommand() python function, but it's not my area of expertise so help needed. If it won't be fixed in the final release we should grey out the option, but with all the other bugs around that now fixed it feels so very close to being solved.. use full path to GRASS's python.exe in env.bat keeps coming up, so seems important simple to do. #1971: r.in.bin: fix LFS support in G_ftell() done, ready to go. (I hope) #1849: g.proj datum transforms broken for epsg and proj4 terms #1967: wxPy loc'n wiz: doesn't allow ellipsoid without datum both done, ready to go. (I hope) lesser issues moved to new tickets targeted at 6.4.4. #1952: package 'more.exe' with msys (pager for g.list) (also +tac.exe +seq.exe +xml2.exe and #1275 (about zip.exe) --what controls what unix powertools are packaged in extrabin/? ? zip is there, but unzip (for r.in.srtm) is not. xml2.exe makes a big difference for r.in.wms[.sh] which *now works on wingrass* (!!) / except for the xml2 :) seq we could live without but it is nice. same for tac, we work around it missing for Mac as well. but if we figure out how to add one binary we could easily add them all. #854: building addons on Mac there was some progress in the last week, what was the outcome? It seems we should also add discussion of wx2.9 + mac to this todo or not todo list, and get that into devbr6 ASAP for the trial and error. if it is not happening now, maybe release a quick 6.4.4 as soon as that's ready. #: go through changelog for new and fix bullet points, add to trac wiki page #: write the 6.4.3 release announcement and press release todo. regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.3 release planning
ok, is my understanding that there is a lack of tester on mac, i'll be happy to test any patch or svn update if available (with or without having it included in next release) i agree wx2.9 is not stable .. but is also true that is More Than 2 Years that osx user with a full 64bit system are without a working WX-GRASS-GUI hopeful tcltk still work on grass64 :) Il giorno 05/giu/2013, alle ore 07:27, Martin Landa landa.mar...@gmail.com ha scritto: Hi, 2013/6/5 epi massimodisa...@gmail.com: i can provide feedback in testing 6.4.x running with wx2.9, if you have any kind of patch that i can apply and test i'll be happy to try it I think it's not good idea to apply wx2.9 patches for 6.4.3. Please bear in mind, that we have already 3 release candidates for 6.4.3 (RC1 from 10/24/2012 !!!). In this way we will never release 6.4.3... Let's move such things to 6.4.4. Let's release the software otherwise most of the user will use dev snapshots from SVN... Martin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.3 release planning
Hi All, i just tried to build grass6_release from the svn grass64 svn, Revision: 56411 build is fine, no errors detected, but without GUI (wx or tcltk are not working in my case, montain lion 64 bit build ***) to test the extension build i tried : g.extension extension=i.landsat.dehaze and it worked without errors. note : from the g.extension page the example point to i.landsat.toar (now included as default in grass) we should change it. *** i was wondering if the WXgui changes in grass7, to have it running with wx2.9-cocoa can be back ported to grass6.x .. is this possible ? thank you, Massimo Il giorno 25/mag/2013, alle ore 12:05, William Kyngesburye wokl...@kyngchaos.com ha scritto: On May 25, 2013, at 5:31 AM, Markus Neteler wrote: #854: building addons on Mac (assume we can handle post-release in pkg'ing) --what's the situation? Commonly our Mac packagers package the release (candidate) versions, so we'll know ex-post only. I had some time to look at this, and it should be fixed now, for 6.4 at least. (Mac makefile was out of sync with the main makefile) Michael, if you're back or have dev Mac available, (and Hamish, do you have a Mac to try?) - can you verify it works for you? - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence - the wisdom of Tarzan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] grass7 - mac osx- 64bit python
Hi, is one week now that i'm testing a grass7 build, using wx cocoa (svn version built from source) i'm really happy to say that almost everything is working fine! .. few debug reported here : - profile tool : -- the pen widget doesn't draw a line and no profile is plotted but ... if i select the measure tool make a measurement and then without quitting the measurement tool (boucle click on the canvas) i open the profile tool .. then the profile is plotted correctly - add text layer : -- doesn't change the font size - map composer run but doesn't have a toolbar nothing is printed in the shell during the guy session, should i set some env var to have more verbose - nviz doesn't render the 3d canvas, but there is no crash :) , the rendering-progress-bar load , this the log in the wx console Traceback (most recent call last): File /usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi ndow.py, line 366, in OnPaint self.DoPaint() File /usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi ndow.py, line 406, in DoPaint self.UpdateMap() File /usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi ndow.py, line 1166, in UpdateMap self.SwapBuffers() File /usr/local/lib/wxPython-2.9.4.0/lib/python2.7/site- packages/wx-2.9.4-osx_cocoa/wx/glcanvas.py, line 124, in SwapBuffers return _glcanvas.GLCanvas_SwapBuffers(*args, **kwargs) wx._core . PyAssertionError : C++ assertion context failed at /BUILD/wxPython- src-2.9.4.0/src/osx/cocoa/glcanvas.mm(289) in SwapBuffers(): should have current context if there is something i can do to do more testing i will be happy to work on it. p.s. with wx 2.9 we have great webkit support @Anna have already tried to work on webkit in wx ? i will start to investigate this to see how to add a new tab to include the Ipython notebook if of interest, at this link there is a simple pyqt app that does something similar : https://github.com/damianavila/vIPer/blob/master/viper.py Massimo. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass7 - mac osx- 64bit python
thanks Anna! that's my bathymetry http://geofemengineering.it//data/nviz_mac_wx-29_cocoa.png I tried to changing resolution, use the slope map as color, light settings and other tools , everything was working properly :) few question : is it possible to unlock the layer manager and the map display so that when i move the layer manager the map window doesn't move with it ? an important bug: i was looking for possible options in the preference settings to unlock the movement of mapdispaly when the layer manager is mived, but i had to force quit the gui every time i tried to do something in that panel when i click on apply in the console i have : Settings applied to current session but not saved then the gui is no more responsive and i forced it to quit .. will be nice to be able to set the transparence for the fringe panels :) i'll try to export the verbose debug ant test again all the other widgets. and generate more useful logs, thanks Massimo. Il giorno 20/mag/2013, alle ore 13:20, Anna Petrášová kratocha...@gmail.com ha scritto: Hi, On Mon, May 20, 2013 at 3:37 PM, epi massimodisa...@gmail.com wrote: Hi, is one week now that i'm testing a grass7 build, using wx cocoa (svn version built from source) i'm really happy to say that almost everything is working fine! glad to hear that, I quickly tested wxGUI some time ago on wxPython 2.9 on linux so the most apparent bugs should be fixed. Unfortunately most bugs you listed here are not reproducible on my ubuntu with 2.9 classic wxPython. .. few debug reported here : - profile tool : -- the pen widget doesn't draw a line and no profile is plotted but ... if i select the measure tool make a measurement and then without quitting the measurement tool (boucle click on the canvas) i open the profile tool .. then the profile is plotted correctly hm, I don't have this behavior, it's working properly. The only problem is that the dashed line does not disappear after rerendering. - add text layer : -- doesn't change the font size - map composer run but doesn't have a toolbar again, both work for me nothing is printed in the shell during the guy session, should i set some env var to have more verbose this is normal, everything goes to gui command console, only when you switch to debug mode it goes to terminal - nviz doesn't render the 3d canvas, but there is no crash :) , the rendering-progress-bar load , this the log in the wx console please try again, I just updated the code for 2.9 Traceback (most recent call last): File /usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi ndow.py, line 366, in OnPaint self.DoPaint() File /usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi ndow.py, line 406, in DoPaint self.UpdateMap() File /usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi ndow.py, line 1166, in UpdateMap self.SwapBuffers() File /usr/local/lib/wxPython-2.9.4.0/lib/python2.7/site- packages/wx-2.9.4-osx_cocoa/wx/glcanvas.py, line 124, in SwapBuffers return _glcanvas.GLCanvas_SwapBuffers(*args, **kwargs) wx._core . PyAssertionError : C++ assertion context failed at /BUILD/wxPython- src-2.9.4.0/src/osx/cocoa/glcanvas.mm(289) in SwapBuffers(): should have current context if there is something i can do to do more testing i will be happy to work on it. I cannot do much about the bugs which I can't reproduce, especially when there is no error... p.s. with wx 2.9 we have great webkit support @Anna have already tried to work on webkit in wx ? not yet, I probably missed something when I compiled wx 2.9, it was not working and then I didn't try again. Thanks and keep testing:) Anna i will start to investigate this to see how to add a new tab to include the Ipython notebook if of interest, at this link there is a simple pyqt app that does something similar : https://github.com/damianavila/vIPer/blob/master/viper.py Massimo. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.fillnulls failure (grass7 )
thanks this fixed my problem! :) Il giorno 07/apr/2013, alle ore 17:20, Markus Neteler nete...@osgeo.org ha scritto: On Sun, Apr 7, 2013 at 11:00 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: ... Try to remove zcol = 'value' from the call to v.surf.rst in the r.fillnulls script. The vector created by r.fillnulls with r.to.vect is 3D, so no z column is needed (or present). Tested, this solves the problem. I guess it is an artifact of the -z usage in the GRASS 6 version or the r.to.vect usage. markusN ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.fillnulls failure (grass7 )
epy@epinux:~/dev/grass_trunk$ svn up Updating '.': At revision 55645. GRASS 7.0.svn (utm19N_wgs84):~ g.region rast=dtm1 -ap projection: 1 (UTM) zone: 19 datum: wgs84 ellipsoid: wgs84 north: 4720170 south: 4715050 west: 391340 east: 398580 nsres: 10 ewres: 10 rows: 512 cols: 724 cells: 370688 GRASS 7.0.svn (utm19N_wgs84):~ r.fillnulls input=dtm1 output=dtm1 --overwrite Using RST interpolation... Locating and isolating NULL areas... 100% Growing NULL areas Assigning IDs to NULL areas 100% Processing 1 map holes Filling hole 2 of 1 100% 100% 100% Note: The following warnings about number of points for interpolation may be ignored. ERROR: Database connection not defined for layer 1 ERROR: Failed to fill hole 2 WARNING: Raster map r_fillnulls_5883_hole_2_dem not found WARNING: r_fillnulls_5883_hole_2_dem nothing removed GRASS 7.0.svn (utm19N_wgs84):~ ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.fillnulls failure (grass7 )
I used the --overwrite option i had problems with r.fillnulls recently see : http://osgeo-org.1560.n6.nabble.com/r-fillnulls-error-lt-z-gt-is-not-a-valid-flag-grass7-td5034768.html after that fix the same syntax was working changing the output to a new name i got the same error GRASS 7.0.svn (utm19N_wgs84):/home/epy r.fillnulls input=dtm1 output=dtm1fill --overwrite Using RST interpolation... Locating and isolating NULL areas... 100% Growing NULL areas Assigning IDs to NULL areas 100% Processing 1 map holes Filling hole 2 of 1 100% 100% 100% Note: The following warnings about number of points for interpolation may be ignored. ERROR: Database connection not defined for layer 1 ERROR: Failed to fill hole 2 WARNING: Raster map r_fillnulls_4517_hole_2_dem not found WARNING: r_fillnulls_4517_hole_2_dem nothing removed GRASS 7.0.svn (utm19N_wgs84):/home/epy Il giorno 06/apr/2013, alle ore 11:08, Markus Neteler nete...@osgeo.org ha scritto: On Sat, Apr 6, 2013 at 4:25 PM, epi massimodisa...@gmail.com wrote: ... GRASS 7.0.svn (utm19N_wgs84):~ r.fillnulls input=dtm1 output=dtm1 --overwrite You try to overwrite the source with the target, to my knowledge invalid (sure, the module should say so). Try r.fillnulls input=dtm1 output=dtm1_filled Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.fillnulls error z is not a valid flag (grass7)
Hi , i was trying to fill some null values on a DTM but i got this error : GRASS 7.0.svn (utm19N_wgs84):~ r.fillnulls input=stell_na10m output=stell10m --overwrite Using RST interpolation... Locating and isolating NULL areas... 100% Growing NULL areas Assigning IDs to NULL areas 100% Processing 171 map holes Filling hole 1 of 171 100% 100% 100% Note: The following warnings about number of points for interpolation may be ignored. ERROR: Sorry, z is not a valid flag ERROR: Failed to fill hole 1 WARNING: Raster map r_fillnulls_82080_hole_1_dem not found WARNING: r_fillnulls_82080_hole_1_dem nothing removed GRASS 7.0.svn (utm19N_wgs84):~ the raster is : GRASS 7.0.svn (utm19N_wgs84):~ g.region rast=stell_na10m -ap projection: 1 (UTM) zone: 19 datum: wgs84 ellipsoid: wgs84 north: 4740344.78303 south: 4659553.9 west: 342858.421078 east: 415502.090519 nsres: 10.00011067 ewres: 10.00050515 rows: 8079 cols: 7264 cells: 58685856 GRASS 7.0.svn (utm19N_wgs84):~ epi:~ epi$ cd /usr/local/src/grass_trunk/ epi:grass_trunk epi$ svn info Path: . URL: https://svn.osgeo.org/grass/grass/trunk Repository Root: https://svn.osgeo.org/grass Repository UUID: 15284696-431f-4ddb-bdfa-cd5b030d7da7 Revision: 55083 Node Kind: directory Schedule: normal Last Changed Author: martinl Last Changed Rev: 55083 Last Changed Date: 2013-02-17 08:03:46 -0500 (Sun, 17 Feb 2013) Have you any clue on what's going wrong ? i'll try with grass6 to see if it is a problem with trunk. Thanks, Massimo. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] does GRASS 7 for Mac compile yet?
' object has no attribute 'GetId' - Save display to graphic file [works] - Print [works] - switch to 3D (wxNviz) [doesn't work]: i got this log in the console : Starting 3D view mode... Traceback (most recent call last): File /usr/local/grass-7.0.svn/etc/gui/wxpython/mapdisp/to olbars.py, line 229, in OnSelectTool self.parent.AddNviz() File /usr/local/grass-7.0.svn/etc/gui/wxpython/mapdisp/fr ame.py, line 328, in AddNviz self._layerManager.AddNvizTools() File /usr/local/grass-7.0.svn/etc/gui/wxpython/lmgr/frame.py, line 341, in AddNvizTools display = self.GetMapDisplay()) File /usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/tools.py, line 102, in __init__ self.AddPage(page = self._createAnimationPage(), File /usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/tools.py, line 401, in _createAnimationPage usage = record, label = _(Record)) File /usr/local/grass-7.0.svn/etc/gui/wxpython/gui_core/w idgets.py, line 405, in __init__ maskColor = wx.Color(255, 255, 255) AttributeError : 'module' object has no attribute 'Color' Traceback (most recent call last): File /usr/local/grass-7.0.svn/etc/gui/wxpython/mapdisp/ma pwindow.py, line 463, in OnIdle self.UpdateMap() File /usr/local/grass-7.0.svn/etc/gui/wxpython/mapdisp/ma pwindow.py, line 687, in UpdateMap pdctype = self.overlays[id].pdcType, coords = self.overlays[id].coords) KeyError : 0 # afeter that i was not able to have the 2D map back working, opening a new display fixed it. - vector tools [doesn't work] : i guess the main problem is the cairo driver .. in any case this is part of the log i got : Traceback (most recent call last): File /usr/local/grass-7.0.svn/etc/gui/wxpython/mapdisp/ma pwindow.py, line 1000, in MouseActions self.OnLeftUp(event) File /usr/local/grass-7.0.svn/etc/gui/wxpython/mapdisp/ma pwindow.py, line 1214, in OnLeftUp self._onLeftUp(event) File /usr/local/grass-7.0.svn/etc/gui/wxpython/vdigit/map window.py, line 834, in _onLeftUp if len(self.digit.GetDisplay().GetSelected()) 0: AttributeError : 'NoneType' object has no attribute 'GetDisplay' (and a pop up no vector map selected for editing) i had to build without cairo support .. because of the error i posted before. thanks to William that point out it can be a configuration problem GRASS Configure is not storing the fontconfig linking in platform.make so it doesn't get into the cairo driver compilation. also building without-cairo when try to display vector data the gui complain about missed cairo. i tried to change the driver in the gui preference from cairo to png but then the gui freeze and i have to force-quit it. i'll be happy to continue testing if can be of any help, thanks for the hard work! Massimo 2013/2/5 Anna Kratochvílová kratocha...@gmail.com Hi, On Mon, Feb 4, 2013 at 11:57 PM, epi massimodisa...@gmail.com wrote: i'm trying to debug the build of GRASS 7 on mac OSX 10.8.x in 64 bit with WX 2.9.x After commenting the check for wx version i got the GUI start, some worning what exactly is the problem with the 'check for wx version'? The warning (wx.InitAllImageHandlers) and the PrepareDC error should be fixed now. Anna : ### GRASS 7.0.svn (spearfish60):~ /usr/local/grass-7.0.svn/etc/gui/wxpython/wxgui.py:54: wxPyDeprecationWarning: Call to deprecated item 'InitAllImageHandlers'. wx.InitAllImageHandlers() /usr/local/grass-7.0.svn/etc/gui/wxpython/gui_core/goutput.py:230: wxPyDeprecationWarning: Call to deprecated item 'SetVirtualSizeHints'. outputSizer.SetVirtualSizeHints(self.panelOutput) ### the Window Manager seems to work properly (i cal load a layer Rast/Vect in the lkayer tree, the shell also pront out the log of commands nicely) but i can't display layers (both Vector and Raster are not displayed). Commenting this 2 line in madisp.py : 359 #self.PrepareDC(dc) 519#self.PrepareDC(dc) i got the Raster map displaying properly but no vector, the error is in a missed Cairo Driver : /usr/local/grass-7.0.svn/etc/gui/wxpython/gui_core/ghelp.py: 608: wxPyDeprecationWarning: Call to deprecated item 'InitAllImageHandlers'. wx.InitAllImageHandlers() Command 'd.vect map=archsites@PERMANENT type=point,line,area,face' failed Details: Unknown display driver cairo Command 'd.vect map=archsites@PERMANENT type=point,line,area,face' failed Details: Unknown display driver cairo I wasn't able to get the cairo driver working during the Make step, it shows the error at the end of the log [1] about a missed arch ... but i guess ... I have everything built as --universal In doubt I rebuilt fontconfig and cairo and checked the relative architecture : lipo -info /usr/local/Cellar/cairo/1.12.12/lib/cairo/libcairo-trace.0.dylib /usr/local/Cellar/cairo/1.12.12/lib/libcairo-gobject.2.dylib /usr/local/Cellar/cairo/1.12.12/lib/libcairo-script-interpreter.2
Re: [GRASS-dev] does GRASS 7 for Mac compile yet?
i'm trying to debug the build of GRASS 7 on mac OSX 10.8.x in 64 bit with WX 2.9.x After commenting the check for wx version i got the GUI start, some worning : ### GRASS 7.0.svn (spearfish60):~ /usr/local/grass-7.0.svn/etc/gui/wxpython/wxgui.py:54: wxPyDeprecationWarning: Call to deprecated item 'InitAllImageHandlers'. wx.InitAllImageHandlers() /usr/local/grass-7.0.svn/etc/gui/wxpython/gui_core/goutput.py:230: wxPyDeprecationWarning: Call to deprecated item 'SetVirtualSizeHints'. outputSizer.SetVirtualSizeHints(self.panelOutput) ### the Window Manager seems to work properly (i cal load a layer Rast/Vect in the lkayer tree, the shell also pront out the log of commands nicely) but i can't display layers (both Vector and Raster are not displayed). Commenting this 2 line in madisp.py : 359 #self.PrepareDC(dc) 519 #self.PrepareDC(dc) i got the Raster map displaying properly but no vector, the error is in a missed Cairo Driver : /usr/local/grass-7.0.svn/etc/gui/wxpython/gui_core/ghelp.py: 608: wxPyDeprecationWarning: Call to deprecated item 'InitAllImageHandlers'. wx.InitAllImageHandlers() Command 'd.vect map=archsites@PERMANENT type=point,line,area,face' failed Details: Unknown display driver cairo Command 'd.vect map=archsites@PERMANENT type=point,line,area,face' failed Details: Unknown display driver cairo I wasn't able to get the cairo driver working during the Make step, it shows the error at the end of the log [1] about a missed arch ... but i guess ... I have everything built as --universal In doubt I rebuilt fontconfig and cairo and checked the relative architecture : lipo -info /usr/local/Cellar/cairo/1.12.12/lib/cairo/libcairo-trace.0.dylib /usr/local/Cellar/cairo/1.12.12/lib/libcairo-gobject.2.dylib /usr/local/Cellar/cairo/1.12.12/lib/libcairo-script-interpreter.2.dylib /usr/local/Cellar/cairo/1.12.12/lib/libcairo.2.dylib Architectures in the fat file: /usr/local/Cellar/cairo/1.12.12/lib/cairo/libcairo-trace.0.dylib are: i386 x86_64 Architectures in the fat file: /usr/local/Cellar/cairo/1.12.12/lib/libcairo-gobject.2.dylib are: i386 x86_64 Architectures in the fat file: /usr/local/Cellar/cairo/1.12.12/lib/libcairo-script-interpreter.2.dylib are: i386 x86_64 Architectures in the fat file: /usr/local/Cellar/cairo/1.12.12/lib/libcairo.2.dylib are: i386 x86_64 epi:~ epi$ /usr/local/Cellar/fontconfig/2.10.91/bin/fc-cache:Mach-O universal binary with 2 architectures /usr/local/Cellar/fontconfig/2.10.91/bin/fc-cache (for architecture i386): Mach-O executable i386 /usr/local/Cellar/fontconfig/2.10.91/bin/fc-cache (for architecture x86_64): Mach-O 64-bit executable x86_64 /usr/local/Cellar/fontconfig/2.10.91/bin/fc-cat: Mach-O universal binary with 2 architectures /usr/local/Cellar/fontconfig/2.10.91/bin/fc-cat (for architecture i386): Mach-O executable i386 /usr/local/Cellar/fontconfig/2.10.91/bin/fc-cat (for architecture x86_64): Mach-O 64-bit executable x86_64 /usr/local/Cellar/fontconfig/2.10.91/bin/fc-list: Mach-O universal binary with 2 architectures /usr/local/Cellar/fontconfig/2.10.91/bin/fc-list (for architecture i386): Mach-O executable i386 /usr/local/Cellar/fontconfig/2.10.91/bin/fc-list (for architecture x86_64): Mach-O 64-bit executable x86_64 /usr/local/Cellar/fontconfig/2.10.91/bin/fc-match:Mach-O universal binary with 2 architectures /usr/local/Cellar/fontconfig/2.10.91/bin/fc-match (for architecture i386): Mach-O executable i386 /usr/local/Cellar/fontconfig/2.10.91/bin/fc-match (for architecture x86_64): Mach-O 64-bit executable x86_64 /usr/local/Cellar/fontconfig/2.10.91/bin/fc-pattern: Mach-O universal binary with 2 architectures /usr/local/Cellar/fontconfig/2.10.91/bin/fc-pattern (for architecture i386): Mach-O executable i386 /usr/local/Cellar/fontconfig/2.10.91/bin/fc-pattern (for architecture x86_64): Mach-O 64-bit executable x86_64 /usr/local/Cellar/fontconfig/2.10.91/bin/fc-query:Mach-O universal binary with 2 architectures /usr/local/Cellar/fontconfig/2.10.91/bin/fc-query (for architecture i386): Mach-O executable i386 /usr/local/Cellar/fontconfig/2.10.91/bin/fc-query (for architecture x86_64): Mach-O 64-bit executable x86_64 /usr/local/Cellar/fontconfig/2.10.91/bin/fc-scan: Mach-O universal binary with 2 architectures /usr/local/Cellar/fontconfig/2.10.91/bin/fc-scan (for architecture i386): Mach-O executable i386 /usr/local/Cellar/fontconfig/2.10.91/bin/fc-scan (for architecture x86_64): Mach-O 64-bit executable x86_64 /usr/local/Cellar/fontconfig/2.10.91/bin/fc-validate: Mach-O universal binary with 2 architectures /usr/local/Cellar/fontconfig/2.10.91/bin/fc-validate (for architecture i386): Mach-O executable i386 /usr/local/Cellar/fontconfig/2.10.91/bin/fc-validate (for architecture x86_64):Mach-O 64-bit executable x86_64 They are multi-arch, but unlucky i still have the same error
[GRASS-dev] GRASS Community Sprint Genova 2013
Hi All, this week we'll have a GRASS GIS Community Sprint http://grasswiki.osgeo.org/wiki/GRASS_Community_Sprint_Genova_2013 if you're willing to join us for a google hangout / irc meeting please feel free to add yourself and set the preference about timing on the doodle pool : http://grasswiki.osgeo.org/wiki/GRASS_Community_Sprint_Genova_2013#Via_IRC_chat_or_hangout Thanks! --Massimo ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] does GRASS 7 for Mac compile yet?
I'm a mac user as well and i will be happy to help, … i built grass weekly (if not daily) in the past, but unfortunately now i'm on mac 10.8.x using 64bit python, all my python packages numpy scipy etc etc etc .. are 64 bit and ... WX gui start-joke great choice /end-joke unfortunately doesn't works on mac in 64 bit mode … i'm waiting the 2.9.x to be stable that is 2 years now ... This IMO can be one of the major reason of lack of mac-man-dev-power i can provide log on the build of grass7 (without gui modules) … but this doesn't help i don't know if grass-gui-dev want try to test grass with wx-2.9 .. it is unstable but works, if yes .. i'll be happy to be a guinea pig --Massimo Il giorno 31/gen/2013, alle ore 05:32, Thomas Adams - NOAA Federal thomas.ad...@noaa.gov ha scritto: All, I'm a Mac user in addition to Linux. I'm going to have more free time starting in a few weeks. I'd be happy to step-up my use of GRASS 7 for testing. Just let me know what I can do. I'm moving from the U.S. to Melbourne, Australia in a couple of weeks! Cheers, Tom On Thu, Jan 31, 2013 at 5:27 AM, Luca Delucchi lucadel...@gmail.com wrote: 2013/1/31 Margherita Di Leo dileomargher...@gmail.com: I think we should consider to promote a fund rising for buying a (used, discounted, whatever) mac computer for the use of developers who are developing or are willing to test on it. What do you think? I don't like this idea. I think should be really better to have some more Mac power user instead, and use the money for community sprint my 2 c madi -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Thomas E Adams Development Operations Hydrologist National Weather Service Ohio River Forecast Center 1901 South State Route 134 Wilmington, OH 45177 http://www.erh.noaa.gov/er/ohrfc/ EMAIL:thomas.ad...@noaa.gov VOICE:937-383-0528 FAX: 937-383-0033 ___ 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
