discuss-gnuradio
[Top][All Lists]
Advanced

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

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


From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] Gnu Radio architecture, etc
Date: Fri, 30 Dec 2011 16:46:29 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

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.
That horse has already left the barn, I'm afraid.

But you know that you can use C++ even for the "connecting the blocks" part now? That has been true for quite some time (two years?). Plus, GRC *almost* doesn't know anything about Python. You could probably tweak it to generate C++ blocks--in fact, a good student project would be to take the current XML files that describe GRC blocks, and make them generate C++ code as an "alternate coding universe"
  output for GRC.



Eliminating Python will eliminate the SWIG dependancies. But all the other dependenices won't go away. FFTW, Boost, Orc, and a bunch of other stuff. Plus, many of the underlying C++ blocks are actually *generated* using templates and a Python script.

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





reply via email to

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