re-activate open/close entries for Winkey device #173
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
N0NB
requested changes
Jan 13, 2020
include/hamlib/rig.h
Outdated
| @@ -111,6 +112,7 @@ | |||
| t.tv_nsec = 0;\ | |||
| nanosleep(&t,NULL);\ | |||
| } while(0) | |||
| #endif | |||
There was a problem hiding this comment.
This change may not be needed with the most recent updates to master as Mike pulled all of this out of rig.h into a separate file in src.
|
This was done intermediately to let it work on Apple. But it was not part
of the pull request since I synchronized before with Mike’s latest version.
… Am 13.01.2020 um 14:53 schrieb Nate Bargmann ***@***.***>:
@N0NB requested changes on this pull request.
In include/hamlib/rig.h:
> @@ -111,6 +112,7 @@
t.tv_nsec = 0;\
nanosleep(&t,NULL);\
} while(0)
+#endif
This change may not be needed with the most recent updates to master as Mike pulled all of this out of rig.h into a separate file in src.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
* On 2020 13 Jan 09:40 -0600, dl1ycf wrote:
This was done intermediately to let it work on Apple. But it was not part
of the pull request since I synchronized before with Mike’s latest version.
But it is part of the pull 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
|
|
Am 13.01.2020 um 19:07 schrieb Nate Bargmann ***@***.***>:
* On 2020 13 Jan 09:40 -0600, dl1ycf wrote:
> This was done intermediately to let it work on Apple. But it was not part
> of the pull request since I synchronized before with Mike’s latest version.
But it is part of the pull request.
73, Nate
Hmmm …
doing a „compare“ on github does not show any changes to rig.h,
and looking into include/hamlib/rig.h in the repository
github.com/dl1ycf/hamlib I cannot see these changes.
In fact, the changes to rig.h (commit 9959be7) were overwritten
by the merge with Mike’s latest version (commit 55d607b), because doing the merge
I realized Mike has taken care of this, so I wonder what I did wrong.
(sorry I have more experience with subversion than with git).
P.S.: I really mean, tell me what I have to do better the next time.
Yours,
DL1YCF
|
|
It does show the affect right here...
#173
If you fixed it maybe you didn't commit/push it?
Mike
On Monday, January 13, 2020, 12:50:27 PM CST, dl1ycf <notifications@github.com> wrote:
Am 13.01.2020 um 19:07 schrieb Nate Bargmann ***@***.***>:
* On 2020 13 Jan 09:40 -0600, dl1ycf wrote:
> This was done intermediately to let it work on Apple. But it was not part
> of the pull request since I synchronized before with Mike’s latest version.
But it is part of the pull request.
73, Nate
Hmmm …
doing a „compare“ on github does not show any changes to rig.h,
and looking into include/hamlib/rig.h in the repository
github.com/dl1ycf/hamlib I cannot see these changes.
In fact, the changes to rig.h (commit 9959be7) were overwritten
by the merge with Mike’s latest version (commit 55d607b), because doing the merge
I realized Mike has taken care of this, so I wonder what I did wrong.
(sorry I have more experience with subversion than with git).
P.S.: I really mean, tell me what I have to do better the next time.
Yours,
DL1YCF
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe._______________________________________________
Hamlib-developer mailing list
Hamlib-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hamlib-developer
|
|
I am going to close this request without merging as both changes have been made by Mike, W9MDB, and are now in the master branch. If you find another issue, feel free to open a new PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the part of hamlib working with microHam "multiplexed" devices such as the microKeyer and DigiKeyer familiy. If hamlib "hogs" on the device for CAT and PTT, it was intended to leave a back door open for getting a file descriptor to write to the Winkeyer built into the microham device. Since hamlib has no API for morse keyers, please leave these open/close calls. They are needed e.g. if a contest logger uses hamlib and also wants to access the Winkey device.
So uh_open_wkey returns a file descriptor which is a FIFO that is treated by hamlib and the winkey data is then immersed in the mulitplexed data stream to/from the microHam device. uh_close_wkey usually is a no-op but closes the connection to the microham device if it is the last connection to be closed.
I know this is not overly well documented, but I ask for leaving this in although probably cppcheck complained about this.