[chirp_devel] The End of Days - #495

[Zhaofeng Li]

Amazing work! I actually played with the codebase a little bit, and
implemented basic PyGObject port on Python 2 (the app starts, and
basic memory editing functionality is intact). I think Python 3 +
PyGObject will be the way to go, but porting to PyGObject will gain us
more than the 2to3 conversion.

Zhaofeng Li

On Fri, Feb 8, 2019 at 5:37 PM Dan Smith via chirp_devel
<chirp_devel at intrepid.danplanet.com> wrote:
>
> > I would like to help with the Python 3 effort, but I'm still a newbie. I think I'm within a week of submitting my new ft4.py driver, and I would like to at least make sure it imports in Python 3. Is there a trivial way to do this? Do I need to do a full-up download of the "py3" branch? If I do the full download, Can I use your ID-800 driver as an example of the changes to make?
>
> Ah, sweet, this will be a good exercise!
>
> Right now, the ID800 driver on the py3 branch works via all the emulation I've got in place. I will try to convert it to be byte-native in the next couple of days and then it will be a reasonable model to follow. All icom radios use the same cloning protocol, so all of that is confined to the icf.py file, so the changes will be spread across that and the actual driver file. That may or may not be similar for yours depending on how you have done it, but the principles will be the same.
>
> > Because the FT-4 is (apparently) completely different than all earlier-generation Yeasu HTs, my driver has very little in common with any other driver. It passes the unit test and I supports all known features of the FT-4, but does not yet support the the FT-65.
>
> Cool, you may win the distinction of landing the first py3 native driver in CHIRP :)
>
> > I use Linux (specifically, Gentoo) so I have a dual Python 2-Python 3 environment.
> >
> > For testing: I know we really need to test with real radios, but almost all testing can be done using image files first, right?
> > In addition, I suspect most radios' serial port comms can be emulated. Since a lot of radios share protocols even when the actual images are very different, the number of emulators would be a good deal smaller than the number of drivers. For example tthe FT-4 serial protocol is identical to the th9000.py and anytone_ht.py protocols event though the images bear no apparent relationship to each other. If you wish I can write an emulator for this protocol. The test suite would use serial pseudo-ports to connect the emulator to CHIRP, and we would need a simple config system to pick the proper emulator for each type of image file.  (I may be a python/CHIRP/Ham newbie, but I've been a data comms developer for 40 years.)
>
> Yeah, we could write simulators for each of the drivers (or the subset of *protocols*), and those would likely help us in this particular case. However, many (many) radios are insanely sensitive to the timing of the conversation, which makes a simulator not that useful for actually proving that it *actually* works. There are some dumb tests in run_tests.py that simulate a broken serial connection for the purposes of testing the way drivers handle error conditions while cloning, which is a simulator of sorts. We could do a similar thing to test a py3 byte conversion on a model, but that's still a lot of work.
>
> --Dan
>
> _______________________________________________
> chirp_devel mailing list
> chirp_devel at intrepid.danplanet.com
> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
> Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers