[GRASS-dev] installing v.mapcalc fails
installing v.mapcalc fails, with the following: g.extension extension=v.mapcalc svnurl= http://svn.osgeo.org/grass/grass-addons/grass7 Fetching v.mapcalc from GRASS-Addons SVN repository (be patient)... Compiling... yylex.c: In function ‘yylex’: yylex.c:32:7: warning: ignoring return value of ‘scanf’, declared with attribute warn_unused_result [-Wunused-result] scanf(%lf, yylval.dbl); ^ make: *** [v.mapcalc.tmp.html] Error 1 ERROR: Compilation failed, sorry. Please check above error messages. Any ideas? ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Add support for Python3
+1 On Fri, Jul 24, 2015 at 4:12 PM Pietro peter.z...@gmail.com wrote: Dear devs, Next week I would like to start the merge between my local changes and trunk to support Python3. As reported in the ticket: https://trac.osgeo.org/grass/ticket/2708 I've tested the changes with python2.6, python2.7 and python3.4. So far I've not found regressions in python2.X. The status quo for python3 is: - the binding of the C GRASS functions is not working; - several python modules (~90) are not readable/usable, I've already started to port them (~20) My idea for the porting is to gradually introduce changes per steps: - Monday 27, change only the grass-init and the gunittest; - If not new problems connected to previous changes raise, Wendesday 29 I commit the grass/script stuff - If not new problems connected to previous changes raise, I will start updating the GRASS modules. In the meanwhile I try to get the ctypes working on PY3. Are you ok with this schedule? Other better options? Let me know Pietro ___ 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] Add support for Python3
Dear devs, Next week I would like to start the merge between my local changes and trunk to support Python3. As reported in the ticket: https://trac.osgeo.org/grass/ticket/2708 I've tested the changes with python2.6, python2.7 and python3.4. So far I've not found regressions in python2.X. The status quo for python3 is: - the binding of the C GRASS functions is not working; - several python modules (~90) are not readable/usable, I've already started to port them (~20) My idea for the porting is to gradually introduce changes per steps: - Monday 27, change only the grass-init and the gunittest; - If not new problems connected to previous changes raise, Wendesday 29 I commit the grass/script stuff - If not new problems connected to previous changes raise, I will start updating the GRASS modules. In the meanwhile I try to get the ctypes working on PY3. Are you ok with this schedule? Other better options? Let me know Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] OpenMP 4.0 / gcc5.0
Last time I tried compiling with OpenMP, It made the process slower. Not sure why. Doug On Sun, Jul 19, 2015 at 10:07 PM, Yann Chemin yche...@gmail.com wrote: Hi, Ubuntu Wily is going towards gcc5.0 as we speak. anybody following the OpenMP 4.0 integration into gcc 5.0? it seems there is embedding of heterogeneous computing in it (i.e. ala OpenCL). is GRASS code using OpenMP forward compatible with this, or will it need modification? y ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compiling on OSX 10.11 (El Capitan Beta)
Well, if the errors are only about documentation, I can live with them. So I went on to create the installation package. I had to manually download PackageMaker from Apple (Late 2012 version). After creating and installing the package, when I run it, I get the startup dialog (choose location etc), but wxgui fails: Launching wxpython GUI in the background, please wait... GRASS 7.0.1RC2 (araca_utm):~/Documents/installs/release_20150720_grass_7_0_1RC2 Unable to import pyGRASS: grass_gis.7.0.1RC2 not found. Some functionality will be not accessible Traceback (most recent call last): File /Applications/GRASS-7.0.app/Contents/MacOS/gui/wxpython/wxgui.py, line 37, in module from lmgr.frame import GMFrame File /Applications/GRASS-7.0.app/Contents/MacOS/gui/wxpython/lmgr/frame.py, line 50, in module from lmgr.layertreeimport LayerTree, LMIcons File /Applications/GRASS-7.0.app/Contents/MacOS/gui/wxpython/lmgr/layertree.py, line 37, in module from mapdisp.frameimport MapFrame File /Applications/GRASS-7.0.app/Contents/MacOS/gui/wxpython/mapdisp/frame.py, line 34, in module from vdigit.toolbarsimport VDigitToolbar File /Applications/GRASS-7.0.app/Contents/MacOS/gui/wxpython/vdigit/toolbars.py, line 30, in module from iclass.digit import IClassVDigit File /Applications/GRASS-7.0.app/Contents/MacOS/gui/wxpython/iclass/digit.py, line 23, in module from vdigit.wxdisplay import DisplayDriver, TYPE_AREA ImportError: cannot import name TYPE_AREA Carlos On Thu, Jul 23, 2015 at 10:35 PM, William Kyngesburye wokl...@kyngchaos.com wrote: I believe what happens is it compiles with links to where it will be installed, but during documentation creation it uses DYLD_LIBRARY_PATH to make it look in the build dir. This is what is not working. On Jul 23, 2015, at 7:40 PM, Carlos Grohmann carlos.grohm...@gmail.com wrote: On thing that I found weird id this: dyld: Library not loaded: /Applications/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1RC2.dylib Referenced from: /Users/guano/Documents/installs/release_20150720_grass_7_0_1RC2/dist.x86_64-apple-darwin15.0.0/bin/g.parser Reason: image not found Why load the library from /Applications/GRASS-7.0.app/ at compiling time? The package hasn't even been created yet... Shouldn't this be loaded from the source dir? Carlos On Thu, Jul 23, 2015 at 12:09 AM, William Kyngesburye wokl...@kyngchaos.com wrote: I don't see any GDAL problem there. It looks like DYLD_LIBRARY_PATH is not working when running the modules to create documentation. I don't know where to go from there. On Jul 22, 2015, at 8:18 PM, Carlos Grohmann carlos.grohm...@gmail.com wrote: Thanks, William. That worked, at least for the configure part. Now the problem is at compiling. At the end of make, I get a ton of errors in modules: the first script, d.correlate, gives me this eror: cd scripts/d.correlate/ GuanoAFBIOTA:d.correlate guano$ make if [ /Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/scripts/d.correlate != ] ; then GISRC=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/demolocation/.grassrc70 GISBASE=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0 PATH=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/bin:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/bin:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/scripts:$PATH PYTHONPATH=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/etc/python:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/gui/wxpython:$PYTHONPATH DYLD_LIBRARY_PATH=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/bin:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/scripts:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/lib:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/lib: LC_ALL=C /Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/scripts/d.correlate --html-description /dev/null | grep -v '/body\|/html' d.correlate.tmp.html ; fi dyld: Library not loaded: /Applications/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1svn.dylib Referenced from: /Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/bin/g.parser Reason: image not found make: *** [d.correlate.tmp.html] Error 1 rm d.correlate.tmp.html - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty. Don't you even hate 'em? What good
Re: [GRASS-dev] [GRASS GIS] #2708: Run GRASS with Python3
#2708: Run GRASS with Python3
--+-
Reporter: zarch| Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.1
Component: Default |Version: unspecified
Resolution: | Keywords:
CPU: Unspecified | Platform: Unspecified
--+-
Comment (by glynn):
Replying to [comment:6 zarch]:
Testing with the python debugger:
{{{
ipdb (1024 / (8 * sizeof(c_ulong)))
16.0
ipdb c_ulong * (1024 / (8 * sizeof(c_ulong)))
*** TypeError: can't multiply sequence by non-int of type 'float'
}}}
Do you have an idea on how we can fix this?
One option is to make ctypesgen use truncating division:
lib/python/ctypes/ctypesgencore/parser/cgrammar.py:282
{{{
-'/': (division, (lambda x,y: x/y), (%s / %s)),
+'/': (division, (lambda x,y: x/y), (%s // %s)),
}}}
However, this would break macros which perform floating-point division.
Another option would be to explicitly convert array sizes to integers, but
that still doesn't handle the situation where a macro is expecting / to
match C's division semantics (truncating division for integers, non-
truncating division for floating-point values).
Ultimately, ctypesgen just translates macros directly to Python, so
whichever division operator is used would be wrong for one case or the
other. We could change it to use e.g. c_division(a,b) and define that
function in ctypes_preamble.py. But that seems like overkill given that
(on Linux) there are two occurrences of the division operator in the
generated files.
One of them is for the definition of sigset_t, which is required for
jmp_buf which in turn is required for G_fatal_longjmp(), and I'm not sure
it's even possible to make use of that from Python. The other is for a
macro named FUDGE() in ogsf.h, which I suspect is probably not
particularly useful (and that one happens to be a floating-point
division).
An alternative option is to just guard the setjmp.h include and the
G_fatal_longjmp() declaration in defs/gis.h with `#ifndef CTYPESGEN`, and
do likewise for the FUDGE() macro in ogsf.h.
However, that ignores the possibility that other platforms may have macros
involving division in their system headers, or that future changes to
GRASS may pull in additional headers with such macros.
Yet another option is a combination of the other two: prevent ctypesgen
from ever seeing a macro involving division, and just remove the division
case from mult_ops_dict so that if it does encounter one it raises an
exception. That may require ongoing maintenance but avoids the situation
where we end up silently generating broken conversions of macros.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2708#comment:7
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compiling on OSX 10.11 (El Capitan Beta)
Just to update my last message, although wxgui won't start, GRASS will start in text mode. In python I tried the import statment: from grass.pygrass import messages Traceback (most recent call last): File stdin, line 1, in module File /Applications/GRASS-7.0.app/Contents/MacOS/etc/python/grass/pygrass/messages/__init__.py, line 19, in module import grass.lib.gis as libgis File /Applications/GRASS-7.0.app/Contents/MacOS/etc/python/grass/lib/gis.py, line 23, in module _libs[grass_gis.7.0.1RC2] = load_library(grass_gis.7.0.1RC2) File /Applications/GRASS-7.0.app/Contents/MacOS/etc/python/grass/lib/ctypes_loader.py, line 57, in load_library raise ImportError,%s not found. % libname ImportError: grass_gis.7.0.1RC2 not found. I can't find any file with that name in the package Carlos On Fri, Jul 24, 2015 at 10:52 AM, Carlos Grohmann carlos.grohm...@gmail.com wrote: Well, if the errors are only about documentation, I can live with them. So I went on to create the installation package. I had to manually download PackageMaker from Apple (Late 2012 version). After creating and installing the package, when I run it, I get the startup dialog (choose location etc), but wxgui fails: Launching wxpython GUI in the background, please wait... GRASS 7.0.1RC2 (araca_utm):~/Documents/installs/release_20150720_grass_7_0_1RC2 Unable to import pyGRASS: grass_gis.7.0.1RC2 not found. Some functionality will be not accessible Traceback (most recent call last): File /Applications/GRASS-7.0.app/Contents/MacOS/gui/wxpython/wxgui.py, line 37, in module from lmgr.frame import GMFrame File /Applications/GRASS-7.0.app/Contents/MacOS/gui/wxpython/lmgr/frame.py, line 50, in module from lmgr.layertreeimport LayerTree, LMIcons File /Applications/GRASS-7.0.app/Contents/MacOS/gui/wxpython/lmgr/layertree.py, line 37, in module from mapdisp.frameimport MapFrame File /Applications/GRASS-7.0.app/Contents/MacOS/gui/wxpython/mapdisp/frame.py, line 34, in module from vdigit.toolbarsimport VDigitToolbar File /Applications/GRASS-7.0.app/Contents/MacOS/gui/wxpython/vdigit/toolbars.py, line 30, in module from iclass.digit import IClassVDigit File /Applications/GRASS-7.0.app/Contents/MacOS/gui/wxpython/iclass/digit.py, line 23, in module from vdigit.wxdisplay import DisplayDriver, TYPE_AREA ImportError: cannot import name TYPE_AREA Carlos On Thu, Jul 23, 2015 at 10:35 PM, William Kyngesburye wokl...@kyngchaos.com wrote: I believe what happens is it compiles with links to where it will be installed, but during documentation creation it uses DYLD_LIBRARY_PATH to make it look in the build dir. This is what is not working. On Jul 23, 2015, at 7:40 PM, Carlos Grohmann carlos.grohm...@gmail.com wrote: On thing that I found weird id this: dyld: Library not loaded: /Applications/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1RC2.dylib Referenced from: /Users/guano/Documents/installs/release_20150720_grass_7_0_1RC2/dist.x86_64-apple-darwin15.0.0/bin/g.parser Reason: image not found Why load the library from /Applications/GRASS-7.0.app/ at compiling time? The package hasn't even been created yet... Shouldn't this be loaded from the source dir? Carlos On Thu, Jul 23, 2015 at 12:09 AM, William Kyngesburye wokl...@kyngchaos.com wrote: I don't see any GDAL problem there. It looks like DYLD_LIBRARY_PATH is not working when running the modules to create documentation. I don't know where to go from there. On Jul 22, 2015, at 8:18 PM, Carlos Grohmann carlos.grohm...@gmail.com wrote: Thanks, William. That worked, at least for the configure part. Now the problem is at compiling. At the end of make, I get a ton of errors in modules: the first script, d.correlate, gives me this eror: cd scripts/d.correlate/ GuanoAFBIOTA:d.correlate guano$ make if [ /Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/scripts/d.correlate != ] ; then GISRC=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/demolocation/.grassrc70 GISBASE=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0 PATH=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/bin:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/bin:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/scripts:$PATH PYTHONPATH=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/etc/python:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/gui/wxpython:$PYTHONPATH
