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