Implementation Status

Which spec features each Hurray implementation actually provides. Rows are format features, taken from Compliance; columns are implementations.

This page is generated, never hand-written. Tag coverage is read back out of the decoders one byte at a time, each capability is proven by an encode → decode round-trip, the Python column is introspected from the compiled module, and the C column is the set of symbols the generated header exports. CI regenerates the page and fails if it differs from the committed copy, so a feature an implementation gains — or loses — cannot pass unreported.

What no probe can detect carries a declared status and a justification, listed under the table it appears in.

Legend

• ✅  Implemented
• ◐  Partly implemented — see the note
• ❌  Not implemented
• ➖  Not this layer's to implement — see the note
• 📄  Specified, implemented nowhere — see the note

Adding a third-party implementation is a column, not a redesign: append an [[implementations]] block to website/coverage-matrix.toml with default = "no", then override that per section or per row as the implementation covers more. No row changes shape.

Conformance Levels

The three levels defined in Compliance. Level 2 implies Level 1, and Level 3 implies Level 2.

• (a) hurray_descriptor_decode parses and validates a descriptor through hurray-core, so the reading itself is complete, but the C surface exposes only the type tag, layout tag, rank, shape, byte offset, and buffer table. Layout-specific payload fields — CSR nnz, tile shape, the block table — have no accessor, so a C caller cannot yet interpret every Tier 1 layout it can decode.
• (b) No crate implements any part of the Level 3 transport: none of the message types, capability flags, or the RDMA data plane appear anywhere in hurray-core, hurray-io, hurray-ffi, hurray-python, or hurray-inspect. hurray-io implements the stream framing and the file container — Levels 1 and 2 — and stops there. The protocol is specified so that an implementation has something to build against; scheduling one is tracked separately.

Element Types

Tier 1 types are mandatory for every conforming implementation; Tier 2 types are optional. Extension types (0xF0–0xFE) are listed under Optional Descriptor Sections, since the type tag and its describing section are one feature on the wire.

• hurray-ffi — The C ABI reports the raw tag byte (hurray_descriptor_element_type_tag, hurray_descriptor_layout_tag) and never interprets it. There is no per-tag support to report at this layer: a C caller decides for itself which tags it can handle, and gains a new one without any change to hurray-ffi.

Memory Layouts

Tier 1 layouts (0x01–0x0B) are mandatory for reading; Hilbert (0x40) is Tier 2.

• hurray-ffi — The C ABI reports the raw tag byte (hurray_descriptor_element_type_tag, hurray_descriptor_layout_tag) and never interprets it. There is no per-tag support to report at this layer: a C caller decides for itself which tags it can handle, and gains a new one without any change to hurray-ffi.

Quantization Schemes

Carried in the optional quantization section. Support means encoding and decoding the scheme descriptor; performing the dequantization arithmetic is a compute concern and outside the format's scope.

• hurray-ffi — The C ABI reports the raw tag byte (hurray_descriptor_element_type_tag, hurray_descriptor_layout_tag) and never interprets it. There is no per-tag support to report at this layer: a C caller decides for itself which tags it can handle, and gains a new one without any change to hurray-ffi.

Optional Descriptor Sections

Sections a descriptor may carry beyond the fixed header, each gated by a flag bit. A reader that does not understand one skips it using descriptor_length, so none of these is required at any conformance level.

Streaming and File Interchange

The two framings that share the descriptor encoding: the self-delimiting stream format and the HRRYFILE container.

Network Transport (Level 3)

The cross-machine protocol in Interchange. Specified in full, implemented nowhere — see the note below the table.

• Every column — No crate implements any part of the Level 3 transport: none of the message types, capability flags, or the RDMA data plane appear anywhere in hurray-core, hurray-io, hurray-ffi, hurray-python, or hurray-inspect. hurray-io implements the stream framing and the file container — Levels 1 and 2 — and stops there. The protocol is specified so that an implementation has something to build against; scheduling one is tracked separately.