Richard,

I love Chirp, and I use it to program some of the Chinese radios, I also use it to program a IC-92AD I have, indeed

that radio brought me to Chirp years ago. Back then it seemed like it worked great with the radio but now it

sort of hangs saying it is still loading at memory 849 or something like that.

I also have a ID-5100, that I would love to be able to address with Chirp rather than the joke that is icom software,

I have offered to loan the radio several times, but no avail. It seems that people rush to support the Chinese

boxen, but we cannot get the radio that I believe started it all (IC-92) working correctly and no one will take the

time to even take me up on my offer of a loan to try to get the ID-5100 on the list of radios.

With the issue with Python looming, of course that will hoover of resources and time, indeed if someone would

tell me some places to look I might be able to go in and plunck around the code my self, but no guidance is a

disaster in waiting.

Still, love the application and use it about as much as anything but the programming for my DMR radios, THAT

gets used a lot...

On Mon, Mar 4, 2019 at 9:16 PM Richard Shaw <hobbes1069@gmail.com> wrote:

On Mon, Mar 4, 2019 at 4:43 PM Dan Clemmensen <danclemmensen@gmail.com> wrote:
Conversion to Python3 is a big issue, for Chirp and for many other projects. A main underlying problem is that CHIRP depends on underlying projects that have not converted. Nevertheless, The main CHIRP developer is in fact working on a conversion. In addition to the CHIRP core, there are also more than 100 separate driver modules to support different radios, and it all must be converted. The developers of Python in their infinite wisdom made changes that affect the semantics of many Python constructs, so all of that stuff needs to be checked, more or less by hand. The average driver is more that 500 lines of code, so there are more than 500,000 lines of code to be checked just in the drivers. Perhaps the biggest changes in Python affect the way strings are handled: Python 3 makes a distinction between text strings and byte strings that did not exist in Python 2. But guess what? serial I/O depends very heavily on the precise semantics of the manipulation of byte strings, and each driver has its own unique serial I/O code. I am a very recent addition to the CHIRP development community, so the best I could do initially was to make sure that the driver that I wrote is compatible with both Python2 and Python 3.

Thank you for making an effort to provide a detailed description. Part of my annoyance is bugs are often closed with terse reasoning or just flat out being ignored. I maintain Chirp on Fedora because I run linux at home so it's really my only option but I haven't found a very welcoming upstream in years past. I've volunteered to loan radios (my Alinco DR-635 which I WISH I could program in chirp... No response.) I've asked for tips on how to update the Alinco driver. I have some experience with serial communications so I'm not starting from zero... no response.

Hence my frustrations...

Thanks,
Richard
KF5OIM
_______________________________________________
chirp_users mailing list
chirp_users@intrepid.danplanet.com
http://intrepid.danplanet.com/mailman/listinfo/chirp_users
This message was sent to Chuck Hast at kp4djt@gmail.com
To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com