[chirp_devel] The End of Days - #495

[Jim Lieb]

I'm the dev who did the Wouxon KG-UV9D+ driver. Since that effort, I've been 
fooling around with a "clone" of chirp written in GO for my own amusement. 
I've been impressed by the quality of the Golang project and have used it in 
the past. Pike and Kernighan do good work. I thought of it to address issues 
someone brought up when I wrote to this list about Fedora's dropping of Py2 
support starting with Fedora 30. I have never been a fan of dynamic/
interpreted languages (bash, perl, python, tk/tcl, lua, etc.) for anything 
larger than a few hundred lines. At least the Python 2->3 has not been as 
disasterous as the Perl 5->6 that is still not really happening.

I do not want to sidetrack the discussion to make a language move as well but 
my choice has been one informed by project experience. Some of my reasoning 
could be applied to this non-trivial effort. One of my concerns, aside from 
the experience of the Py2->Py3 death-march,  that pointed me to GO instead of 
Py3 was the deprecation of Win/NT by the Python community. This is an issue to 
some in the Ham community who just want to play with their radios, not 
sysadmin upgrade purgatory. But so much for that idea; Go has also dropped 
support starting with V1.11... But a key point remains. The language choice 
drags along with it a runtime environment that must also be present on the 
target system. The motivation for the move (for me) was that Go produces a 
single binary whereas Python (and most other "dynamic" languages) requires a 
whole mess of other "stuff" that must be either already present on the target 
client machine or must be ported/installed by the user before the application 
can be installed. This is the primary reason why Win/NT was dropped. The 
Python footprint is *huge*. To get enough Python to run a simple app like 
chirp, you have to also have enough Python runtime to run any Python script, 
including nearly all of the dev/debug environment. A Go app is just one static 
binary and their cross-dev tooling is one of the best I've seen (and yes, I 
know (and avoid) Java...). Multi-platform deployment is all about package 
dependencies and runtime footprint. YMMV but my little project choice has been 
to have a target device (radio) agnostic binary that could be easily cross-
built to other platforms and a separate set of device specific description 
"recipes" for the target devices. BTW, this could extend the use case to 
things like IOT devices and anything else that gets configured by dumping bits 
into existing firmware memory.

Aside from the excursion through my personal choice of Go, there are a few 
things to consider in this effort:

1. Fork the project. This is especially true given the current diff stats and 
comments about the work so far. There are folks who are not moving from Win/NT 
anytime soon and if they have PCs of that vintage, they probably have radios 
of that vintage too that could have at least *some* maintenance support 
without having what they need working muddied up by orthogonal development 
efforts. There is a lot of work to do here and a separate fork will not cause 
un-testable changes in the old code.

1a. This is an opportunity to move the codebase to git (and github). We had 
this discussion a while back on the list. Hg is fine but it didn't catch on 
and aside from its already captured base, it has become an impediment to 
attracting a wider dev population. I got thru getting a driver submitted but 
hg got in the way for me, a long time git based dev, than it should. This is 
no knock on the hg devs nor do I want to start yet another SCM religion war. 
They did and still do good work but hg is just one tool among many that follow 
git around. Moving the fork to github also relieves the project from the 
distraction of also maintaining a dev/scm infrastructure. There is more than 
enough work to do maintaining chirp which is the main task. I was project lead 
and release manager of a project we moved from Sourceforge to github years 
ago. That moved our project (nfs-ganesha) from the margins to mainstream and 
made the support of developer contributions much easier.

