- edited description
Dolfin fails to import with python 2.7.10
When building dolfin in an environment with python 2.7.10, the resulting python fails to import with the following backtrace:
skramer@gyre:~/tmp/dolfin$ python -c "import dolfin"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/skramer/.hashdist/bld/profile/ar54j3cbpg5r/lib/python2.7/site-packages/dolfin/__init__.py", line 16, in <module>
from . import cpp
File "/home/skramer/.hashdist/bld/profile/ar54j3cbpg5r/lib/python2.7/site-packages/dolfin/cpp/__init__.py", line 42, in <module>
exec("from . import %s" % module_name)
File "<string>", line 1, in <module>
File "/home/skramer/.hashdist/bld/profile/ar54j3cbpg5r/lib/python2.7/site-packages/dolfin/cpp/common.py", line 132, in <module>
__pythonversion__ = "%d.%d.%d"%(tuple(map(int, [tmp[2], tmp[4], tmp[6]])))
ValueError: invalid literal for int() with base 10: 'a'
I believe this is due to the way it is trying to convert the python version hex string PY_VERSION_HEX (see line 29 of dolfin/swig/version.i) into seperate major, minor and micro version numbers. This conversion only works for single digit (in decimal) version numbers. For instance the PY_VERSION_HEX I get with my python 2.7.10 (this is python from Debian unstable) is 0x2070ac1
Comments (8)
-
reporter -
Can you check if this patch fixes the problem?
diff --git a/dolfin/swig/version.i b/dolfin/swig/version.i index 8dace25..1af3497 100644 --- a/dolfin/swig/version.i +++ b/dolfin/swig/version.i @@ -33,6 +33,6 @@ unsigned int dolfin_pythonversion() { return PY_VERSION_HEX; } tmp = hex(dolfin_swigversion()) __swigversion__ = "%d.%d.%d"%(tuple(map(int, [tmp[-5], tmp[-3], tmp[-2:]]))) tmp = hex(dolfin_pythonversion()) -__pythonversion__ = "%d.%d.%d"%(tuple(map(int, [tmp[2], tmp[4], tmp[6]]))) + __pythonversion__ = "%d.%d.%d"%(tuple(map(lambda x: int(x, 16), [tmp[2], tmp[4], tmp[6]]))) del tmp, dolfin_pythonversion, dolfin_swigversion %}
-
reporter Great, thanks! Works as it should (minus the spurious two spaces at the beginning of the pythonversion definition). My only concern would be that this will break again with python 2.7.16 - assuming they'll keep on bringing out regular bug fix releases for 2.7.
-
Good point! The white space just lurked in there. I think this patch should fix all our trouble to python 2.255.255
diff --git a/dolfin/swig/version.i b/dolfin/swig/version.i index 8dace25..6d65aac 100644 --- a/dolfin/swig/version.i +++ b/dolfin/swig/version.i @@ -33,6 +33,6 @@ unsigned int dolfin_pythonversion() { return PY_VERSION_HEX; } tmp = hex(dolfin_swigversion()) __swigversion__ = "%d.%d.%d"%(tuple(map(int, [tmp[-5], tmp[-3], tmp[-2:]]))) tmp = hex(dolfin_pythonversion()) -__pythonversion__ = "%d.%d.%d"%(tuple(map(int, [tmp[2], tmp[4], tmp[6]]))) +__pythonversion__ = "%d.%d.%d"%(tuple(map(lambda x: int(x,16), [tmp[2], tmp[3:5], tmp[5:7]]))) del tmp, dolfin_pythonversion, dolfin_swigversion %} #!diff
-
- changed status to resolved
Fix issue 525 where the micro and minor part of the python version could not be larger than 9.
→ <<cset 747e8acefb0f>>
-
Above fix now in next.
-
- changed status to closed
Fixed by: 747e8acefb0f4402cba6444a59391892fd3dd0a7
-
I think this patch should fix all our trouble to python 2.255.255
Great! Now only Py3, Py4, ..., Py255 issues are remaining :)
- Log in to comment