hamlib-developer Mailing List for Ham Radio Control Libraries (Page 7)
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
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|
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. |
|
From: George B. <geo...@gm...> - 2025-06-19 19:04:07
|
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 |
|
From: Daniele F. <iu...@gm...> - 2025-06-18 21:26:10
|
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) * the tests that currently use the Dummy devices working also with the simulators (and with real hardware where it makes sense) * the work done by George for the cache * the work done by George for thread safety (is it finished?) -- 73 de IU5HKX Daniele |
|
From: Nate B. <n0...@n0...> - 2025-06-18 20:08:06
|
* On 2025 18 Jun 13:16 -0500, Daniel Hice wrote: > Rodger just replied, it is expected by the end of June. 🤞 Thanks, Daniel. 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: Daniel H. <da...@ad...> - 2025-06-18 18:16:11
|
Rodger just replied, it is expected by the end of June. 🤞 73 Daniel Hice, AD2GL ________________________________ From: Nate Bargmann <n0...@n0...> Sent: Wednesday, June 18, 2025 1:53 PM To: Daniel Hice <da...@ad...> Cc: ham...@li... <ham...@li...> Subject: Re: [Hamlib-developer] Yaesu FTX-1 * On 2025 18 Jun 12:00 -0500, Daniel Hice wrote: > Nate, > > I just dropped Rodger a note asking about it. He’s been quite > responsive to my question, but US support doesn’t seem to have much > more info than us consumers. Fingers crossed either way 😊 It makes me wonder if they're still developing firmware and that is being reflected in changing CAT commands as the reason for the delay. > When I asked about this directly with the WSJT-X group they said HRD > works perfectly fine as a CAT already. Are there any collaborations > between the programs or not with them being commercial? Between HRD and Hamlib? No. Between WSJT-X and Hamlib? Some. Two SKs, Bill Sommerville, G4WJS, and Mike, W9MDB, both worked in the WSJT-X project or were very closely associated with it and also here, but other than that, no one has revealed an association. 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-18 17:53:30
|
* On 2025 18 Jun 12:00 -0500, Daniel Hice wrote: > Nate, > > I just dropped Rodger a note asking about it. He’s been quite > responsive to my question, but US support doesn’t seem to have much > more info than us consumers. Fingers crossed either way 😊 It makes me wonder if they're still developing firmware and that is being reflected in changing CAT commands as the reason for the delay. > When I asked about this directly with the WSJT-X group they said HRD > works perfectly fine as a CAT already. Are there any collaborations > between the programs or not with them being commercial? Between HRD and Hamlib? No. Between WSJT-X and Hamlib? Some. Two SKs, Bill Sommerville, G4WJS, and Mike, W9MDB, both worked in the WSJT-X project or were very closely associated with it and also here, but other than that, no one has revealed an association. 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-18 17:45:49
|
----- Forwarded message from David Balharrie <da...@ba...> ----- Date: Wed, 18 Jun 2025 16:43:13 +0000 From: David Balharrie <da...@ba...> To: Nate Bargmann <n0...@n0...> Subject: RE: [Hamlib-developer] Yaesu FTX-1 I found this on a groups.io talking about the FTx-1 and CAT/WSJTX " Got this working this morning. Using Standard Yaesu USB driver, Ham Radio Deluxe configured for FTDX10 and linked to WSJT-X to HRD. Not sure why the other variations I tried didn't work, however this is a satisfactory solution for me. Alan AK6DG" Link to the thread.. https://groups.io/g/FTX-1F/topic/cat_control/113179751 It might not be too difficult to get it working in Hamlib.. 73 de David M0DGB/G8FKH -----Original Message----- From: Nate Bargmann <n0...@n0...> Sent: 18 June 2025 17:30 To: Daniel Hice <da...@ad...> Cc: ham...@li... Subject: Re: [Hamlib-developer] Yaesu FTX-1 As a follow up, I did check the Yaseu site earlier and while several manuals are listed, I didn't find a CAT command reference among them. I wonder if they'd provide one upon request? 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 ----- End forwarded message ----- -- "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: Daniel H. <da...@ad...> - 2025-06-18 16:59:52
|
Nate, I just dropped Rodger a note asking about it. He’s been quite responsive to my question, but US support doesn’t seem to have much more info than us consumers. Fingers crossed either way 😊 When I asked about this directly with the WSJT-X group they said HRD works perfectly fine as a CAT already. Are there any collaborations between the programs or not with them being commercial? On 6/18/25, 12:30, "Nate Bargmann" <n0...@n0...> wrote: As a follow up, I did check the Yaseu site earlier and while several manuals are listed, I didn't find a CAT command reference among them. I wonder if they'd provide one upon request? 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-18 16:30:41
|
As a follow up, I did check the Yaseu site earlier and while several manuals are listed, I didn't find a CAT command reference among them. I wonder if they'd provide one upon request? 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-18 16:28:55
|
* 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 -- "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-18 15:44:13
|
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. We would need some volunteers who have one to check out the daily builds and give feedback. It is ready when it is ready. 73 n3gb On 6/15/25 11:27 AM, Nate Bargmann wrote: > I have received a couple of private queries about when support will land > for the FTX-1. One of those queries also admitted that Yaesu has not > released a programmer's reference for it yet. Whether it would be > available under an NDA, I don't know. > > I do know that I won't be buying one! The question I do have is that > apparently there is interest in it and I hope someone finds a recent > Yaesu model that will enable it to work with WSJT-X, et. al. in the > interim, should a 4.7.0 release be more or less contingent on when > support for this radio is added? > > 73, Nate > > > > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Nate B. <n0...@n0...> - 2025-06-18 13:38:22
|
* On 2025 18 Jun 07:18 -0500, Daniel Hice wrote: > Good afternoon, > > Apologies if I’m 10,000+ in line. Is there a planned update to add > support for the Yaesu FTX-1? Is there anything I can provide to > assist? Hi Daniel. You're only about third or fourth in line. 🤣 I was told in one private query that the programmer's reference is still unavailable from Yaesu. Being able to get documentation on the radio would be the biggest help. 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-18 03:09:14
|
Branch: refs/heads/Hamlib-4.6.3 Home: https://github.com/Hamlib/Hamlib Commit: b365b0afe0886d5b183e1739953f62f472b12631 https://github.com/Hamlib/Hamlib/commit/b365b0afe0886d5b183e1739953f62f472b12631 Author: Lars Kellogg-Stedman <la...@od...> Date: 2025-06-17 (Tue, 17 Jun 2025) Changed paths: M rigs/kenwood/kenwood.c Log Message: ----------- Un-break hamlib on TM-D710/TM-V71/etc Commit d1e0e3f introduced a `remove_nonprint` method that breaks hamlib on all TM-D710/TM-V71A devices by erroneously removing the command termination character (`\r`). This commit adopts a solution proposed by @GeoBaltz that only runs `remove_nonprint` if the command termination character itself is printable. Resolves: #1767 #1698 (cherry picked from commit 85c9e15eac641ddddad57fc4b1683becaa6d7e83) Commit: cea177f3959cb57673573273f839bea2450f93b5 https://github.com/Hamlib/Hamlib/commit/cea177f3959cb57673573273f839bea2450f93b5 Author: Nate Bargmann <n0...@n0...> Date: 2025-06-17 (Tue, 17 Jun 2025) Changed paths: M NEWS Log Message: ----------- Update NEWS on Kenwood command terminator fix Compare: https://github.com/Hamlib/Hamlib/compare/371db9ffd2ef...cea177f3959c To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
|
From: Nate B. <no...@gi...> - 2025-06-18 02:52:37
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 85c9e15eac641ddddad57fc4b1683becaa6d7e83 https://github.com/Hamlib/Hamlib/commit/85c9e15eac641ddddad57fc4b1683becaa6d7e83 Author: Lars Kellogg-Stedman <la...@od...> Date: 2025-06-17 (Tue, 17 Jun 2025) Changed paths: M rigs/kenwood/kenwood.c Log Message: ----------- Un-break hamlib on TM-D710/TM-V71/etc Commit d1e0e3f introduced a `remove_nonprint` method that breaks hamlib on all TM-D710/TM-V71A devices by erroneously removing the command termination character (`\r`). This commit adopts a solution proposed by @GeoBaltz that only runs `remove_nonprint` if the command termination character itself is printable. Resolves: #1767 #1698 Commit: b25ba02aca830895fe63d7aadbfd1918398e463e https://github.com/Hamlib/Hamlib/commit/b25ba02aca830895fe63d7aadbfd1918398e463e Author: Nate Bargmann <n0...@n0...> Date: 2025-06-17 (Tue, 17 Jun 2025) Changed paths: M NEWS Log Message: ----------- Update news on Kenwood command terminator fix Compare: https://github.com/Hamlib/Hamlib/compare/aca0b2d1c63e...b25ba02aca83 To unsubscribe from these emails, change your notification settings at https://github.com/Hamlib/Hamlib/settings/notifications |
33 messages has been excluded from this view by a project administrator.
