Further improvements to HDF5 I/O, and TESTS #79
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
Both Node-to-HDF5 and5 HDF-to-Node (write, and read) now have the ability to deal with original string-form content (as from an original XML file, in GNDStk's Node), and "type-ified" versions thereof. For example, `"1.2 3.4"` is a string, but for HDF5 we can write it as two doubles. Also, importantly, content related to "special" nodes, in particular what we'd see in XML as CDATA, comments, and PCDATA, are now handled in a full, and I believe proper, manner. For both input and output of HDF5. At some point I'll have to document all the HDF5 capabilities. For now, for anyone who wants to play around with HDF5, I recommend trying different combinations of the HDF5::reduced and HDF5::typed boolean flags; and then using perhaps the `h5dump` tool, or any other good HDF5 tool, for seeing what GNDStk's HDF5 capabilities can produce. Also: I filled out the main HDF5 test code with tons of new tests. This was definitely needed at this point. Also... Changed some HDF5-related function names that are in the detail:: namespace. The earlier names had tried to use capitalization (e.g. HDF5 instead of hdf5) in a manner that was consistent with the non-detail:: API names. For detail stuff, however, certain capitalization and long names felt heavy and painful to the eyes. Added a couple of tests for constructs that, it turned out, had not been interpreted correctly by the "type guesser" algorithm that the generic Node-to-HDF5 conversion uses. Did a few things that were unrelated to the main work (HDF5) here, but I was thinking about them... Tweaked a couple of autogen files, per some remarks about earlier pull requests. Figured out how to provide certain *constexpr* `has()` functions for classes derived from `Component`. We anticipate that these may eventually prove to be quite useful. Importantly, these are fully in `class Component` itself. Nothing had to be added to the generated classes. Things like this is why `Component` is awesome.
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.
Both Node-to-HDF5 and HDF5-to-Node (write, and read) now have the ability to deal with original string-form content (as from an original XML file, in GNDStk's Node), and "type-ified" versions thereof. For example,
"1.2 3.4"is a string, but for HDF5 we can write it as two doubles. Also, importantly, content related to "special" nodes, in particular what we'd see in XML as CDATA, comments, and PCDATA, are now handled in a full, and I believe proper, manner. For both input and output of HDF5.At some point I'll have to document all the HDF5 capabilities. For now, for anyone who wants to play around with HDF5, I recommend trying different combinations of the
HDF5::reducedandHDF5::typedboolean flags; and then using perhaps theh5dumptool, or any other good HDF5 tool, for seeing what GNDStk's HDF5 capabilities can produce.Also: I filled out the main HDF5 test code with tons of new tests. This was definitely needed at this point.
Also...
Changed some HDF5-related function names that are in the
detail::namespace. The earlier names had tried to use capitalization (e.g. HDF5 instead of hdf5) in a manner that was consistent with the non-detail:: API names. For detail stuff, however, certain capitalization and long names felt heavy and painful to the eyes.Added a couple of tests for constructs that, it turned out, had not been interpreted correctly by the "type guesser" algorithm that the generic Node-to-HDF5 conversion uses.
Did a few things that were unrelated to the main work (HDF5) here, but I was thinking about them...
Tweaked a couple of autogen files, per some remarks about earlier pull requests.
Figured out how to provide certain constexpr
has()functions for classes derived fromComponent. We anticipate that these may eventually prove to be quite useful. Importantly, these are fully inclass Componentitself. Nothing had to be added to the generated classes. Things like this are whyComponentis awesome.