Correcting spelling errors throughout project

Author: recursion-ninja

CONTRIBUTING.md

@@ -20,7 +20,7 @@ has to be enabled, either by setting the flag in
 executable using `--flag=+serialblockio`.
 
 > :warning: **When enabling `serialblockio`, disable the
-> `cabal.project.blockio-uring` import in `cabal.project`!** Unforunately, this
+> `cabal.project.blockio-uring` import in `cabal.project`!** Unfortunately, this
 > line has to be removed/commented out manually (for now), or the project won't
 > build.
 

README.md

@@ -26,7 +26,7 @@ It has support for:
 
 - Monoidal upserts which combine the stored and new values.
 
-- BLOB storage which assocates a large auxiliary BLOB with a key.
+- BLOB storage which associates a large auxiliary BLOB with a key.
 
 - Durable on-disk persistence and rollback via named snapshots.
 
@@ -78,7 +78,7 @@ LSM-trees can be used concurrently, but with a few restrictions:
   cannot be accessed from different processes at the same time.
 
 - Tables can be used concurrently and concurrent use of read operations
-  such as lookups is determinstic. However, concurrent use of write
+  such as lookups is deterministic. However, concurrent use of write
   operations such as insert or delete with any other operation results
   in a race condition.
 
@@ -318,7 +318,7 @@ The worst-case in-memory size of an LSM-tree is *O*(*n*).
   A compact index stores the 64 most significant bits of the minimum
   serialised key for each memory page, as well as 1 bit per memory page
   to resolve clashes, 1 bit per memory page to mark overflow pages, and
-  a negligable amount of memory for tie breakers. The total in-memory
+  a negligible amount of memory for tie breakers. The total in-memory
   size of all indexes is approximately 66 bits per memory page.
 
 The total size of an LSM-tree must not exceed 2<sup>41</sup> physical

bench/micro/Bench/Database/LSMTree/Internal/Index/Compact.hs

@@ -91,7 +91,7 @@ constructIndexCompact (ChunkSize csize) apps = runST $ do
   Benchmarks for UTxO keys that are /almost/ uniformly distributed
 -------------------------------------------------------------------------------}
 
--- | UTXO keys are not truly uniformly distrbuted. The 'txId' is a uniformly
+-- | UTXO keys are not truly uniformly distributed. The 'txId' is a uniformly
 -- distributed hash, but the same 'txId' can appear in multiple UTXO keys, but
 -- with a different 'txIx'. In the worst case, this means that we have a clash
 -- in the compact index for /every page/. The following benchmarks show

blockio/src-sim/System/FS/BlockIO/Sim.hs

@@ -54,7 +54,7 @@ fromHasFS hfs =
 -- | Lock files are reader\/writer locks.
 --
 -- We implement this using the content of the lock file. The content is a
--- counter, positive for readers and negaive (specifically -1) for writers.
+-- counter, positive for readers and negative (specifically -1) for writers.
 -- There can be any number of readers, but only one writer. Writers can not
 -- coexist with readers.
 --

blockio/src/System/FS/BlockIO/API.hs

