Re: [Discuss-gnuradio] Compiling SWIG python bindings with -builtin option

[Daniele Nicolodi]

Hello Martin,

thank you for reviewing this idea. I'm already working on a branch with
the required changes.

The required changes are the build flag and some adjustment to the SWIG
bindings. With builtin object classes there isn't anymore a python
wrapper class therefore it is not possible to fiddle with the class
methods at runtime. For example, the __repr__() method cannot be patched
in at runtime but needs to be defined in the SWIG interface.

So far I have gnuradio-runtime, including pmt, and gr-blocks compiling
and I haven't found any major change required and I'm looking for the
cleaner way to implement some things. I haven't yet tried to propagate
my changes to the other modules.

I hope to have a proof of concept ready in the next few days. I'm not
familiar with SWIG (and it is not very friendly), so the process of
finding the right way of doing things has been mostly a process of try
and error.

Cheers,
Daniele


On 20/10/14 09:36, Martin Braun wrote:
> 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
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>