-
Notifications
You must be signed in to change notification settings - Fork 30
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
Copyless mir.ndslice and numpy.ndarray integration #53
Comments
Which direction are you envisioning? Seems to me going numpy.ndarray -> ndslice makes sense as long as the numpy array is C contiguous, it's just extract the appropriate pointers to the data and put them in the d structure. I don't know off the top of my head how feasible going the other way would be. memory management - Going from python to D should be fine, pyd keeps an extra reference so python won't reclaim it. Actually, it seems like pyd keeps references on both sides, so this shouldn't be an issue. Until we start supporting non GC allocated memory. |
Both. |
ndslice part of work is done in mir.ndslice.connect.cpython |
Buffer interface seems like the right way to go, pyd doesn't have a way to wrap buffer interface implementations, so that needs to be added. You might consider making Py_buffer a template parameter in mir, since you're going to be getting a pyd Py_buffer struct, and the contents of the struct may differ depending on the version of python (looks like it hasn't changed since 2.5, but you never know what will happen in the future). Buffer interface requires functions getbuffer and releasebuffer to be implemented. I would expect to be able to wrap d methods/functions of signatures int my_getbuffer(Py_buffer* buffer); but we'll see. 2.7 and earlier will also require some additional functions, hopefully I can just wrap getbuffer. I would expect this to be part of pyd's wrap_class functionality, which would probably require making wrapper classes on the mir side. Usage would probably look something like
That would handle the use case of mir -> python now how about python -> mir use case:
provided the appropriate converter is defined. I notice fromPythonBuffer is copying pointers, which raises concerns about python destroying the buffer while you're using it. Hm. Could just require the user to keep a reference to a PydObject somewhere. That might work sometimes. What does mir use for memory allocation? Pyd is pretty coupled to garbage collector, and being able to support other schemes is probably going to require some significant redesign. use case:
if do_something's signature has a YourMirType parameter, same as above, conversion is automatic, otherwise you'll have to add it manually somewhere. Reference counting is still the problem. |
Mir does not specify allocations. By default users use GC allocated memory ( |
ok. I think we'll have to constrain this to GC allocated memory only, since that's all pyd supports right now |
I want to ask a related question: how can I pass a D (native) array to the Python side? I don't care copyless or not, as long as I can pass it. Any example code to show how this can be done? Thanks. |
No description provided.
The text was updated successfully, but these errors were encountered: