docs(tvix): fix some typos across various documents

Fix some typos found while reading various documents, mostly those
relating to the castore.

Here is a summary of the edits.

- fix broken link between documents in the store and castore directories
- clarify expression in castore's data model document that indicates
  that the *name* of each child node of a directory must be unique
  across all three lists of children
- add missing closing parenthesis in castore's data model document
- replace "how" with "what" in the phrase "unclear how a ... would even
  look like" in castore's why-not-git-trees document
- remove unnecessary articles in castore's blobstore chunking document
- add missing "y" to "optionall" in eval's compilation of bindings
  document

Change-Id: I1997ea91bb4e9c40abcd81e0cde9405968580ba6
Reviewed-on: https://cl.tvl.fyi/c/depot/+/11763
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
This commit is contained in:
Ben Webb 2024-06-08 15:29:16 -05:00 committed by benjaminedwardwebb
parent 4ed397ad00
commit 23e0973cdf
5 changed files with 8 additions and 8 deletions

View file

@ -73,10 +73,10 @@ This means one only needs to the root digest to validate a constructions, and th
constructions can be sent [separately][bao-spec].
This relieves us from the need of having to encode more granular chunking into
our data model / identifier upfront, but can make this a mostly a transport/
our data model / identifier upfront, but can make this mostly a transport/
storage concern.
For the some more description on the (remote) protocol, check
For some more description on the (remote) protocol, check
`./blobstore-protocol.md`.
#### Logical vs. physical chunking

View file

@ -15,8 +15,8 @@ a directory.
All three message types have a `name` field, specifying the (base)name of the
element (which MUST not contain slashes or null bytes, and MUST not be '.' or '..').
For reproducibility reasons, the lists MUST be sorted by that name and also
MUST be unique across all three lists.
For reproducibility reasons, the lists MUST be sorted by that name and the
name MUST be unique across all three lists.
In addition to the `name` field, the various *Node messages have the following
fields:
@ -27,7 +27,7 @@ A `DirectoryNode` message represents a child directory.
It has a `digest` field, which points to the identifier of another `Directory`
message, making a `Directory` a merkle tree (or strictly speaking, a graph, as
two elements pointing to a child directory with the same contents would point
to the same `Directory` message.
to the same `Directory` message).
There's also a `size` field, containing the (total) number of all child
elements in the referenced `Directory`, which helps for inode calculation.

View file

@ -48,7 +48,7 @@ The git tree object format uses sha1 both for references to other trees and
hashes of blobs, which isn't really a hash function to fundamentally base
everything on in 2023.
The [migration to sha256][git-sha256] also has been dead for some years now,
and it's unclear how a "blake3" version of this would even look like.
and it's unclear what a "blake3" version of this would even look like.
[bao]: https://github.com/oconnor663/bao
[blake3]: https://github.com/BLAKE3-team/BLAKE3

View file

@ -62,7 +62,7 @@ This is done by compiling bindings in several phases:
At the end of this phase, we know the stack slots of all namespaces for
inheriting from, all values inherited from them, and all values (and
optionall keys) of bindings at the current level.
optionally keys) of bindings at the current level.
Only statically known keys are actually merged, so any dynamic keys that
conflict will lead to a "key already defined" error at runtime.

View file

@ -5,7 +5,7 @@ This document outlines the design of the API exposed by tvix-castore and tvix-
store, as well as other implementations of this store protocol.
This document is meant to be read side-by-side with
[castore.md](../../tvix-castore/docs/castore.md) which describes the data model
[castore.md](../../castore/docs/data-model.md) which describes the data model
in more detail.
The store API has four main consumers: