Bug #10171
closed"'NoneType' object is not iterable" on settings tab with a Yaesu VX-6
0%
Description
When navigating to the settings tab in a VX-6 image, CHIRP pops up a dialog saying, "'NoneType' object is not iterable" and leaves the tab empty. Here are the exceptions displayed in the terminal:
Traceback (most recent call last):
File "/home/dominickpastore/chirp/chirp/drivers/vx6.py", line 823, in get_settings
return self._get_settings()
File "/home/dominickpastore/chirp/chirp/drivers/vx6.py", line 640, in _get_settings
val = RadioSettingValueString(0, 16,
File "/home/dominickpastore/chirp/chirp/settings.py", line 215, in __init__
self.set_value(current)
File "/home/dominickpastore/chirp/chirp/settings.py", line 229, in set_value
raise InvalidValueError("Value contains invalid " +
chirp.settings.InvalidValueError: Value contains invalid character `'
ERROR: Context raised unexpected_exception
Traceback (most recent call last):
File "/home/dominickpastore/chirp/chirp/wxui/settingsedit.py", line 49, in _initialize
self._load_settings()
File "/home/dominickpastore/chirp/chirp/wxui/settingsedit.py", line 59, in _load_settings
for group in self._settings:
TypeError: 'NoneType' object is not iterable
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/wx/core.py", line 3285, in <lambda>
lambda event: event.callable(*event.args, **event.kw) )
File "/home/dominickpastore/chirp/chirp/wxui/settingsedit.py", line 49, in _initialize
self._load_settings()
File "/home/dominickpastore/chirp/chirp/wxui/settingsedit.py", line 59, in _load_settings
for group in self._settings:
TypeError: 'NoneType' object is not iterable
This is on the py3 branch, but a similar exception happens on the py2 build:
Traceback (most recent call last):
File "/app/lib/python2.7/site-packages/chirp/drivers/vx6.py", line 823, in get_settings
return self._get_settings()
File "/app/lib/python2.7/site-packages/chirp/drivers/vx6.py", line 642, in _get_settings
_settings.arts_cwid_alpha))
File "/app/lib/python2.7/site-packages/chirp/settings.py", line 212, in __init__
self.set_value(current)
File "/app/lib/python2.7/site-packages/chirp/settings.py", line 227, in set_value
"character `%s'" % char)
InvalidValueError: Value contains invalid character `'
Traceback (most recent call last):
File "/app/lib/python2.7/site-packages/chirp/ui/settingsedit.py", line 220, in _build_ui
raise Exception("Invalid Radio Settings")
Exception: Invalid Radio Settings
The image causing this issue is attached. This may in fact be my own fault. I used this radio to reverse engineer some of the settings that were missing from CHIRP, and I may have accidentally introduced a bit of corruption in the process. (I also bring it up because you may find some weird things that a user wouldn't normally do with their radio in that image.)
I did try opening an older image and the settings page seemed to work fine.
This was on Ubuntu 20.04 with the py3 branch at commit d1a22929 and the daily-20221207 py2 build.
Files
Updated by Dominick Pastore over 1 year ago
Looking into this a it more, the problem seems to be the CHARSET list in the VX-6 driver:
CHARSET = ["%i" % int(x) for x in range(10)] + \
[chr(x) for x in range(ord("A"), ord("Z")+1)] + \
list(" +-/\x00[]__" + ("\x00" * 9) + "$%%\x00**.|=\\\x00@") + \
list("\x00" * 100)
From what I can tell, the last 100 nulls are not in the radio's character set, but all the nulls on the third line are (though many are not recognizable ASCII characters). My radio's current setting for the ARTS CW ID has the symbol between the / and the [ in it, which looks vaguely like a question mark on the radio. When that symbol decodes as the null character, set_value does not like it.
Updated by Dan Smith over 1 year ago
Yeah, so we can fix it to just discard characters it doesn't know about, which is easiest. Otherwise, someone needs to decode the character set, which is, of course, not super easy. Some radios actually list all the characters in the manual which makes it much easier to do, but not Yaesu.
Since this is broken on py2 as well, we should probably fix it there and let it sync over to the py3 branch, to avoid more difference between then two than necessary. I can work on this with your image if you want, but if you're already doing it I'll hold off.
Updated by Dominick Pastore over 1 year ago
- File PXL_20221212_173906888.jpg PXL_20221212_173906888.jpg added
- File PXL_20221212_174106876.MP.jpg PXL_20221212_174106876.MP.jpg added
I can decode the character set this evening. I did it some time ago, and I can't find where I put the results but I can do it again without too much trouble. It seems like it should be an easy fix once that's done, so I'm happy to do that.
My only question would be what to do with the characters that don't have clear ASCII equivalents (e.g. see photos). Is there a recommended way to handle those?
Updated by Dan Smith over 1 year ago
Typically we have no option other than to filter them out for display, which of course means that if the value is changed, we'll remove it from the radio. No particularly good options really...
Thanks for working on this!
Updated by Dominick Pastore over 1 year ago
I've created PR 245 and 246 for this for the py2 and py3 branches, respectively, but re-reading your earlier update, will the py2 commit sync to py3 on its own somehow? If so, it sounds like 246 can be closed.
Let me know if there are any problems. Thanks!
Updated by Dan Smith over 1 year ago
- Status changed from New to Closed
- Target version set to chirp-legacy
Yep, it will and I'll get it into py3 in a bit. Thanks very much for considering both branches :)
Fixed in d6555b4