class.md

@@ -663,7 +663,7 @@ horizontal direction is the "instance - class" relation, and in the
 vertical direction is inheritance (the superclasses are above).
 
 <figure>
-	hanks<img src="images/ch_class_addsclass.png" alt="figure 1: `rb_singleton_class`">
+	<img src="images/ch_class_addsclass.png" alt="figure 1: `rb_singleton_class`">
 	<figcaption>figure 1: `rb_singleton_class`</figcaption>
 </figure>
 
@@ -769,7 +769,7 @@ Even a class has a class, and it's `Class`. And the class of `Class`
 is again `Class`. We find ourselves in an infinite loop (figure 2).
 
 <figure>
-	hanks<img src="images/ch_class_infloop.png" alt="figure 2: Infinite loop of classes">
+	<img src="images/ch_class_infloop.png" alt="figure 2: Infinite loop of classes">
 	<figcaption>figure 2: Infinite loop of classes</figcaption>
 </figure>
 
@@ -843,7 +843,7 @@ singleton methods. By chain reaction, that also makes singleton
 classes necessary. Figure 3 shows these dependency relationships.
 
 <figure>
-	hanks<img src="images/ch_class_reqlink.png" alt="figure 3: Requirements dependencies">
+	<img src="images/ch_class_reqlink.png" alt="figure 3: Requirements dependencies">
 	<figcaption>figure 3: Requirements dependencies</figcaption>
 </figure>
 
@@ -998,7 +998,7 @@ the singleton class for `klass`. It looks like the singleton class is
 caught between a class and this class's superclass's class.
 
 <figure>
-	hanks<img src="images/ch_class_metaclass.png" alt="figure 4: Introduction of a class's singleton class">
+	<img src="images/ch_class_metaclass.png" alt="figure 4: Introduction of a class's singleton class">
 	<figcaption>figure 4: Introduction of a class's singleton class</figcaption>
 </figure>
 
@@ -1008,7 +1008,7 @@ must again be a singleton class.
 You'll understand with one more inheritance level (figure 5).
 
 <figure>
-	hanks<img src="images/ch_class_multi.png" alt="figure 5: Hierarchy of multi-level inheritance">
+	<img src="images/ch_class_multi.png" alt="figure 5: Hierarchy of multi-level inheritance">
 	<figcaption>figure 5: Hierarchy of multi-level inheritance</figcaption>
 </figure>
 
@@ -1029,7 +1029,7 @@ end
 internally, a structure like figure 6 is created.
 
 <figure>
-	hanks<img src="images/ch_class_metatree.png" alt="figure 6: Class hierarchy and metaclasses">
+	<img src="images/ch_class_metatree.png" alt="figure 6: Class hierarchy and metaclasses">
 	<figcaption>figure 6: Class hierarchy and metaclasses</figcaption>
 </figure>
 
@@ -1046,7 +1046,7 @@ I've made figure 7 from the results of this
 investigation.
 
 <figure>
-	hanks<img src="images/ch_class_mmm.png" alt="figure 7: Class of a class's singleton class">
+	<img src="images/ch_class_mmm.png" alt="figure 7: Class of a class's singleton class">
 	<figcaption>figure 7: Class of a class's singleton class</figcaption>
 </figure>
 
@@ -1099,7 +1099,7 @@ chain (figure 8).
 `I_CLASS` will appear later when we will talk about include.
 
 <figure>
-	hanks<img src="images/ch_class_real.png" alt="figure 8: Singleton class and real class">
+	<img src="images/ch_class_real.png" alt="figure 8: Singleton class and real class">
 	<figcaption>figure 8: Singleton class and real class</figcaption>
 </figure>
 
@@ -1160,15 +1160,15 @@ And in the three lines of the second half, `(Object)`, `(Module)` and
 metaobjects' bootstrap is finished.
 
 <figure>
-	hanks<img src="images/ch_class_boot1.png" alt="figure 9: Metaobjects creation">
+	<img src="images/ch_class_boot1.png" alt="figure 9: Metaobjects creation">
 	<figcaption>figure 9: Metaobjects creation</figcaption>
 </figure>
 
 After taking everything into account, it gives us the final shape
 like figure 10.
 
 <figure>
-	hanks<img src="images/ch_class_metaobj.png" alt="figure 10: Ruby metaobjects">
+	<img src="images/ch_class_metaobj.png" alt="figure 10: Ruby metaobjects">
 	<figcaption>figure 10: Ruby metaobjects</figcaption>
 </figure>
 
@@ -1622,7 +1622,7 @@ module's body and the include class will still have exactly the
 same methods (figure 11).
 
 <figure>
-	hanks<img src="images/ch_class_symbolic.png" alt="figure 11: Include class">
+	<img src="images/ch_class_symbolic.png" alt="figure 11: Include class">
 	<figcaption>figure 11: Include class</figcaption>
 </figure>
 
@@ -1637,7 +1637,7 @@ wrong. In brief, including is inserting the include class of a
 module between a class and its superclass (figure 12).
 
 <figure>
