On Mon, Sep 26, 2011 at 12:05 PM, Josh Blum
<address@hidden> wrote:
>
> 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.
>
Sort of, yes, and no... we'll still have everything on
gnuradio.org as a permanent repo that's cloned on github. For one thing, I was looking into Redmine, and I'm not sure it can handle a project that's not local to the file system; so we have to have a local clone.
In this case, if it's kept as a separate project, we would clone it on
gnuradio.org and have a project page set up for it and periodically refresh it from github.
> 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.
Maybe... as I've said, I haven't been hugely impressed with the speed of numpy/scipy in many cases. For the adder, you might be right due to the vectorization.
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.
True.
> 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?
So you basically need to create a callback function and set it as the message handler. So you call:
template <typename T> void set_msg_handler(T msg_handler){
d_msg_handler = msg_handler_t(msg_handler);
}
Where d_msg_handler is of type:
typedef boost::function<void(pmt::pmt_t)> msg_handler_t;
You then use gruel::send (in msg_passing.h) to a block that has a message acceptor handler defined (or not; if there is no handler, nothing happens). You can see gnuradio-core/src/lib/runtime/qa_set_msg_handler.cc for an example of this.
We have wrapped most of the PMT stuff into Python, but I don't think that the send method has been made available, yet. So there's work to be done there.
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
Ok, that's fixable. We probably want to redo much of the tags interface to make it easier, and those are good suggestions.