[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] making gnuradio blocks entirely in python
Date: Tue, 27 Sep 2011 10:13:08 -0400

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.

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

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.

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


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.


Ok, that's fixable. We probably want to redo much of the tags interface to make it easier, and those are good suggestions.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]