Normalise H5T enums and use them to initialise types #1658
Conversation
axelboc
force-pushed
the
h5t-enums
branch
2 times, most recently
from
007e484
to
63b513e
Compare
| return intOrUintType( | ||
| signed ? H5T_SIGN.SIGN_2 : H5T_SIGN.NONE, | ||
| size * 8, | ||
| littleEndian ? H5T_ORDER.LE : H5T_ORDER.BE, |
There was a problem hiding this comment.
h5wasm exposes two booleans: signed and littleEndian. It might be better to expose the raw H5T enum values instead/as well, like in h5grove, since the enums have more than two values: https://docs.hdfgroup.org/hdf5/v1_14/_h5_tpublic_8h.html#title3 (H5T_NSGN, H5T_ORDER_MIXED, etc.)
There was a problem hiding this comment.
Is it planned than h5wasm eventually exposes the enum values ?
There was a problem hiding this comment.
Not yet, but I'll make a note of it.
| export enum H5T_SIGN { | ||
| NONE = 0, // unsigned | ||
| SIGN_2 = 1, // signed | ||
| NSGN = 2, |
There was a problem hiding this comment.
Not sure what this enum member represents, TBH.
There was a problem hiding this comment.
Even the HDF people don't know apparently: https://docs.hdfgroup.org/hdf5/v1_14/_h5_tpublic_8h.html#af7bfee2db210a12b9290eba85d730a71
Perhaps @t20100 has an idea ?
| return intOrUintType( | ||
| signed ? H5T_SIGN.SIGN_2 : H5T_SIGN.NONE, | ||
| size * 8, | ||
| littleEndian ? H5T_ORDER.LE : H5T_ORDER.BE, |
There was a problem hiding this comment.
Is it planned than h5wasm eventually exposes the enum values ?
| export enum H5T_SIGN { | ||
| NONE = 0, // unsigned | ||
| SIGN_2 = 1, // signed | ||
| NSGN = 2, |
There was a problem hiding this comment.
Even the HDF people don't know apparently: https://docs.hdfgroup.org/hdf5/v1_14/_h5_tpublic_8h.html#af7bfee2db210a12b9290eba85d730a71
Perhaps @t20100 has an idea ?
[email protected] has just been released with the new
strpadmetadata property to address #1621.Since this is another case where we need to map an H5T enum number to a more readable string, and since both h5grove and h5wasm expose a few of those raw enum values now (dtype class, charset, sign, order), I thought I'd first normalise things a bit...
h5t.tsfile in the shared package to hold the H5T enums and their mappings to readable strings.The enums and their keys are named as closely to the HDF5 spec as possible (though I don't specify keys for errors (
-1) and reserved values — I'll explain why in a comment.)stringType(),intType(), etc.) to accept H5T enum values; it is now there responsibility to convert those values to readable strings ('little-endian', etc.) using the mappings inh5t.tsinstead of the providers.Hopefully this makes sense. I'll add some more comments.