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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio