Hello,

I use the vector_source_x and vector_sinc_x blocks quite a lot for
testing, debugging and simulations, even with quite large input and
output data streams.

Therefore I was looking in speeding up the feeding and retrieval of data
by implementing the Python buffer interface [0] that permits to exposed
data to other components handling uniform vectors of data in a copy-free
manner.

Investigating how to do that in SWIG I found that [1] the only supported
way of doing this is to compile the bindings with the SWIG -builtin
option [2] that modifies how the Python bindings are constructed. Making
a long story short, the Python class definition is not done anymore in
python code, but with a proper Python extension (in a more clean way, IMHO).

At first I tried to implement this in an out-of-tree GNURadio module,
however I run into problems because SWIG is unable to generate bindings
with the -builtin flag for types subclassing from types defined in an
extension compiled without the -builtin option (sorry, that reads a bit
too convoluted...).

There is interest in switching GNURadio over to the -builtin way of
generating the bindings? We would gain somehow cleaner bindings, the
possibility of populating the Python objects slots to implement specific
object behaviors (to get rid of the __repr__() override necessary for
each block, and the buffer interface, for example).

If there is interest, I can look into providing a patch. A quick test
revealed no problems in adding the -builtin option to the makefiles.

Thank you for reading all that :-)

Cheers,
Daniele


[0] https://docs.python.org/2.7/c-api/buffer.html
[1]
http://swig.10945.n7.nabble.com/swig-python-extension-accessing-PyObject-to-implment-pep-3118-revised-buffer-Protocol-td2419.html
[2] http://quantlib.org/reposit/docs/swig/Python.html#Python_builtin_types

_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to