Skip to content

Commit

Permalink
Merge pull request #288 from alex-sparus/fix-typos
Browse files Browse the repository at this point in the history
Small fixes for the persist documentation
  • Loading branch information
arximboldi authored Sep 2, 2024
2 parents 9d44126 + 297b952 commit ccb0a91
Show file tree
Hide file tree
Showing 2 changed files with 17 additions and 17 deletions.
16 changes: 8 additions & 8 deletions doc/persist-introduction.rst
Original file line number Diff line number Diff line change
Expand Up @@ -2,14 +2,14 @@ Introduction
===============

The ``immer::persist`` library persists persistent data structures,
allowing the preservation structural sharing of ``immer`` containers
allowing the preservation of structural sharing of ``immer`` containers
when serializing, deserializing or transforming the data.


.. warning:: This library is still experimental and it's API may
.. warning:: This library is still experimental and its API may
change in the future. The headers can be found in
``immer/extra/persist/...`` and the ``extra`` subpath will be
removed once it's interface stabilises.
removed once its interface stabilizes.

Dependencies
------------
Expand All @@ -30,7 +30,7 @@ runtime, two distinct containers can be operated on independently but
internally they share nodes and use memory efficiently in that
way.

However when such containers are serialized in a trival form, for
However when such containers are serialized in a trivial form, for
example, as JSON lists, this sharing is lost: they become truly
independent---the same data is stored multiple times on disk, and
later, when read back into memory, the program has lost the structural
Expand All @@ -50,8 +50,8 @@ Consider this scenario where you have multiple
``immer::vector<std::string>``, where the various instances are
derived from one another. Some of these vectors would be completely
identical, while others would have just a few elements different. This
scenario is not uncommon, for example, when `implement the undo
history of an application by preseriving the previous
scenario is not uncommon, for example, when `implementing the undo
history of an application by preserving the previous
states <https://sinusoid.es/lager/modularity.html#genericity>`_.

The goal is to apply a transformation function to these vectors with
Expand Down Expand Up @@ -81,9 +81,9 @@ type. For example, we may have a pool that contains all
``immer::vector<int>`` of our document. You can think of it as a small
database of ``immer`` containers. When serializing the pool, the
internal structure of all those ``immer`` containers is written as
whole, preserving the structural sharing between those containers.
a whole, preserving the structural sharing between those containers.

Note that for the most part, the user of the library is not concerned
with pools, as they are generated automatically from your
data-structures. However, you may become aware of them in the JSON
data structures. However, you may become aware of them in the JSON
output or when transforming recursive data structures.
18 changes: 9 additions & 9 deletions doc/persist-serialization.rst
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
Serialization
=========

Serializing your data structures using ``immer::persist`` allows you
Serializing your data structures using ``immer::persist`` allows you to
preserve the *structural sharing* across sessions of your application.

This has multiple practical use cases, like storing the undo history
Expand Down Expand Up @@ -82,28 +82,28 @@ replaced by an identifier. This identifier is a key into a
:ref:`pool<pools>`, which is serialized just after.

.. note::
Currently, ``immer-persist`` makes a distiction between
Currently, ``immer-persist`` makes a distinction between
pools used for saving containers (*output* pools) and for loading
containers (*input* pools), similar to ``cereal`` with its
``InputArchive`` and ``OutputArchive`` distiction.
``InputArchive`` and ``OutputArchive`` distinction.

Currently, ``immer-persist`` focuses on JSON as the serialization
format and uses the ``cereal`` library internally. In principle, other
formats and serialization libraries could be supported in the future.
sharing across sessions.

You can see in the out that the nodes of the trees that make up the
You can see in the output that the nodes of the trees that make up the
``immer`` containers are directly represented in the JSON and, because
we are representing all the containers as a whole, those nodes that
are referenced in multiple trees can be stored only once. That same
we are representing all the containers as a whole, those nodes that are
referenced in multiple trees can be stored only once. That same
structure is preserved when reading the pool back from disk and
reconstructing the vectors (and other containers) from it, thus
allowing us to preserve the structural sharing across sessions.
reconstructing the vectors (and other containers) from it, thus allowing
us to preserve the structural sharing across sessions.

Custom policies
----------

We can use policy to control the names of the pools for each container.
We can use policy to control the naming of the pools for each container.

For this example, let's define a new document type ``doc_2``. It will
also contain another type ``extra_data`` with a ``vector`` of
Expand Down

0 comments on commit ccb0a91

Please sign in to comment.