h5wasm@0.7.5 has just been released with the new strpad metadata 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...
I create a h5t.ts file 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.)
I refactor the dtype factories (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 in h5t.ts instead of the providers.
Hopefully this makes sense. I'll add some more comments.
h5wasm@0.7.5 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.