[chirp_devel] Question about banks paradigm and kenwood commercial radios.
M.Sc. Pavel Milanes Costa
Sun Dec 27 16:45:52 PST 2015
Hi to all.
As you may noticed I'm developing a new driver for commercial Kenwoods,
see details in issue 2999 here: http://chirp.danplanet.com/issues/2999
I just have completed the last milestone (full bank support, a lot of
bug fixes, a lot of validation, PEP8, and new settings) to send the
patch to the daily tree, and the code it's stable enough in my testing
bed here with 3 radios.
But the /run_tests/ script fails, digging around this I found that the
culprit is the run_test script it self in he section for testing banks
with newly created channels exactly in two places (so far):
<code>
{set memory empty}
{assign some basic data to channel}
mem_banks = model.get_memory_mappings(mem)
if len(mem_banks) != 0:
raise TestFailedError("Freshly-created memory has banks and " +
"should not", "Banks: %s"
% str(mem_banks))
{.....}
model.remove_memory_from_mapping(mem, banks[0])
reason = verify(banks[0])
if reason is None:
raise TestFailedError("Memory remains in bank after remove",
reason)
</code>
As you can see in this code segments this assume that _a channel may be
assigned to a bank *or not*_, but then here come this Kenwood commercial
radios to break this:
The Kenwood Radio Serie 60G family has a different paradigm:
*A channel must belong to a **Channel****Group (aka bank) **always*
Then, should I patch the run_test.sh script to reproduce the desired
behavior?
It's the less traumatic solution from my point of view, but the less
elegant.
My python is improving but it's not enough to recreate a bank model
class with this enforcement link incluede, if such provision is made we
need to change also the /run_tests/ script to reflect this changes.
As I'm new into this community I has to ask to the collective intelligence:
What is the correct solution to this?
Cheers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20151227/0bd69d22/attachment-0001.html
More information about the chirp_devel
mailing list