Re: [Discuss-gnuradio] Gnu Radio architecture, etc

[Andrew Davis]

Well it's not the language choice, it's all the helper programs that are
 version locked that annoy me most. Python is in a weird state of limbo 
right now with the version 3 switchover. Many systems are defaulting to 
python 3 and we should probably do the same. Python would work great if I
 was just putting together an FM radio by connecting blocks, but for any
 more computational advanced program I would want to switch to C++. 
GNUradio is almost catered to Pyhton, this should not be the case, it 
should be modular so I can call it from any scripting language or GRC. 
For just connecting blocks Python has way too much overhead, a simpler 
scripting environment would suffice. Then for more advance programs you 
almost have to switch to C++. Take usrp_spectrum_sence for example, this program has 
it's own block ( bin_statistics ) that has no use other than basically 
being the heart of usrp_spectrum_sence, it just shows python isn't up to the task of real DSP work beyond just connecting real C++ code. Whats needed is a common block connecting API that can be run directly from GRC without using python as an intermediary. Without the need for python/swig we eliminate a great deal of version locking and system incompatibility.

On Fri, Dec 30, 2011 at 3:45 PM, Marcus D. Leech <address@hidden> wrote:

Very true, all of it, GNUradio is quite the hodgepodge of different APIs, Languages, and Ideas.
And that's not always a bad thing, it can allow great flexibility, but sadly it is currently doing the opposite. With required versions of SWIG, Python 2.x/3.x and other helper programs it ONLY compiles reliably on ubuntu and fedora, and only Ubuntu, not kubuntu or Xubuntu as the small differences in GTK versions break most of wxgui. I am also a die-hard FreeBSD user forced into Ubuntu as no other operating system can compile GNUradio since 3.2. OK sorry for the rant.

See my earlier rant about "shoulders of giants".

I think that what happens for *some* people is that Gnu Radio isn't written using their programming language/paradigm of choice.
 To *them* it's "obvious it should have been written in {C,C++,Ruby,Java,Fortran,Pascal,Erlang,Cobol} and I can't understand why
 these Gnu Radio idiots picked Python/C++".  I admit that back in 2005, when I first started using Gnu Radio, I was resentful of
 the choice of Python/C++.  Two languages that I was ill-prepared for.  I spend most of my professional life coding in C, with
 occasional excursions into C++.  Gnu Radio forced me to learn enough Python to get by.  Now, I love it.  I find that I'm much more
 likely to write a "throw away" program in Python than C these days, and I've been a C programmer since 1979!  I taught my son
 Python when he was 8.  He still loves it at nearly-14, and even taught Python to his class-mates when he was at a private school.

With the advent of GRC, you don't even have to know Python or C++ to accomplish a great deal of stuff.  If the "plugging lego together"
 paradigm isn't "natural" or is too restricting, you can always program in a soup of Python and C++.  It's all doable.


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio