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. Having to write .i files for everything would be a nuisance, given that we mostly got rid of that in 3.7. Also, I'm very interested in benchmarks. If there's some effort involved here, it has to pay off in terms of speed. 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. M _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
