> > Now, here's the question. Do we keep this as a separate project or put it > into GNU Radio proper? >
Id like it too see more testing. But I hope to get it in gnuradio. The implementation is relying on a hairy thing like swig directors. Shiver... > If you want to keep it separate and on github, we could at least clone it on > gnuradio.org and have a redmine projects page for it. Or even just a link if > you don't want to worry about updating and supporting the redmine interface > and feel that github gives you everything you need. > I thought we were transitioning to github so I dont even know anymore. > 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. > All the tag qa code could be in python. That could make a developers life easier. Id like to point out that the adder implemented w/ numpy could be performing arithmetic faster because thats vectorized and until we use volk, the adder in gnuradio C++ is not. The real overhead probably comes from the memory allocations that happen going between python and C++ and making python objects. I havent benchmarked it, but I am guessing its non-trivial. > On the other hand (I think I've run out of hands...), this also goes a long > way to solving the problem of people wanting a Matlab interface system. If > you could work in using Matplotlib into your examples, people might see how > much they can do in Python that replicates/replaces/supersedes Matlab for > these purposes. > > Again, great stuff. Let us know how you want to continue to support it. > Yes: I want to support proper message passing. I noticed that I can register a message handler to receive messages. Can you point me to how messages are produced? I really hate gr_tag_info.h. I would rather get_tags_in_range filled a vector of type tag_type, where tag_type has methods like .get_key(), .get_value(), etc... Basically im complaining that we didnt use object orientedness here when its realy well suited for it. You will see that I did this wrap-around in my pyblock_gateway so I didnt have to swig tag_info. See the tags_demo.py to see how I used it. _josh _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio