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

[George B. <geo...@gm...>]

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.
  * 4.6.x won't compile without P_THREADS - make that an overt requirement.
  * 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.

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.

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.

4. The usual lineup of bug busting and feature/model requests.

Whew!  Writing that tells me I might have bitten off more than anyone 
can chew. Prioritize away!

73 n3gb

On 6/18/25 12:28 PM, Nate Bargmann wrote:
> * On 2025 18 Jun 10:44 -0500, George Baltz wrote:
>> I don't have any problem with working just from the manual(when there is
>> one), but I don't think the FTX-1 should be the defining feature of 4.7.
>> Since we don't have any clue as to what the command set even looks like,
>> it's really hard to give a time line.  I guess I should check out the
>> feature set and see how much it shares with previous hardware.
> I did take a look at the Yaesu site earlier
> (https://www.yaesu.com/product-detail.aspx?Model=FTX-1%20Series&CatName=HF%20Transceivers/Amplifiers)
> and there isn't a CAT manual that I could find.  The operating manual
> has the menu items for changing serial rate and such but not even a
> command summary is included.
>
>> We would need some volunteers who have one to check out the daily builds and
>> give feedback.
> Certainly.
>
>> It is ready when it is ready.
> I agree.
>
> That said, perhaps we need a feature roadmap (bugs will always be
> stomped as they become visible).  I know Mike was setting various
> feature issues to various milestones but that isn't a concise list of
> items that can be checked off or progress documented.  It seemed the
> roadmap was in his mind which made it a bit inaccessible to the rest of
> us.
>
> I know you have some things to work on as does Daniele, myself, and
> likely others.  Such a list should probably be no more than six to ten
> items long.  It may be that not all items are 100% complete but I think
> we need some kind of an idea of where we're going with each release.
>
> What are everyone's thoughts on this idea?
>
> 73, Nate
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer