Re: [Hamlib-developer] Yaesu FTX-1--target for 4.7.0?

[Mikael N. <mik...@fa...>]

Hi folks!

There is some good planning here, great to see Hamlib going forward!

I'm trying to release some (long overdue) amplifier API extensions + backends during the summer, so I'd optimally like to get them to 5.0 + have some feedback. Stay tuned for a bit larger PR (once I get the Expert AMP backend fully tested).

We're (me and another developer from OH land) also aiming to get a larger Hamlib development project going after the summer (likely in September if all goes well) where we'd create a Hamlib backend testing framework (fully complementing the pytest stuff, which is on a higher level) + a lot of work to support network/SDR-based rigs. Let's see if we get the full support so we can spend the time required for it. We will release more info on this project as soon as we can! As a backup (even if the project didn't get all the support we need), we'll try to craft and release plans / APIs for future improvements we've had in mind. This is all 5.0 or 5.x work, of course.

Some questions about releases/schedule:

- Do you have any timeline in mind for a 5.0 release? Early next year? "When it is ready"?
- Do you see any 4.x releases preparing for the larger changes before it?

Also, please see my additional comments below.

On Fri, Jun 20, 2025, at 02:41, Nate Bargmann wrote:
> Good list, George.
>
> * On 2025 19 Jun 14:04 -0500, George Baltz wrote:
>> I do have a couple of things I would like to see in 5.0, and I've been doing
>> some reading and doodling about them; nothing concrete yet, but here's my
>> blue-sky ideas:
>> 
>> 1. Update the requirements for building/running/developing with Hamlib.
>> 
>>  * ANSI C is 35 years old - no need to support K&R C anymore.  I'd like
>>    to see -std=c17 at least, but -std=c11 would still be better than c89.
>
> I think that should probably a 5.0.0 target.  C11 would likely be
> safest, even though these days C17 should be supported, though likely
> only really well on distros less than five years old, I would guess.
>
> I'm not sure what C standard MinGW/MSYS supports.

Fully agree at least with C11. We need more modern features in the code.

>
>>  * 4.6.x won't compile without P_THREADS - make that an overt requirement.
>
> This should be a 4.7.0 target.

+1 - I don't think we can support any of the more advanced features in Hamlib without using threads. It's just a fact we can't really get around anymore. Use of threads will likely only increase when going forward with any recent network/SDR rig support with audio or I/Q data streaming. That said, there's a lot of internal stuff (including pthread mutexes) that should not get exposed to "end-users" in rig.h (directly related to the goal below).

>
>>  * Split include/hamlib/rig.h so including rig.h gives the app access
>>    to the whole API, but none of the structures - and guarantee this is
>>    stable. Allows app developers to not worry about Hamlib internal
>>    changes unless they explicitly need/include the structure definitions.
>
> I would say this is a 5.0.0 target as the API is being changed
> considerably and the promise is that such a change is signaled by
> advancing the major version number.

Also agree with this one. 5.0 should make a clearer distinction between public and private structs.

>
>> 2. Follow up on the cache move by breaking out the port and state
>> structures.  Now I'm not sure we can make things transparent across
>> 4.7<->5.0 - having cache inside state inside rig throws a monkey wrench into
>> what I had hoped to do.
>
> Your decision.  I get the sense you're leaning toward the 5.0.0 target.

+1 - thanks for working on this!

>
>> 3. Regarding thread safety; the answer could be 'yes', 'no', or 'which one?'
>> There at least 4 different locking mechanisms in Hamlib.  None cover
>> everything.  Current code(rig_lock()) fixes interference between some API
>> calls and morse_data_handler() so CW works, and I think the Icom code
>> handles their flavor of automatic updates.  The multicast stuff I haven't
>> looked into, and the original morse_mutex() could now be replaced by a
>> simple flag. And none of these look like a good candidate for the whole
>> shebang.
>
> This sounds like something that will be ongoing over the next several
> releases and maybe not something easily confined to a single release
> target.

I think there should be some form of thread-safety, so that Hamlib cannot "break itself" with the current multithreaded features it has. I'm all for simplifying / streamlining locking/mutexes, however.

>
>> 4. The usual lineup of bug busting and feature/model requests.
>
> +1
>
>> Whew!  Writing that tells me I might have bitten off more than anyone can
>> chew. Prioritize away!
>
> This is exactly why I want there to be no more than two or three
> priority items per developer for each release.  It frees up the mind
> from feeling overwhelmed and trying to do everything at once.  Over the
> past five years I observed Mike seemingly swamping himself in just this
> manner and we had much too long time elapse from the last 4.5.x release
> to 4.6.  Of course that time included his ALS fight so that likely was a
> huge factor as well.

+1 -> more coordinated/targeted fixes by release will help a lot!

>
> If I can help establish a process whereby we take smaller bites and make
> more frequent releases, that is what I am hoping to achieve.
>
> 73, Nate
>

73,
Mikael OH3BHX