On Thu, Nov 14, 2013 at 12:14 PM, Sylvain Munaut <246...@gmail.com> wrote:
> Hi, > > > First: Please pay attention and reply to the list and not to me personally. > Mercy! That was an honest mistake. A thousand apologies. > > > > A suggested "improvement" to the gnuradio code base (let me know what you > > think) : > > Please keep such objects in a globally visible list (I can provide a > diff if there is interest) so that applications such as mine can access > them. UHD > sources and sinks are likely to be quite static as are indeed > most gr blocks I would suspect. > > What I think is that I wouldn't call that an improvement at all. IMHO > It's a horrible design ... > I agree. If you notice I started off with that premise (i.e. that it was a hack). > > > >> You'll have to give the instanciated uhd source block as an argument > >> of your custom block constructor and play with SWIG to make the Python > >> object be converted back to a C++ smart pointer. Have fun. > > > > It sounds quite messy and hence I had to ask this list if there was a > better > > way. > > Wait what ? Passing the pointer cleanly between blocks is "messy", > but polluting the global application namespace is "clean" ??? I think > we have radically different idea of what's good design and what's not > ... > > > > I am open to any ideas. I could of course modify the gnuradio source > code > > to export a global pointer but I'd love it if I could leave the core > source > > code alone. > > If I'm not mistaken, you can control the UHD source / sink with > message passing to change the frequency. Then your MAC just has a msg > output port connecting to the uhd message input port to control it. > I will look at the block again but I could not see that. Thanks for taking the time to reply. Regards, Ranga > > Cheers, > > Sylvain > -- M. Ranganathan
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
