if _mem.freq_rx == _mem.freq_tx:
mem.duplex = ""
- mem.freq = _mem.freq_rx
+ mem.freq = int(_mem.freq_rx)
elif _mem.freq_rx + _freq_offset == _mem.freq_tx:
mem.duplex = "+"
- mem.freq = _mem.freq_rx
+ mem.freq = int(_mem.freq_rx)
mem.offset = _freq_offset
elif _mem.freq_rx - _freq_offset == _mem.freq_tx:
mem.duplex = "-"
- mem.freq = _mem.freq_rx
+ mem.freq = int(_mem.freq_rx)
mem.offset = _freq_offset
else:
mem.duplex = "split"
- mem.freq = _mem.freq_rx
- mem.offset = _mem.freq_tx
+ mem.freq = int(_mem.freq_rx)
+ mem.offset = int(_mem.freq_tx)
On Nov 11, 2024, at 14:36, Dan Smith via Developers <developers@lists.chirpmyradio.com> wrote:I’m (still) working on support for the Icom IC-F521/F621. Now I have a traceback that has me stumped. I get the error when I try to copy a memory to the clipboard. I’m running Chirp on Ubuntu 24.04.1 LTS (noble).
Traceback (most recent call last):
File "/home/joseph/Devl/chirp/chirp/wxui/memedit.py", line 1716, in <lambda>
self.Bind(wx.EVT_MENU, lambda e: self.cb_copy(cut=False), copy_item)
^^^^^^^^^^^^^^^^^^^^^^^
File "/home/joseph/Devl/chirp/chirp/wxui/memedit.py", line 1953, in cb_copy
self.cb_copy_data(self.cb_copy_getdata(cut=cut))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/joseph/Devl/chirp/chirp/wxui/memedit.py", line 1936, in cb_copy_getdata
memdata.SetData(pickle.dumps(payload))
^^^^^^^^^^^^^^^^^^^^^
AttributeError: Can't pickle local object 'Processor.do_bitfield.<locals>.bitDE'
What might I have done (or failed to do) in my driver that has memedit so upset?
I did look through memedit.py and read about the pickle module (even played with making variables global) but no flash of enlightenment.
It's hard to guess about this with just a stack trace and no code. However, it's trying to serialize (pickle) all the memories it pulled from the driver according to the selected rows and it's failing to do that because there's something unserializable in there. Looks like you're including a bitDE from bitwise (i.e. some of the low-level memory objects) in a Memory object that you're returning. Since those *directly* reference a chunk of the memory map of a radio, it's definitely not cool to let that escape from your driver. Hard to say much more than that without code and a sample image though.Second question.
Which Icom drivers make good examples? I’m using ic2820.py only because I have an IC-2820 radio.
The ic2820 driver is almost one of the oldest drivers in the tree. I certainly reference it a lot myself because it was, at one point, the most complete example available. Not sure that's really true or not anymore, but I wouldn't say it's a bad example.
--Dan
_______________________________________________
Developers mailing list -- developers@lists.chirpmyradio.com
To unsubscribe send an email to developers-leave@lists.chirpmyradio.com