hamlib-developer Mailing List for Ham Radio Control Libraries (Page 111)
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
(40) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michael B. <no...@gi...> - 2022-09-03 18:11:37
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 81f489b969d39d5460efe36b16fe3290e56d6186 https://github.com/Hamlib/Hamlib/commit/81f489b969d39d5460efe36b16fe3290e56d6186 Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-09-03 (Sat, 03 Sep 2022) Changed paths: M README.win32 A scripts/MSVC/2022/x64/hamlibTest/Resource.h A scripts/MSVC/2022/x64/hamlibTest/framework.h A scripts/MSVC/2022/x64/hamlibTest/hamlibTest.cpp A scripts/MSVC/2022/x64/hamlibTest/hamlibTest.h A scripts/MSVC/2022/x64/hamlibTest/hamlibTest.ico A scripts/MSVC/2022/x64/hamlibTest/hamlibTest.rc A scripts/MSVC/2022/x64/hamlibTest/hamlibTest.sln A scripts/MSVC/2022/x64/hamlibTest/hamlibTest.vcxproj A scripts/MSVC/2022/x64/hamlibTest/hamlibTest.vcxproj.user A scripts/MSVC/2022/x64/hamlibTest/hamlibTest2.cpp A scripts/MSVC/2022/x64/hamlibTest/libhamlib-4.def A scripts/MSVC/2022/x64/hamlibTest/libhamlib-4.exp A scripts/MSVC/2022/x64/hamlibTest/libhamlib-4.lib A scripts/MSVC/2022/x64/hamlibTest/libhamlib.def A scripts/MSVC/2022/x64/hamlibTest/makelib.bat A scripts/MSVC/2022/x64/hamlibTest/packages.config A scripts/MSVC/2022/x64/hamlibTest/small.ico A scripts/MSVC/2022/x64/hamlibTest/targetver.h A scripts/MSVC/2022/x86/hamlibTest/README.txt A scripts/MSVC/2022/x86/hamlibTest/Resource.h A scripts/MSVC/2022/x86/hamlibTest/framework.h A scripts/MSVC/2022/x86/hamlibTest/hamlibTest.cpp A scripts/MSVC/2022/x86/hamlibTest/hamlibTest.h A scripts/MSVC/2022/x86/hamlibTest/hamlibTest.ico A scripts/MSVC/2022/x86/hamlibTest/hamlibTest.rc A scripts/MSVC/2022/x86/hamlibTest/hamlibTest.sln A scripts/MSVC/2022/x86/hamlibTest/hamlibTest.vcxproj A scripts/MSVC/2022/x86/hamlibTest/hamlibTest.vcxproj.user A scripts/MSVC/2022/x86/hamlibTest/hamlibTest2.cpp A scripts/MSVC/2022/x86/hamlibTest/libhamlib-4.lib A scripts/MSVC/2022/x86/hamlibTest/libhamlib.def A scripts/MSVC/2022/x86/hamlibTest/makelib.bat A scripts/MSVC/2022/x86/hamlibTest/packages.config A scripts/MSVC/2022/x86/hamlibTest/small.ico A scripts/MSVC/2022/x86/hamlibTest/targetver.h Log Message: ----------- Add MSVC projects to scripts/MSVC for 32 and 64-bit builds in C++ https://github.com/Hamlib/Hamlib/milestone/14 |
|
From: G0GJV <g0...@go...> - 2022-09-03 18:04:06
|
Thanks Mike - I'll try it tomorrow Mike G0GJV > That should be fixed in the github repository now -- package will > be available 20220904 later tonight. > Mike W9MDB > > > > On Saturday, September 3, 2022 at 10:49:28 AM CDT, G0GJV <g0...@go...> > wrote: > > Mike > > It's showing promise; I have to define HAVE_STRUCT_TIMESPEC or timespec gets defined > twice > > More testing needed. > > Mike G0GJV > > > I may have another solution. > > There is a NUGet pthread package. > > Can you add that to your project and then change rig.hFrom#if defined(_MSC_VER)#include > > <hamlib/winpthreads.h>#else#include <pthread.h>#endif > > To just#include <pthread.h> > > And see if that compiles cleanly for you.ÃÂ I would prefer not to > > reinvent the wheel -- especially if there's a working pthread package > > for MSVC. > > Mike W9MDB > > > > > > > >Â > > > >Â Â On Wednesday, August 31, 2022 at 10:15:38 AM CDT, G0GJV > <g0...@go...> > > wrote:Â > >Â > >Â I've gone back to basics, and regenerated everything. > > > > I can now build and run with MSVC. My main Qt build now has it's own > > compilation issues - none of you concern! > > > > BUT if I add e.g. > > > > #include <io.h> > > > > after > > > > #include <hamlib/rig.h> > > > > the #defines of /* Wrap cancellation points */ > > > > after l1381 in winpthreads.h causes all sorts of problems. > > > > I note that in the original pthreads.h these get skipped unless > > __WINPTRHEAD_ENABLE_WRAP_API is defined. > > > > Maybe this should be included in your winpthreads.h? > > > > Also, if you include rig.h in multiple compilation units, I get linker > > complaints that the winpthreads functions are defined multiple times. > > > > Mike G0GJV > > > > > I still cannot compile and run with MSVC > > > > > > What are you compiling, with which compiler? > > > > > > Mike G0GJV > > > > > > > So what's your status on this?ÃÂ My compile worked. > > > > > > > > Mike W9MDB |
|
From: Black M. <mdb...@ya...> - 2022-09-03 16:33:36
|
That should be fixed in the github repository now -- package will be available 20220904 later tonight.
Mike W9MDB
On Saturday, September 3, 2022 at 10:49:28 AM CDT, G0GJV <g0...@go...> wrote:
Mike
It's showing promise; I have to define HAVE_STRUCT_TIMESPEC or timespec gets defined
twice
More testing needed.
Mike G0GJV
> I may have another solution.
> There is a NUGet pthread package.
> Can you add that to your project and then change rig.hFrom#if defined(_MSC_VER)#include
> <hamlib/winpthreads.h>#else#include <pthread.h>#endif
> To just#include <pthread.h>
> And see if that compiles cleanly for you. I would prefer not to
> reinvent the wheel -- especially if there's a working pthread package
> for MSVC.
> Mike W9MDB
>
>
>
>
>
> On Wednesday, August 31, 2022 at 10:15:38 AM CDT, G0GJV <g0...@go...>
> wrote:
>
> I've gone back to basics, and regenerated everything.
>
> I can now build and run with MSVC. My main Qt build now has it's own
> compilation issues - none of you concern!
>
> BUT if I add e.g.
>
> #include <io.h>
>
> after
>
> #include <hamlib/rig.h>
>
> the #defines of /* Wrap cancellation points */
>
> after l1381 in winpthreads.h causes all sorts of problems.
>
> I note that in the original pthreads.h these get skipped unless
> __WINPTRHEAD_ENABLE_WRAP_API is defined.
>
> Maybe this should be included in your winpthreads.h?
>
> Also, if you include rig.h in multiple compilation units, I get linker
> complaints that the winpthreads functions are defined multiple times.
>
> Mike G0GJV
>
> > I still cannot compile and run with MSVC
> >
> > What are you compiling, with which compiler?
> >
> > Mike G0GJV
> >
> > > So what's your status on this? My compile worked.
> > >
> > > Mike W9MDB
_______________________________________________
Hamlib-developer mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-developer
|
|
From: Michael B. <no...@gi...> - 2022-09-03 16:21:11
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 1d0d73340547f7c0f49a5dda34fc7443ac7c647c https://github.com/Hamlib/Hamlib/commit/1d0d73340547f7c0f49a5dda34fc7443ac7c647c Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-09-03 (Sat, 03 Sep 2022) Changed paths: M README.win32 M include/Makefile.am M include/hamlib/rig.h Log Message: ----------- Remove winpthreads.h MSVC build now needs NuGet pthreads package to compile https://github.com/Hamlib/Hamlib/issues/1107 |
|
From: Michael B. <no...@gi...> - 2022-09-03 16:13:25
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 571f59e696f474ee3cffe35a8a3a74e20d68e055 https://github.com/Hamlib/Hamlib/commit/571f59e696f474ee3cffe35a8a3a74e20d68e055 Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-09-03 (Sat, 03 Sep 2022) Changed paths: M simulators/simicom9700.c Log Message: ----------- Add an async freq report to simicom9700 https://github.com/Hamlib/Hamlib/issues/1108 |
|
From: G0GJV <g0...@go...> - 2022-09-03 15:49:03
|
Mike It's showing promise; I have to define HAVE_STRUCT_TIMESPEC or timespec gets defined twice More testing needed. Mike G0GJV > I may have another solution. > There is a NUGet pthread package. > Can you add that to your project and then change rig.hFrom#if defined(_MSC_VER)#include > <hamlib/winpthreads.h>#else#include <pthread.h>#endif > To just#include <pthread.h> > And see if that compiles cleanly for you. I would prefer not to > reinvent the wheel -- especially if there's a working pthread package > for MSVC. > Mike W9MDB > > > > > > On Wednesday, August 31, 2022 at 10:15:38 AM CDT, G0GJV <g0...@go...> > wrote: > > I've gone back to basics, and regenerated everything. > > I can now build and run with MSVC. My main Qt build now has it's own > compilation issues - none of you concern! > > BUT if I add e.g. > > #include <io.h> > > after > > #include <hamlib/rig.h> > > the #defines of /* Wrap cancellation points */ > > after l1381 in winpthreads.h causes all sorts of problems. > > I note that in the original pthreads.h these get skipped unless > __WINPTRHEAD_ENABLE_WRAP_API is defined. > > Maybe this should be included in your winpthreads.h? > > Also, if you include rig.h in multiple compilation units, I get linker > complaints that the winpthreads functions are defined multiple times. > > Mike G0GJV > > > I still cannot compile and run with MSVC > > > > What are you compiling, with which compiler? > > > > Mike G0GJV > > > > > So what's your status on this? My compile worked. > > > > > > Mike W9MDB |
|
From: Brian M. <bd...@fe...> - 2022-09-03 14:44:20
|
On Wed, 17 Aug 2022 17:45:37 +0100 Brian Morrison <bd...@fe...> wrote: > > The freedv code has now been modified to move the hamlib calls into a > > separate thread, this debug output is now no longer appearing. > > > > No, I was wrong, this is still occurring when a VFO is selected but not > when in Memory mode on the TS-890. As a further report, the current git version as of today, September 3rd, does not seem to have this problem, I suspect that recent clean-ups of the VFO debug and Icom debug code has reduced the time taken by the commands and these time-outs are no longer occurring. -- Brian G8SEZ |
|
From: Black M. <mdb...@ya...> - 2022-09-03 13:05:10
|
I may have another solution.
There is a NUGet pthread package.
Can you add that to your project and then change rig.hFrom#if defined(_MSC_VER)#include <hamlib/winpthreads.h>#else#include <pthread.h>#endif
To just#include <pthread.h>
And see if that compiles cleanly for you. I would prefer not to reinvent the wheel -- especially if there's a working pthread package for MSVC.
Mike W9MDB
On Wednesday, August 31, 2022 at 10:15:38 AM CDT, G0GJV <g0...@go...> wrote:
I've gone back to basics, and regenerated everything.
I can now build and run with MSVC. My main Qt build now has it's own
compilation issues - none of you concern!
BUT if I add e.g.
#include <io.h>
after
#include <hamlib/rig.h>
the #defines of /* Wrap cancellation points */
after l1381 in winpthreads.h causes all sorts of problems.
I note that in the original pthreads.h these get skipped unless
__WINPTRHEAD_ENABLE_WRAP_API is defined.
Maybe this should be included in your winpthreads.h?
Also, if you include rig.h in multiple compilation units, I get linker
complaints that the winpthreads functions are defined multiple times.
Mike G0GJV
> I still cannot compile and run with MSVC
>
> What are you compiling, with which compiler?
>
> Mike G0GJV
>
> > So what's your status on this? My compile worked.
> >
> > Mike W9MDB
_______________________________________________
Hamlib-developer mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-developer
|
|
From: Michael B. <no...@gi...> - 2022-09-02 13:06:51
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: d3824aa7abcfa1856097bc31777198d3e50241e7 https://github.com/Hamlib/Hamlib/commit/d3824aa7abcfa1856097bc31777198d3e50241e7 Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-09-02 (Fri, 02 Sep 2022) Changed paths: M src/rig.c Log Message: ----------- Reset all cache when changing VFOs on a rig without get_vfo https://github.com/Hamlib/Hamlib/issues/1108 |
|
From: Michael B. <no...@gi...> - 2022-09-02 13:05:41
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 927b2d858ab2710301c26c04a40316c6bc4a6e8d https://github.com/Hamlib/Hamlib/commit/927b2d858ab2710301c26c04a40316c6bc4a6e8d Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-09-02 (Fri, 02 Sep 2022) Changed paths: M src/cache.c Log Message: ----------- Update debug in cache.c https://github.com/Hamlib/Hamlib/issues/1108 |
|
From: Michael B. <no...@gi...> - 2022-09-02 13:00:35
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 5701e73e1e38f3c8818b26044f7734f109d164dc https://github.com/Hamlib/Hamlib/commit/5701e73e1e38f3c8818b26044f7734f109d164dc Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-08-31 (Wed, 31 Aug 2022) Changed paths: M rigs/icom/icom.c M rigs/icom/icom.h Log Message: ----------- Fix valgrind warning https://github.com/Hamlib/Hamlib/issues/1108 Commit: e630fc818005f551e4fccf522a0fd71d73b42d54 https://github.com/Hamlib/Hamlib/commit/e630fc818005f551e4fccf522a0fd71d73b42d54 Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-09-01 (Thu, 01 Sep 2022) Changed paths: M simulators/simicom9700.c Log Message: ----------- Update simicom9700.c Commit: e2616b991a6cc6fa22c6f0e77fd437aa5aa17bfd https://github.com/Hamlib/Hamlib/commit/e2616b991a6cc6fa22c6f0e77fd437aa5aa17bfd Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-09-02 (Fri, 02 Sep 2022) Changed paths: M src/misc.c Log Message: ----------- Add RIG_VFO_ALL for rig_strvfo() Commit: 9410e7f66f2a6b789dc5fa0dc2534837688477c4 https://github.com/Hamlib/Hamlib/commit/9410e7f66f2a6b789dc5fa0dc2534837688477c4 Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-09-02 (Fri, 02 Sep 2022) Changed paths: Log Message: ----------- Merge branch 'master' of https://github.com/Hamlib/Hamlib Compare: https://github.com/Hamlib/Hamlib/compare/69a39dfa2e33...9410e7f66f2a |
|
From: Black M. <mdb...@ya...> - 2022-08-31 15:26:42
|
Yeah...that guy decided to put static functions and such in the include rather than separating them.Need to fix that.
Mike
On Wednesday, August 31, 2022 at 10:15:38 AM CDT, G0GJV <g0...@go...> wrote:
I've gone back to basics, and regenerated everything.
I can now build and run with MSVC. My main Qt build now has it's own
compilation issues - none of you concern!
BUT if I add e.g.
#include <io.h>
after
#include <hamlib/rig.h>
the #defines of /* Wrap cancellation points */
after l1381 in winpthreads.h causes all sorts of problems.
I note that in the original pthreads.h these get skipped unless
__WINPTRHEAD_ENABLE_WRAP_API is defined.
Maybe this should be included in your winpthreads.h?
Also, if you include rig.h in multiple compilation units, I get linker
complaints that the winpthreads functions are defined multiple times.
Mike G0GJV
> I still cannot compile and run with MSVC
>
> What are you compiling, with which compiler?
>
> Mike G0GJV
>
> > So what's your status on this? My compile worked.
> >
> > Mike W9MDB
_______________________________________________
Hamlib-developer mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-developer
|
|
From: G0GJV <g0...@go...> - 2022-08-31 15:15:12
|
I've gone back to basics, and regenerated everything. I can now build and run with MSVC. My main Qt build now has it's own compilation issues - none of you concern! BUT if I add e.g. #include <io.h> after #include <hamlib/rig.h> the #defines of /* Wrap cancellation points */ after l1381 in winpthreads.h causes all sorts of problems. I note that in the original pthreads.h these get skipped unless __WINPTRHEAD_ENABLE_WRAP_API is defined. Maybe this should be included in your winpthreads.h? Also, if you include rig.h in multiple compilation units, I get linker complaints that the winpthreads functions are defined multiple times. Mike G0GJV > I still cannot compile and run with MSVC > > What are you compiling, with which compiler? > > Mike G0GJV > > > So what's your status on this? My compile worked. > > > > Mike W9MDB |
|
From: Michael B. <no...@gi...> - 2022-08-31 13:57:04
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 69a39dfa2e335d1208a4cf692690e61f9dd33ba9 https://github.com/Hamlib/Hamlib/commit/69a39dfa2e335d1208a4cf692690e61f9dd33ba9 Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-08-31 (Wed, 31 Aug 2022) Changed paths: M rigs/icom/icom.c M rigs/icom/icom.h Log Message: ----------- Fix valgrind warning |
|
From: Black M. <mdb...@ya...> - 2022-08-31 13:36:08
|
# Visual Studio Version 16VisualStudioVersion = 16.0.32428.217 Can you install AnyDesk and we can hook up? https://anydesk.com/en On Wednesday, August 31, 2022 at 08:26:34 AM CDT, G0GJV <g0...@go...> wrote: I still cannot compile and run with MSVC What are you compiling, with which compiler? Mike G0GJV > So what's your status on this? My compile worked. > > Mike W9MDB _______________________________________________ Hamlib-developer mailing list Ham...@li... https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: G0GJV <g0...@go...> - 2022-08-31 13:26:13
|
I still cannot compile and run with MSVC What are you compiling, with which compiler? Mike G0GJV > So what's your status on this? My compile worked. > > Mike W9MDB |
|
From: Black M. <mdb...@ya...> - 2022-08-31 12:50:19
|
So what's your status on this? My compile worked.
Mike W9MDB
On Saturday, August 27, 2022 at 11:21:01 AM CDT, Black Michael <mdb...@ya...> wrote:
Yes
On Saturday, August 27, 2022 at 10:58:10 AM CDT, G0GJV <g0...@go...> wrote:
Mike
Do you have a Qt installation under windows?
Mike G0GJV
> Mike
>
> It's open source
>
> https://sourceforge.net/projects/minos
>
> I'll try creating a Qt example.
>
> Mike G0GJV
>
> > Your test program compiles OK though, right? The one you sent me?
> > I need your project files for the Qt version.
> >
> >
> >
> > On Saturday, August 27, 2022 at 08:26:50 AM CDT, G0GJV
> <g0...@go...>
> > wrote:
> >
> > Yes. When it showed missing, I went looking for it!
> >
> > I haven't yet managed to build a .lib for it, but as it
> won't compile that isn't currently
> > important.
> >
> > Mike G0GJV
> >
> > > Did you use the winpthreads.h from the github repository?
> > > https://github.com/Hamlib/Hamlib/tree/master/include/hamlib
> > >
> > > Mike
> > >
> > >Â
> > >
> > >Â Â On Saturday, August 27, 2022 at 06:56:23 AM CDT, G0GJV
> > <g0...@go...>
> > > wrote:Â
> > >Â
> > >Â Mike
> > >
> > > winpthreads.h hasn't made it into the overnight zip.
> > >
> > > When I add it manually, I find that it creates some serious clashes with Qt!
> > >
> > > Why do you need to expose pthreads to the application
> builder? It looks like it is just
> > > for
> > >
> > > pthread_mutex_t mutex_set_transaction;
> > >
> > > Can't you put this somewhere else, and have a
> void * to point to it in rig.h? This would
> > > remove the need for a large #include, and would compile easily everywhere.
> > >
> > > Mike G0GJV
_______________________________________________
Hamlib-developer mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-developer
|
|
From: Black M. <mdb...@ya...> - 2022-08-30 13:11:12
|
There are no Icom rigs that know what VFO they are on.
Icom does not provide that capability at all and trying to figure it out is problematic. Can't rely on "knowing" the VFO state in Hamlib since user can push buttons.
Mike W9MDB
On Tuesday, August 30, 2022 at 07:54:17 AM CDT, Saku <oh...@sr...> wrote:
Hi!
It seems you are running Cqrlog. It uses "fmv".
ICOM models (some I know) can not answer to "v" (VFO) question. I have IC7300 by my self. It can not tell vfo.
I recommend to upgrade to Hamlib 4.5 and Cqrlog 2.6.0
ham...@li... kirjoitti 29.8.2022 klo 15.27:
| Aihe: [Hamlib-developer] rigctld, problem |
| Lähettäjä: <ja...@oh...> |
| Päiväys: 29.8.2022 klo 11.41 |
| Vastaanottaja: <ham...@li...> |
Hi,
I am using rigctld from Hamlib 3.3, talking to an Icom 7300 receiver. The software cqrlog calls rigctld regularly with the command fmv but this is not answered.
If I use a telnet command to the port connected to rigctld, it answers the commands f m and v correctly, if issued separately. However, if I use the whole string fmv as a command, it won´t answer.
What should I do abouit this?
Kind regards,
Jan
--
Saku
OH1KH _______________________________________________
Hamlib-developer mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-developer
|
|
From: Saku <oh...@sr...> - 2022-08-30 12:53:54
|
Hi! It seems you are running Cqrlog. It uses "fmv". ICOM models (some I know) can not answer to "v" (VFO) question. I have IC7300 by my self. It can not tell vfo. I recommend to upgrade to Hamlib 4.5 and Cqrlog 2.6.0 ham...@li... kirjoitti 29.8.2022 klo 15.27: > Aihe: > [Hamlib-developer] rigctld, problem > Lähettäjä: > <ja...@oh...> > Päiväys: > 29.8.2022 klo 11.41 > > Vastaanottaja: > <ham...@li...> > > > Hi, > > I am using rigctld from Hamlib 3.3, talking to an Icom 7300 receiver. > The software cqrlog calls rigctld regularly with the command fmv but > this is not answered. > > If I use a telnet command to the port connected to rigctld, it answers > the commands f m and v correctly, if issued separately. However, if I > use the whole string fmv as a command, it won´t answer. > > What should I do abouit this? > > Kind regards, > > Jan > -- Saku OH1KH |
|
From: Michael B. <no...@gi...> - 2022-08-29 17:50:40
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 5e9b853d0791cae2d9bbb9e364052134866de843 https://github.com/Hamlib/Hamlib/commit/5e9b853d0791cae2d9bbb9e364052134866de843 Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-08-29 (Mon, 29 Aug 2022) Changed paths: M src/rig.c Log Message: ----------- Reduce debug in rig_set_vfo |
|
From: Michael B. <no...@gi...> - 2022-08-29 15:12:13
|
Branch: refs/heads/master Home: https://github.com/Hamlib/Hamlib Commit: 7e51932a9ec55d75f74768c27fb40e9819170066 https://github.com/Hamlib/Hamlib/commit/7e51932a9ec55d75f74768c27fb40e9819170066 Author: Mike Black W9MDB <mdb...@ya...> Date: 2022-08-29 (Mon, 29 Aug 2022) Changed paths: M rigs/icom/icom.c Log Message: ----------- Remove some debug from icom.c |
|
From: <ja...@oh...> - 2022-08-29 08:57:43
|
Hi, I am using rigctld from Hamlib 3.3, talking to an Icom 7300 receiver. The software cqrlog calls rigctld regularly with the command fmv but this is not answered. If I use a telnet command to the port connected to rigctld, it answers the commands f m and v correctly, if issued separately. However, if I use the whole string fmv as a command, it won´t answer. What should I do abouit this? Kind regards, Jan |
|
From: Nate B. <n0...@n0...> - 2022-08-27 19:24:25
|
* On 2022 27 Aug 06:57 -0500, G0GJV wrote: > Mike > > winpthreads.h hasn't made it into the overnight zip. Hi Mike. I made a fix this morning and uploaded new versions of the files. winpthreads.h should be in the archive now. 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: Black M. <mdb...@ya...> - 2022-08-27 16:21:13
|
Yes
On Saturday, August 27, 2022 at 10:58:10 AM CDT, G0GJV <g0...@go...> wrote:
Mike
Do you have a Qt installation under windows?
Mike G0GJV
> Mike
>
> It's open source
>
> https://sourceforge.net/projects/minos
>
> I'll try creating a Qt example.
>
> Mike G0GJV
>
> > Your test program compiles OK though, right? The one you sent me?
> > I need your project files for the Qt version.
> >
> >
> >
> > On Saturday, August 27, 2022 at 08:26:50 AM CDT, G0GJV
> <g0...@go...>
> > wrote:
> >
> > Yes. When it showed missing, I went looking for it!
> >
> > I haven't yet managed to build a .lib for it, but as it
> won't compile that isn't currently
> > important.
> >
> > Mike G0GJV
> >
> > > Did you use the winpthreads.h from the github repository?
> > > https://github.com/Hamlib/Hamlib/tree/master/include/hamlib
> > >
> > > Mike
> > >
> > >Â
> > >
> > >Â Â On Saturday, August 27, 2022 at 06:56:23 AM CDT, G0GJV
> > <g0...@go...>
> > > wrote:Â
> > >Â
> > >Â Mike
> > >
> > > winpthreads.h hasn't made it into the overnight zip.
> > >
> > > When I add it manually, I find that it creates some serious clashes with Qt!
> > >
> > > Why do you need to expose pthreads to the application
> builder? It looks like it is just
> > > for
> > >
> > > pthread_mutex_t mutex_set_transaction;
> > >
> > > Can't you put this somewhere else, and have a
> void * to point to it in rig.h? This would
> > > remove the need for a large #include, and would compile easily everywhere.
> > >
> > > Mike G0GJV
_______________________________________________
Hamlib-developer mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-developer
|
|
From: G0GJV <g0...@go...> - 2022-08-27 15:57:49
|
Mike Do you have a Qt installation under windows? Mike G0GJV > Mike > > It's open source > > https://sourceforge.net/projects/minos > > I'll try creating a Qt example. > > Mike G0GJV > > > Your test program compiles OK though, right? The one you sent me? > > I need your project files for the Qt version. > > > > > > > > On Saturday, August 27, 2022 at 08:26:50 AM CDT, G0GJV > <g0...@go...> > > wrote: > > > > Yes. When it showed missing, I went looking for it! > > > > I haven't yet managed to build a .lib for it, but as it > won't compile that isn't currently > > important. > > > > Mike G0GJV > > > > > Did you use the winpthreads.h from the github repository? > > > https://github.com/Hamlib/Hamlib/tree/master/include/hamlib > > > > > > Mike > > > > > > > > > > > >  On Saturday, August 27, 2022 at 06:56:23 AM CDT, G0GJV > > <g0...@go...> > > > wrote: > > > > > > Mike > > > > > > winpthreads.h hasn't made it into the overnight zip. > > > > > > When I add it manually, I find that it creates some serious clashes with Qt! > > > > > > Why do you need to expose pthreads to the application > builder? It looks like it is just > > > for > > > > > > pthread_mutex_t mutex_set_transaction; > > > > > > Can't you put this somewhere else, and have a > void * to point to it in rig.h? This would > > > remove the need for a large #include, and would compile easily everywhere. > > > > > > Mike G0GJV |
33 messages has been excluded from this view by a project administrator.
