I knew this patch was too big. I was hoping you would give me one freebie before I started in with actual maintenance-style patches. :-)
I'll try to be good from now on.
Heh, thanks :)
Some of the data structure issues you see are in fact leftovers, and I have already made changes. When I originally coded the tone stuff, I had convinced myself that there was no way to create a true two-way mapping. In fact there is not (because the UI cannot handle the values "none" for the tones, but the radio requires this value). However, I now know that the unit tests will forgive you if you fail to return the same tone the UI supplies in those circumstances. I will re-work the code.
Okay, if the re-work comes after a big last-freebie version that's okay, I would just like it to be cleaned up in the tree at some point before we lose context, you stop paying attention to it daily, etc.
About those multiple patches: Is it acceptable to send a patch and then send a second patch (and third...) before the first one becomes part of the daily build?
Yeah, if you send them as a stack with patchbomb, it's clear that they're supposed to be applied in a specific order. If you don't, then just make sure to call out the order somehow. Queueing up multiple is fine, but I'd prefer if they weren't like "change thing, okay nevermind change it like this, okay that was dumb, now it works" kind of thing. If they really build on each other, then by all means.
OK. I will start from what is in your current repository (i.e., the initial ft4.py) and make isolated incremental changes that cumulatively will reach my current working file. Patches:
- whitespace, spelling, other non-code changes
- re-arrangement
- through N): incremental fixups, each addressing a specific issue.
This would be great thanks. So just to be clear you're doing that for this patch or just in the future?
For the py3 upload: I only realized that I had failed to test this after I submitted the initial build. I had tested it earlier before is consolidated my py2 and py3 code, and I overlooked the fact that the unit tests don't test the serial code, which of course is blatantly obvious in retrospect.
That's fine. I was worried maybe it worked _only_ on py2. It's not a requirement to be working on py3 yet, so that's totally cool.
As penance, I'm going to write that emulator. As you said earlier, emulators cannot do a valid timing test for those drivers that have timing sensitivities, but this particular protocol does not have a timing issue.
Cool, I wrote one for icf-based drivers here in the py3 tree if you want to look at it:
https://chirp.danplanet.com/projects/chirp/repository/revisions/py3/entry/te...
It's not beautiful, but it's something. I haven't ported all the test cleanups from the py3 branch over to default yet, so maybe just doing that emulator in a patch for py3 for now would be good and we'll get it in default when we merge?
About patchbomb: I tried to set up to send patches directly to your smtp server by following your directions, but my system refused because it could not negotiate a compatible secure protocol.
Hmm, okay, it worked for me last time I tried it. Maybe contact me off-list with the details of the failure and we can try to figure out if the hangup is work-around-able?
Thanks!
--Dan