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

[Daniele Nicolodi]

On 20/10/14 11:50, Martin Braun wrote:
> On 10/20/2014 11:19 AM, Daniele Nicolodi wrote:
>> 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.
> 
> Oh, we know what you're talking about :)
> 
> I'm interested what happens when you reach blocks that *do* fiddle with
> SWIG. gr-uhd does this, and in gr-digital with have a couple of tweaks.

I had a look at what gr-uhd does in its python code and it looks like it
mostly corrects for things that could be also solved easily in SWIG.
Worst case what can be done is that the SWIGGed class is renamed (with a
SWIG directive) and at is sub-classed in Python to tweat with it at
will. However, I don't see the need of it so far.

> Having to write .i files for everything would be a nuisance, given that
> we mostly got rid of that in 3.7.

I don't understand what you mean with this. We have .i files for
everything! For out-of-tree modules they are auto-generated by
gr_modtool and some parts are hidden behind SWIG macros, but there
definitely are .i files for all the classes in GNURadio. It is how SWIG
works :)

> Also, I'm very interested in benchmarks. If there's some effort involved
> here, it has to pay off in terms of speed.

I don't think there are any speed advantages for blocks coded in C++,
what can be sped up is instantiation and configuration of the blocks.
The actual work methods are already called in C++ context without Python
overhead, so there is nothing to to gain there.

This is different for blocks coded in Python, but to take advantage of
the improved SWIG wrappers other changes would be required, probably.
There is quite a bit of magic involved at the moment, that can be
probably simplified with better wrappers.

However, I have the feeling that if speed is a goal, SWIG is probably
not the right tool. The code it generates it sub-optimal under many
aspects (starting with the double type system it puts in place: the SWIG
type system somehow glued on top of the Python type system...)

> I'd suggest you open an issue on our tracker, and we take the discussion
> there. I'm hoping that that some people with more SWIG experience can
> chime in here, too.

I'll do.

Cheers,
Daniele