hurray_ffi/file/mod.rs
1//! Blocking `HRRYFILE` reads and writes over a caller-supplied transport (ADR-041 ยง 8).
2//!
3//! The file container is *addressed*, not consumed: its trailer sits at `size - 40`, its
4//! index is located from there, and tensors are found by name. So the reader here drives
5//! `hurray-io`'s random-access core and asks the caller's
6//! [`read_at`][crate::HurrayTransport::read_at] callback for absolute ranges, while the
7//! writer emits one forward pass through `write` and never seeks back.
8//!
9//! The division of labour is the stream surface's, unchanged:
10//!
11//! - the **core** decides which bytes it needs and never blocks,
12//! - the **transport** moves them and MAY block,
13//! - these handles carry counts between the two.
14//!
15//! Scope: flat tensors, composites, and the KV metadata section. A composite is addressed
16//! by its head's name, read back whole by
17//! [`hurray_file_reader_read_composite`], and written from the preorder node array
18//! [`HurrayCompositeNode`][crate::HurrayCompositeNode] describes.
19
20// `pub(crate)`: its pointer helpers (`bytes_from_c`, `str_from_c`) are the boundary's,
21// not the KV section's, and `crate::composite` needs the same ones.
22pub(crate) mod kv;
23mod reader;
24mod writer;
25
26pub use kv::{
27 HurrayKvEntry, HurrayKvValue, HURRAY_KV_ARRAY, HURRAY_KV_BOOL, HURRAY_KV_BYTES,
28 HURRAY_KV_FLOAT64, HURRAY_KV_INT64, HURRAY_KV_STRING, HURRAY_KV_UINT64,
29};
30pub use reader::{
31 hurray_file_reader_destroy, hurray_file_reader_kv_count, hurray_file_reader_kv_entry,
32 hurray_file_reader_new, hurray_file_reader_read_composite, hurray_file_reader_read_descriptor,
33 hurray_file_reader_read_tensor, hurray_file_reader_tensor_count,
34 hurray_file_reader_tensor_name, HurrayFileReader,
35};
36pub use writer::{
37 hurray_file_writer_destroy, hurray_file_writer_finish, hurray_file_writer_new,
38 hurray_file_writer_write_composite, hurray_file_writer_write_tensor, HurrayFileWriter,
39 HurrayFileWriterOptions,
40};