@@ -111,7 +111,7 @@ data HasBlockIO m h = HasBlockIO {
     -- function in 'IO' much more complex. In particular, if we want to reuse
     -- "GHC.IO.Handle.Lock" functionality, then we have to either ...
     --
-    -- 1. Convert there and back between OS-specific file desciptors and
+    -- 1. Convert there and back between OS-specific file descriptors and
     --   'GHC.Handle's, which is not possible on Windows without creating new
     --   file descriptors, or ...
     -- 2. Vendor all of the "GHC.IO.Handle.Lock" code and its dependencies
@@ -131,7 +131,7 @@ data HasBlockIO m h = HasBlockIO {
     -- | Synchronise file contents with the storage device.
     --
     -- Ensure that all change to the file handle's contents which exist only in
-    -- memory (as buffered system cache pages) are transfered/flushed to disk.
+    -- memory (as buffered system cache pages) are transferred/flushed to disk.
     -- This will also update the file handle's associated metadata.
     --
     -- This uses different system calls on different distributions.

bloomfilter/src/Data/BloomFilter/Hash.hs

@@ -279,7 +279,7 @@ https://github.com/facebook/rocksdb/blob/096fb9b67d19a9a180e7c906b4a0cdb2b2d0c1f
 
 -}
 
--- | Evalute 'CheapHashes' family.
+-- | Evaluate 'CheapHashes' family.
 --
 -- \[
 -- g_i = h_0 + \left\lfloor h_1 / 2^i \right\rfloor

doc/format-page.md

@@ -226,7 +226,7 @@ representation gives natural alignment without any padding.
 
 If the blob reference bitmap indicates that there is a blob reference for key i,
 then the index in the blob reference array can be found by counting the number
-of 1 bits for all bitmap indexes stricly less than i. This can be done
+of 1 bits for all bitmap indexes strictly less than i. This can be done
 relatively efficiently using the popcount CPU instruction. For example, pages
 with up to 64 keys, the bitmap fits into a single 64bit word and thus a single
 popcount instruction, (and some bit shifting and masking) is needed to find the

doc/format-run.md

@@ -134,7 +134,7 @@ vector.
 
 The first 4 bytes (32bit) are a format identifier / format version. This
 determines the format of the rest of the header and file.
-The format identifier also acts as endianess marker.
+The format identifier also acts as endianness marker.
 It (and remaining fields) are serialised in native byte order.
 
 The remainder of the header for format 1 consists of:

lsm-tree.cabal

@@ -10,7 +10,7 @@ description:
   *   Basic key–value operations, such as lookup, insert, and delete.
   *   Range lookups, which efficiently retrieve the values for all keys in a given range.
   *   Monoidal upserts which combine the stored and new values.
-  *   BLOB storage which assocates a large auxiliary BLOB with a key.
+  *   BLOB storage which associates a large auxiliary BLOB with a key.
   *   Durable on-disk persistence and rollback via named snapshots.
   *   Cheap table duplication where all duplicates can be independently accessed and modified.
   *   High-performance lookups on SSDs using I\/O batching and parallelism.
@@ -47,7 +47,7 @@ description:
 
   *   Each session locks its session directory.
       This means that a database cannot be accessed from different processes at the same time.
-  *   Tables can be used concurrently and concurrent use of read operations such as lookups is determinstic.
+  *   Tables can be used concurrently and concurrent use of read operations such as lookups is deterministic.
       However, concurrent use of write operations such as insert or delete with any other operation results in a race condition.
 
   == Performance #performance#
@@ -172,7 +172,7 @@ description:
           An ordinary index stores the maximum serialised key for each memory page.
           The total in-memory size of all indexes is proportional to the average size of one serialised key per memory page.
       [@CompactIndex@]:
-          A compact index stores the 64 most significant bits of the minimum serialised key for each memory page, as well as 1 bit per memory page to resolve clashes, 1 bit per memory page to mark overflow pages, and a negligable amount of memory for tie breakers.
+          A compact index stores the 64 most significant bits of the minimum serialised key for each memory page, as well as 1 bit per memory page to resolve clashes, 1 bit per memory page to mark overflow pages, and a negligible amount of memory for tie breakers.
           The total in-memory size of all indexes is approximately 66 bits per memory page.
 
   The total size of an LSM-tree must not exceed \(2^{41}\) physical entries.

prototypes/ScheduledMerges.hs

@@ -656,7 +656,7 @@ newMergingRun mergeType runs = do
     assertST $ length runs > 1
     -- in some cases, no merging is required at all
     (debt, state) <- case filter (\r -> runSize r > 0) runs of
-      []  -> let (r:_) = runs -- just re-use the empty input
+      []  -> let (r:_) = runs -- just reuse the empty input
               in return (runSize r, CompletedMerge r)
       [r] -> return (runSize r, CompletedMerge r)
       rs  -> do