Re: Stop making unneeded improvements

[Glen Langston]

Dear Johannes and all members of the GNURadio community,

Happy New Year.  I hope all are doing well.

Thanks for all your efforts!    

Concerning my previous email, sent in extreme frustration.   I understand
that we all want to make improvements and progress.  

Concerning your points below.   I understand that python2 is being replaced by 
python3.
I’ve gotten over that, mostly thanks to simply using the tool:

2to3

Which is fantastic, and should be a model for us all.

My particular goal is to get my code/blocks documented before they are broken 
again by “improvements”.
I know that the group is focused on making GNURadio enhancements to 
capabilities.
However this is killing the “users” of GNURadio, who barely have the capability 
of writing
C++ modules and python code.  Once I got these working I was really, really 
hoping I could
go on to make discoveries in the universe, and not have to scratch my head over 
“improvements”.

So, you’re right about your points 1 and 2 (below).

From my point of view you’re wrong about 3.  Unless there is the equivalent of 

swig2pybind

Please don’t make this change until swig2pybind is written.

I’m neutral about point 4.  I’m not sure exactly which modules your are 
referring to.
It was frustrating to go from WX to QT, but that is done.  
There was not a 1-to-1 match of functions from WX to QT, when installed.
The new functions are great, but not having matching replacements to existing 
functions 
is a challenge to the feeble minded.

Again, thanks for all your great efforts.   Just remember that “established"
users are challenged by improvements and may have completely different 
priorities 
than developers.

Best regards

Glen

> On Jan 5, 2021, at 9:24 AM, Johannes Demel <demel@ant.uni-bremen.de> wrote:
> 
> Hi Glen,
> 
> I fully understand your frustration to make things work long term and 
> constant breakage.
> 
> There are, however, reasons why breaking changes are unavoidable. Some 
> examples are:
> 1. GRC used Cheetah with XML for block definitions BUT:
> Cheetah got unmaintained for years. Cheetah is only available for Python2. 
> Python2 support ran out. Instead of relying on an unmaintained project, GRC 
> switched to Mako which uses YAML instead.
> 
> 2. With Ubuntu 20.04, it would probably be impossible to do a "simple" 
> install of GR 3.7 because it requires Python2 and 20.04 basically dumped 
> Python2 in favor of Python3. Thus, it was important to move to a newer Python 
> version. You might be able to install 3.7 on that system BUT you might very 
> well break it for other applications.
> Ubuntu 20.04 is actually a very good reason to move to a newer GR version 
> because it cuts off a lot of dependencies GR 3.7 has. e.g. Python2, Qt4, etc. 
> That also exemplifies why GNU Radio must evolve because the ecosystem around 
> it evolves as well.
> 
> 3. There has been a lot of discussion if and how SWIG might be replaced by a 
> different system. SWIG seemed like a good solution when it was introduced. 
> But it turned out to be extremely frustrating whenever there are problems to 
> fix.
> 
> 4. Deprecating blocks seems like an annoying thing to do as well. 
> Unfortunately, sometimes things that seemed like a good idea turn out to be a 
> dead end. In this case, we all like a better alternative and some time to 
> move in case we must.
> 
> I know that a lot of package maintainers do a fantastic job to make GR 
> available for their respective systems. I hope that helps to get the 
> installation process going.
> I'd like to refer to Geof Nieboers recent email where he explains all the 
> difficulties that come up with old software.
> 
> Of course, developers tend to be eager to adopt new technology and learn how 
> to use it. Just like Radio astronomers want to discover and learn about new 
> signals.
> Personally, I think Marcus is doing a fantastic job and balancing things 
> between long term usability and progressive changes.
> Also, you'd be very welcome to join discussions about the future of GNU Radio 
> and make sure it is as good as possible for you too.
> 
> Cheers
> Johannes
> 
> On 23.12.20 02:21, 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
>>> On Dec 22, 2020, at 3:43 PM, Adam Gorski <Adam.Gorski@vt-arc.org> wrote: