> 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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment