CHIRP

Actually, I don't mind working on this myself, depending upon the build process. Dan knows, but for the rest: I wrote DStarCom, a Win32/Linux command line program a few years ago in C++ to do what Chirp does, for the IC-91/92AD, IC-2820H, ID-1, and ID-800/880H. When Dan came out w/ Chirp, I made my program open source and ceased development, so I'm very familiar w/ reverse engineering .ICF files.

I have both Linux and Windows machines. The Linux machines are all active web DB servers, and I'd like not to do development on them. I despise the CentOS GUIs and have very little experience with them, and would not even have installed them if I could have gotten away with it. Installed is CentOS 4.4 w/ python-devel-2.3.4-14.2.i386.rpm and gnome-python2-2.6.0-3.i386.rpm. Yes, I know it's very long in the tooth ...

On Windows 7/64-bit, I have Visual Studio 2005 (and some prior editions), which is where I prefer to do development. I don't care for (yet even more on the planet) IDEs, and do my development in a straight text editor, using GNU make (on both platforms. I use CVS for source code control but can adapt. I have no idea what tools/libraries I'd need on the Windows box. My first and only exposure to Python source code is that in Chirp.

Ideally, someone would copy the ID-31 code to a new id51.py file and I would modify it. Each day I do development, I would submit patches, wait for the overnight build, and next day test it. Obviously, others downloading the nightly build should avoid using the module until it has some semblance of readiness.

From my past experience w/ Icom radios, I'd think this should be a very simple port, by updating code for file signatures, memory sizes, and valid frequency ranges. I would not plan to implement the ID-51's broadcast memory slots and banks, at least not without significant architectural guidance.

OK, I've installed the listed tools and run "python chirpw". An x64 install of Python goes nowhere, due to the GTK tool apparently only being available for x86, so that's what I settled on. I thought the tools installation would be more of a chore, so I had to ask (grin) about submitting untested changes for a new device/file. Of course, if the ID-51 code is in the ID-31 file, that would obviously be a no-no anyway.

So, I'm not sure how you are suggesting I proceed: Are you suggesting that I just modify the id31.py file, and inherit from the existing "ID31Bank" and "ID31Radio" classes? I'm not familiar with Python classes, but that seems not the best architectural form. Should the source filename remain the same?

Or, should I create from the ID-31 classes, "abstract" (in the C++) sense that are common to both radios, and have new ID-31 and ID-51 classes that inherit from those? If I do the latter, I have no way of testing the resultant code for the ID-31.

First off, I'd really like to have this discussion on the devel mailing list and not in the bug tracker, if that's okay.

Python convention does not dictate one class per file like Java, so it's perfectly fine to add another class in id31.py. It's also fine to put the subclass in a different file if you like. The former is usually done because it's easier to re-use module-scope utility functions that are common to both but aren't (for what ever reason) class methods.

My recommendation would be to copy the id31.py to id51.py and get started. If it's clear that the memory formats are very similar once you get started, then it's probably best to look at an inheritance model. If it's not strikingly similar, then perhaps a separate implementation is better since you can't test changes against the id31 driver.

In any case, lets take this to the chirp_devel mailing list for further discussion.

Thanks!

I was just going to ask on the list, about where the detailed development discussion should be for device-specific issues, so I shall "reappear" on the list (grin).

Shouldn't this be closed, so interested users can see the details of the radio was tested/added, and any further work on combining classes with the ID-31, be a separate bug/enhancement?