When creating a binding for FoundationDB is it necessary to implement encoding and decoding of single precision floats (32bits) for using the binding tester?
I would like to test my binding with the binding tester. Single precision floats are part of the tuple layer standard but the programming language I am using doesn’t support 32bit floats at all. So in my binding I could easily forgo of single precision floats in the tuple layer. Even in the official bindings there are classes that kind of implement 32bit floats, e.g. SingleFloat in Python and Ruby. But you can’t do anything with them. Single precision floats are kind of moot.
Which encodings/decodings in the tuple layer are actually needed for the binding tester?
As background, the main goal with the single precision float type in, say, the Python bindings is mainly to ensure that any Tuple written in one language can be parsed by another language. That doesn’t always work out, particularly around versionstamps, and the
SingleFloat approach is definitely a little clunky.
The binding tester’s
Tester specification does have a place where you can specify a list of types (here: https://github.com/FoundationDB/foundationdb/blob/9bc55f67c32602f489c78eb2a062a15e1396c7b4/bindings/bindingtester/known_testers.py#L49). In theory, you could have a tester that leaves out, say, 32-bit floats, though I think you’d also need to update a few places that currently generate
floats, most notably
api.py currently generates
DECODE_FLOAT operations regardless of whether the
float type is supported: https://github.com/FoundationDB/foundationdb/blob/9bc55f67c32602f489c78eb2a062a15e1396c7b4/bindings/bindingtester/tests/api.py#L209 I think that the Tuple tests around tuple packing/unpacking currently should work, in that they should only generate supported types (here in the random tuple generator: https://github.com/FoundationDB/foundationdb/blob/9bc55f67c32602f489c78eb2a062a15e1396c7b4/bindings/bindingtester/tests/test_util.py#L83)