-	hanks<img src="images/ch_class_include.png" alt="figure 12: Include">
+	<img src="images/ch_class_include.png" alt="figure 12: Include">
 	<figcaption>figure 12: Include</figcaption>
 </figure>
 
@@ -1663,7 +1663,7 @@ that includes `m2`. From there, the changes made to include `m1` in
 `c1` are (2) and (3). `im`s are of course include classes.
 
 <figure>
-	hanks<img src="images/ch_class_simulate.png" alt="figure 13: Include">
+	<img src="images/ch_class_simulate.png" alt="figure 13: Include">
 	<figcaption>figure 13: Include</figcaption>
 </figure>
 
@@ -1732,4 +1732,3 @@ but in the case of module there is no such thing. Therefore the
 singleton methods of the module are not inherited by the including
 class (or module). When you want to also inherit singleton methods,
 the usual way is to override `Module#append_features`.
-

contextual.md

@@ -107,7 +107,7 @@ What states are there? Let’s look at the definitions.
 The EXPR prefix stands for “expression”. `EXPR_BEG` is “Beginning of
 expression” and `EXPR_DOT` is “inside the expression, after the dot”.
 
-To elaborate, `EXPR_BEG` denotes “Located at the head of the expression”. 
+To elaborate, `EXPR_BEG` denotes “Located at the head of the expression”.
 `EXPR_END` denotes “Located at the end of the expression”. `EXPR_ARG` denotes
 “Before the method parameter”. `EXPR_FNAME` denotes “Before the method name
 (such as `def`)”. The ones not covered here will be analyzed in detail below.
@@ -176,7 +176,7 @@ export their location, for example, such as `'#'` and `'*'` and `'!'` of
 which case suits best (see image 1)
 
 <figure>
-	hanks<img src="images/ch_contextual_transittobeg.jpg" alt="figure 1: Transition to `EXPR_BEG`">
+	<img src="images/ch_contextual_transittobeg.jpg" alt="figure 1: Transition to `EXPR_BEG`">
 	<figcaption>figure 1: Transition to `EXPR_BEG`</figcaption>
 </figure>
 
@@ -830,7 +830,7 @@ be enough to understand the criteria for making the distinction.
 
 It’s a little messy, but you only need the part associated with `kDO_COND`.
 That is because only two comparisons are meaningful.
-The first is the comparison between `kDO_COND` and `kDO`/`kDO_BLOCK` 
+The first is the comparison between `kDO_COND` and `kDO`/`kDO_BLOCK`
 The second is the comparison between `kDO` and `kDO_BLOCK`.
 The rest are meaningless.
 Right now we only need to distinguish the conditional `do` - leave all the
@@ -904,7 +904,7 @@ MSB←   →LSB
 
 ((errata:<br>
 It leaves `COND_P()` only when it is 1.
-When `COND_P()` is 0 and the second bottom bit is 1,  
+When `COND_P()` is 0 and the second bottom bit is 1,
 it would become 1 after doing LEXPOP,
 thus `COND_P()` is not left in this case.
 ))
@@ -961,7 +961,7 @@ the name `cond_stack` itself is clearly the name for a macro that determines
 whether or not it’s on the same level as the conditional expression (see image 2)
 
 <figure>
-	hanks<img src="images/ch_contextual_condp.jpg" alt="figure 2: Changes of `COND_P(">
+	<img src="images/ch_contextual_condp.jpg" alt="figure 2: Changes of `COND_P(">
 	<figcaption>figure 2: Changes of `COND_P(</figcaption>
 </figure>
 
@@ -1160,7 +1160,7 @@ Now I need you to focus on `method_call` and `command_call` If you leave the
 will appear from `tLPAREN_ARG` and conflict with `method_call` (see image 3)
 
 <figure>
-	hanks<img src="images/ch_contextual_trees.jpg" alt="figure 3: `method_call` and `command_call`">
+	<img src="images/ch_contextual_trees.jpg" alt="figure 3: `method_call` and `command_call`">
 	<figcaption>figure 3: `method_call` and `command_call`</figcaption>
 </figure>
 
@@ -1721,9 +1721,9 @@ In the following case, priorities should have an influence.
 (But it does not in the actual code. It means this is a bug.)
 
 ```TODO-lang
-m m (a) { ... } # This should be interpreted as m(m(a) {...}), 
+m m (a) { ... } # This should be interpreted as m(m(a) {...}),
                 # but is interpreted as m(m(a)) {...}
