On 12/22/2020 08:21 PM, Glen Langston wrote:
Hello GNuradio Superheros,
I have to say, after 5 years with gnu radio, I’m either tool old or
something has to change.
I’ve been trying to produce some tools for High School teacher to do radio
astronomy.
and for that gnuradio 3.7 was perfectly fine. However some people are
continuing
to make “improvements” that break everything. I used to really like gnuradio.
I like the SDRPlay device, but it can not be used in gnuradio 3.8. According
to the web.
But the web indicates it might be usable in 3.9
So I installed 3.9 only to find that swig has been replace by pybind. This
breaks all my
existing C++ modules. The modules worked fine, but if using ubuntu 20.40 the
students can not
easily install gnuradio 3.7. The pybind instructions are puzzling. gr-modtool
all the
modules copy something or other. This is for no good reason that I’m aware of.
Either make the equivalent of pythons “2to3” or do not make the gnuradio
fundamental changes.
Stop making useless changes that break all code!
We do NOT need these changes. The advice on the web, after I’ve spent 2 days
building 3.9
on a Raspberry pi is use 3.8. This is frustrating.
The documentation is falling apart because of all these variants.
It is good to make changes that ADD tool capabilities. It is NOT good to make
changes that
make small improvements and break such large fractions of the code.
Sorry for the Rant.
Best regards Glen
Glen, I sympathize. But compared to the 3.6-->3.7 debacle, the changes
have been easier, in my experience.
The switch to pybind11 was because SWIG is no longer a supported
subsystem, from what I understand.
The change from XML to YAML for .grc files and .grc block descriptions
is a bit more gratuitous, IMHO, but there may be subtle
improvements in YAML compared to XML (apart from the easier syntax)
that I'm not aware of.
MOST of my own library of radio astronomy code is still stuck at GR 3.7
-- because of the pain you note. I did manage to get
stupid_simple_pulsar working on GR3.9, but it required some patches
to be applied to the underlying code-base because certain
*crucial* setters for frequently-used blocks like multiply_const and
add_const and subtract_const hadn't actually had
pybind11 bindings produced for them. Which lead to silent and
very-perplexing failure. It may be the case that there is no
automated tooling to go from SWIG to PyBind11, which means that it's
easy to miss stuff. Dunno.
The GR developers, per se, cannot be blamed for things like
hardware-specific drivers not being available--those are the clear
responsibility
of the purveyors of those drivers. Now, granted, the lack of
availability may be BECAUSE of the "pain" factor. Similarly, the particular
configurations of GR in *specific* Linux distributions is NOT the
mandate of the GR project, per se. If your fave Linux distro happens
to package GR in a way that is unpleasant in your particular
circumstance, that isn't, generally, the fault of the GR team here.
I've been a C/C++/Python developer now for just over 4 decades, and the
modern "let a thousand flowers bloom" nature of Linux is
**daunting** not just for *users*, but for *developers* as well. I
get grief for my own code because someone wants to build/install
it on some version of Linux with which I am utterly unfamiliar. If I
had to become intimately familiar with the machinations of every
single Linux variant out there (in the multiple dimensions of
version, hardware platform, package-management-framework, etc), I'd
only be able to produce perhaps 1 piece of software every 5 years or so.