Merge pull request #2621 from 1u0/documentation-fix-some-typos

Documentation: fix some typos

documentation/sphinx/source/flow.rst

@@ -99,13 +99,13 @@ To write the equivalent code directly in C++, a developer would have to implemen
 Caveats
 =======
 
-Even though flow-code looks a lot like C++, it is not. It has different rules and the files are preprocessed. It is always important to keep this in mind when programming flow.
+Even though Flow code looks a lot like C++, it is not. It has different rules and the files are preprocessed. It is always important to keep this in mind when programming flow.
 
 We still want to be able to use IDEs and modern editors (with language servers like cquery or clang-based completion engines like ycm). Because of this there is a header-file ``actorcompiler.h`` in flow which defines preprocessor definitions to make flow compile as normal C++ code. CMake even supports a special mode so that it doesn't preprocess flow files. This mode can be used by passing ``-DOPEN_FOR_IDE=ON`` to cmake. Additionally we generate a special ``compile_commands.json`` into the source-directory which will support opening the project in IDEs and editors that look for a compilation database.
 
-Some preprocessor definitions will not fix all issues though. When programming flow the following things have to be taken care of by the programmer:
+Some preprocessor definitions will not fix all issues though. When programming Flow the following things have to be taken care of by the programmer:
 
-- Local variables don't survive a call to ``wait``. So this would be legal flow-code, but NOT legal C++-code:
+- Local variables don't survive a call to ``wait``. So this would be legal Flow code, but NOT legal C++ code:
 
   .. code-block:: c
 
@@ -133,8 +133,8 @@ Some preprocessor definitions will not fix all issues though. When programming f
                     }
                 }
 
-- An ``ACTOR`` is compiled into a class internally. Which means that within an actor-function, ``this`` is a valid pointer to this class. But using them explicitely (or as described later implicitely) will break IDE support. One can use ``THIS`` and ``THIS_ADDR`` instead. But be careful as ``THIS`` will be of type ``nullptr_t`` in IDE-mode and of the actor-type in normal compilation mode.
-- Lambdas and state variables are weird in a sense. After actorcompilation a state variable is a member of the compiled actor class. In IDE mode it is considered a normal local variable. This can result in some surprising side-effects. So the following code will only compile if the method ``Foo::bar`` is defined as ``const``:
+- An ``ACTOR`` is compiled into a class internally. Which means that within an actor-function, ``this`` is a valid pointer to this class. But using them explicitly (or as described later implicitly) will break IDE support. One can use ``THIS`` and ``THIS_ADDR`` instead. But be careful as ``THIS`` will be of type ``nullptr_t`` in IDE-mode and of the actor-type in normal compilation mode.
+- Lambdas and state variables are weird in a sense. After actor compilation, a state variable is a member of the compiled actor class. In IDE mode it is considered a normal local variable. This can result in some surprising side-effects. So the following code will only compile if the method ``Foo::bar`` is defined as ``const``:
 
   .. code-block:: c
 
@@ -144,7 +144,7 @@ Some preprocessor definitions will not fix all issues though. When programming f
                 }
 
 
-  If it is not, one has to pass the member explictely as reference:
+  If it is not, one has to pass the member explicitly as a reference:
 
   .. code-block:: c
 
@@ -154,5 +154,5 @@ Some preprocessor definitions will not fix all issues though. When programming f
                     foo([x]() { x->bar(); })
                 }
 
-- state variables in flow don't follow the normal scoping rules. So in flow a state variable can be defined in a inner scope and later it can be used in the outer scope. In order to not break compilation in IDE-mode, always define state variables in the outermost scope they will be used.
+- state variables in Flow don't follow the normal scoping rules. So in Flow a state variable can be defined in an inner scope and later it can be used in the outer scope. In order to not break compilation in IDE-mode, always define state variables in the outermost scope they will be used.
 

documentation/sphinx/source/kv-architecture.rst

@@ -20,7 +20,7 @@ The master is responsible for coordinating the transition of the write sub-syste
 Proxies
 =======
 
-The proxies are responsible for providing read versions, committing transactions, and tracking the storage servers responsible for each range of keys. To provide a read version, a proxy will ask all other proxies to see the largest committed version at this point in time, while simultaneously checking that the transaction logs have not been stopped. Ratekeeper will artificially slow down the rate at which the proxy provides read versions. 
+The proxies are responsible for providing read versions, committing transactions, and tracking the storage servers responsible for each range of keys. To provide a read version, a proxy will ask all other proxies to see the largest committed version at this point in time, while simultaneously checking that the transaction logs have not been stopped. Ratekeeper will artificially slow down the rate at which the proxy provides read versions.
 
 Commits are accomplished by:
 
@@ -28,7 +28,7 @@ Commits are accomplished by:
 * Use the resolvers to determine if the transaction conflicts with previously committed transactions.
 * Make the transaction durable on the transaction logs.
 
-The key space starting with the '\xff' byte is reserved for system metadata. All mutations committed into this key space are distributed to all of the proxies through the resolvers. This metadata includes a mapping between key ranges and the storage servers which have the data for that range of keys. The proxies provides this information to clients on-demand. The clients cache this mapping; if they ask a storage server for a key it does not have, they will clear their cache and get a more up-to-date list of servers from the proxies.
+The key space starting with the '\xff' byte is reserved for system metadata. All mutations committed into this key space are distributed to all of the proxies through the resolvers. This metadata includes a mapping between key ranges and the storage servers which have the data for that range of keys. The proxies provide this information to clients on-demand. The clients cache this mapping; if they ask a storage server for a key it does not have, they will clear their cache and get a more up-to-date list of servers from the proxies.
 
 Transaction Logs
 ================
@@ -43,7 +43,7 @@ The resolvers are responsible determining conflicts between transactions. A tran
 Storage Servers
 ===============
 
-The vast majority of processes in a cluster are storage servers. Storage servers are assigned ranges of key, and are responsible to storing all of the data for that range. They keep 5 seconds of mutations in memory, and an on disk copy of the data as of 5 second ago. Clients must read at a version within the last 5 seconds, or they will get a transaction_too_old error. The ssd storage engine stores the data in a b-tree. The memory storage engine store the data in memory with an append only log that is only read from disk if the process is rebooted.
+The vast majority of processes in a cluster are storage servers. Storage servers are assigned ranges of keys, and are responsible for storing all of the data for that range. They keep 5 seconds of mutations in memory, and an on disk copy of the data as of 5 second ago. Clients must read at a version within the last 5 seconds, or they will get a transaction_too_old error. The ssd storage engine stores the data in a b-tree. The memory storage engine stores the data in memory with an append only log that is only read from disk if the process is rebooted.
 
 Clients
 =======