On Mon, Sep 26, 2011 at 12:05 PM, Josh B. [email protected] wrote:
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.
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.
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