#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