Re: [Discuss-gnuradio] making gnuradio blocks entirely in python

[Josh Blum]

> 
> 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