Hi, is this the right ticket to look into the porting of grass to work with python3 ? what’s the state of port, is there any temporary fork of the project or should I apply the several patches on this ticket ?
At the moment my build fails on most of core modules my default python is V3. Is there a way to specify in the configure which python has to be used for to build grass ? Thanks! Massimo. > On Jul 24, 2015, at 9:57 AM, GRASS GIS <t...@osgeo.org> wrote: > > #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 _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev