Merge pull request #230 from proski/typos

Fix typos

book.xml

@@ -16,7 +16,7 @@
       This is a ported version of the <emphasis role="strong">Nix
       Pills</emphasis>, a series of blog posts written by <emphasis
       role="strong">Luca Bruno</emphasis> (aka Lethalman) and
-      orginally published in 2014 and 2015. It provides a tutorial
+      originally published in 2014 and 2015. It provides a tutorial
       introduction into the Nix package manager and Nixpkgs package
       collection, in the form of short chapters called 'pills'.
     </para>

pills/03-enter-environment.xml

@@ -372,7 +372,7 @@
     </para>
 
     <para>
-      Everytime we change the environment, a new generation is created.
+      Every time we change the environment, a new generation is created.
       Switching between generations is easy and immediate.
     </para>
 

pills/04-basics-of-language.xml

@@ -205,7 +205,7 @@
     <title>Attribute sets</title>
 
     <para>
-      Attribute sets are an association between string keys and a Nix values. Keys
+      An attribute set is an association between string keys and Nix values. Keys
       can only be strings. When writing attribute sets you can also use unquoted identifiers as
       keys.
     </para>

pills/05-functions-and-imports.xml

@@ -93,7 +93,7 @@ xml:id="functions-and-imports">
   </para>
 
   <para>
-    You don't have to use parenthesis at all, Nix has sane priorities when
+    You don't have to use parentheses at all, Nix has sane priorities when
     parsing the code:
   </para>
 
@@ -102,7 +102,7 @@ xml:id="functions-and-imports">
   <para>
     Much more readable, you don't even notice that functions only receive one
     argument. Since the argument is separated by a space, to pass more complex
-    expressions you need parenthesis. In other common languages you would write
+    expressions you need parentheses. In other common languages you would write
     <code>mul(6+7, 8+9)</code>.
   </para>
 
@@ -121,7 +121,7 @@ xml:id="functions-and-imports">
 </section>
 
 <section>
-  <title>Arguments set</title>
+  <title>Argument set</title>
 
   <para>
     Now this is a very cool feature of Nix. It is possible to pattern match over
@@ -134,13 +134,13 @@ xml:id="functions-and-imports">
   <para>
     In the first case we defined a function that accepts a single parameter. We
     then access attributes <code>a</code> and
-    <code>b</code> from the given set. Note how the parenthesis-less syntax for
+    <code>b</code> from the given set. Note how the parentheses-less syntax for
     function calls is very elegant in this case, instead of doing <code>mul({
     a=3; b=4; })</code> in other languages.
   </para>
 
   <para>
-    In the second case we defined an arguments set. It's like defining a set,
+    In the second case we defined an argument set. It's like defining a set,
     except without values. We require that the passed set contains the keys
     <code>a</code> and <code>b</code>. Then we can use those <code>a</code> and
     <code>b</code> in the function body directly.
@@ -160,7 +160,7 @@ xml:id="functions-and-imports">
 
   <para>
     It is possible to specify <emphasis role="strong">default values</emphasis>
-    of attributes in the arguments set:
+    of attributes in the argument set:
   </para>
 
   <screen><xi:include href="./05/default-values.txt" parse="text" /></screen>
@@ -264,7 +264,7 @@ xml:id="functions-and-imports">
   <screen><xi:include href="./05/import.txt" parse="text" /></screen>
 
   <para>
-    Yes it's really that simple. You import a file, and it gets parsed as
+    Yes it's really that simple. You import a file, and it gets parsed as an
     expression. Note that the scope of the imported file does not inherit the
     scope of the importer.
   </para>
@@ -324,7 +324,7 @@ xml:id="functions-and-imports">
   </itemizedlist>
 
   <para>
-    So when is the message shown? Only when it's in need to be evaluated.
+    So when is the message shown? Only when it needs to be evaluated.
   </para>
 </section>
 

pills/06-our-first-derivation.xml

