Default tree implementation
The parts of the serialization system that seem like they're need hooks are:
Must provide a function that takes a node, serializes it, and returns an addr
Must be able to rollback writing an addr
Whatever the addr it returns, it should cache its resolve in-mem somehow
The serialize a node & rollback a node functions should accept a 'stats' object as well
The 'stats' object must be convertible to a summary or whatever at the end
Default tree implementation The parts of the serialization system that seem like they're need hooks are: * Must provide a function that takes a node, serializes it, and returns an addr * Must be able to rollback writing an addr * Whatever the addr it returns, it should cache its resolve in-mem somehow * The serialize a node & rollback a node functions should accept a 'stats' object as well * The 'stats' object must be convertible to a summary or whatever at the end
Description of refcounting system in redis
The refcounting system allows any key in redis to be managed by refcounting. This refcounter doesn't do cycle protection, but weakrefs would be very simple to add.
To have a key point to another, we call add-refs with the pointer key and list of pointee keys. Usually, the pointer key would be a struct with children.
Each key which is pointed to has an auxiliary key, which has the same name but ends in :rc. This is an int of the refcount of the key; the system deletes the key when its refcount reaches 0.
Each key which is a pointer has an auxiliary key, which has the same name but ends in :rl. This is the list of keys that we have a reference, or pointer, to. rl=reflist. This list is used when the pointer is finally deleted--every key which the pointer points to must have its refcount decremented, and if any refcount reaches 0, that key must too be deleted.
To reduce the frequency that keys are orphaned, we allow for new roots to be marked by the new-root function. This function stores the given key as a newly created root pointer, which is put onto a list with its creation time. Somehow, we track when root pointers are older than a certain time, so that we can delete them automatically.
Description of refcounting system in redis The refcounting system allows any key in redis to be managed by refcounting. This refcounter doesn't do cycle protection, but weakrefs would be very simple to add. To have a key point to another, we call add-refs with the pointer key and list of pointee keys. Usually, the pointer key would be a struct with children. Each key which is pointed to has an auxiliary key, which has the same name but ends in :rc. This is an int of the refcount of the key; the system deletes the key when its refcount reaches 0. Each key which is a pointer has an auxiliary key, which has the same name but ends in :rl. This is the list of keys that we have a reference, or pointer, to. rl=reflist. This list is used when the pointer is finally deleted--every key which the pointer points to must have its refcount decremented, and if any refcount reaches 0, that key must too be deleted. To reduce the frequency that keys are orphaned, we allow for new roots to be marked by the new-root function. This function stores the given key as a newly created root pointer, which is put onto a list with its creation time. Somehow, we track when root pointers are older than a certain time, so that we can delete them automatically.
An operation is an object with a few functions
An operation is an object with a few functions 1. It has a function that it applies to the tree to apply its effect In the future, it could also have 2. It has a promise which can be filled with the end result (more memory but faster results for repeat queries)
FIXME would be nice to get rid of that ns
FIXME would be nice to get rid of that ns
This namespace provides functions to help visualizing hh-trees.
It provides a visualization similar to those in https://youtu.be/jdn617M3-P4?t=1583
This namespace provides functions to help visualizing hh-trees. It provides a visualization similar to those in https://youtu.be/jdn617M3-P4?t=1583
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close