On Fri, Dec 30, 2011 at 4:38 PM, Andrew D.
[email protected]wrote:
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.
Version locked? We have a minimum version for the dependencies, but few
actually have a set version required or a max version allowed (even Swig
2.0 seems to work, somewhat to my surprise). All the versions we depend
on
are also very old. When we made the move to Swig 1.3.31 as the min
required, it was a big deal as that version wasn’t generally supported
out
of the box by most distros. But that was 2007.
Many systems are defaulting to python 3 and we should probably do the
same. Python
Many, but not most. And the ones most of our users work with still
default
to 2.x. We’ll make that leap when we have to, but it’s non-trivial.
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
Remember that Python is only the glue language; all of the computation
takes place in C++.
scripting language or GRC. For just connecting blocks Python has way too
much overhead,
Wow. That’d be a nightmare to maintain. We had hooks for Guile for a
while,
but it’s been too big of a deal to manage that and Python, so we’re no
longer supporting it. It seems like it’d be a simple thing to support
various scripting languages, but it isn’t.
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.
I’m curious about your issues with “version locking.” It sounds like
it’s
isolated to a particular system. We’ve built GNU Radio on a huge range
of
systems. The Swig version is pretty ancient in software standards and we
support Python 2.5 - 2.7, which is what most systems still use.
Any time we have a dependency, which are essential these days to making
a
program of any worth and complexity, we are going to have version
issues,
but I think we’ve been very good about handling them for the past few
years. The move to Python 3.0 is going to be significant, and we
probably
don’t want to support both.
And Python isn’t the only thing that suffers from this. Look into the
changes from Guile 1.8 to 2.0. Huge differences and massive
incompatibilities.
Anyways, if you have a particular problem that you’ve run into with a
given
system, please let us know what it is! Hell, I fairly recently built GNU
Radio on CentOS 5.2. I think the only thing I had to hand-install was
Swig
and Cmake (maybe Boost; I can’t recall).
Tom