Daniele, this is interesting. However, I'm not 100% clear about the implications this would have (i.e. which changes are necessary). Is it just the build flag, and then of course the accompanying limitations listed in the manual (those would not be a problem, as far as I can tell)?
One thing I can say for sure is that it won't be merged into GNU Radio 3.7, since it requires a compat bump for SWIG. However, we are planning that for 3.8, so this change is not unreasonable. This is new to me, and I just gave the manual a quick browse. From that, it seems a good idea, but as I said, I can't quite see all the consequences. If you could provide a branch with the necessary changes (an incomplete proof of concept would be fine, just so we can see what needs to be changed), branched off of next, that would be great. Thanks for suggesting this! Martin On 10/15/2014 08:12 PM, Daniele Nicolodi wrote: > 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 > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
