On Mon, Sep 26, 2011 at 12:17 PM, Ben Hilburn <[email protected]> wrote:
> >>> On the other hand, part of me doesn't want it in GNU Radio because I >> don't want people to start using it as the default way of doing things, >> specifically, that they don't start with a pyblock and never move it into a >> proper C++ block. In my experience with numpy (and scipy), they are great >> interfaces and they are faster than using Python, but they are still much >> slower than they could/should be. So we shouldn't be relying on Python-level >> stuff for real implementations. >> > > "Devil's avocado, here, Dave" - For what it's worth, I think you could put > it into GNURadio proper, and not have it become the de-facto standard for > block development. If people want to use the tool to rapidly-prototype > block functionality, this seems ideal. Filter design in GNURadio could > suddenly become much easier - especially for people unfamiliar with the C++ > / Python barrier. Once someone gets a block working, it would be easy to > simply refuse to merge it into the proper codebase until it is written in > C++. > > Part of this comes from the fact that I think there is a serious difference > between the production/release code that is in GNURadio proper, and the > prototype code that people all over the world are writing from desks covered > in textbooks, research papers, and mad scientist drawings of new radio > designs. > > If we can make it easier for the mad scientists to prototype stuff in > Python, I'm all for it - because that means the good stuff can get > translated into C++ production code, and merged in. > > Anyway, this is certainly an interesting point and discussion - I just > wanted to throw my opinion in. > > Cheers, > Ben > Yes, it's just my concern that people will use it for development but just get comfortable in that mode and not move it into c++ for production. As always, the way we intend for things to be used is not always the way they are used. That's just a concern, though, and not a show-stopper. If that's how people want to work and they aren't having performance issues, then why not let them work away? Tom
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
