Looks like the only problematic use of id() is to get the underlying address of the ndarray object (the PyObject, not the memory buffer), right? I would suggest instead just passing a memoryview object, which contains all the relevant information even in Py2 (https://docs.python.org/2/library/stdtypes.html#memoryview), and adapting the extension code to accept such an input (it's all private anyways).

Actually now that I look at it it's not clear whether tk.call can pass memoryviews, but you can also just pass in the address of the underlying buffer and the size and strides of the array (and fix the extension code accordingly). The address of the underlying buffer is accessible att.__array_interface__["data"] (https://docs.scipy.org/doc/numpy-1.13.0/reference/arrays.interface.html#__array_interface__).

If possible, I'd prefer avoid too much pypy specific code, because I fear it's quite likely to bitrot...

@anntzer thanks for picking this up.

I tried to modify the id() calls as you said, but have not been able to getload_tkinter_funcs fron the_tkagg.cpp c-extension working on PyPy, so in the mean time I fleshed out this approach to see if it is functional.

I actually needed to change very little to get this working, in the end I:

• modified the private calls to pass "ptr height width" instead of id(array)
• added another case to the code on non-win32 that searches for the shared object that works with PyPy's cffi moduletk._tkinter.tklib_cffi.__file__

On PyPy unfortunately there seems to be an issue with opening the "configure subplot" subfigure on a basic plot, the mouse events are not reliably reaching the event handlers inlib/matplotlib/widgets.py, maybe a threading issue or competing event loops?

@tacaswell I got a mail reviewing the changes tosetupext.py but cannot see it here, I removed the reference topy_converters.cpp since it is no longer needed. It was used to convert the python-levelid(ndarray) to a C-level ndarray. Now I changed the code to pass inptr height width instead, so the conversion does not require any knowlege about ndarrays

How do I fix the codecov/patch check failure?

Don't worry about the codecov check there. The Tk GUI code, unfortunately, has no automated tests for CI to run.

We tend to ignore that check to be honest...

ping

Can you rebase on master (to try to make appveyor pass... perhaps)?

thanks, I tested on pypy HEAD and tkagg now works. However the way matplotlib usesweakref.ref in callbacks exposes a bug in the JIT, am working on distilling it so I can report and get it fixes

just to be clear, the weakref issue is not a matplotlib issue, rather a PyPy issue that matplotlib exposes

after#9899 was merged, this is all that is needed for the next release of PyPy to work with the TkAgg backend

I never mentioned that what I thought was a PyPy weakref or JIT issue was actually solved by PR#9899 so this PR is all that is needed for TkAgg and PyPy

what's up with docs build? It seems to have timed out with no connection to my pull request

@tacaswell converted back toagg::int8u

what's up with docs build? It seems to have timed out with no connection to my pull request

@tacaswell converted back toagg::int8u

edit: docs build seems to have passed

Sometimes the builds need to be restarted manually because the host has a problem...

can I get this marked 2.2-critical?

"Making PyPy work" sounds like a good thing to have...

By the way would be nice to add a whatsnew entry (including info about what versions of PyPy are supposed to work).

Not sure270f05d is the proper way to do it, let me know if I should have done it differently

Perfect@mattip

Thanks@mattip !