hamlib-developer Mailing List for Ham Radio Control Libraries (Page 13)
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
hamlib-developer — hamlib developers forum
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(24) |
Oct
(16) |
Nov
(8) |
Dec
(9) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(49) |
Feb
(17) |
Mar
(3) |
Apr
(7) |
May
(3) |
Jun
(1) |
Jul
(2) |
Aug
(8) |
Sep
(18) |
Oct
(15) |
Nov
(15) |
Dec
(26) |
| 2002 |
Jan
(46) |
Feb
(14) |
Mar
(44) |
Apr
(3) |
May
(6) |
Jun
(47) |
Jul
(40) |
Aug
(14) |
Sep
(59) |
Oct
(39) |
Nov
(58) |
Dec
(76) |
| 2003 |
Jan
(82) |
Feb
(66) |
Mar
(37) |
Apr
(56) |
May
(34) |
Jun
(19) |
Jul
(23) |
Aug
(55) |
Sep
(31) |
Oct
(40) |
Nov
(21) |
Dec
(60) |
| 2004 |
Jan
(57) |
Feb
(110) |
Mar
(41) |
Apr
(17) |
May
(18) |
Jun
(19) |
Jul
(18) |
Aug
(5) |
Sep
(31) |
Oct
(16) |
Nov
(26) |
Dec
(36) |
| 2005 |
Jan
(69) |
Feb
(26) |
Mar
(62) |
Apr
(120) |
May
(31) |
Jun
(47) |
Jul
(7) |
Aug
(27) |
Sep
(4) |
Oct
(9) |
Nov
(26) |
Dec
(21) |
| 2006 |
Jan
(13) |
Feb
(26) |
Mar
(38) |
Apr
(31) |
May
(17) |
Jun
(6) |
Jul
(23) |
Aug
(6) |
Sep
(38) |
Oct
(87) |
Nov
(49) |
Dec
(49) |
| 2007 |
Jan
(52) |
Feb
(19) |
Mar
(20) |
Apr
(5) |
May
(25) |
Jun
(15) |
Jul
(49) |
Aug
(43) |
Sep
(21) |
Oct
(21) |
Nov
(27) |
Dec
(10) |
| 2008 |
Jan
(23) |
Feb
(20) |
Mar
(25) |
Apr
(39) |
May
(36) |
Jun
(17) |
Jul
(10) |
Aug
(18) |
Sep
(44) |
Oct
(88) |
Nov
(60) |
Dec
(65) |
| 2009 |
Jan
(99) |
Feb
(91) |
Mar
(49) |
Apr
(34) |
May
(52) |
Jun
(9) |
Jul
(11) |
Aug
(4) |
Sep
(41) |
Oct
(16) |
Nov
(51) |
Dec
(71) |
| 2010 |
Jan
(43) |
Feb
(79) |
Mar
(59) |
Apr
(55) |
May
(51) |
Jun
(38) |
Jul
(38) |
Aug
(61) |
Sep
(53) |
Oct
(46) |
Nov
(43) |
Dec
(41) |
| 2011 |
Jan
(74) |
Feb
(96) |
Mar
(41) |
Apr
(42) |
May
(61) |
Jun
(66) |
Jul
(50) |
Aug
(40) |
Sep
(11) |
Oct
(30) |
Nov
(21) |
Dec
(45) |
| 2012 |
Jan
(59) |
Feb
(4) |
Mar
(52) |
Apr
(19) |
May
(62) |
Jun
(46) |
Jul
(61) |
Aug
(18) |
Sep
(21) |
Oct
(25) |
Nov
(66) |
Dec
(41) |
| 2013 |
Jan
(36) |
Feb
(64) |
Mar
(37) |
Apr
(24) |
May
(74) |
Jun
(40) |
Jul
(43) |
Aug
(34) |
Sep
(65) |
Oct
(52) |
Nov
(23) |
Dec
(20) |
| 2014 |
Jan
(18) |
Feb
(29) |
Mar
(13) |
Apr
(41) |
May
(10) |
Jun
(12) |
Jul
(16) |
Aug
(25) |
Sep
(20) |
Oct
(56) |
Nov
(43) |
Dec
(61) |
| 2015 |
Jan
(36) |
Feb
(38) |
Mar
(92) |
Apr
(42) |
May
(13) |
Jun
(19) |
Jul
(18) |
Aug
(22) |
Sep
(21) |
Oct
(2) |
Nov
(49) |
Dec
(22) |
| 2016 |
Jan
(55) |
Feb
(144) |
Mar
(40) |
Apr
(98) |
May
(61) |
Jun
(36) |
Jul
(16) |
Aug
(33) |
Sep
(59) |
Oct
(16) |
Nov
(37) |
Dec
(32) |
| 2017 |
Jan
(70) |
Feb
(71) |
Mar
(14) |
Apr
(43) |
May
(31) |
Jun
(24) |
Jul
(38) |
Aug
(54) |
Sep
(24) |
Oct
(15) |
Nov
(26) |
Dec
(27) |
| 2018 |
Jan
(22) |
Feb
(24) |
Mar
(109) |
Apr
(12) |
May
(46) |
Jun
(23) |
Jul
(39) |
Aug
(34) |
Sep
(22) |
Oct
(43) |
Nov
(26) |
Dec
(157) |
| 2019 |
Jan
(102) |
Feb
(51) |
Mar
(63) |
Apr
(60) |
May
(91) |
Jun
(55) |
Jul
(27) |
Aug
(76) |
Sep
(52) |
Oct
(95) |
Nov
(67) |
Dec
(204) |
| 2020 |
Jan
(311) |
Feb
(148) |
Mar
(230) |
Apr
(122) |
May
(204) |
Jun
(204) |
Jul
(114) |
Aug
(36) |
Sep
(120) |
Oct
(186) |
Nov
(60) |
Dec
(151) |
| 2021 |
Jan
(182) |
Feb
(171) |
Mar
(202) |
Apr
(153) |
May
(110) |
Jun
(50) |
Jul
(58) |
Aug
(142) |
Sep
(112) |
Oct
(120) |
Nov
(97) |
Dec
(125) |
| 2022 |
Jan
(175) |
Feb
(147) |
Mar
(54) |
Apr
(73) |
May
(127) |
Jun
(95) |
Jul
(88) |
Aug
(85) |
Sep
(38) |
Oct
(40) |
Nov
(116) |
Dec
(159) |
| 2023 |
Jan
(175) |
Feb
(55) |
Mar
(83) |
Apr
(70) |
May
(165) |
Jun
(79) |
Jul
(123) |
Aug
(90) |
Sep
(40) |
Oct
(95) |
Nov
(84) |
Dec
(88) |
| 2024 |
Jan
(105) |
Feb
(60) |
Mar
(52) |
Apr
(43) |
May
(56) |
Jun
(59) |
Jul
(53) |
Aug
(47) |
Sep
(62) |
Oct
(36) |
Nov
(45) |
Dec
(100) |
| 2025 |
Jan
(52) |
Feb
(45) |
Mar
(30) |
Apr
(97) |
May
(72) |
Jun
(83) |
Jul
(124) |
Aug
(83) |
Sep
(84) |
Oct
|
Nov
|
Dec
|
|
From: Nate B. <no...@gi...> - 2025-06-26 02:37:40
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 4653b8f96c4cf0f489a021e647a7c30d790eee90 https://github.com/Hamlib/Hamlib/commit/4653b8f96c4cf0f489a021e647a7c30d790eee90 Author: George Baltz N3GB <Geo...@gm...> Date: 2025-06-24 (Tue, 24 Jun 2025) Changed paths: M rigs/kenwood/k3.c M rigs/kenwood/tmd710.c M rigs/kenwood/ts480.c M rigs/kenwood/ts890s.c Log Message: ----------- More cppcheck "errors" in rigs/kenwood/* Still mostly cosmetic - currently ignoring syntax cppcheck can't cope with. Commit: ec4590df8decc4c47a57e6dc78e92871b92c230e https://github.com/Hamlib/Hamlib/commit/ec4590df8decc4c47a57e6dc78e92871b92c230e Author: George Baltz N3GB <Geo...@gm...> Date: 2025-06-24 (Tue, 24 Jun 2025) Changed paths: M rigs/kenwood/ts590.c Log Message: ----------- Restore TS-590S/SG RIG_LEVEL_RFPOWER_METER Commit: aa3e6cb6e9a8a45a2b2f627d11155e14f6808b99 https://github.com/Hamlib/Hamlib/commit/aa3e6cb6e9a8a45a2b2f627d11155e14f6808b99 Author: George Baltz N3GB <Geo...@gm...> Date: 2025-06-24 (Tue, 24 Jun 2025) Changed paths: M rigs/icom/ic7300.c M rigs/icom/ic746.c M rigs/icom/icom.c Log Message: ----------- Fix cppcheck "errors" in rigs/icom/*.c Commit: 0b75b96ef160a5d14be39361b8bcf0a59f04982c https://github.com/Hamlib/Hamlib/commit/0b75b96ef160a5d14be39361b8bcf0a59f04982c Author: George Baltz N3GB <Geo...@gm...> Date: 2025-06-25 (Wed, 25 Jun 2025) Changed paths: M include/hamlib/rotator.h M src/sprintflst.c Log Message: ----------- Fix rotctl \dump_caps output rot_sprintf_status() was printing items multiple times. Cause of problem noticed by cppcheck. Commit: 921a6a9de372adedf68dd57eec620ed7b323c097 https://github.com/Hamlib/Hamlib/commit/921a6a9de372adedf68dd57eec620ed7b323c097 Author: George Baltz N3GB <Geo...@gm...> Date: 2025-06-25 (Wed, 25 Jun 2025) Changed paths: M NEWS M src/serial.c M tests/hamlibmodels.c M tests/rigfreqwalk.c M tests/rigmatrix.c M tests/rotctl.c Log Message: ----------- Still more cppcheck cleanups Commit: 55b0599b752d5cd5c3e1ec1791624aaf8d8f3dbb https://github.com/Hamlib/Hamlib/commit/55b0599b752d5cd5c3e1ec1791624aaf8d8f3dbb Author: George Baltz N3GB <Geo...@gm...> Date: 2025-06-25 (Wed, 25 Jun 2025) Changed paths: M include/hamlib/rig.h M include/hamlib/rotator.h M src/sprintflst.c Log Message: ----------- Stop the blithering Commit: e163aa2645d9b7c8ae823edfc5d1066b346ce230 https://github.com/Hamlib/Hamlib/commit/e163aa2645d9b7c8ae823edfc5d1066b346ce230 Author: George Baltz N3GB <Geo...@gm...> Date: 2025-06-25 (Wed, 25 Jun 2025) Changed paths: M src/sprintflst.c Log Message: ----------- Another reversion Commit: 31c3c973520e8bf87478e17dc6136845351e2e74 https://github.com/Hamlib/Hamlib/commit/31c3c973520e8bf87478e17dc6136845351e2e74 Author: Nate Bargmann <n0...@n0...> Date: 2025-06-25 (Wed, 25 Jun 2025) Changed paths: M NEWS M include/hamlib/rig.h M rigs/icom/ic7300.c M rigs/icom/ic746.c M rigs/icom/icom.c M rigs/kenwood/k3.c M rigs/kenwood/tmd710.c M rigs/kenwood/ts480.c M rigs/kenwood/ts590.c M rigs/kenwood/ts890s.c M src/serial.c M tests/hamlibmodels.c M tests/rigfreqwalk.c M tests/rigmatrix.c M tests/rotctl.c Log Message: ----------- Merge GitHub PR #1783 Compare: https://github.com/Hamlib/Hamlib/compare/92a077585510...31c3c973520e To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: FVsonar <no...@gi...> - 2025-06-26 02:26:10
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 25487237e907c1cf2525d2efcc9e2e0af79f71c1 https://github.com/Hamlib/Hamlib/commit/25487237e907c1cf2525d2efcc9e2e0af79f71c1 Author: 声纳 <159...@qq...> Date: 2025-06-25 (Wed, 25 Jun 2025) Changed paths: M include/hamlib/riglist.h A rigs/guohetec/guohetec.c A rigs/guohetec/guohetec.h A rigs/guohetec/pmr171.c A rigs/guohetec/q900.c Log Message: ----------- Added support for PMR171 and Q900 radios Commit: 96ab1b3a3a5782cfd7b0c97a9909fcca30d8aa3b https://github.com/Hamlib/Hamlib/commit/96ab1b3a3a5782cfd7b0c97a9909fcca30d8aa3b Author: 声纳 <159...@qq...> Date: 2025-06-25 (Wed, 25 Jun 2025) Changed paths: A rigs/guohetec/Makefile.am M rigs/yaesu/Makefile.am R rigs/yaesu/pmr171.c Log Message: ----------- Migrate PMR171 driver from Yaesu to Guohetec directory Commit: a4904aed6270056d5e25d2462a181eee9797eb3d https://github.com/Hamlib/Hamlib/commit/a4904aed6270056d5e25d2462a181eee9797eb3d Author: 声纳 <159...@qq...> Date: 2025-06-25 (Wed, 25 Jun 2025) Changed paths: M configure.ac Log Message: ----------- Add Guohetec directory to build system Commit: e9f50226163f33c0cc1c1bca7d766fa5a690f00e https://github.com/Hamlib/Hamlib/commit/e9f50226163f33c0cc1c1bca7d766fa5a690f00e Author: 声纳 <159...@qq...> Date: 2025-06-25 (Wed, 25 Jun 2025) Changed paths: M rigs/yaesu/ft817.c M rigs/yaesu/yaesu.c M rigs/yaesu/yaesu.h Log Message: ----------- fix: correct PMR171/Q900 definitions in yaesu config Commit: 3d9288d099b06fe0f1395605480ecc3d475f7449 https://github.com/Hamlib/Hamlib/commit/3d9288d099b06fe0f1395605480ecc3d475f7449 Author: 声纳 <159...@qq...> Date: 2025-06-25 (Wed, 25 Jun 2025) Changed paths: M rigs/guohetec/pmr171.c M rigs/guohetec/q900.c Log Message: ----------- Change rig_debug and comments to English Commit: d28acc7d60589da1bfa11325f8132d66765a8183 https://github.com/Hamlib/Hamlib/commit/d28acc7d60589da1bfa11325f8132d66765a8183 Author: 声纳 <159...@qq...> Date: 2025-06-25 (Wed, 25 Jun 2025) Changed paths: M rigs/guohetec/guohetec.c M rigs/guohetec/guohetec.h Log Message: ----------- Change the rig_debug and comments of guohetec.c and guohetec.h to English Commit: 13335aff698c1fc1bac3aeb34cd447803b611080 https://github.com/Hamlib/Hamlib/commit/13335aff698c1fc1bac3aeb34cd447803b611080 Author: 声纳 <159...@qq...> Date: 2025-06-25 (Wed, 25 Jun 2025) Changed paths: M src/register.c Log Message: ----------- Add the DEFINE-INITRIGBACK macro to guohetec Commit: b1ad6a71122acc640841b4c5f4231fe81ad51faf https://github.com/Hamlib/Hamlib/commit/b1ad6a71122acc640841b4c5f4231fe81ad51faf Author: 声纳 <159...@qq...> Date: 2025-06-25 (Wed, 25 Jun 2025) Changed paths: M src/register.c Log Message: ----------- Add the rig_backend_list to guohetec Commit: 14a81b9ad9eb24e2c92762f94939c5bab4e36087 https://github.com/Hamlib/Hamlib/commit/14a81b9ad9eb24e2c92762f94939c5bab4e36087 Author: 声纳 <159...@qq...> Date: 2025-06-26 (Thu, 26 Jun 2025) Changed paths: M rigs/guohetec/pmr171.c M rigs/guohetec/q900.c Log Message: ----------- Fix q900 and pmr171 compilation warnings Commit: b7388e2fca4382232b71301cef3a625d74b6a2d7 https://github.com/Hamlib/Hamlib/commit/b7388e2fca4382232b71301cef3a625d74b6a2d7 Author: 声纳 <159...@qq...> Date: 2025-06-26 (Thu, 26 Jun 2025) Changed paths: M rigs/guohetec/pmr171.c M rigs/guohetec/q900.c Log Message: ----------- Delete useless variables of pmr171 and q900 Commit: acd4a98cd5eddb7b9f09608d2973d6670fdfcb5d https://github.com/Hamlib/Hamlib/commit/acd4a98cd5eddb7b9f09608d2973d6670fdfcb5d Author: 声纳 <159...@qq...> Date: 2025-06-26 (Thu, 26 Jun 2025) Changed paths: M rigs/guohetec/pmr171.c Log Message: ----------- Modify buffer size to prevent overflow Commit: 92a0775855109aae116f4352139a6d69c5c0ff46 https://github.com/Hamlib/Hamlib/commit/92a0775855109aae116f4352139a6d69c5c0ff46 Author: 声纳 <159...@qq...> Date: 2025-06-26 (Thu, 26 Jun 2025) Changed paths: M rigs/guohetec/q900.c Log Message: ----------- Modify the buffer size of q900. c to prevent overflow Compare: https://github.com/Hamlib/Hamlib/compare/0ddc6bc8f41e...92a077585510 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: George B. <geo...@gm...> - 2025-06-25 13:27:48
|
They're 'extra levels' - look at the lines after the level list in dump_caps. On 6/25/25 05:32, Stefan Jansen wrote: > Hi, > > I compiled hamlib 4.7 out of GitHub and found the following inconsistency, at least it’s one from my point of view. > > When I type: rigctl -m1 —dump-caps > The output for „Set levels“ and „Get levels“ does not contain levels MGF, MGL and MGC. But typing: rigctl -m1 l ? > Lists these levels. > > Why are MGF, MGL and MGC mentioned in the output of „l ?“ But not in „—dump-caps“? > > > Vy 73 de Stefan, DK7STJ > > -- > Stefan Jansen *** E-Mail: DK...@da... > > > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Stefan J. <DK...@da...> - 2025-06-25 09:33:21
|
Hi, I compiled hamlib 4.7 out of GitHub and found the following inconsistency, at least it’s one from my point of view. When I type: rigctl -m1 —dump-caps The output for „Set levels“ and „Get levels“ does not contain levels MGF, MGL and MGC. But typing: rigctl -m1 l ? Lists these levels. Why are MGF, MGL and MGC mentioned in the output of „l ?“ But not in „—dump-caps“? Vy 73 de Stefan, DK7STJ -- Stefan Jansen *** E-Mail: DK...@da... |
|
From: Nate B. <n0...@n0...> - 2025-06-24 18:26:57
|
* On 2025 24 Jun 12:16 -0500, "Christoph v. Wüllen" wrote: > > > > The size_t(3) man page states size_t is an unsigned integer and here in > > rig.c the 'needed' variable is of the size_t type. Thus 'u' should be > > correct. > > > This is (only) true for a specific system. What the size_t type > is all about is that it can be different on different systems. Sure, but as I understand from this Stack Overflow thread: https://stackoverflow.com/q/940087 This is exactly the intent of the 'z' length modifier which was introduced in C99. The discussion also concludes that the 'u' conversion specifier is correct for a size_t variable. > Do not draw conclusions for coding from a specific system. > My advice is to use > %ul and type-cast the argument to unsigned long, this should > work (as of now) on any system I know of. That thread gives your example for C90. As I agree with others that it should be standard practice to target C11/C17, I think we simply need to stop coding against C90 and move forward. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 |
|
From: Christoph v. W. <DL...@da...> - 2025-06-24 17:16:17
|
> > The size_t(3) man page states size_t is an unsigned integer and here in > rig.c the 'needed' variable is of the size_t type. Thus 'u' should be > correct. > This is (only) true for a specific system. What the size_t type is all about is that it can be different on different systems. Do not draw conclusions for coding from a specific system. My advice is to use %ul and type-cast the argument to unsigned long, this should work (as of now) on any system I know of. Yours, DL1YCF. |
|
From: Nate B. <no...@gi...> - 2025-06-24 13:47:37
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 0ddc6bc8f41e597ba4c21df5256d6970c3d3ee6b https://github.com/Hamlib/Hamlib/commit/0ddc6bc8f41e597ba4c21df5256d6970c3d3ee6b Author: Nate Bargmann <n0...@n0...> Date: 2025-06-24 (Tue, 24 Jun 2025) Changed paths: M src/rig.c Log Message: ----------- Fix MinGW64/MSYS2 w/GCC 15.1 warning As reported by Steve, VK3SIR on the mailing list: On compilation, through a fully up-to-date MinGW64/MSYS2 environment, we receive the following warnings: .... make[3]: Entering directory '/home/sir/src/hamlib/build/src' CC rig.lo ../../src/src/rig.c: In function 'rig_init': ../../src/src/rig.c:624:45: warning: unknown conversion type character 'z' in format [-Wformat=] 624 | rig_debug(RIG_DEBUG_TRACE, "Requesting %zd bytes for rig_struct\n", needed); | ^ ../../src/src/rig.c:624:32: warning: too many arguments for format [-Wformat-extra-args] 624 | rig_debug(RIG_DEBUG_TRACE, "Requesting %zd bytes for rig_struct\n", needed); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../../src/src/rig.c:657:45: warning: unknown conversion type character 'z' in format [-Wformat=] 657 | rig_debug(RIG_DEBUG_TRACE, "Requesting %zd bytes for rig_cache\n", needed); | ^ ../../src/src/rig.c:657:32: warning: too many arguments for format [-Wformat-extra-args] 657 | rig_debug(RIG_DEBUG_TRACE, "Requesting %zd bytes for rig_cache\n", needed); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CC serial.lo .... The '%z' modifier is also found in rigs/icom/icom.c but with a 'u' conversion specifier. Turns out that since 'needed' in this function is of type 'size_t' which is an unsigned integer so the 'u' is required. To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <n0...@n0...> - 2025-06-24 12:35:59
|
* On 2025 24 Jun 04:33 -0500, Stephen VK3SIR wrote:
> Hi Nate (and Team),
>
> On compilation, through a fully up-to-date MinGW64/MSYS2 environment, we receive the following warnings:
>
> ....
> make[3]: Entering directory '/home/sir/src/hamlib/build/src'
> CC rig.lo
> ../../src/src/rig.c: In function 'rig_init':
> ../../src/src/rig.c:624:45: warning: unknown conversion type character 'z' in format [-Wformat=]
> 624 | rig_debug(RIG_DEBUG_TRACE, "Requesting %zd bytes for rig_struct\n", needed);
> | ^
> ../../src/src/rig.c:624:32: warning: too many arguments for format [-Wformat-extra-args]
> 624 | rig_debug(RIG_DEBUG_TRACE, "Requesting %zd bytes for rig_struct\n", needed);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../../src/src/rig.c:657:45: warning: unknown conversion type character 'z' in format [-Wformat=]
> 657 | rig_debug(RIG_DEBUG_TRACE, "Requesting %zd bytes for rig_cache\n", needed);
> | ^
> ../../src/src/rig.c:657:32: warning: too many arguments for format [-Wformat-extra-args]
> 657 | rig_debug(RIG_DEBUG_TRACE, "Requesting %zd bytes for rig_cache\n", needed);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> CC serial.lo
> ....
>
> MinGW64/MSYS2 delivers the GCC 15.1 compiler.
Hi Steve,
I see that "%z" shows up in just four places in the tree. The other two
places are in rigs/icom/icom.c at lines 9035 and 9060. There it is
followed by "u" in both cases which apparently didn't raise a warning.
If you modify the lines in rig.c to match does the warning go away?
> If we do not report then things become bigger later one !
All I can think of is that the compiler now enforces the use of an
unsigned integer. From the printf(3) man page:
z A following integer conversion corresponds to a size_t or
ssize_t argument, or a following n conversion corresponds to a
pointer to a size_t argument.
The size_t(3) man page states size_t is an unsigned integer and here in
rig.c the 'needed' variable is of the size_t type. Thus 'u' should be
correct.
I'll work up a patch for this.
Thanks!
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
|
|
From: Stephen V. <vk...@ho...> - 2025-06-24 09:33:16
|
Hi Nate (and Team),
On compilation, through a fully up-to-date MinGW64/MSYS2 environment, we receive the following warnings:
....
make[3]: Entering directory '/home/sir/src/hamlib/build/src'
CC rig.lo
../../src/src/rig.c: In function 'rig_init':
../../src/src/rig.c:624:45: warning: unknown conversion type character 'z' in format [-Wformat=]
624 | rig_debug(RIG_DEBUG_TRACE, "Requesting %zd bytes for rig_struct\n", needed);
| ^
../../src/src/rig.c:624:32: warning: too many arguments for format [-Wformat-extra-args]
624 | rig_debug(RIG_DEBUG_TRACE, "Requesting %zd bytes for rig_struct\n", needed);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../src/src/rig.c:657:45: warning: unknown conversion type character 'z' in format [-Wformat=]
657 | rig_debug(RIG_DEBUG_TRACE, "Requesting %zd bytes for rig_cache\n", needed);
| ^
../../src/src/rig.c:657:32: warning: too many arguments for format [-Wformat-extra-args]
657 | rig_debug(RIG_DEBUG_TRACE, "Requesting %zd bytes for rig_cache\n", needed);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CC serial.lo
....
MinGW64/MSYS2 delivers the GCC 15.1 compiler.
If we do not report then things become bigger later one !
73
Steve I
VK3SIR
|
|
From: Nate B. <no...@gi...> - 2025-06-23 13:20:21
|
Branch: refs/heads/Hamlib-4.6.3 Home: https://github.com/Hamlib/Hamlib Commit: a57e5583fd7903c100b8cc01c286b2a9da9096c6 https://github.com/Hamlib/Hamlib/commit/a57e5583fd7903c100b8cc01c286b2a9da9096c6 Author: markjfine <mar...@fi...> Date: 2025-06-23 (Mon, 23 Jun 2025) Changed paths: M rigs/icom/icr75.c Log Message: ----------- Correct powerstat check The R75 for some reason rejects the powerstat query and returns an error. Commented out .get_powerstat to correct that. Applications should initially assume it's on, then internally track power status, since you can still turn it off. (cherry picked from commit dc12b01aed6b4449e42ff57e71f3687b1b837a20) Commit: 867fc5886a5a9f0bee66be4fd2e5821a9cf0b00d https://github.com/Hamlib/Hamlib/commit/867fc5886a5a9f0bee66be4fd2e5821a9cf0b00d Author: Nate Bargmann <n0...@n0...> Date: 2025-06-23 (Mon, 23 Jun 2025) Changed paths: M NEWS Log Message: ----------- Update NEWS for R75 powerstat fix Compare: https://github.com/Hamlib/Hamlib/compare/b34695aab8dc...867fc5886a5a To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: markjfine <no...@gi...> - 2025-06-23 13:15:45
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: dc12b01aed6b4449e42ff57e71f3687b1b837a20 https://github.com/Hamlib/Hamlib/commit/dc12b01aed6b4449e42ff57e71f3687b1b837a20 Author: markjfine <mar...@fi...> Date: 2025-06-23 (Mon, 23 Jun 2025) Changed paths: M rigs/icom/icr75.c Log Message: ----------- Correct powerstat check The R75 for some reason rejects the powerstat query and returns an error. Commented out .get_powerstat to correct that. Applications should initially assume it's on, then internally track power status, since you can still turn it off. To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <n0...@n0...> - 2025-06-22 20:38:42
|
Regarding a feature roadmap of sorts. I have created two new issues and pinned them at the top of the GitHub Issues page. They are #1772 and #1773 for 4.7.0 and 5.0.0 respectively. I figure the Issues page gets more reads than the Wiki does. I added a progress bar link to https://markdone.org/ which can be updated in 5% increments. Of course, that's going to be a guesstimate on everyone's part. As such, I consider the first post in each issue to be a living document. For example, if it is necessary that a feature is deemed unsuitable for a release it can be moved to the later release. Also check marks will be added upon satisfactory completion and progress updated (I'm not sure if that ability is mine alone or not). I also included GitHub usernames for each item which is primarily who made the suggestion and who will likely be the primary contributor as a reference. It's not intended to make that contributor solely responsible, however. Also, I don't want these feature lists to be too large. Right now 4.7.0 has three items and 5.0.0 has four. A couple more in each should be sufficient. Hopefully, this will help maintain focus and center the release discussions, although there is no problem having such discussions here. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 |
|
From: Nate B. <n0...@n0...> - 2025-06-22 19:57:55
|
* On 2025 18 Jun 16:26 -0500, Daniele Forsi wrote: > 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. > > I agree on both points > > > > It is ready when it is ready. > > > > I agree. > > I agree too > > WRT a feature roadmap, I would like to see > * the Python bindings mostly complete and the other languages at least > working for some basic functionality such as set/get frequency (some > time before 5.0) I think this is reasonable for 4.7.0 > * the tests that currently use the Dummy devices working also with the > simulators (and with real hardware where it makes sense) 5.0?? 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 |
|
From: Nate B. <no...@gi...> - 2025-06-22 15:55:54
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 9fe3ae7e7da0daf2b1cd674e2c23570772e426fc https://github.com/Hamlib/Hamlib/commit/9fe3ae7e7da0daf2b1cd674e2c23570772e426fc Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-15 (Sun, 15 Jun 2025) Changed paths: M bindings/Makefile.am R bindings/py3test.py R bindings/pytest.py M configure.ac Log Message: ----------- Remove the scripts pytest.py and py3test.py They will be replaced by the official pytest tool. Because of name clash it would be impossible to call the pytest tool from the bindings directory. Commit: f4dcd7d565d3baaafacf083c0fc5572c4361f274 https://github.com/Hamlib/Hamlib/commit/f4dcd7d565d3baaafacf083c0fc5572c4361f274 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-15 (Sun, 15 Jun 2025) Changed paths: M bindings/Makefile.am A bindings/python/test_startup.py M configure.ac Log Message: ----------- Add a pytest test copying all the contents of the old py3test.py Python tests are enabled by default when building the Python bindings if pytest is available at configuration time: ./configure --with-python-binding or ./configure --with-python-binding --enable-pytest=check To fail the configure step if the tests can't be enabled: ./configure --with-python-binding --enable-pytest or ./configure --with-python-binding --enable-pytest=yes To disable the tests: ./configure --with-python-binding --enable-pytest=no To run the tests: make -C bindings/ check Commit: c693afb04058886cc374ce2d024adc57740d6463 https://github.com/Hamlib/Hamlib/commit/c693afb04058886cc374ce2d024adc57740d6463 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-15 (Sun, 15 Jun 2025) Changed paths: M bindings/python/test_startup.py Log Message: ----------- Replace print() with assert So changes in behavior can be detected. Commit: 77c02b58bb9bbd81b92ae728c5b72a86a22c6bc1 https://github.com/Hamlib/Hamlib/commit/77c02b58bb9bbd81b92ae728c5b72a86a22c6bc1 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-15 (Sun, 15 Jun 2025) Changed paths: A bindings/python/test_rig.py Log Message: ----------- Add tests for the Rig class Commit: 65ffc5426b8c47d1a082ed793c5750ddf61f3a79 https://github.com/Hamlib/Hamlib/commit/65ffc5426b8c47d1a082ed793c5750ddf61f3a79 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-15 (Sun, 15 Jun 2025) Changed paths: M bindings/python/test_rig.py M bindings/rig.swg Log Message: ----------- Remove undocumented unused method rig.chan_clear() Commit: 591f7cf5c818fc38d2a2b9b217ca866b46826b0e https://github.com/Hamlib/Hamlib/commit/591f7cf5c818fc38d2a2b9b217ca866b46826b0e Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-15 (Sun, 15 Jun 2025) Changed paths: M bindings/python/test_rig.py M bindings/rig.swg Log Message: ----------- Fix Rig.get_ant() Commit: 637ccebe0261a2a101d072bd56fe2bd180c6ce7e https://github.com/Hamlib/Hamlib/commit/637ccebe0261a2a101d072bd56fe2bd180c6ce7e Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-15 (Sun, 15 Jun 2025) Changed paths: M bindings/python/test_rig.py Log Message: ----------- Test returned datatypes Commit: bf4daf1486a4a35f14089722e08e7458e7d1b36b https://github.com/Hamlib/Hamlib/commit/bf4daf1486a4a35f14089722e08e7458e7d1b36b Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-15 (Sun, 15 Jun 2025) Changed paths: M .github/workflows/c-cpp.yml Log Message: ----------- Enable pytest in github actions, also for feature/* branches Commit: 8a191213e6d42ce00a059fc70c556587e0e91368 https://github.com/Hamlib/Hamlib/commit/8a191213e6d42ce00a059fc70c556587e0e91368 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-15 (Sun, 15 Jun 2025) Changed paths: M bindings/hamlib.swg Log Message: ----------- Add missing definitions for amplifiers Commit: aa5c232def665e39714414fc30ce8a775ecce6f9 https://github.com/Hamlib/Hamlib/commit/aa5c232def665e39714414fc30ce8a775ecce6f9 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-15 (Sun, 15 Jun 2025) Changed paths: M bindings/amplifier.swg Log Message: ----------- Rename and fix AMPMETHOD1VGET macro Drop the V which means VFO and add missing parentheses. Commit: df0d434b27cb7abdc86c926a1f7437b5926f953b https://github.com/Hamlib/Hamlib/commit/df0d434b27cb7abdc86c926a1f7437b5926f953b Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-15 (Sun, 15 Jun 2025) Changed paths: M bindings/ignore.swg Log Message: ----------- Remove more symbols from Hamlib module using regexes Commit: 4b0fa60e95cae7a977a6ca6884b07f589fd03ef9 https://github.com/Hamlib/Hamlib/commit/4b0fa60e95cae7a977a6ca6884b07f589fd03ef9 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-15 (Sun, 15 Jun 2025) Changed paths: M bindings/python/test_rig.py Log Message: ----------- Remove ignored symbol Commit: 48c40dc326e089b62ecd6a7d0c5b5957d4718082 https://github.com/Hamlib/Hamlib/commit/48c40dc326e089b62ecd6a7d0c5b5957d4718082 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-15 (Sun, 15 Jun 2025) Changed paths: M bindings/amplifier.swg M bindings/hamlib.swg M bindings/rig.swg M bindings/rotator.swg Log Message: ----------- Move includes in the files where they are used Makes the other files less dependent on being included by hamlib.swg and more self-contained. Need to explicitly add %include for amplist.h, riglist.h, rotlist.h to have the definitions picked up by SWIG even if they are included by the main .swg file. Commit: bca1d80d205b00f1a005806c52ffb7363243b194 https://github.com/Hamlib/Hamlib/commit/bca1d80d205b00f1a005806c52ffb7363243b194 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-15 (Sun, 15 Jun 2025) Changed paths: M bindings/amplifier.swg M bindings/hamlib.swg M bindings/rig.swg M bindings/rotator.swg Log Message: ----------- Move/add %immutable in their files Makes the other files less dependent on being included by hamlib.swg and more self-contained. Also drop the symbols that are ignored. Commit: f2aaed6e0947bebeb6cccb8d392110e14568a96c https://github.com/Hamlib/Hamlib/commit/f2aaed6e0947bebeb6cccb8d392110e14568a96c Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-15 (Sun, 15 Jun 2025) Changed paths: M bindings/amplifier.swg Log Message: ----------- Add missing type of the 4th argument of macro AMPMETHOD4 Commit: 464450384d95f2f6777db5552c1992bf118faded https://github.com/Hamlib/Hamlib/commit/464450384d95f2f6777db5552c1992bf118faded Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/Makefile.am A bindings/python/generate_tests.py Log Message: ----------- Add a Python script to autogenerate some tests for pytest Commit: 57b23e7efcc862a784fb55c1d00f87f19c3d4393 https://github.com/Hamlib/Hamlib/commit/57b23e7efcc862a784fb55c1d00f87f19c3d4393 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/Makefile.am A bindings/python/test_Hamlib_Amp_class.py A bindings/python/test_Hamlib_Rig_class.py A bindings/python/test_Hamlib_Rot_class.py A bindings/python/test_Hamlib_class.py Log Message: ----------- Add autogenerated test scripts for pytest Commit: 98fdcf130f2e1b3bd7a0ae85f350bb7f07d4da33 https://github.com/Hamlib/Hamlib/commit/98fdcf130f2e1b3bd7a0ae85f350bb7f07d4da33 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: A bindings/python/test_amp.py Log Message: ----------- Add tests for the Amp object Commit: 02f7b96163ac4a086ed62fc0b75ac1fbcb7c95cf https://github.com/Hamlib/Hamlib/commit/02f7b96163ac4a086ed62fc0b75ac1fbcb7c95cf Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/amplifier.swg M bindings/python/test_amp.py Log Message: ----------- Implement Amp.get_powerstat Commit: 4e415f412be941598e48e5c311a5e54e4833de03 https://github.com/Hamlib/Hamlib/commit/4e415f412be941598e48e5c311a5e54e4833de03 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/amplifier.swg M bindings/python/test_amp.py Log Message: ----------- Implement Amp.get_freq Commit: f7d38f92cac73fb8b952f5dde3853f40ef910e14 https://github.com/Hamlib/Hamlib/commit/f7d38f92cac73fb8b952f5dde3853f40ef910e14 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/amplifier.swg M bindings/python/test_amp.py Log Message: ----------- Implement Amp.get_level Commit: 4b64ea316994d7c8e25d44f08a682fc5170b2aa3 https://github.com/Hamlib/Hamlib/commit/4b64ea316994d7c8e25d44f08a682fc5170b2aa3 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/python/test_Hamlib_Amp_class.py Log Message: ----------- Update autogenerated tests for Amp object Commit: a172b6001fa90e3fd32ff91262e06c1ca6bb7831 https://github.com/Hamlib/Hamlib/commit/a172b6001fa90e3fd32ff91262e06c1ca6bb7831 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: A bindings/python/test_rot.py Log Message: ----------- Add tests for the Rot object Commit: 5a5279492ebc46d1b758b847a9e41be111fda5e0 https://github.com/Hamlib/Hamlib/commit/5a5279492ebc46d1b758b847a9e41be111fda5e0 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/python/test_rig.py M bindings/python/test_rot.py Log Message: ----------- Mark asserts that are currently failing Commit: cc0dbc9efd7b3efbe360029e2987aa2c87490717 https://github.com/Hamlib/Hamlib/commit/cc0dbc9efd7b3efbe360029e2987aa2c87490717 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/python/test_rot.py M bindings/rotator.swg Log Message: ----------- Implement Rot.set_func() Commit: bb79bbc2782712fb21bda8b70d3b51f8e4eb9736 https://github.com/Hamlib/Hamlib/commit/bb79bbc2782712fb21bda8b70d3b51f8e4eb9736 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/python/test_rot.py M bindings/rotator.swg Log Message: ----------- Implement Rot.get_func() Commit: cfca827f5e85c4162e1accb05e0f6b8e4b611fcc https://github.com/Hamlib/Hamlib/commit/cfca827f5e85c4162e1accb05e0f6b8e4b611fcc Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/python/test_rot.py M bindings/rotator.swg Log Message: ----------- Implement Rot.set_parm() Commit: 94774a63d99ae55b28e602dd6d1ad3ce271b30c7 https://github.com/Hamlib/Hamlib/commit/94774a63d99ae55b28e602dd6d1ad3ce271b30c7 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/python/test_rot.py M bindings/rotator.swg Log Message: ----------- Implement Rot.set_level() Commit: 8093f05c656a40de1fb9eb3c64f598a22575ebeb https://github.com/Hamlib/Hamlib/commit/8093f05c656a40de1fb9eb3c64f598a22575ebeb Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/python/test_rot.py M bindings/rotator.swg Log Message: ----------- Implement Rot.get_level() Commit: 5d142de5cd5cee1dc8312ae4171bdfd6007bc055 https://github.com/Hamlib/Hamlib/commit/5d142de5cd5cee1dc8312ae4171bdfd6007bc055 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/python/test_rot.py M bindings/rotator.swg Log Message: ----------- Implement Rot.get_parm() Commit: 20960b726e03a9916887838c6c7608a55087d3ca https://github.com/Hamlib/Hamlib/commit/20960b726e03a9916887838c6c7608a55087d3ca Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/python/test_rot.py M bindings/rotator.swg Log Message: ----------- Implement Rot.set_ext_level() Commit: f7710d96b084100451125662d265859f2ea9cc08 https://github.com/Hamlib/Hamlib/commit/f7710d96b084100451125662d265859f2ea9cc08 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/python/test_rot.py M bindings/rotator.swg Log Message: ----------- Implement Rot.set_ext_func() Commit: be1a558e0def0fff6f24f8fb595869ec9aa28968 https://github.com/Hamlib/Hamlib/commit/be1a558e0def0fff6f24f8fb595869ec9aa28968 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/python/test_rot.py M bindings/rotator.swg Log Message: ----------- Implement Rot.set_ext_parm() Commit: e34026707ce2b487c2bc234e773b3d1650bd9c83 https://github.com/Hamlib/Hamlib/commit/e34026707ce2b487c2bc234e773b3d1650bd9c83 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/python/test_rot.py M bindings/rotator.swg Log Message: ----------- Implement Rot.get_ext_func() Commit: 6fd6e94d3b02b70e9cc23fc3ac2d65c859e60ad6 https://github.com/Hamlib/Hamlib/commit/6fd6e94d3b02b70e9cc23fc3ac2d65c859e60ad6 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/python/test_rot.py M bindings/rotator.swg Log Message: ----------- Implement Rot.get_ext_level() Commit: 5c58c9920793f400686744dfa70fc413179bfd8e https://github.com/Hamlib/Hamlib/commit/5c58c9920793f400686744dfa70fc413179bfd8e Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/python/test_rot.py M bindings/rotator.swg Log Message: ----------- Implement Rot.get_ext_parm() Commit: 5915f173221f6fe8d4e32b6e97e3a15179b8e1cb https://github.com/Hamlib/Hamlib/commit/5915f173221f6fe8d4e32b6e97e3a15179b8e1cb Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/python/test_Hamlib_Rot_class.py Log Message: ----------- Update autogenerated tests for Rot object Commit: ec8eaab1f529332e886f2ae606a7e26ec3930e2e https://github.com/Hamlib/Hamlib/commit/ec8eaab1f529332e886f2ae606a7e26ec3930e2e Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/python/test_startup.py Log Message: ----------- Enable assert Hamlib.rigerror() Pull request #1727 has been merged so now the test succeeds. Commit: a42d18b59fd0e8b1747f65f7b2df7d189b9d8876 https://github.com/Hamlib/Hamlib/commit/a42d18b59fd0e8b1747f65f7b2df7d189b9d8876 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/ignore.swg Log Message: ----------- Change the ignore list to explicitly accept symbols This way the list documents all available symbols (even if in abbreviated form) instead of those not available. Commit: 5d1baed7e57615b74ce832a806e6c76709f4c62d https://github.com/Hamlib/Hamlib/commit/5d1baed7e57615b74ce832a806e6c76709f4c62d Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/python/test_rot.py Log Message: ----------- Test setting and getting meaningful values Commit: 16a0ad7bf146418fa452e11edf34238f4c7b1e05 https://github.com/Hamlib/Hamlib/commit/16a0ad7bf146418fa452e11edf34238f4c7b1e05 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/python/test_Hamlib_class.py Log Message: ----------- Update autogenerated tests for Hamlib module Commit: c453cc788dda5decb553a90ed79c1b2324a38af9 https://github.com/Hamlib/Hamlib/commit/c453cc788dda5decb553a90ed79c1b2324a38af9 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M README.developer Log Message: ----------- Update README.developer Commit: 68633fa627088739b5bc6f50d6e3c99ff81cd76b https://github.com/Hamlib/Hamlib/commit/68633fa627088739b5bc6f50d6e3c99ff81cd76b Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/Makefile.am A bindings/macros.swg Log Message: ----------- Add SWIG macros Commit: 93c16bcdd568e0e3fce550cd27ece193a85eea5c https://github.com/Hamlib/Hamlib/commit/93c16bcdd568e0e3fce550cd27ece193a85eea5c Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/rotator.swg Log Message: ----------- Use the macros Commit: 66977a0f129ac18fe11ce0580d7a94ab8542db56 https://github.com/Hamlib/Hamlib/commit/66977a0f129ac18fe11ce0580d7a94ab8542db56 Author: Daniele Forsi IU5HKX <iu...@gm...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M bindings/python/test_rot.py Log Message: ----------- Explain unexpected results Commit: 1441ce18391beece4e4b65036da911e6d55fd409 https://github.com/Hamlib/Hamlib/commit/1441ce18391beece4e4b65036da911e6d55fd409 Author: Nate Bargmann <n0...@n0...> Date: 2025-06-22 (Sun, 22 Jun 2025) Changed paths: M .github/workflows/c-cpp.yml M README.developer M bindings/Makefile.am M bindings/amplifier.swg M bindings/hamlib.swg M bindings/ignore.swg A bindings/macros.swg R bindings/py3test.py R bindings/pytest.py A bindings/python/generate_tests.py A bindings/python/test_Hamlib_Amp_class.py A bindings/python/test_Hamlib_Rig_class.py A bindings/python/test_Hamlib_Rot_class.py A bindings/python/test_Hamlib_class.py A bindings/python/test_amp.py A bindings/python/test_rig.py A bindings/python/test_rot.py A bindings/python/test_startup.py M bindings/rig.swg M bindings/rotator.swg M configure.ac Log Message: ----------- Merge GitHub PR #1726 Compare: https://github.com/Hamlib/Hamlib/compare/8d0e67f0173d...1441ce18391b To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <n0...@n0...> - 2025-06-21 15:58:37
|
* On 2025 20 Jun 02:49 -0500, Mikael Nousiainen wrote: > Hi folks! > > There is some good planning here, great to see Hamlib going forward! Trying something different. 🤣 > 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). +1 > 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. +1 > Some questions about releases/schedule: > > - Do you have any timeline in mind for a 5.0 release? Early next year? "When it is ready"? Yes to the latter, and early next year would be an ideal target, but not a hard one. I don't know how popular Ubuntu is in the ham radio world any more but some downstream distros do base on it and 26.04 should be an LTS. In this regard, having a made a couple of 4.7 branch releases for stabilization and bug fixes is more important. > - Do you see any 4.x releases preparing for the larger changes before it? Yes, I'd like to see us get 4.7.0 released in three to four months time. That should include some things identified in this thread as well as FTX-1 support with at least the basics working. As there is a report that it works by selecting FTDX-10 in other software, this *should* be fairly straight forward. This gives plenty of time for 4.7.x to "settle in" before 26.04 LTS. When we're satisfied that we're close enough for 4.7, I'll create its branch and all future 4.7 work will occur there and master will be targeted toward 5.0. This means 4.7.x would be the least series with the present API/ABI and that 5.0 can make changes as needed. None of this is to imply that our release schedule is governed by any one distribution. I just tend to keep an eye on these sorts of things and realize there is a benefit to downstream when we keep those schedules in mind. > Also, please see my additional comments below. I have some comments inline and at the bottom. > 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. According to GNU, current GCC supports up to C23: https://gcc.gnu.org/onlinedocs/gcc/Standards.html From that page I read that C17 is a set of corrections to C11 so as there is sufficient compiler support, then it seems like the rest of the tooling is in question. I've not looked to determine if autoconf or the external archive have macros enforcing a minimum C version. > >> 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! I've been thinking about where to place a release goals document. It could be a thread here or a new document on the Wiki. Thoughts? 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 |
|
From: Nate B. <no...@gi...> - 2025-06-21 15:26:58
|
Branch: refs/heads/Hamlib-4.6.3 Home: https://github.com/Hamlib/Hamlib Commit: c7cf8593172a03892576268aa7d2124a8af8f740 https://github.com/Hamlib/Hamlib/commit/c7cf8593172a03892576268aa7d2124a8af8f740 Author: George Baltz N3GB <Geo...@gm...> Date: 2025-06-21 (Sat, 21 Jun 2025) Changed paths: M tests/rigctl_parse.c Log Message: ----------- Fix memory leak in rigctl_parse.c strip_quotes() orphaned 1 or 2 strings per call. (cherry picked from commit 0740af61a37f7ae2a350ae2d1c4151c07849b6c3) Commit: 7b8ce52a9ea5bf0e5df18167253e461e429fefcb https://github.com/Hamlib/Hamlib/commit/7b8ce52a9ea5bf0e5df18167253e461e429fefcb Author: George Baltz N3GB <Geo...@gm...> Date: 2025-06-21 (Sat, 21 Jun 2025) Changed paths: M doc/man1/rigctld.1 Log Message: ----------- Add -S to rigctld man page (cherry picked from commit 65d922ce536dd0001fc690e7a6a2e59f334f3cb8) Commit: 7127d887833d8c9dbc22ddb46d3ad10c514c41a1 https://github.com/Hamlib/Hamlib/commit/7127d887833d8c9dbc22ddb46d3ad10c514c41a1 Author: George Baltz N3GB <Geo...@gm...> Date: 2025-06-21 (Sat, 21 Jun 2025) Changed paths: M tests/rigctld.c Log Message: ----------- Make separator character local to rigctld connection Response to rigctld command was being corrupted by other threads Fixes issue #1748 (cherry picked from commit 8d0e67f0173d1cd7131c1235997105204cc48dbd) Commit: b34695aab8dc7865620676a28ee7bbe7dc67fd3e https://github.com/Hamlib/Hamlib/commit/b34695aab8dc7865620676a28ee7bbe7dc67fd3e Author: Nate Bargmann <n0...@n0...> Date: 2025-06-21 (Sat, 21 Jun 2025) Changed paths: M NEWS Log Message: ----------- Update NEWS for rigctld seperator character fix. Compare: https://github.com/Hamlib/Hamlib/compare/619cf9fc0d3d...b34695aab8dc To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: GeoBaltz <no...@gi...> - 2025-06-21 15:16:55
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 0740af61a37f7ae2a350ae2d1c4151c07849b6c3 https://github.com/Hamlib/Hamlib/commit/0740af61a37f7ae2a350ae2d1c4151c07849b6c3 Author: George Baltz N3GB <Geo...@gm...> Date: 2025-06-21 (Sat, 21 Jun 2025) Changed paths: M tests/rigctl_parse.c Log Message: ----------- Fix memory leak in rigctl_parse.c strip_quotes() orphaned 1 or 2 strings per call. Commit: 65d922ce536dd0001fc690e7a6a2e59f334f3cb8 https://github.com/Hamlib/Hamlib/commit/65d922ce536dd0001fc690e7a6a2e59f334f3cb8 Author: George Baltz N3GB <Geo...@gm...> Date: 2025-06-21 (Sat, 21 Jun 2025) Changed paths: M doc/man1/rigctld.1 Log Message: ----------- Add -S to rigctld man page Commit: 8d0e67f0173d1cd7131c1235997105204cc48dbd https://github.com/Hamlib/Hamlib/commit/8d0e67f0173d1cd7131c1235997105204cc48dbd Author: George Baltz N3GB <Geo...@gm...> Date: 2025-06-21 (Sat, 21 Jun 2025) Changed paths: M tests/rigctld.c Log Message: ----------- Make separator character local to rigctld connection Response to rigctld command was being corrupted by other threads Fixes issue #1748 Compare: https://github.com/Hamlib/Hamlib/compare/aa39d6a618c8...8d0e67f0173d To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <no...@gi...> - 2025-06-21 02:32:18
|
Branch: refs/heads/Hamlib-4.6.3 Home: https://github.com/Hamlib/Hamlib Commit: 7d2e82886130070e6680d60d8d9596c697cb9c08 https://github.com/Hamlib/Hamlib/commit/7d2e82886130070e6680d60d8d9596c697cb9c08 Author: markjfine <mar...@fi...> Date: 2025-06-20 (Fri, 20 Jun 2025) Changed paths: M rigs/jrc/jrc.c Log Message: ----------- Fixed jrc_set_chan set_chan() was correctly creating and sending the command, and returning RIG_OK. However, radio was actually ignoring it because command wasn't terminated with a CR. This is now corrected. (cherry picked from commit aa39d6a618c82bb0482098fefd2cfddb7bd7ee61) Commit: 619cf9fc0d3de8f31fc9d30c8199898c5a91be94 https://github.com/Hamlib/Hamlib/commit/619cf9fc0d3de8f31fc9d30c8199898c5a91be94 Author: Nate Bargmann <n0...@n0...> Date: 2025-06-20 (Fri, 20 Jun 2025) Changed paths: M NEWS Log Message: ----------- Update NEWS for jrc_set_chan Compare: https://github.com/Hamlib/Hamlib/compare/cea177f3959c...619cf9fc0d3d To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: markjfine <no...@gi...> - 2025-06-21 02:24:59
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: aa39d6a618c82bb0482098fefd2cfddb7bd7ee61 https://github.com/Hamlib/Hamlib/commit/aa39d6a618c82bb0482098fefd2cfddb7bd7ee61 Author: markjfine <mar...@fi...> Date: 2025-06-20 (Fri, 20 Jun 2025) Changed paths: M rigs/jrc/jrc.c Log Message: ----------- Fixed jrc_set_chan set_chan() was correctly creating and sending the command, and returning RIG_OK. However, radio was actually ignoring it because command wasn't terminated with a CR. This is now corrected. To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: George B. <geo...@gm...> - 2025-06-20 18:45:35
|
Yes, it is broken. i think I have found the problem - your description was very detailed, thank you. Fixing it may take a few days, mostly to determine the scope of the affected data, and to make sure there are no loose ends. In the meantime, the problem is being tracked as an issue on github at https://github.com/Hamlib/Hamlib/issues/1748. 73 n3gb On 5/23/25 9:16 PM, Stephen Pattinson via Hamlib-developer wrote: > Hi, > > I have several programs that interrogate rigctld simultaneously which > among other things request various radio parameters from my IC-7300 > every second. With just one rigctld client program running I have no > issue, but I have discovered a number of issues that the developers > may or may not consider worth of rectification, when multiple rigctld > clients request radio parameters more of less simultaneously. > > I can work around these issues, but nevertheless, I think they are > worth of reporting. > > Hamlib version is - hamlib-w64-4.6.2 > > Windows (10) DOS Command to start rigctld is as follows: “rigctld -m > 3073 -r COM4 -s 115200 -vvv” > > These issues are probably all related or indeed have the same cause, > but I’ll list separately. > > 1 – Two Python programs are requesting the ptt status of the radio > every second. There is no synchronization between the two programs, so > whether or not they request the ptt status at the same time is hard to > say. The programs also request the frequency and mode of the radio. > > Both programs request the ptt status using the “extended” method, ie > the TCP message is (in Python code). I’m using the optional ‘|’ > separator as can be seen from the code snippet > > sentBytes = rigctldSock.sendall(b'|t\n') > response = rigctldSock.recv(1024) > > The response should be b'get_ptt:|PTT: 0|RPRT > 0\n' > however, every now and again, the response is of the form > b'get_ptt:\nPTT: 0\nRPRT 0\n' > > which causes my parsing to fail. The response looks like the result as > if the ‘+’ separator was used, however this is not the case. Perhaps I > can avoid this by using the ‘+’ separator, but it shouldn’t be necessary. > > 2- Running the commercial LOG4OM program which is configured to use > the “Hamlib NET rigctl Stable” rig model, and one of my Python > programs has a similar effect as described in issue 1 above. I don’t > of course know the exact command that LOG4OM is using other than it is > communicating to rigctld on port 4532. > > Also, the issue arises with multiple parameters. Once again, my > program uses the ‘|’ separator character. I don’t know what LOG4OM > uses, or indeed if it uses the “extended” or “default” method. > > As before, expected responses are of the form ( for get_ptt and > get_mode commands) > > b'get_ptt:|PTT: 0|RPRT 0\n' > b'get_mode:|Mode: LSB|Passband: 2400|RPRT 0\n' > > however, occasionally the responses are > > b'get_ptt:\nPTT: 0\nRPRT 0\n' > b'get_mode:\nMode: LSB\nPassband: 2400\nRPRT 0\n' > > which fails my parsing due to the LF char unexpectedly replacing the > ‘|’ char. > > The cause is no doubt the same as in issue one. It may or may not > matter if two programs accessing rigctld use the same separator > character. > > 3 – A similar issue arises if one rigctld TCP client is using the > “default” protocol and other the “extended” protocol more of less > simultaneously. > > For example, I have one Python program accessing rig frequency using > the “extended” protocol which results in a response of this form > > b'get_freq:|Frequency: 1424840|RPRT 0\n' > > at the same approximate time, the second client program uses the > “default” protocol which results in a response of this form > > b'1424840\n' > > however, every once in a while, the response to the “default” protocol > results in this response > > b'1424840|\n' > > It appears that the “default” response has been “infected” by the > separation character of the “extended” response due to the other client. > > Of course, maybe I shouldn’t allow mixing of the two types of request, > but of course I have no easy way of knowing what any other arbitrary > program might be using that may simultaneously request radio parameters. > > In summary, I feel these issues which probably all have the same root > cause may warrant looking at, but I will totally understand if it is > regarded as low priority or not worth fixing. In my case, I’ll > probably alter my programs to use the ‘+’ separator character that > results in ‘\n’ characters separating the fields as I suspect this is > what is usually used. > > Thanks for reading. > Rgds > Steve > VK3SPX > > > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: G0GJV <g0...@go...> - 2025-06-20 09:55:34
|
I'm not suggesting getting rid of threading - just that I don't think it is needed in rig.h, where it makes compilation of user code with MSVC difficult. Hamlib itself can use it with the mingw libraries; if rig.h facilities need it then provide a separate interface into it. Mike > It might be possible but a lot of things won't work - some by design > (multicast, async data like IC-7300 spectrum, etc.), and some by bit > rot(CW keying, multiple connections to rigctld, maybe multithreaded > applications). I'm not sure it's worth the effort since any app with a > GUI nowadays will probably be using threads. > > The #ifdef/#endif usage by the thread code is very suspect - it would > require vetting each one, and fixing the '#include "config.h"' usage in > each file. It's easier to just use it as required. > > 73 n3gb > > On 6/19/25 3:24 PM, G0GJV wrote: > > Could we get rid of threads entirely from rig.h? I've never understood > > why Mike wanted it there. > > > > Mike G0GJV > > > >> 4.6.x won't compile without P_THREADS - make that an overt requirement. > > |
|
From: Mikael N. <mik...@fa...> - 2025-06-20 07:49:07
|
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 |
|
From: Nate B. <n0...@n0...> - 2025-06-19 23:41:34
|
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. > * 4.6.x won't compile without P_THREADS - make that an overt requirement. This should be a 4.7.0 target. > * 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. > 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. > 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. > 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. 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 -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 |
|
From: George B. <geo...@gm...> - 2025-06-19 22:07:25
|
It might be possible but a lot of things won't work - some by design (multicast, async data like IC-7300 spectrum, etc.), and some by bit rot(CW keying, multiple connections to rigctld, maybe multithreaded applications). I'm not sure it's worth the effort since any app with a GUI nowadays will probably be using threads. The #ifdef/#endif usage by the thread code is very suspect - it would require vetting each one, and fixing the '#include "config.h"' usage in each file. It's easier to just use it as required. 73 n3gb On 6/19/25 3:24 PM, G0GJV wrote: > Could we get rid of threads entirely from rig.h? I've never understood > why Mike wanted it there. > > Mike G0GJV > >> 4.6.x won't compile without P_THREADS - make that an overt requirement. > > > > > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: G0GJV <g0...@go...> - 2025-06-19 19:44:34
|
Could we get rid of threads entirely from rig.h? I've never understood why Mike wanted it there. Mike G0GJV > 4.6.x won't compile without P_THREADS - make that an overt requirement. |
33 messages has been excluded from this view by a project administrator.
