Gpib enums#600
Closed
DavidCPlatt wants to merge 5 commits into
Closed
Conversation
Add code in GPIBsession _get_attribute and _set_attribute to map the TERMCHAR and TERMCHAR_EN attributes into the proper GPIB configuration settings. This allows GPIB reads to work correctly, when directed at older GPIB devices which do not signal EOI at the end of their talk output, but depend on EOS character matching.
for more information, see https://pre-commit.ci
Create a file of symbolic constants (IntEnum classes) for the various libgpib interface calls. Use these symbols rather than hard-coded integers. Remove now-extraneous commentary about what the hard-coded integers mean.
for more information, see https://pre-commit.ci
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #600 +/- ##
==========================================
+ Coverage 39.18% 41.02% +1.83%
==========================================
Files 27 28 +1
Lines 5022 5175 +153
Branches 518 517 -1
==========================================
+ Hits 1968 2123 +155
+ Misses 3028 3026 -2
Partials 26 26
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Contributor
Author
|
Ugh. This seems to have picked up some unnecessary commits, from my local merges and rebases. I'm going to abandon it, and cherry-pick the change into a fresh tree. |
Member
|
Thanks for doing that !!! |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Clean up the GPIB code, by using symbolic constants (IntEnums) when calling the libgpib APIs, rather than bare integers.
Rather than trying to include the API constants directly out of gpib_ctypes (which would have introduced a strict dependency that doesn't seem to exist today) I copied and modified the constant definitions from that file, creating "gpib_constants.py". The new constant definitions take the form of an individual IntEnum class per API-call, with the class name corresponding to the API call (or the returned-value interpretation) and the class member names matching the names used in gpib_ctypes. This constants file is now imported by gpib.py.
In gpib.py, all of the bare-integer value uses (I think) are replaced by the corresponding symbol, and old commentary explaining the interpretation of the bare-integer values is removed as redundant.
Tested with my Xyphro adapter and HP2903B. No errors encountered.
This deserves a careful set of eyeball checks before merging! I have reviewed it a couple of times myself and think I've got all of the bare-integer-to-symbol correspondences correct, but you know how much an author's own code reviews are worth :-)
black . && isort -c . && flake8with no errors