Skip to content

Commit

Permalink
docs quirks
Browse files Browse the repository at this point in the history
  • Loading branch information
mrdimidium committed May 5, 2024
1 parent 438b170 commit 154a97e
Show file tree
Hide file tree
Showing 2 changed files with 8 additions and 8 deletions.
6 changes: 3 additions & 3 deletions objects.go
Original file line number Diff line number Diff line change
Expand Up @@ -106,10 +106,10 @@ func (cho *Chotki) ObjectIterator(oid rdx.ID, snap *pebble.Snapshot) *pebble.Ite

// todo []Field -> map[uint64]Field
func (cho *Chotki) ClassFields(cid rdx.ID) (fields Fields, err error) {
fields, ok := cho.types.Load(cid)
if ok {
return
if fields, ok := cho.types.Load(cid); ok {
return fields, nil
}

okey := OKey(cid, 'C')
tlv, clo, e := cho.db.Get(okey)
if e != nil {
Expand Down
10 changes: 5 additions & 5 deletions rdx/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,7 @@ Our objects can have fields of the following CRDT types. Each
type is named by a letter.

1. last-write-wins variables (`I` for int64, `S` for string, `F`
is float64, and `R` is [id64](./rdx/id.go#12))
is float64, and `R` is [id64](./id.go#12))
2. counters, `N` increment-only uint64 and `Z` two-way int64
3. maps (M), like key-value maps, where keys and values are `FIRST`
4. sets (E), contain arbitrary `FIRST` elements
Expand All @@ -52,13 +52,13 @@ let's see how a bare (no TLV envelope) `I` int64 `-11` would
look like, assuming it is the 4th revision of the register
autored by replica #5. The TLV would look like: `32 08 05 15`
(hex) where `0x15` is a [zig-zag][g] encoded and zipped `-11`,
while `32 08 05` is a tiny [ToyTLV](./protocol/tlv.go) record for a zipped pair
while `32 08 05` is a tiny [ToyTLV](../protocol/tlv.go) record for a zipped pair
of ints, 4 (signed, zig-zagged, so `08`) and 5 (unsigned, so
`05`). If we add a ToyTLV envelope, that becomes `69 04 32 08 05
15` (type of record `I`, length 4, then the bare part).

String `S` values are simply UTF-8 strings. Int64 `I`, float64
`F` and id64 `R` values get compressed using [`zip_int`](./rdx/zipint.go)
`F` and id64 `R` values get compressed using [`zip_int`](./zipint.go)
routines. Overlong encodings are forbidden both for strings and
for zip-ints!

Expand Down Expand Up @@ -222,7 +222,7 @@ here we imply `I` last-write-wins int64.

## Serialization format

We use the [ToyTLV](./protocol/tlv.go) format for enveloping/nesting all data.
We use the [ToyTLV](../protocol/tlv.go) format for enveloping/nesting all data.
That is a bare-bones type-length-value format with zero
semantics. What we put into ToyTLV envelopes is integers,
strings, and floats. Strings are UTF-8, no surprises. Floats are
Expand All @@ -231,7 +231,7 @@ as a compressed pair of integers.

A note on integer compression. From the fact that protobuf
has about ten integer types, one can guess that things can
be complicated here. We use [ZipInt](./rdx/zipint.go) routines to produce
be complicated here. We use [ZipInt](./zipint.go) routines to produce
efficient varints in a TLV format (differently from protobuf
which has a separate bit-level [LEB128][b] coding for ints).

Expand Down

0 comments on commit 154a97e

Please sign in to comment.