[chirp_devel] FT2D error traceback
Here’s a chirp* run with a “bad” FT2D image. I’ve elided most of the "Bandplan … duplicates" warnings. The traceback occurs after loading the image, navigating to the Banks tab, when I try to click on a box in the second bank, which the radio’s user had defined with an immutable special memory location. The UI gives a modal error dialog “Failed to add # to mapping: list index out of range”, where # is the memory “Loc” I touched. The UI will never add or delete any instance in the selected bank thereafter. If one never touches a checkbox in the bank, all is OK. Chirp does not crash, but it won’t allow access to that memory bank. I believe it also does not change the entry in the bank location, so it’s not “corrupting” the memory image.
When I look at the browser, the entry for the “bad” bank is 0x1801, which is clearly too large for a 1000-entry memory. I’ve determined that the “18” bits are actually flags defining which immutable address to use for that location. They are [usually?] not in the memory image that chirp can access.
The easy changes will special-case those entries and prevent the UI from ever seeing them. I will also add the non-immutable special memory entries so that they can be displayed and changed in memedit.py. I do not think that the radio will allow those entries to be included in a bank, so they should have no effect on bankedit.py. If I could figure out the syntax, it’d probably be best to make the image actually acknowledge the top bit as an “unused” flag,
Since I do not have FT1D, I cannot test these changes on that radio. By reading the Yaesu manuals, it’s clear to me that the FT1D also has the problem that a radio can put a special memory into a bank reference, and that will cause FT1D users the same problem as an FT2D. The FTM-3200D also inherits from the FT1D. That will also need to be checked, although that radio shouldn’t be capable of getting into the special memory situation (according to its manual.)
$ chirp 2017-12-03 14:26:37.923 python2.7[17267:1313234] *** WARNING: Method userSpaceScaleFactor in class NSView is deprecated on 10.7 and later. It should not be used in new applications. Use convertRectToBacking: instead. /usr/local/Cellar/chirp/20170714/libexec/lib/python2.7/site-packages/chirp/ui/mainapp.py:1971: Warning: invalid cast from 'GtkMenuBar' to 'GtkWindow' macapp.set_menu_bar(menu_bar) /usr/local/Cellar/chirp/20170714/libexec/lib/python2.7/site-packages/chirp/ui/mainapp.py:1971: GtkWarning: gtk_window_add_accel_group: assertion 'GTK_IS_WINDOW (window)' failed macapp.set_menu_bar(menu_bar) WARNING: Bandplan North American Band Plan has duplicates [1800000-2000000 160 Meter Band simplex , 1800000-2000000 160 Meter Band simplex mode: CW ] … WARNING: Bandplan North American Band Plan has duplicates [29300000-29510000 Satellite downlink simplex , 29300000-29510000 Satellite Downlinks simplex ] /usr/local/Cellar/chirp/20170714/libexec/lib/python2.7/site-packages/chirp/ui/settingsedit.py:126: Warning: value "0" of type 'guint' is invalid or out of range for property 'n-rows' of type 'guint' table = gtk.Table(len(group), 2, False) ERROR: Exception running RadioJob: list index out of range ERROR: -- Exception: -- ERROR: Traceback (most recent call last): File "/usr/local/Cellar/chirp/20170714/libexec/lib/python2.7/site-packages/chirp/ui/common.py", line 116, in _execute result = func(*self.args, **self.kwargs) File "/usr/local/Cellar/chirp/20170714/libexec/lib/python2.7/site-packages/chirp/drivers/ft1d.py", line 503, in add_memory_to_mapping self.update_vfo() File "/usr/local/Cellar/chirp/20170714/libexec/lib/python2.7/site-packages/chirp/drivers/ft1d.py", line 452, in update_vfo if not flags[channel].nosubvfo: File "/usr/local/Cellar/chirp/20170714/libexec/lib/python2.7/site-packages/chirp/bitwise.py", line 208, in __getitem__ return self.__items[index] IndexError: list index out of range
ERROR: ---------------- ERROR: Job Args: (Memory[6], FT2Bank-1) ERROR: Job KWArgs: {} ERROR: Job Called from: File "/usr/local/bin/chirp", line 143, in <module> gtk.main() File "/usr/local/Cellar/chirp/20170714/libexec/lib/python2.7/site-packages/chirp/ui/bankedit.py", line 229, in do_mapping_adjustment job = common.RadioJob(do_mapping_index, fn, memory, mapping)
* I used the latest chirp from “brew” for Macintosh: CHIRP daily-20170714 on Darwin XXXXX 17.2.0 Darwin Kernel Version 17.2.0: Fri Sep 29 18:27:05 PDT 2017; root:xnu-4570.20.62~3/RELEASE_X86_64 x86_64 (Python 2.7.14)
Here’s a chirp* run with a “bad” FT2D image. I’ve elided most of the "Bandplan … duplicates" warnings. The traceback occurs after loading the image, navigating to the Banks tab, when I try to click on a box in the second bank, which the radio’s user had defined with an immutable special memory location. The UI gives a modal error dialog “Failed to add # to mapping: list index out of range”, where # is the memory “Loc” I touched. The UI will never add or delete any instance in the selected bank thereafter. If one never touches a checkbox in the bank, all is OK. Chirp does not crash, but it won’t allow access to that memory bank. I believe it also does not change the entry in the bank location, so it’s not “corrupting” the memory image.
Okay, well, the error you show shouldn’t screw the UI anyway, so maybe there is yet another bug.
Can you send me an image (privately is fine) that has a bank with a special memory mapped into it so I can reproduce this?
The easy changes will special-case those entries and prevent the UI from ever seeing them. I will also add the non-immutable special memory entries so that they can be displayed and changed in memedit.py. I do not think that the radio will allow those entries to be included in a bank, so they should have no effect on bankedit.py. If I could figure out the syntax, it’d probably be best to make the image actually acknowledge the top bit as an “unused” flag,
Um, I thought you were saying that the radio _did_ allow these special channels to be in a bank, and that doing so on the radio itself is what would confuse chirp when it tries to interpret the image? Are there two type of special memories here that I’m missing?
- I used the latest chirp from “brew” for Macintosh:
CHIRP daily-20170714 on Darwin XXXXX 17.2.0 Darwin Kernel Version 17.2.0: Fri Sep 29 18:27:05 PDT 2017; root:xnu-4570.20.62~3/RELEASE_X86_64 x86_64 (Python 2.7.14)
In order to submit changes, you’ll need to pull down the source tree and generate patches from that, FWIW. Also, if I post things for you to try, you’ll want to apply them to the real source tree for testing. If brew has installed all the deps you need to run it the way you show in your log, then you can probably just do “./chirpw” from the root of the source tree without much trouble.
—Dan
participants (2)
-
Dan Smith -
NNN Wx