@@ -81,7 +81,7 @@
   <para>
     Oh oh, what's that? Did it build the derivation? No it didn't, but it
     <emphasis role="strong">did create the .drv file</emphasis>. <literal>nix repl</literal> does
-    not build derivations unless you tell to do so.
+    not build derivations unless you tell it to do so.
   </para>
 
 </section>
@@ -342,7 +342,7 @@
   <screen><xi:include href="./06/coreutils.txt" parse="text" /></screen>
 
   <para>
-    Apart the nixpkgs stuff, just think we added to the scope a series of
+    Apart from the nixpkgs stuff, just think we added to the scope a series of
     variables. One of them is coreutils. It is the derivation of the coreutils
     package you all know of from other Linux distributions. It contains basic
     binaries for GNU/Linux systems (you may have multiple derivations of
@@ -387,7 +387,7 @@
 
 
   <para>
-    <emphasis role="underline">Obvious note</emphasis>: everytime we change the
+    <emphasis role="underline">Obvious note</emphasis>: every time we change the
     derivation, a new hash is created.
   </para>
 

pills/08-generic-builders.xml

@@ -123,7 +123,7 @@
 
     <para>
       As you can see, there's no reference to "hello" in the builder anymore.
-      It still does several assumptions, but it's certainly more generic.
+      It still makes several assumptions, but it's certainly more generic.
     </para>
 
     <para>
@@ -134,7 +134,7 @@
 
     <para>
       All clear, except that buildInputs. However it's easier than any black
-      magic you are thinking in this moment.
+      magic you are thinking of at this moment.
     </para>
 
     <para>
@@ -162,7 +162,7 @@
     <para>
       We managed to write a builder that can be used for multiple autotools
       projects. But in the hello.nix expression we are specifying tools that
-      are common to more projects; we don't want to pass them everytime.
+      are common to more projects; we don't want to pass them every time.
     </para>
 
     <para>

pills/09-automatic-runtime.xml

@@ -102,7 +102,7 @@
       </listitem>
       <listitem>
         <para>
-          For each build dependency <code>.drv</code> and it's relative out path,
+          For each build dependency <code>.drv</code> and its relative out path,
           search the contents of the NAR for this out path.
         </para>
       </listitem>
@@ -146,7 +146,7 @@
     <para>
       Even after reducing the rpath, the <code>hello</code> binary would still
       depend upon <code>gcc</code> because of some debugging information. This
-      unnecesarily increases the size of our runtime
+      unnecessarily increases the size of our runtime
       dependencies. We'll explore how <command><link
       xlink:href="https://linux.die.net/man/1/strip">strip</link>
       </command> can help us with that in the next section.
@@ -218,7 +218,7 @@
     </para>
 
     <para>
-      Now, we rebuild <filename>hello.nix</filename>:nd...:
+      Now, we rebuild <filename>hello.nix</filename>...
     </para>
 
     <screen><xi:include href="./09/build-hello-nix.txt" parse="text" /></screen>
@@ -252,7 +252,7 @@
       We saw some of the tools Nix provides, along with their features.
       In particular, we saw how Nix is able to compute runtime dependencies
       automatically. This is not limited to only shared libraries,
-      but can also referenced executables, scripts, Python libraries, and so
+      but can also reference executables, scripts, Python libraries, and so
       forth.
     </para>
 

pills/10-developing-with-nix-shell.xml

@@ -67,7 +67,7 @@
     </para>
 
     <para>
-      This means the we can <command>source</command> our
+      This means that we can <command>source</command> our
       <filename>builder.sh</filename>, and it will build the derivation.
       You may get an error in the installation phase, because your user may
       not have the permission to write to <filename>/nix/store</filename>:
@@ -122,7 +122,7 @@
 
     <para>
       First, when we <command>source</command>d the <filename>builder.sh</filename>
-      file, we obtained the file in the currenty directory. What we really wanted
+      file, we obtained the file in the current directory. What we really wanted
       was the <filename>builder.sh</filename> that is stored in the nix store,
       as this is the file that would be used by <command>nix-build</command>.
       To achieve this, the correct technique is to pass an environment variable
@@ -142,7 +142,7 @@
     </para>
 
     <para>
-      During our refactoring, we ill wrap the build phases in functions to
+      During our refactoring, we will wrap the build phases in functions to
       give more structure to our design. Additionally, we'll move the
       <code>set -e</code> to the builder file instead of the setup file.
       The <code>set -e</code> is annoying in <command>nix-shell</command>,
@@ -214,7 +214,7 @@
       With <command>nix-shell</command> we are able to drop into an isolated
       environment suitable for developing a project. This environment provides the necessary
       dependencies for the development shell, similar to how
-      <command>nix-build</command> providesthe necessary dependencies to a builder.
+      <command>nix-build</command> provides the necessary dependencies to a builder.
       Additionally, we can build and debug the project manually, executing step-by-step
       like we would in any other operating system. Note that we never installed tools
       such <command>gcc</command> or <command>make</command> system-wide; these tools

pills/11-garbage-collector.xml

@@ -8,7 +8,7 @@
 
   <para>
     Welcome to the 11th Nix pill. In the previous
-    <link linkend="developing-with-nix-shell">10th pill</link>, we drew a
+    <link linkend="developing-with-nix-shell">10th pill</link>, we drew
     a parallel between the isolated build environment provided by
     <command>nix-build</command> and the isolated development shell provided by
     <command>nix-shell</command>. Using <command>nix-shell</command> allowed us
@@ -44,21 +44,21 @@
 
     <para>
       Instead of objects, Nix's garbage collection operates on store paths, <link xlink:href="https://nixos.org/manual/nix/stable/package-management/garbage-collector-roots.html">with the GC roots themselves being store paths</link>.
-.     This approach is much mode principled than traditional package
+.     This approach is much more principled than traditional package
       managers such as <code>dpkg</code> or <code>rpm</code>, which may
       leave around unused packages or dangling files.
     </para>
 
     <para>
       The implementation is very simple and transparent to the user. The primary
       GC roots are stored under <filename>/nix/var/nix/gcroots</filename>. If there
-      is a symlink to a store path, then linked store path is a GC root.
+      is a symlink to a store path, then the linked store path is a GC root.
     </para>
 
     <para>
       Nix allows this directory to have subdirectories: it will simply recursively
       traverse the subdirectories in search of symlinks to store paths. When
-      a symlink is encountered, it's target is added to the list of live store
+      a symlink is encountered, its target is added to the list of live store
       paths.
     </para>
 
@@ -90,7 +90,7 @@
 
     <para>
       We now install a new program, <code>bsd-games</code>, inspect its
-      store path, and examine it's GC root. The <command>nix-store -q --roots</command>
+      store path, and examine its GC root. The <command>nix-store -q --roots</command>
       command is used to query the GC roots that refer to a given derivation. In this
       case, our current user environment refers to <code>bsd-games</code>:
     </para>
@@ -131,7 +131,7 @@
       <filename>/nix/var/nix/gcroots</filename>. In addition to the latter,
       Nix treats <filename>/nix/var/nix/profiles</filename> as a GC root.
       This is useful because it means that any profile and its generations
-      are GC roots. Other path are considered GC roots as well; for example,
+      are GC roots. Other paths are considered GC roots as well; for example,
       <filename>/run/booted-system</filename> on NixOS.
       The command <command>nix-store --gc --print-roots</command> prints all
       paths considered as GC roots when running the garbage collector.
@@ -166,14 +166,14 @@
       What is important is that such a symlink exists and points to
       <filename>/home/nix/result</filename>. This is called an
       <emphasis role="bold">indirect GC root</emphasis>. A GC root is
-      considred indirect if it's specification is outside of
+      considered indirect if its specification is outside of
       <filename>/nix/var/nix/gcroots</filename>. In this case, this means
       that the target of the <filename>result</filename> symlink will
       not be garbage collected.
     </para>
 
     <para>
-      To remove a deriviation considered "live" by an indirect GC root,
+      To remove a derivation considered "live" by an indirect GC root,
       there are two possibilities:
     </para>
 
@@ -211,7 +211,7 @@
       The main source of software duplication in the nix store comes from
       GC roots, due to <command>nix-build</command> and profile generations.
       Running <command>nix-build</command> results in a GC root for the build
-      that refers to a specific version of specific libaries, such as
+      that refers to a specific version of specific libraries, such as
       <package>glibc</package>. After an upgrade, we must delete the previous build
       if we want the garbage collector to remove the corresponding derivation,
       as well as if we want old dependencies cleaned up.
@@ -272,7 +272,7 @@
     <title>Conclusion</title>
 
     <para>
-      Garbage collection in Nix is a powerful mechanism to cleanup your system.
+      Garbage collection in Nix is a powerful mechanism to clean up your system.
       The <command>nix-store</command> commands allow us to know why a certain
       derivation is present in the nix store, and whether or not it is eligible
       for garbage collection. We also saw how to conduct more destructive deletion

pills/12-inputs-design-pattern.xml

@@ -16,7 +16,7 @@
   <section>
     <title>Repositories in Nix</title>
     <para>
-      Package repositories in Nix arose naturally from the need to organize pacakges.
+      Package repositories in Nix arose naturally from the need to organize packages.
       There is no preset directory structure or packaging policy prescribed by Nix itself;
       Nix, as a full, functional programming language, is powerful enough to support
       multiple different repository formats.
@@ -25,15 +25,15 @@
     <para>
       Over time, the <literal>nixpkgs</literal> repository evolved a particular
       structure. This structure reflects the history of Nix as well as the design
-      patterns adopted by it's users as useful tools in building and organizing
+      patterns adopted by its users as useful tools in building and organizing
       packages. Below, we will examine some of these patterns in detail.
     </para>
   </section>
   <section>
     <title>The single repository pattern</title>
     <para>
       Different operating system distributions have different opinions about how
-      package repositories should organized. Systems like Debian scatter packages
+      package repositories should be organized. Systems like Debian scatter packages
       in several small repositories (which tends to make tracking interdependent
       changes more difficult, and hinders contributions to the repositories),
       while systems like Gentoo put all package descriptions in a single repository.
@@ -102,7 +102,7 @@
       The <code>graphviz</code> configuration script uses <command>pkg-config</command>
       to specify which flags are passed to the compiler. Since there is no global location
       for libraries, we need to tell <command>pkg-config</command> where to find
-      it's description files, which tell the configuration script where to find
+      its description files, which tell the configuration script where to find
       headers and libraries.
     </para>
     <para>
@@ -150,7 +150,7 @@
       Now that we have two packages, we want to combine them into a single repository.
       To do so, we'll mimic what <literal>nixpkgs</literal> does: we will create
       a single attribute set containing derivations. This attribute set can
-      then be imported, and deriviations can be selected by accessing the
+      then be imported, and derivations can be selected by accessing the
       top-level attribute set.
     </para>
     <para>
@@ -175,8 +175,8 @@
     <screen><xi:include href="./12/repository-test-nix-build.txt" parse="text" /></screen>
     <para>
       The <filename>default.nix</filename> file is special. When a directory
-      contains a <filename>default.nix</filename> file, it is used as the implict
-      nix expression of the directory. This, for example, allows use to run
+      contains a <filename>default.nix</filename> file, it is used as the implicit
+      nix expression of the directory. This, for example, allows us to run
       <command>nix-build -A hello</command> without specifying
       <filename>default.nix</filename> explicitly.
     </para>
@@ -295,7 +295,7 @@
       <code>gd</code>, it would suffice to pass <literal>gd = ...;</literal>.
     </para>
     <para>
-      If we wanted to change the toolchain, we simply pass a different
+      If we wanted to change the toolchain, we would simply pass a different
       <literal>mkDerivation</literal> function.
     </para>
     <para>