-
Notifications
You must be signed in to change notification settings - Fork 217
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ValueError: array.array size changed, may indicate binary incompatibility on PyPy #854
Comments
Related: conda-forge/pyproj-feedstock#90 |
hope ? |
For reference: https://foss.heptapod.net/pypy/pypy/-/issues/3039 (from: conda-forge/pyproj-feedstock#90 (comment)) |
I'm lost in thoughts, it seems the problem is back with PyPy-3.7-7.3.6, and now Pyproj is droping support for 3.7. plotnine: giving a taste of ggplot of R langage (formerly we were using ggpy)from plotnine import ggplot, aes, geom_blank, geom_point, stat_smooth, facet_wrap, theme_bw
|
@stonebig, are you using the latest pyproj version? |
pyproj-3.2.1 I have lot of (new ?) problems of messageless crash with PyPy-3.7-7.3.6 just released (and rc3, and rc2). |
That is also my experience. I get reproducible crashes in numpy's |
there seems to be maybe a hint from https://libera.irclog.whitequark.org/pypy/2021-10-18 |
@cgohlke PyPy-3.7-7.3.6 broke binary compatibility with previous versions. I released 7.3.7 to revert the breaking changes. Sorry for the mess. |
Thank you! Do you think it is safe to start building for pypy3.8-v7.3.7? |
I think so. it would be nice to get some feedback. Issues of failures can be opened on the PyPy bug tracker |
Hi. I'm a bit lost in thoughts, On My PC, with pypy3.7-v7.3.7-win64.zip and re-downloaded pyproj-3.2.1-pp37-pypy37_pp73-win_amd64.whl wheel , this basic test from first cells of https://github.com/pyproj4/pyproj/blob/master/docs/advanced_examples.rst fails:
|
The only binary wheel for PyPy on https://pypi.org/project/pyproj/#files is one for windows. Perhaps somehow it missed the change in #883? |
@cgohlke creates the Windows wheels. The wheels for Linux & OSX are built here: https://github.com/pyproj4/pyproj-wheels/. Contributions welcome =). |
@cgohlke made another wheel, so problem moved down to rtree wheel now, that seems a bit lost with pypy3.7-v7.3.7 old way of things pypy3.8-v7.3.7 is clother to cPython standard, so unmaintained rtree may feel better. see also rtreee issue Toblerity/rtree#191 |
after copying around rtree DLLs, another tree hit
|
transformer.py seems lowercase on Windows ... playing lowercase with the example or the 'transformer.py' leads me to :
|
Back to this problem on PyPy-3.8rc1+nightly.... |
@stonebig could you confirm you are using pyproj 3.3 from https://www.lfd.uci.edu/~gohlke/pythonlibs/#pyproj, and that this line fails?
|
I have once again recompiled the pyproj package for PyPy and it is importing again. I think this issue is due to Cython producing incompatible versions of C files when cythonizing on CPython vs PyPy, which makes it hard and error prone to build CPython and PyPy wheels from the same copy of the source without removing the cythonized files in between builds. |
Thanks @cgohlke. It seems this cython-translation time directive, which was added in #883, means that the cython c-code will indeed change depending on implementation. Over at cython/cython#3448, the discussion of this problem ended with
and cython HEAD emits a warning when using array.array on PyPy. In h5py a similar problem was solved by replacing a local variable that used Perhaps the translation time directive could be replaced with a runtime check for |
Importing pyproj 3.0.1 on PyPy for Windows raises the following error:
The issue is that there is "no clean C interface to the array.array object in Python". See discussion at h5py/h5py#1514 and h5py/h5py#1515 for a possible fix.
The text was updated successfully, but these errors were encountered: