make docs netcdf-java specific #1
Merged
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
DennisHeimbigner
added a commit
to DennisHeimbigner/netcdf-java
that referenced
this pull request
Sep 28, 2022
## Description of Changes re: Issue Unidata#126 The code for handling enum types in Group.java is incorrect. When creating a new enum type, it is appropriate to search only the current group for a conflicting name and this is what the current code does. But when an enum typed variable searches for the matching enum type, it must search not only the current group but all parent groups and the current code does not do that. The fix consists of two similar parts. 1. Modify Group.findEnumeration to take an extra boolean parameter to control if search is this group only or to search up the group's parents. 2. Modify Group.Builder.findEnumTypedef to act like \Unidata#1 but to search the sequence of parent Group.Builder instances. As a consequence, this PR modifies a number of other files to adapt to the modified signatures. ## Misc. Other Changes: 1. Fix the handling of special attributes so that they are accessible. ## Note This same problem appears to affect the opaque type also, but fixing that may be a bit more difficult because CDM appears to convert opaque types to byte typess. ## PR Checklist <!-- This will become an interactive checklist once the PR is opened --> - [ ] Link to any issues that the PR addresses - [ ] Add labels - [ ] Open as a [draft PR](https://github.blog/2019-02-14-introducing-draft-pull-requests/) until ready for review - [ ] Make sure GitHub tests pass - [ ] Mark PR as "Ready for Review"
DennisHeimbigner
added a commit
to DennisHeimbigner/netcdf-java
that referenced
this pull request
Sep 30, 2022
## Description of Changes re: Issue Unidata#126 The code for handling enum types in Group.java is incorrect. When creating a new enum type, it is appropriate to search only the current group for a conflicting name and this is what the current code does. But when an enum typed variable searches for the matching enum type, it must search not only the current group but all parent groups and the current code does not do that. The fix consists of two similar parts. 1. Modify Group.findEnumeration to take an extra boolean parameter to control if search is this group only or to search up the group's parents. 2. Modify Group.Builder.findEnumTypedef to act like \Unidata#1 but to search the sequence of parent Group.Builder instances. As a consequence, this PR modifies a number of other files to adapt to the modified signatures. ## Note This same problem appears to affect the opaque type also, but fixing that may be a bit more difficult because CDM appears to convert opaque types to byte typess. ## PR Checklist <!-- This will become an interactive checklist once the PR is opened --> - [x] Link to any issues that the PR addresses - [ ] Add labels - [x] Open as a [draft PR](https://github.blog/2019-02-14-introducing-draft-pull-requests/) until ready for review - [x] Make sure GitHub tests pass - [ ] Mark PR as "Ready for Review"
haileyajohnson
pushed a commit
that referenced
this pull request
Jan 27, 2023
* ckp * Fix EnumTypedef name problem ## Description of Changes re: Issue #126 The code for handling enum types in Group.java is incorrect. When creating a new enum type, it is appropriate to search only the current group for a conflicting name and this is what the current code does. But when an enum typed variable searches for the matching enum type, it must search not only the current group but all parent groups and the current code does not do that. The fix consists of two similar parts. 1. Modify Group.findEnumeration to take an extra boolean parameter to control if search is this group only or to search up the group's parents. 2. Modify Group.Builder.findEnumTypedef to act like \#1 but to search the sequence of parent Group.Builder instances. As a consequence, this PR modifies a number of other files to adapt to the modified signatures. * 1. Remove unused import in H5HeaderNew 2. Add overloaded functions to Group.java to restore access to original versions of findEnumTypedef and findEnumeration. * Force re-test * It turns out that I missed the error in the code in H5headerNew that attempts to match an enum typed variable with the proper enumeration type declaration. The problem and fix (as described by a comment in H5headerNew) is a bit of a hack. It should be fixed in H5Object.read(). Unfortunately, information is not being passed down so that the proper fix can be applied early in the HDF5->CDM translation. Fixing this would affect a lot of function signatures. Also modified TestEnumTypedef.java to test two cases: 1. the actual enum type def is in the same group as the variable that uses it. 2. the actual enum type def is in a parent group of the variable that uses it ## Misc. Other Changes * Suppress printing of _NCProperties to simplify text-based comparison testing. * ## Addendum 2 Sigh! Apparently NetcdfFile.java defaulted to using H5iosp instead of H5iospNew. This meant that many of my changes were being bypassed. So, modify NetcdfFile to default to H5iospNew. * Undo change to NetcdfFile.java' * test4 * NCProperties fix * ## Additional modifications * NetcdfFile.java: convert to use H5iospNew (needed by TestH5iosp.java) * H5headerNew.java: provide get function for accessing the btree (needed by TestDataBTree.java) * H5iospNew.java: make getRandomAccessFile() method public (needed by tests) * CompareNetcdf2.java: Add a constructor to specify if attribute name comparison should ignore case or not. It turns out that some tests require case sensitive name matching. Specifically TestCoordSysCompare.java and TestN3iospCompare.java * Apply Spotless * remove debugging --------- Co-authored-by: haileyajohnson <hailey.johnson@ufl.edu>
DennisHeimbigner
added a commit
to DennisHeimbigner/netcdf-java
that referenced
this pull request
Nov 4, 2023
re: Issue The DAP4 code was improperly handling the use of the "dap4:" protocol in a url. This PR fixes it by detecting that protocol and doing two actions: 1. Convert the protocol to "https:". 2. Add the fragment "#dap4" to end of the url. Note that in \Unidata#1, this should really be https, but test.opendap.org still uses http; one hopes that other servers are setup to redirect http: to https: ## PR Checklist <!-- This will become an interactive checklist once the PR is opened --> - [X] Link to any issues that the PR addresses - [X] Add labels - [X] Open as a [draft PR](https://github.blog/2019-02-14-introducing-draft-pull-requests/) until ready for review - [X] Make sure GitHub tests pass - [X] Mark PR as "Ready for Review"
DennisHeimbigner
added a commit
to DennisHeimbigner/netcdf-java
that referenced
this pull request
Nov 8, 2023
re: Issue The DAP4 code was improperly handling the use of the "dap4:" protocol in a url. This PR fixes it by detecting that protocol and doing two actions: 1. Convert the protocol to "https:". 2. Add the fragment "#dap4" to end of the url. Note that in \Unidata#1, this should really be https, but test.opendap.org still uses http; one hopes that other servers are setup to redirect http: to https: ## PR Checklist <!-- This will become an interactive checklist once the PR is opened --> - [X] Link to any issues that the PR addresses - [X] Add labels - [X] Open as a [draft PR](https://github.blog/2019-02-14-introducing-draft-pull-requests/) until ready for review - [X] Make sure GitHub tests pass - [X] Mark PR as "Ready for Review"
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.
No description provided.