On Mon, Sep 26, 2011 at 12:05 PM, Josh Blum <[email protected]> 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.
> >
>
> 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.
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.
Tom
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
