[PATCH 2/2] Fix some typos in HACKING

[Dan Čermák]

From: Dan Čermák <address@hidden>

---
 HACKING | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/HACKING b/HACKING
index 403908c..9a4f30f 100644
--- a/HACKING
+++ b/HACKING
@@ -462,7 +462,7 @@ coverage
 
 refresh-po
   This target download the latest available translations from the
-  translationproject and installs them in the source tree.
+  translation project and installs them in the source tree.
 
 update-copyright
   Run this rule once per year (usually early in January) to update all
@@ -497,7 +497,7 @@ The Poke Compiler
 Compiler Overview
 ~~~~~~~~~~~~~~~~~
 
-This figure depicts the architecutre of the compiler::
+This figure depicts the architecture of the compiler::
   
       /--------\
       | source |
@@ -537,7 +537,7 @@ limitations in the LARL parser:
 - It annotates variables with their lexical addresses.
 - It links return statements with their containing functions.
 - It annotates return statements with he number of lexical frames they
-  should pop before exitting the function.
+  should pop before exiting the function.
 
 As we shall see below, any further analysis and transformations on the
 AST are performed by the compiler phases, which are implemented
@@ -749,7 +749,7 @@ A *struct type*
      element.  C1 is a poke expression evaluating to a boolean; it is
      the constraint associated to the element.   Of all these
      attributes, only T1 is mandatory.  PINNED is a boolean indicating
-     whether structs having this type are pinnned.
+     whether structs having this type are pinned.
 
 A *function type*
   Type expressions for functions are characterized by a type
@@ -930,8 +930,8 @@ In practice you will seldom find yourself in the need to use
 ``pkl_ast_node_free``.
 
 However, there are situations where ``ASTDEREF`` is necessary in order
-toavoid a memory leak.  For example, consider transformations like ``a
--> b`` to ``a -> x -> b``.  In that case, you sould use something
+to avoid a memory leak.  For example, consider transformations like ``a
+-> b`` to ``a -> x -> b``.  In that case, you should use something
 like::
 
   b = PKL_AST_KIND_WHAT (node);
@@ -976,7 +976,7 @@ an entry point into the routine (as a Jittery VM ``program 
point``)::
 However, since ``routine`` is malloc-allocated, the GC can't traverse
 it.  Consequently, the references to contained boxed values won't be
 accounted for, and these values will be collected if there are no more
-refences to them!
+references to them!
 
 The solution, recommended by Luca Saiu, is to keep an array of
 pointers in the closure structure, containing the pointers to every
@@ -1201,7 +1201,7 @@ the PKL compiler, manage their own memory.
 Valgrind gets easily confused by the GCs tampering with the stack, and
 emits a lot of spurious warnings.  Fortunately it is possible to tell
 memcheck to omit these warnings: the file etc/boehm-gc.suppresions
-contains a list of suppresions.
+contains a list of suppressions.
 
 Invoke valgrind with ``--suppressions=etc/boehm-gc.suppressions``.
 
@@ -1212,10 +1212,10 @@ please use::
 
 
 Then process raw.log with the ``etc/parse-valgrind-suppressions.sh``
-script, wilcard the result as much as you can, and append the results
+script, wildcard the result as much as you can, and append the results
 to ``etc/boehm-gc.suppressions``.
 
-In order to run the testsuite with valgring, edit lib/poke-dg.exp and
+In order to run the testsuite with valgrind, edit ``lib/poke-dg.exp`` and
 uncomment the lines::
 
  set VALGRIND "valgrind --quiet \
-- 
2.24.0