2. Attempting shim layers etc. to somehow keep both domains happy is a path to 
ruin. There be dragons. This does not mean starting with a completely blank 
slate but the code, especially the pile of drivers needs refactoring work and 
attempts at shims get in the way of wholesale rewrites where they are needed. 
I have been down this road many times before before with attempts such as 
hacking on obsolete Linux drivers that clients wanted to be extended just a 
little more and a little longer rather than going for the re-written new work. 
Fortunately, that frustrating work was done under contract so I got paid for 
eventually proving to the client that they would have been better off 
modifying their userland code to use the new scsi drivers for r/w cdroms 
rather than my hacking the cdrom hack of the old IDE HDD driver (ide-scsi),  
that the ide maintainers decided to scrap, one more time. If you are not 
careful you end up with a bigger mess than what you started with. That is why 
I recommend (1). This is an opportunity for an un-encumbered refactor while 
leaving the legacy installed base in peace.

3. The memmap and bitwise code is a great idea. But it does not go far enough. 
It also could use a refactor because things silently break and the result of 
the Python parser on errors is maddenly difficult to debug. The _real_ value 
of this code is its idea that there is a description string that contains a 
well defined syntax that gets parsed to deliver the memory map and the 
namespace and methods to access it.

4. The get_settings method is a prime candidate for refactor in the spirit of 
(3). In my driver (kguv9dplus.py) I gave it a go at refactoring what I saw in 
the uv8d (and other) drivers but it is still messy. What is needed is to apply 
the parser idea to the UI as well. This is all repetitive and bulky code. It 
is also the massive blob of radio specific Python2 code that needs to be 
hacked into Python3. If this moved to a parsed description, you would refactor 
all that py2/gtk code out of existence while shrinking the lines of code. The 
goal to achieve with this idea is to have the vast majority of a radio driver 
be a description of the memory and the UI that presents it. I got this idea 
from the QT framework which uses QML, an XML syntax UI description, instead of 
inline C++, GO, C code. QML abstracts all that hardwired compiled API calls 
into a description file that gets walked by the runtime.

5. My driver is also full of functions like int2freq() and freq2int()). These 
are really type conversions in compiler terms. These two named functions map a 
string representation of a frequency in MHz to a uint32 of Hz. I have some 
ideas in design that would allow these too to be described in a syntax that 
would map one type to another along with the scripted expressions to do the 
type conversion. We already have this in the memory map syntax where a u16 
describes a big-endian 16 bit unsigned and a ul16 describes a little-endian. 
Every language has type conversion rules. Chirp just has a richer set of 
domain specific types that need conversion rules. This eliminates a lot more 
Python2 code.

6. The i/o code is a mess but unavoidable. See the comments in my driver. I 
don't know what kind of dope the radio firmware coders were smoking but they 
were toking more than one more over the line when they should have been paying 
attention in data structures and comm protocols class. From my reading of the 
other drivers, other chirp devs have suffered the same reverse-engineering 
fate. Some scripting here is unavoidable. We have some of the lower level 
stuff factored out into common Python code but we could probably do more. The 
drivers dir has a lot of legacy code that was a good idea at the time but is 
now full of slight variations of duplicated themes. It could use some love.

There is a lot of work ahead in this effort. It is also an opportunity to make 
the project better. What I offer above is suggestions based on my multiple 
trips down this road. Take what you find useful and leave the rest. "Explore 
the idea in V1.0, re-write it to work in V2.0, ship V3.0".

I have mentioned code that I am working on. This has been mostly entertainment 
for myself now that I've retired. My university work eons ago was originally 
in language design etc. but my career got sidetracked into the Siren Song of 
UNIX/Linux and the Internet... This is keeping my mind functional and active 
as I (re)learn things like recursive descent parsers and code generators/
interpreters. In other words, I've scratching an itch and do not intend to dev 
a rival to chirp. I'd be happy to discuss my work with anyone but that should 
be on a side channel, not here on this dev list. And no, I haven't pushed 
anything to my github (github.com/lieb) yet. That will be a while.

Jim

-- 
Jim Lieb

Mobile: 831-295-9317
GPG Key: 79BB52C7BD0530F5

"If ease of use was the only requirement, we would all be riding tricycles"
- Douglas Engelbart 1925–2013
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20190209/96a6a7bd/attachment-0001.html