[chirp_users] New Python coming?
Does anyone know whether Dan is working on a new version of Python to run CHIRP on Macs? I just got the warming about the current version not working when the next release of macOS comes out. I see some 64-bit versions of Python from Apple installed on my Mac, but the installation instructions for CHIRP specifically say to use Dan's Python, which is only 32 bits.
Patty N6BIS
I know nothing about Mac but to my knowledge it shouldn't matter if it's 32 or 64 bits. The problem is Python 2 is EOL in 2020 and Chirp currently doesn't work with Python 3.
There's an issue submitted for it but it got closed without resolution. There doesn't seem to be much interest in getting it fixed.
Thanks, Richard KF5OIM
Alas, yes, it matters.
With the next release of OSX (this fall), 32-bit apps will fail. If Chirp has no plans to move to 64-bit, then it effectively is a dead-end for Mac users.
73, Jeff K4EI
On Mar 4, 2019, at 9:28 AM, Richard Shaw hobbes1069@gmail.com wrote:
I know nothing about Mac but to my knowledge it shouldn't matter if it's 32 or 64 bits. The problem is Python 2 is EOL in 2020 and Chirp currently doesn't work with Python 3.
There's an issue submitted for it but it got closed without resolution. There doesn't seem to be much interest in getting it fixed.
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 Jeff Hughes at jeffreyhughes@earthlink.net To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com
Time to break out the Wine on OSX?
On 3/4/2019 6:40 AM, Jeff Hughes wrote:
Alas, yes, it matters.
With the next release of OSX (this fall), 32-bit apps will fail. If Chirp has no plans to move to 64-bit, then it effectively is a dead-end for Mac users.
73, Jeff K4EI
On Mar 4, 2019, at 9:28 AM, Richard Shaw hobbes1069@gmail.com wrote:
I know nothing about Mac but to my knowledge it shouldn't matter if it's 32 or 64 bits. The problem is Python 2 is EOL in 2020 and Chirp currently doesn't work with Python 3.
There's an issue submitted for it but it got closed without resolution. There doesn't seem to be much interest in getting it fixed.
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 Jeff Hughes at jeffreyhughes@earthlink.net To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users This message was sent to (Peter) at ptlambert@sbcglobal.net To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com
On Mon, Mar 4, 2019 at 9:04 AM Peter ptlambert@sbcglobal.net wrote:
Time to break out the Wine on OSX?
It may be overkill for some, but one thing I did when I was still using the OEM software rather than Chirp was to run Windows in a virtual machine on my MacBook. Depending on the VM software being used, there may be an additional step or two to get the right interface cable to appear to Windows in the VM rather than be captured natively on the Mac, but it worked well.
(Newbie to this list, but long time Chirp user now... both Mac & PC)
Leo A. Notenboom (N7LEO) ---------------- https://askleo.com/about http://leonotenboom.com
What does it take to convince folks there is an interest in maintaining usability for Mac users? I for one am very interested.
Regards,
Mary Graff
________________________________ From: chirp_users-bounces@intrepid.danplanet.com on behalf of Leo Notenboom (N7LEO) leo@n7leo.com Sent: Monday, March 4, 2019 9:12 AM To: Discussion of CHIRP Subject: Re: [chirp_users] New Python coming?
On Mon, Mar 4, 2019 at 9:04 AM Peter <ptlambert@sbcglobal.netmailto:ptlambert@sbcglobal.net> wrote: Time to break out the Wine on OSX?
It may be overkill for some, but one thing I did when I was still using the OEM software rather than Chirp was to run Windows in a virtual machine on my MacBook. Depending on the VM software being used, there may be an additional step or two to get the right interface cable to appear to Windows in the VM rather than be captured natively on the Mac, but it worked well.
(Newbie to this list, but long time Chirp user now... both Mac & PC)
Leo A. Notenboom (N7LEO) ---------------- https://askleo.com/about http://leonotenboom.com
Hi
Although I am not a Mac user I would support Mac users on this issue.
Wenlock VK3YWB
Sent from my iPad
On 5 Mar 2019, at 4:21 AM, Mary Graff <megraff@gmail.commailto:megraff@gmail.com> wrote:
What does it take to convince folks there is an interest in maintaining usability for Mac users? I for one am very interested.
Regards,
Mary Graff
________________________________ From: chirp_users-bounces@intrepid.danplanet.commailto:chirp_users-bounces@intrepid.danplanet.com on behalf of Leo Notenboom (N7LEO) <leo@n7leo.commailto:leo@n7leo.com> Sent: Monday, March 4, 2019 9:12 AM To: Discussion of CHIRP Subject: Re: [chirp_users] New Python coming?
On Mon, Mar 4, 2019 at 9:04 AM Peter <ptlambert@sbcglobal.netmailto:ptlambert@sbcglobal.net> wrote: Time to break out the Wine on OSX?
It may be overkill for some, but one thing I did when I was still using the OEM software rather than Chirp was to run Windows in a virtual machine on my MacBook. Depending on the VM software being used, there may be an additional step or two to get the right interface cable to appear to Windows in the VM rather than be captured natively on the Mac, but it worked well.
(Newbie to this list, but long time Chirp user now... both Mac & PC)
Leo A. Notenboom (N7LEO) ---------------- https://askleo.com/about http://leonotenboom.com
_______________________________________________ chirp_users mailing list chirp_users@intrepid.danplanet.commailto:chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users This message was sent to Wenlock at wenlock.burton@hotmail.commailto:wenlock.burton@hotmail.com To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.commailto:chirp_users-unsubscribe@intrepid.danplanet.com
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.
On Mon, Mar 4, 2019 at 12:14 PM Wenlock Burton wenlock.burton@hotmail.com wrote:
Hi
Although I am not a Mac user I would support Mac users on this issue.
Wenlock VK3YWB
Sent from my iPad
On 5 Mar 2019, at 4:21 AM, Mary Graff megraff@gmail.com wrote:
What does it take to convince folks there is an interest in maintaining usability for Mac users? I for one am very interested.
Regards,
Mary Graff
*From:* chirp_users-bounces@intrepid.danplanet.com on behalf of Leo Notenboom (N7LEO) leo@n7leo.com *Sent:* Monday, March 4, 2019 9:12 AM *To:* Discussion of CHIRP *Subject:* Re: [chirp_users] New Python coming?
On Mon, Mar 4, 2019 at 9:04 AM Peter ptlambert@sbcglobal.net wrote:
Time to break out the Wine on OSX?
It may be overkill for some, but one thing I did when I was still using the OEM software rather than Chirp was to run Windows in a virtual machine on my MacBook. Depending on the VM software being used, there may be an additional step or two to get the right interface cable to appear to Windows in the VM rather than be captured natively on the Mac, but it worked well.
(Newbie to this list, but long time Chirp user now... both Mac & PC)
Leo A. Notenboom (N7LEO)
https://askleo.com/about http://leonotenboom.com
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users This message was sent to Wenlock at wenlock.burton@hotmail.com To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users This message was sent to Dan Clemmensen at danclemmensen@gmail.com To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com
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
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
Why run a heavy windows VM when you can use some light linux VM take up a lot less resources and have Chirp running in it's native environment?
Indeed I just installed a lubuntu VM on my work machine and installed chirp in it, took a total of 15 minutes and it was done. That way if they do not get the conversion done by the time the event takes place you at least have somewhere to run to.
On Mon, Mar 4, 2019 at 11:12 AM Leo Notenboom (N7LEO) leo@n7leo.com wrote:
On Mon, Mar 4, 2019 at 9:04 AM Peter ptlambert@sbcglobal.net wrote:
Time to break out the Wine on OSX?
It may be overkill for some, but one thing I did when I was still using the OEM software rather than Chirp was to run Windows in a virtual machine on my MacBook. Depending on the VM software being used, there may be an additional step or two to get the right interface cable to appear to Windows in the VM rather than be captured natively on the Mac, but it worked well.
(Newbie to this list, but long time Chirp user now... both Mac & PC)
Leo A. Notenboom (N7LEO)
https://askleo.com/about http://leonotenboom.com
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
I'm still confused about this conversation... Is the MacOS version somehow arch dependent? CHIRP is pure python (noarch). It shouldn't care if it's using a 32bit or 64bit version of Python....
Thanks, Richard KF5OIM
The issue is that you must use a specific version of Python, linked to on the install page, for macOS. There is no 64-bit version of it available. Starting with the next release of MacOS, 32-bit executables will no longer be supported. Hence, without an upgrade path, Chirp on Mac will be dead.
Jim K2SON
Quoting Richard Shaw hobbes1069@gmail.com:
I'm still confused about this conversation... Is the MacOS version somehow arch dependent? CHIRP is pure python (noarch). It shouldn't care if it's using a 32bit or 64bit version of Python....
Thanks, Richard KF5OIM
On Tue, Mar 5, 2019 at 9:33 AM jimmcc@mccorison.com wrote:
The issue is that you must use a specific version of Python, linked to on the install page, for macOS. There is no 64-bit version of it available. Starting with the next release of MacOS, 32-bit executables will no longer be supported. Hence, without an upgrade path, Chirp on Mac will be dead.
You don't *have* to install it that way. The runtime is just the original supported method.
The instructions indicate you can also install via Homebrew: https://chirp.danplanet.com/projects/chirp/wiki/Download#MacOS-Users brew install tdsmith/ham/chirp
Tom KD7LXL
It's been a very long time for me since I looked at Mac-/anything/, but:
Homebrew installs the stuff you need https://formulae.brew.sh/formula/ that Apple (or your Linux system) didn’t.
brew install tdsmith/ham/chirp
... just uses Homebrew to install the KK7DS Python runtime http://www.d-rats.com/download/OSX_Runtime/KK7DS_Python_Runtime_R10.pkg for Mac OSX, right? Will Homebrew still install that runtime into "the next release of MacOS", when "32-bit executables will no longer be supported"?
On 3/5/2019 11:34 AM, Tom Hayward wrote:
On Tue, Mar 5, 2019 at 9:33 AM <jimmcc@mccorison.com mailto:jimmcc@mccorison.com> wrote:
The issue is that you must use a specific version of Python, linked to on the install page, for macOS. There is no 64-bit version of it available. Starting with the next release of MacOS, 32-bit executables will no longer be supported. Hence, without an upgrade path, Chirp on Mac will be dead.You don't /have/ to install it that way. The runtime is just the original supported method.
The instructions indicate you can also install via Homebrew: https://chirp.danplanet.com/projects/chirp/wiki/Download#MacOS-Users brew install tdsmith/ham/chirp
Tom KD7LXL
To be clear, that question was rhetorical. If/when OSX no longer supports 32-bit executables, then it will need a 64-bit Python runtime, and a 64-bit CHIRP -- and the KK7DS Python runtime will also need to be updated accordingly.
On 3/5/2019 12:54 PM, Peter wrote:
It's been a very long time for me since I looked at Mac-/anything/, but:
Homebrew installs the stuff you need https://formulae.brew.sh/formula/ that Apple (or your Linux system) didn’t.
brew install tdsmith/ham/chirp
... just uses Homebrew to install the KK7DS Python runtime http://www.d-rats.com/download/OSX_Runtime/KK7DS_Python_Runtime_R10.pkg for Mac OSX, right? Will Homebrew still install that runtime into "the next release of MacOS", when "32-bit executables will no longer be supported"?
On 3/5/2019 11:34 AM, Tom Hayward wrote:
The instructions indicate you can also install via Homebrew: https://chirp.danplanet.com/projects/chirp/wiki/Download#MacOS-Users brew install tdsmith/ham/chirp
Tom KD7LXL
But Chirp is only a set of Python scripts written in plain text. Plain text is only 8 bit so why would the OS matter? It's only the Python runtime that needs to be 64 bit.
On 05 March 2019 at 16:01 Peter ptlambert@sbcglobal.net wrote:
To be clear, that question was rhetorical. If/when OSX no longer supports 32-bit executables, then it will need a 64-bit Python runtime, and a 64-bit CHIRP -- and the KK7DS Python runtime will also need to be updated accordingly.
Nigel A. Gunn, 1865 El Camino Drive, Xenia, OH 45385-1115, USA. tel +1 937 825 5032 Amateur Radio G8IFF W8IFF and GMRS WRBV701, e-mail nigel@ngunn.net www http://www.ngunn.net
For the record, e.g. http://intrepid.danplanet.com/pipermail/chirp_users/
... please ignore my previous replies below. Written with not enough caffeine and/or reading comprehension.
On 3/5/2019 1:01 PM, Peter wrote:
To be clear, that question was rhetorical. If/when OSX no longer supports 32-bit executables, then it will need a 64-bit Python runtime, and a 64-bit CHIRP -- and the KK7DS Python runtime will also need to be updated accordingly.
On 3/5/2019 12:54 PM, Peter wrote:
It's been a very long time for me since I looked at Mac-/anything/, but:
Homebrew installs the stuff you need https://formulae.brew.sh/formula/ that Apple (or your Linux system) didn’t.
brew install tdsmith/ham/chirp
... just uses Homebrew to install the KK7DS Python runtime http://www.d-rats.com/download/OSX_Runtime/KK7DS_Python_Runtime_R10.pkg for Mac OSX, right? Will Homebrew still install that runtime into "the next release of MacOS", when "32-bit executables will no longer be supported"?
Hmm... looks like HTML replies are not handled very well by the list server. Switching to text on this reply, just to see if that formats correctly in the Thread view of the message archive. Please ignore this as well...
On 3/5/2019 2:08 PM, Peter wrote:
For the record, e.g. http://intrepid.danplanet.com/pipermail/chirp_users/
... please ignore my previous replies below. Written with not enough caffeine and/or reading comprehension.
On 3/5/2019 1:01 PM, Peter wrote:
To be clear, that question was rhetorical. If/when OSX no longer supports 32-bit executables, then it will need a 64-bit Python runtime, and a 64-bit CHIRP -- and the KK7DS Python runtime will also need to be updated accordingly.
On 3/5/2019 12:54 PM, Peter wrote:
It's been a very long time for me since I looked at Mac-/anything/, but:
Homebrew installs the stuff you need https://formulae.brew.sh/formula/ that Apple (or your Linux system) didn’t.
brew install tdsmith/ham/chirp
... just uses Homebrew to install the KK7DS Python runtime http://www.d-rats.com/download/OSX_Runtime/KK7DS_Python_Runtime_R10.pkg for Mac OSX, right? Will Homebrew still install that runtime into "the next release of MacOS", when "32-bit executables will no longer be supported"?
On Tue, Mar 5, 2019 at 12:55 PM Peter ptlambert@sbcglobal.net wrote:
It's been a very long time for me since I looked at Mac-/anything/, but:
Homebrew installs the stuff you need https://formulae.brew.sh/formula/ that Apple (or your Linux system) didn’t.
brew install tdsmith/ham/chirp
... just uses Homebrew to install the KK7DS Python runtime http://www.d-rats.com/download/OSX_Runtime/KK7DS_Python_Runtime_R10.pkg for Mac OSX, right? Will Homebrew still install that runtime into "the next release of MacOS", when "32-bit executables will no longer be supported"?
Sure doesn't look like it. https://github.com/tdsmith/homebrew-ham/blob/master/chirp.rb#L9
Am I missing something you know about?
I hope you're not just guessing and spreading misinformation.
It should be simple enough to update the Chirp wiki when an incompatible macOS version is released to note that options other than the runtime should be used with the new version.
Tom
I wasn't just guessing but apparently didn't read the CHIRP page correctly. Thanks for calling me out on this and yes you are correct, the CHIRP page does indeed say:
"Homebrew http://brew.sh users can install Chirp *without *the KK7DS runtime by running |brew install tdsmith/ham/chirp| and then running |chirp| from the terminal."
Apologies to you and the group.
"It should be simple enough to update the Chirp wiki when an incompatible macOS version is released to note that options other than the runtime should be used with the new version."
Totally agree on this. Might also be helpful to update the News page to note this issue. But I am not a maintainer of the Wiki (thank G-d for that!)
(Peter)
On 3/5/2019 1:22 PM, Tom Hayward wrote:
On Tue, Mar 5, 2019 at 12:55 PM Peter <ptlambert@sbcglobal.net mailto:ptlambert@sbcglobal.net> wrote:
It's been a very long time for me since I looked at Mac-/anything/, but: Homebrew installs the stuff you need <https://formulae.brew.sh/formula/> that Apple (or your Linux system) didn’t. brew install tdsmith/ham/chirp ... just uses Homebrew to install the KK7DS Python runtime <http://www.d-rats.com/download/OSX_Runtime/KK7DS_Python_Runtime_R10.pkg> for Mac OSX, right? Will Homebrew still install that runtime into "the next release of MacOS", when "32-bit executables will no longer be supported"?Sure doesn't look like it. https://github.com/tdsmith/homebrew-ham/blob/master/chirp.rb#L9
Am I missing something you know about?
I hope you're not just guessing and spreading misinformation.
It should be simple enough to update the Chirp wiki when an incompatible macOS version is released to note that options other than the runtime should be used with the new version.
Tom
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users This message was sent to Peter KM6WXN at ptlambert@sbcglobal.net To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com
You can always run it on a Raspberry Pi, then you VNC into the pi and do Chirp. That is what I do when I am using an Android tablet and want to change a radio. Works great, yeah it is and extra box, but it was a cheap solution (I have a few pi's around the house for such things).
I would expect that somewhere in the background they are working on getting Chirp moved to Python 3 as it sort of is the light that is the train in the tunnel.
By way gentile programming folk, sure still would like to know if someone can fix the issues with the IC-92AD
On Mon, Mar 4, 2019 at 8:41 AM Jeff Hughes jeffreyhughes@earthlink.net wrote:
Alas, yes, it matters.
With the next release of OSX (this fall), 32-bit apps will fail. If Chirp has no plans to move to 64-bit, then it effectively is a dead-end for Mac users.
73, Jeff K4EI
On Mar 4, 2019, at 9:28 AM, Richard Shaw hobbes1069@gmail.com wrote:
I know nothing about Mac but to my knowledge it shouldn't matter if it's
32 or 64 bits. The problem is Python 2 is EOL in 2020 and Chirp currently doesn't work with Python 3.
There's an issue submitted for it but it got closed without resolution.
There doesn't seem to be much interest in getting it fixed.
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 Jeff Hughes at jeffreyhughes@earthlink.net To unsubscribe, send an email to
chirp_users-unsubscribe@intrepid.danplanet.com
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
I agree with Chuck. I too, run Chirp on a Raspberry Pi 3b+. This works great. I do prefer Teamviewer over VNC. I have access to my full desktop, and can configure my Wouxun 3 with no problem.
Bret Goodfellow
On Mar 4, 2019, at 10:18 PM, Chuck Hast kp4djt@gmail.com wrote:
You can always run it on a Raspberry Pi, then you VNC into the pi and do Chirp. That is what I do when I am using an Android tablet and want to change a radio. Works great, yeah it is and extra box, but it was a cheap solution (I have a few pi's around the house for such things).
I would expect that somewhere in the background they are working on getting Chirp moved to Python 3 as it sort of is the light that is the train in the tunnel.
By way gentile programming folk, sure still would like to know if someone can fix the issues with the IC-92AD
On Mon, Mar 4, 2019 at 8:41 AM Jeff Hughes <jeffreyhughes@earthlink.net mailto:jeffreyhughes@earthlink.net> wrote: Alas, yes, it matters.
With the next release of OSX (this fall), 32-bit apps will fail. If Chirp has no plans to move to 64-bit, then it effectively is a dead-end for Mac users.
73, Jeff K4EI
On Mar 4, 2019, at 9:28 AM, Richard Shaw <hobbes1069@gmail.com mailto:hobbes1069@gmail.com> wrote:
I know nothing about Mac but to my knowledge it shouldn't matter if it's 32 or 64 bits. The problem is Python 2 is EOL in 2020 and Chirp currently doesn't work with Python 3.
There's an issue submitted for it but it got closed without resolution. There doesn't seem to be much interest in getting it fixed.
Thanks, Richard KF5OIM _______________________________________________ chirp_users mailing list chirp_users@intrepid.danplanet.com mailto:chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users http://intrepid.danplanet.com/mailman/listinfo/chirp_users This message was sent to Jeff Hughes at jeffreyhughes@earthlink.net mailto:jeffreyhughes@earthlink.net To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com mailto:chirp_users-unsubscribe@intrepid.danplanet.com
chirp_users mailing list chirp_users@intrepid.danplanet.com mailto:chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users http://intrepid.danplanet.com/mailman/listinfo/chirp_users This message was sent to Chuck Hast at kp4djt@gmail.com mailto:kp4djt@gmail.com To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com mailto:chirp_users-unsubscribe@intrepid.danplanet.com
-- Chirp + Editcp + MD380Tools on Linux Celestial!!! Chuck -- KP4DJT _______________________________________________ chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users This message was sent to Deuce at deuce2ii@gmail.com To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com
I know nothing about Mac but to my knowledge it shouldn't matter if it's 32 or 64 bits. The problem is Python 2 is EOL in 2020 and Chirp currently doesn't work with Python 3.
Of course the bitness issue *does* matter because there is so much extra stuff that has to be installed on a MacOS machine to be able to run CHIRP. Yes, CHIRP is "just" python, but it uses a ton of stuff that is not Python (gtk, gdk, cairo, on and on), and all of that is compiled to a binary on all platforms. This is the same for Windows, of course, but as of yet, Microsoft still cares about backwards compatibility -- Apple knows better than all of us, of course.
There's an issue submitted for it but it got closed without resolution. There doesn't seem to be much interest in getting it fixed.
Richard, I'd sure appreciate you not spreading misinformation in such a public forum. It creates extra work for developers which have to end up spending time writing replies like these instead of working on CHIRP (like me, spending my Friday night writing this email). In general, this community is really awesome because it provides the support outlet by letting power users help the non-power users so that those of us that work on CHIRP can focus our efforts there.
A lot of work has been done on making CHIRP work for python3. Because the UI toolkit we use has gone from "the obvious choice" to "complete abandonware" during the lifetime of CHIRP, porting to python3 requires a re-write of some substantial parts of the GUI, in *addition* to the large amount of work required to account for some of the fundamental things that python decided to change between 2 and 3.
Porting to python3 is not just some minor amount of work that we just need to spend a couple afternoons doing. It's a major undertaking, and merely opening a new bug on the website is not the only thing that needs to be done. Opening multiple duplicate issues (and being unhelpful and snarky in those) is just a distraction. That's why issues have been closed as duplicates of this original one:
https://chirp.danplanet.com/issues/495
As you can see from the "Associated Revisions" section on the bottom right, there has been a lot of work done on this. Many people have showed up over the years saying they were going to do the work of porting, but nothing substantive has come from these plans over the years. Since the future of Python2 on Windows has a much (much) longer road, and since working around a distro missing python2 is so trivially easy, I have chosen to focus my time over the years on adding support for new radio drivers. There is, of course, an unending supply of *those* requests as well.
The branch for python3 has about 50% of the drivers converted. If you look at the list of supported models on the website, that's a lot of work, and a lot remains. The other half won't even *load* on python3, much less work properly. Before we can even begin to have people testing this, a lot of the core of CHIRP has to be converted (much of which has been now done) and then each driver has to be hand-converted with careful attention to detail. Then, because there are way more drivers than developers with radios, someone has to chase down someone to test each converted driver to prove that it works. The current set of drivers that are converted are ones that I've been able to test personally or know of someone who can do the testing quickly, or where someone has stepped up to convert their pet driver. From here on out, I'm going to have to create a bug for each remaining driver, get a build for each platform created with the new code and new runtime, and start having to chase people down to confirm that each one works. When I have enough pieces glued together, I will definitely be asking for help on this list to test a python3-based build.
In a week, I will be traveling to visit family for a birthday event. You can bet that I will be working on driver conversions on the plane and in the evenings instead of doing what I should be doing, and spending time with loved ones that I rarely see. I really appreciate the supportive people in this community, but those that seem to think that the volunteer development team for CHIRP *should* do something with their free/family time need to re-evaluate their priorities :)
Please rest assured that nobody is taking this situation lightly. 95% of CHIRP users are on Windows, and there is currently zero concern about the python2-based windows build being at risk. The remaining users on other platforms (and I'm one of them, btw) have many options to work around the issue in the short term. If you choose a Linux distro that has a super-aggressive deprecation policy, has already dropped python2 and provides no way to install it, then, well, you got what you asked for :)
Thanks!
--Dan
On Fri, Mar 8, 2019 at 9:56 PM Dan Smith dsmith@danplanet.com wrote:
There's an issue submitted for it but it got closed without resolution.
There doesn't seem to be much interest in getting it fixed.
Richard, I'd sure appreciate you not spreading misinformation in such a public forum. It creates extra work for developers which have to end up spending time writing replies like these instead of working on CHIRP (like me, spending my Friday night writing this email). In general, this community is really awesome because it provides the support outlet by letting power users help the non-power users so that those of us that work on CHIRP can focus our efforts there.
I can admit I was venting a bit so please accept my apologies, but I did in fact ask on two separate occasions (years apart) for help, even just hints, on how to go about adding my Alinco DR-635 and was met with zero helpful responses both times. And that was after I offered to ship my radio to a dev. That may not be everyone's experience but it was mine.
A lot of work has been done on making CHIRP work for python3. Because the UI toolkit we use has gone from "the obvious choice" to "complete abandonware" during the lifetime of CHIRP, porting to python3 requires a re-write of some substantial parts of the GUI, in *addition* to the large amount of work required to account for some of the fundamental things that python decided to change between 2 and 3.
Porting to python3 is not just some minor amount of work that we just need to spend a couple afternoons doing. It's a major undertaking, and merely opening a new bug on the website is not the only thing that needs to be done. Opening multiple duplicate issues (and being unhelpful and snarky in those) is just a distraction. That's why issues have been closed as duplicates of this original one:
Thank you for the detailed description of the problem and update, however, I wish it didn't take this thread to provoke a detailed response. I know everyone's a volunteer here (myself included, I maintain over 150 packages between Fedora and RPM Fusion). Regardless, both the issue tracker and this mailing list are how you interface with your "customers". The simple truth is that even when something is "free" people still get frustrated when they feel ignored. I try to stay on top of my bugzilla tickets but sometimes I miss one.
As you can see from the "Associated Revisions" section on the bottom right,
there has been a lot of work done on this. Many people have showed up over the years saying they were going to do the work of porting, but nothing substantive has come from these plans over the years. Since the future of Python2 on Windows has a much (much) longer road, and since working around a distro missing python2 is so trivially easy, I have chosen to focus my time over the years on adding support for new radio drivers. There is, of course, an unending supply of *those* requests as well.
I deal with a lot of upstream projects but can admit I'm not very familiar with the issue tracker chirp uses. I'll make sure I pay more attention to that section in the future.
Please rest assured that nobody is taking this situation lightly. 95% of CHIRP users are on Windows, and there is currently zero concern about the python2-based windows build being at risk. The remaining users on other platforms (and I'm one of them, btw) have many options to work around the issue in the short term. If you choose a Linux distro that has a super-aggressive deprecation policy, has already dropped python2 and provides no way to install it, then, well, you got what you asked for :)
Again, thanks for the detailed response. I know Windows has the vast majority of users, but the original EOL was earlier than 2020 and then moved out. Additionally, its 1/1/2020, not the end of 2020 which means <1 year. You may see Fedora as "aggressive" but we don't want to ship software that's not supported, especially something as important as Python.
Thanks, Richard KF5OIM
Dan, thank you for responding in this thread. Do I understand correctly that when you and the other volunteer developers finish the new Python 3-compatible version of CHIRP, the whole CHIRP environment will be 64 bit and work on macOS 10.15 and later versions?
For now, I'm going to program my radio with all the repeaters I think I might need in the areas I'm apt to travel through. That way I won't be so concerned if I want to upgrade to 10.15 before the new CHIRP comes out.
As Peter said, we all appreciate your efforts and those of the other CHIRP developers. I'm going over to your download page right now to make a donation. :-)
Patty N6BIS
Dan, thank you for responding in this thread. Do I understand correctly that when you and the other volunteer developers finish the new Python 3-compatible version of CHIRP, the whole CHIRP environment will be 64 bit and work on macOS 10.15 and later versions?
Yes, that's the expectation. As other people have said, it's technically possible to build a 64-bit Python2 environment in which to run it currently. Packaging that is not a simple task, so I'm aiming to update the MacOS runtime once the Python3 work is done (or close enough). Hopefully that will happen before Apple forcibly drops 32-bit support, but time will tell.
--Dan
"As other people have said, it's technically possible to build a 64-bit Python2 environment in which to run it currently. Packaging that is not a simple task, so I'm aiming to update the MacOS runtime once the Python3 work is done (or close enough)."
Oh goodness, yes, that seems like the most reasonable approach. Based on what people have said about the imminent demise of Python2, there's no reason to do a bunch of work to keep CHIRP Mac running on that after 10.15 comes out.
Patty N6BIS
participants (14)
-
Bret Goodfellow -
Chuck Hast -
Dan Clemmensen -
Dan Smith -
Jeff Hughes -
jimmcc＠mccorison.com -
Leo Notenboom (N7LEO) -
Mary Graff -
Nigel A. Gunn G8IFF/W8IFF -
Patty Winter -
Peter -
Richard Shaw -
Tom Hayward -
Wenlock Burton