[chirp_devel] Commercial Kenwoods & run_test FAIL: it has a different bank model paradigm.
M.Sc. Pavel Milanes Costa
Sun Dec 27 16:25:00 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_test.sh 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 Serie 60G family has a enforcement to every channel:*it hast
belong to a bank (or groups in kenwood speaking) *
Then, should I patch the run_test 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 between, if such provision is made we
need to change run_test.sh 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/3a1d3199/attachment-0001.html
More information about the chirp_devel
mailing list