Hello,

Attached is patch vx8-4881-1.patch. This patch lays some groundwork for adding setting support for the VX-8 (Issue #4881).

The patch simply moves all VX8DRadio class functions that I anticipate will be needed for the VX-8R up to the VX8Radio class.

None of the functions have been modified in any way and there are no changes to Chirp behaviour. I will follow this patch with a second

groundwork patch where I will modify the radio memory layout to accommodate differences between the VX-8DR/VX-8GE and VX-8R

layouts.

I have tested the attached patch will all three radio image files and all tests pass except that the Settings test continues to be skipped

for the VX-8R only.

73's,

Keith

On Mon, Jun 5, 2017 at 5:07 PM, Keith Williamson <hkwilliamson@gmail.com> wrote:

Hello,

Attached is patch "vx8-4883.patch" which resolves bug issue #4883. This
patch simply creates distinct MODELs for each of the supported VX-8
variants and removes the VARIANT constant for each of the radio classes.
The result is new Yaesu radio drop down selections for VX-8R, VX-8DR, and
VX-8GE. Also attached are test image files for each of the three radios. Running
"run-tests" for each of the radios yields all PASSED except for the VX-8R which
yields SKIPPED for the Settings test. Running a full "run-tests" shows 735 TOTAL
with 624 PASSED and 111 SKIPPED.

The tests/images file Yaesu_VX-8_R.img is replaced by identical file Yaesu_VX-8R.img
reflecting the assumed naming convention of MANUFACTURER_MODEL[_VARIANT].img
since the "R" variant was subsumed into the model.

Cheers,

Keith
KF7DRV

On Mon, Jun 5, 2017 at 1:49 PM, Dan Smith via chirp_devel <chirp_devel@intrepid.danplanet.com> wrote:
> OK cool. In that case, I'll leave the bug fix as is and make that
> the first patch. The goal of the first patch is simply to ensure that
> if you download from a VX-8R, you don't generate trace back errors
> and you don't get a Settings menu at all. In other words, ensure that
> the correct code gets called for a given variant.

Yeah, good plan.

> On an administrative note, should we just reject Issue 4881 and have
> me create a new issue with the scope of work limited to the bug fix?

It's up to you, but I don't think you need to close it. You could call
all of your patches "groundwork" for getting to 4881, or open a new bug
for the correctness (i.e. fixing the tracebacks) and then any refactors
are mostly groundwork for the end goal of settings support for the base
driver.

But, your call as you're doing the work. I just granted you permissions
to monkey with the issues, so you can close/create/link as you see fit.

Thanks!

--Dan

_______________________________________________
chirp_devel mailing list
chirp_devel@intrepid.danplanet.com
http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers