[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: Josh Blum
Subject: Re: [Discuss-gnuradio] making gnuradio blocks entirely in python
Date: Mon, 26 Sep 2011 09:05:05 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

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

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


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.


reply via email to

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