-m m (a) do ... end # as the same as this: m(m(a)) do ... end 
+m m (a) do ... end # as the same as this: m(m(a)) do ... end
 ```
 ))
 

gc.md

@@ -44,7 +44,7 @@ When doing `return`, one stack frame will be popped.
 Figure 1 shows the really simplified appearance of the machine stack.
 
 <figure>
-	hanks<img src="images/ch_gc_macstack.jpg" alt="figure 1: Machine Stack">
+	<img src="images/ch_gc_macstack.jpg" alt="figure 1: Machine Stack">
 	<figcaption>figure 1: Machine Stack</figcaption>
 </figure>
 
@@ -87,7 +87,7 @@ free them by using `free()`.
 
 
 <figure>
-	hanks<img src="images/ch_gc_calloca.jpg" alt="figure 2: The behavior of an `alloca(">
+	<img src="images/ch_gc_calloca.jpg" alt="figure 2: The behavior of an `alloca(">
 	<figcaption>figure 2: The behavior of an `alloca(</figcaption>
 </figure>
 
@@ -155,7 +155,7 @@ let's simplify the structure by assuming that there are only objects and links.
 This would look as shown in Figure 3.
 
 <figure>
-	hanks<img src="images/ch_gc_objects.jpg" alt="figure 3: Objects">
+	<img src="images/ch_gc_objects.jpg" alt="figure 3: Objects">
 	<figcaption>figure 3: Objects</figcaption>
 </figure>
 
@@ -176,7 +176,7 @@ necessary objects. The rest of the objects can be released.
 
 
 <figure>
-	hanks<img src="images/ch_gc_gcimage.jpg" alt="figure 4: necessary objects and unnecessary objects">
+	<img src="images/ch_gc_gcimage.jpg" alt="figure 4: necessary objects and unnecessary objects">
 	<figcaption>figure 4: necessary objects and unnecessary objects</figcaption>
 </figure>
 
@@ -228,7 +228,7 @@ And put an "active" mark on the one of the areas.
 When creating an object, create it only in the "active" one. (Figure 5)
 
 <figure>
-	hanks<img src="images/ch_gc_stop2.jpg" alt="figure 5: Stop and Copy (1">
+	<img src="images/ch_gc_stop2.jpg" alt="figure 5: Stop and Copy (1">
 	<figcaption>figure 5: Stop and Copy (1</figcaption>
 </figure>
 
@@ -239,7 +239,7 @@ mark-and-sweep. However, move objects to another area instead of marking them
 which remain in @A@, and make @B@ active next.
 
 <figure>
-	hanks<img src="images/ch_gc_stop3.jpg" alt="figure 6: Stop and Copy (2">
+	<img src="images/ch_gc_stop3.jpg" alt="figure 6: Stop and Copy (2">
 	<figcaption>figure 6: Stop and Copy (2</figcaption>
 </figure>
 
@@ -271,7 +271,7 @@ When the counter of an object becomes zero, release the object.
 This is the method called reference counting (Figure 7).
 
 <figure>
-	hanks<img src="images/ch_gc_refcnt.jpg" alt="figure 7: Reference counting">
+	<img src="images/ch_gc_refcnt.jpg" alt="figure 7: Reference counting">
 	<figcaption>figure 7: Reference counting</figcaption>
 </figure>
 
@@ -292,7 +292,7 @@ If this is the case the counters will never decrease
 and the objects will never be released.
 
 <figure>
-	hanks<img src="images/ch_gc_cycle.jpg" alt="figure 8: Cycle">
+	<img src="images/ch_gc_cycle.jpg" alt="figure 8: Cycle">
 	<figcaption>figure 8: Cycle</figcaption>
 </figure>
 
@@ -430,7 +430,7 @@ the each contained array is probably each @heap@.
 Each element of @heap@ is each @slot@ (Figure 9).
 
 <figure>
-	hanks<img src="images/ch_gc_heapitems.jpg" alt="figure 9: `heaps`, `heap`, `slot`">
+	<img src="images/ch_gc_heapitems.jpg" alt="figure 9: `heaps`, `heap`, `slot`">
 	<figcaption>figure 9: `heaps`, `heap`, `slot`</figcaption>
 </figure>
 
@@ -440,7 +440,7 @@ is in the corresponding @heaps_limits[index]@.
 Figure 10 shows the structure of the object heap.
 
 <figure>
-	hanks<img src="images/ch_gc_heaps.jpg" alt="figure 10: conceptual diagram of `heaps` in memory">
+	<img src="images/ch_gc_heaps.jpg" alt="figure 10: conceptual diagram of `heaps` in memory">
 	<figcaption>figure 10: conceptual diagram of `heaps` in memory</figcaption>
 </figure>
 
@@ -1722,7 +1722,7 @@ the new-generation objects will not be marked. (Figure 11)
 
 
 <figure>
-	hanks<img src="images/ch_gc_gengc.jpg" alt="figure 11: reference over generations">
+	<img src="images/ch_gc_gengc.jpg" alt="figure 11: reference over generations">
 	<figcaption>figure 11: reference over generations</figcaption>
 </figure>
 
@@ -1766,7 +1766,7 @@ extension libraries is lost.
 
 
 <figure>
-	hanks<img src="images/ch_gc_objid.jpg" alt="figure 12: reference through the object ID">
+	<img src="images/ch_gc_objid.jpg" alt="figure 12: reference through the object ID">
 	<figcaption>figure 12: reference through the object ID</figcaption>
 </figure>
 
@@ -1780,7 +1780,7 @@ object structs is quite high.
 
 
 <figure>
-	hanks<img src="images/ch_gc_mostcopy.jpg" alt="figure 13: Mostly-copying garbage collection">
+	<img src="images/ch_gc_mostcopy.jpg" alt="figure 13: Mostly-copying garbage collection">
 	<figcaption>figure 13: Mostly-copying garbage collection</figcaption>
 </figure>