On Fri, Dec 30, 2011 at 4:38 PM, Andrew Davis
<address@hidden> 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
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
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio