Python Bindings for Cork #17
Conversation
produce the same answers as calling the binary. The main work we need to do is that input parameters may not be properly deallocated.
This may or may not be desirable for the non-python use case. There's no clear way to do this with a flag, but we should probably build out the build system
This was a bit of an adventure.
|
8a2d3e6 resolves the deallocation issue; before we were indeed just never freeing the memory allocated as return values. Also, PIC is required for building a python extension. a01b9b4 shows where to add to the Makefile; I think it's okay to leave them in there, but the makefile sort of needs more surgery than I'm willing to do right now. Making it respect CXXFLAGS would be nice though! |
|
Thanks for implementing this, even though I assume |
|
It's kind of a swig convention -- it compiles the actual c code into a shared library named _cork.so, and generates a python module named cork.py that does some type checking then calls the real call inside of _cork. So in application code, you would still "import cork" as people probably expect. Yeah, I don't expect it's maintained; I was really just helping my buddy out with these bindings but they should be decent, if people are using the project. We found that we were wasting a lot of time dumping meshes and reloading then rather than using them in-process. |
|
Hi, yes. I don't have much time to maintain this code these days. However, it seems like various people have built extensions. I think it'd be a good idea to try to merge some of these efforts if possible. Please feel free to email me if you want to talk about someone else taking ownership of the code. Of course, I'll be around to consult regardless--especially on the numeric/robustness aspects. |
This is mostly to see if you're interested in supporting python bindings. I wrote some typemaps that do a pretty decent (zero-copy!) job of it if you use numpy matrices. There are test cases that verify we get the same result as calling the binary on the samples (they won't work though unless you patch initRand and just do an srand(0) there).
Before we would merge, I think there are a couple things we need to check ...