| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
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 at t.__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... |
Sorry, something went wrong.
|
@anntzer thanks for picking this up. I tried to modify the id() calls as you said, but have not been able to get load_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. |
Sorry, something went wrong.
|
I actually needed to change very little to get this working, in the end I:
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 in lib/matplotlib/widgets.py, maybe a threading issue or competing event loops? |
Sorry, something went wrong.
| _tkagg.tkinit(tk.interpaddr(), 1) | ||
| else: | ||
| # very old python? | ||
| _tkagg.tkinit(tk, 0) |
There was a problem hiding this comment.
interpaddr was added in 1998(! python/cpython@9d1b7ae) so I cannot actually imagine a case where this is triggered today (but that can go to another PR of course)
Sorry, something went wrong.
|
@tacaswell I got a mail reviewing the changes to setupext.py but cannot see it here, I removed the reference to py_converters.cpp since it is no longer needed. It was used to convert the python-level id(ndarray) to a C-level ndarray. Now I changed the code to pass in ptr height width instead, so the conversion does not require any knowlege about ndarrays |
Sorry, something went wrong.
|
How do I fix the codecov/patch check failure? |
Sorry, something went wrong.
|
Don't worry about the codecov check there. The Tk GUI code, unfortunately, has no automated tests for CI to run. |
Sorry, something went wrong.
|
We tend to ignore that check to be honest... |
Sorry, something went wrong.
|
ping |
Sorry, something went wrong.
| # define SIZE_T_FORMAT "%zu" | ||
| # define IMG_FORMAT "%zu %d %d" | ||
| #endif | ||
| # define BBOX_FORMAT "%f %f %f %f" |
There was a problem hiding this comment.
extra space?
Sorry, something went wrong.
There was a problem hiding this comment.
fixed in cc7b73e
Sorry, something went wrong.
| deststride = 4 * destwidth; | ||
|
|
||
| destbuffer = new agg::int8u[deststride * destheight]; | ||
| destbuffer = new uint8_t[deststride * destheight]; |
There was a problem hiding this comment.
any reason for the change?
Sorry, something went wrong.
There was a problem hiding this comment.
now it no longer uses #include py_converters.h which supplied the agg:int8u
Sorry, something went wrong.
| return TCL_ERROR; | ||
| } | ||
|
|
||
| if (sscanf(argv[4], BBOX_FORMAT, &x1, &x2, &y1, &y2) == 4) { |
There was a problem hiding this comment.
should probably error out cleanly if an invalid string is passed?
Sorry, something went wrong.
There was a problem hiding this comment.
yesish, these are basically "private" functions parsing a call from python, but I will add more checking code
Sorry, something went wrong.
There was a problem hiding this comment.
updated in cc7b73e
Sorry, something went wrong.
| has_bbox = true; | ||
| } | ||
| else { | ||
| else if (bbox_parse == 1 && x1 == 0){ |
There was a problem hiding this comment.
parens
Sorry, something went wrong.
|
Can you rebase on master (to try to make appveyor pass... perhaps)? |
Sorry, something went wrong.
| desty = hdata - y2; | ||
| destwidth = x2 - x1; | ||
| destheight = y2 - y1; | ||
| destx = (int)x1; |
There was a problem hiding this comment.
Shouldn't BBOX_FORMAT just be 4 integers and just use integers all along? (not sure if tk would have the bad idea to always cast things to float)
Edit: Actually I guess not, what should really happen is that we should explicitly cast on the caller's side but this can just go as it is for now...
Sorry, something went wrong.
There was a problem hiding this comment.
The call sequence is backend.blit(image, bbox) -> tkagg.py:blit(image, bbox) -> PyAggImagePhoto(as_string(image, bbox)) so we cannot change the root backend.blit call. AFAICT the choice is:
I usually prefer converting as late as possible to postpone rounding and allow future refactoring with floats to be as painless as possible, but will flow with whatever is matplotlib best practices
Sorry, something went wrong.
There was a problem hiding this comment.
I think we can leave it as it is for now, we were using floats to start with and we can change that later.
Sorry, something went wrong.
There was a problem hiding this comment.
assuming appveyor passes
Tested locally on cpython, not actually tested myself on pypy...
Sorry, something went wrong.
|
thanks, I tested on pypy HEAD and tkagg now works. However the way matplotlib uses weakref.ref in callbacks exposes a bug in the JIT, am working on distilling it so I can report and get it fixes |
Sorry, something went wrong.
|
just to be clear, the weakref issue is not a matplotlib issue, rather a PyPy issue that matplotlib exposes |
Sorry, something went wrong.
|
after #9899 was merged, this is all that is needed for the next release of PyPy to work with the TkAgg backend |
Sorry, something went wrong.
embedding_in_tk2_sgskip is essentially a slightly simplified duplicate of embedding_in_tk_sgskip.
| deststride = 4 * destwidth; | ||
|
|
||
| destbuffer = new agg::int8u[deststride * destheight]; | ||
| destbuffer = new uint8_t[deststride * destheight]; |
There was a problem hiding this comment.
Why change away from the agg types here?
Sorry, something went wrong.
There was a problem hiding this comment.
Previously there was a conversion from a PyArrayObject * (in other words ndarray) to a data pointer, width, height, etc via py_converters. Now I pass that information directly from python. I no longer need the "py_converters.cpp" and ""py_converters.h" since there is no use of ndarray in the c++ code. Should I leave the include for this one type definition?
Sorry, something went wrong.
There was a problem hiding this comment.
I am concerned about the corner case where unint8_t and agg:int8u are different underlying types. Not sure how likely that actually is, hence leaning towards being conservative about changing it.
Sorry, something went wrong.
There was a problem hiding this comment.
I wonder what different types you think these can be.
I would also bet that there must be parts of the code where we assume that this is interconvertible with np.uint8, or that this fits in a single byte... doesn't leave you a lot of options!
Sorry, something went wrong.
|
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 |
Sorry, something went wrong.
|
what's up with docs build? It seems to have timed out with no connection to my pull request @tacaswell converted back to agg::int8u |
Sorry, something went wrong.
|
what's up with docs build? It seems to have timed out with no connection to my pull request @tacaswell converted back to agg::int8u edit: docs build seems to have passed |
Sorry, something went wrong.
|
Sometimes the builds need to be restarted manually because the host has a problem... |
Sorry, something went wrong.
|
can I get this marked 2.2-critical? |
Sorry, something went wrong.
|
"Making PyPy work" sounds like a good thing to have... |
Sorry, something went wrong.
|
By the way would be nice to add a whatsnew entry (including info about what versions of PyPy are supposed to work). |
Sorry, something went wrong.
|
Not sure 270f05d is the proper way to do it, let me know if I should have done it differently |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
PR Summary
the tkagg::blitfunction uses the id built-in to obtain memory adresses. This is not compatible with PyPy. I have written a proof-of-concept alternative blit function that uses a pure-python _tkagg backend via CFFI. Since CPython prefers a c-extension (_tkagg.so) over a python file (_tkagg.py) and PyPy reverses this, the two implementations can live side by side.
It is working but not yet complete:
but I wanted to see if this approach is acceptable before continuing. Any thoughts?
Edit: now point three (bbox handling) is complete
Edit: (5.Nov.17) now points one and two are done, and documentation does not change