I noticed that you added a Python module interface to RapidCode. ¡Excelente!
Why the dependency on
numpy? We bundle a slim distribution of python with our product, and I try to keep it as small as possible. The doc says that it’s used for array conversion, but it adds ~50 MiB to my Python install to include it.
The SWIG (4.x) interface I made for RapidCode didn’t need it, but I don’t know if I tried using any of the
MotionController::Move*(...) functions in it. Usually, I just use it in testing to query states and things. What parts of the interface necessitated using numpy?
Also, is it strictly a 64-bit module? How hard would it be to make it work for either architecture?
The numpy dependency is for array marshalling for the (small) subset of RapidCode methods that pass arrays. That’s mostly streaming motion and several methods on the Robot class.
Yes for now it is a 64-bit module (as are all our utilities and tools). Do you still use the 32-bit libraries? If so, how long do you anticipate needing support for 32-bit? It’s not “hard” to make it work for 32-bit but would require additional builds and tests for our CI/CI pipelines.
The app that we develop for is still 32-bit. I don’t have a timeline for when it will change, but it is a (long term?) goal.
Also, it looks like the
_RapidCode.pyd DLL was built exclusively for Python 3.10. Is there any way to support other versions (also)? I realize this is going to be a constantly moving target. Is there some way that customers could build the module against their own dependencies, like could you distribute the SWIG interface file and whatever other stuff you use to build the DLL?