Hi again,

Attached is patch "vx8-4881-2.patch". This patch modifies the radio memory layout to accommodate differences between the
VX-8DR/VX-8GE and VX-8R layouts. (Issue #4881).

The patch divides the original memobj aprs struct into a shorter aprs struct, followed by an aprs_msg_macro[] struct, and then an
aprs2 struct. The aprs_msg_macro struct and aprs2 struct are parameterized differently in the _mem_params of the VX8Radio class
and the VX8DRadio class. All memory element dereferences that were formerly to the aprs struct but are now in either the aprs2 struct
or aprs_msg_macro struct have been updated.

As with the prior patch, there are no changes to Chirp behaviour. At this point all of the necessary groundwork has been laid to add
Settings support for the stock VX-8R. The patch for that will follow.

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 Tue, Jun 6, 2017 at 10:31 AM, Keith Williamson <hkwilliamson@gmail.com> wrote:
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!