Add a revision for Chapters 12 and 13

Chapters/01-base64.qmd

@@ -69,7 +69,7 @@ These are the 64 characters that compose the base64 scale. The equal sign charac
 but it is a special character in the base64 encoding system. This character is used solely as a suffix, to mark the end of the character sequence,
 or, to mark the end of meaningful characters in the sequence.
 
-The bulletpoints below summarises the base64 scale:
+The bullet points below summarises the base64 scale:
 
 - range 0 to 25 is represented by: ASCII uppercase letters `-> [A-Z]`;
 - range 26 to 51 is represented by: ASCII lowercase letters `-> [a-z]`;
@@ -379,7 +379,7 @@ becoming:
 - `output[2]` and `output[3]` are the character `=`.
 
 
-If these bulletpoints were a bit confusing for you, you may find the @tbl-transf-6bit more intuitive.
+If these bullet points were a bit confusing for you, you may find the @tbl-transf-6bit more intuitive.
 This table unifies all this logic into a simple table. Notice that
 this table also provides the exact expression in Zig that creates the corresponding
 byte in the output.

Chapters/09-data-structures.qmd

@@ -815,7 +815,7 @@ pub fn main() !void {
 
 There are other methods available from the linked list object, depending if this object is
 a singly linked list or a doubly linked list, that might be very useful for you. You can find a
-summary of them in the bulletpoints below:
+summary of them in the bullet points below:
 
 - `remove()` to remove a specific node from the linked list.
 - if singly linked list, `len()` to count how many nodes there is in the linked list.

Chapters/14-threads.qmd

@@ -75,7 +75,7 @@ the following steps:
 1. start cooking the food in the kitchen.
 1. when the food is fully cooked deliver this food to the client.
 
-If you think about the bulletpoints above, you will notice that one big moment of waiting
+If you think about the bullet points above, you will notice that one big moment of waiting
 is present in this hole process, which is while the food is being prepared and cooked
 inside the kitchen. Because while the food is being prepped, both the waiter and the client
 itself are waiting for the food to be ready and delivered.
@@ -609,7 +609,7 @@ where undefined behaviour can be introduced into the program.
 When we use mutexes in our program, the critical section defines the area of the codebase that we want to lock.
 So we normally lock the mutex object at the beginning of the critical section,
 and then, we unlock it at the end of the critical section.
-The two bulletpoints exposed below comes from the "Critical Section" article from GeekFromGeeks,
+The two bullet points exposed below comes from the "Critical Section" article from GeekFromGeeks,
 and they summarise well the role that a critical section plays in the thread syncronization problem [@geeks_critical_section].
 
 

ZigExamples/data-structures/generic_stack.zig

@@ -11,7 +11,6 @@ fn Stack(comptime T: type) type {
 
         pub fn init(allocator: Allocator, capacity: usize) !Stack(T) {
             var buf = try allocator.alloc(T, capacity);
-            @memset(buf[0..], 0);
             return .{
                 .items = buf[0..],
                 .capacity = capacity,
@@ -23,10 +22,10 @@ fn Stack(comptime T: type) type {
         pub fn push(self: *Self, val: T) !void {
             if ((self.length + 1) > self.capacity) {
                 var new_buf = try self.allocator.alloc(T, self.capacity * 2);
-                @memset(new_buf[0..], 0);
                 @memcpy(new_buf[0..self.capacity], self.items);
                 self.allocator.free(self.items);
                 self.items = new_buf;
+                self.capacity = self.capacity * 2;
             }
 
             self.items[self.length] = val;
@@ -36,7 +35,7 @@ fn Stack(comptime T: type) type {
         pub fn pop(self: *Self) void {
             if (self.length == 0) return;
 
-            self.items[self.length - 1] = 0;
+            self.items[self.length - 1] = undefined;
             self.length -= 1;
         }
 
@@ -66,5 +65,5 @@ pub fn main() !void {
     std.debug.print("Stack len: {d}\n", .{stack.length});
     stack.pop();
     std.debug.print("Stack len: {d}\n", .{stack.length});
-    std.debug.print("Stack state: {any}\n", .{stack.items});
+    std.debug.print("Stack state: {any}\n", .{stack.items[0..stack.length]});
 }

ZigExamples/data-structures/stack.zig

@@ -9,7 +9,6 @@ const Stack = struct {
 
     pub fn init(allocator: Allocator, capacity: usize) !Stack {
         var buf = try allocator.alloc(u32, capacity);
-        @memset(buf[0..], 0);
         return .{
             .items = buf[0..],
             .capacity = capacity,
@@ -21,10 +20,10 @@ const Stack = struct {
     pub fn push(self: *Stack, val: u32) !void {
         if ((self.length + 1) > self.capacity) {
             var new_buf = try self.allocator.alloc(u32, self.capacity * 2);
-            @memset(new_buf[0..], 0);
             @memcpy(new_buf[0..self.capacity], self.items);
             self.allocator.free(self.items);
             self.items = new_buf;
+            self.capacity = self.capacity * 2;
         }
 
         self.items[self.length] = val;
@@ -34,7 +33,7 @@ const Stack = struct {
     pub fn pop(self: *Stack) void {
         if (self.length == 0) return;
 
-        self.items[self.length - 1] = 0;
+        self.items[self.length - 1] = undefined;
         self.length -= 1;
     }
 
@@ -62,5 +61,5 @@ pub fn main() !void {
     std.debug.print("Stack len: {d}\n", .{stack.length});
     stack.pop();
     std.debug.print("Stack len: {d}\n", .{stack.length});
-    std.debug.print("Stack state: {any}\n", .{stack.items});
+    std.debug.print("Stack state: {any}\n", .{stack.items[0..stack.length]});
 }

docs/Chapters/01-base64.html

@@ -388,7 +388,7 @@ <h3 data-number="4.1.1" class="anchored" data-anchor-id="sec-base64-scale"><span
 <p>The base64 encoding system is based on a scale that goes from 0 to 63 (hence the name). Each index in this scale is represented by a character (it is a scale of 64 characters). So, in order to convert some binary data, to the base64 encoding, we need to convert each binary number to the corresponding character in this “scale of 64 characters”.</p>
 <p>The base64 scale starts with all ASCII uppercase letters (A to Z) which represents the first 25 indexes in this scale (0 to 25). After that, we have all ASCII lowercase letters (a to z), which represents the range 26 to 51 in the scale. After that, we have the one digit numbers (0 to 9), which represents the indexes from 52 to 61 in the scale. Finally, the last two indexes in the scale (62 and 63) are represented by the characters <code>+</code> and <code>/</code>, respectively.</p>
 <p>These are the 64 characters that compose the base64 scale. The equal sign character (<code>=</code>) is not part of the scale itself, but it is a special character in the base64 encoding system. This character is used solely as a suffix, to mark the end of the character sequence, or, to mark the end of meaningful characters in the sequence.</p>
-<p>The bulletpoints below summarises the base64 scale:</p>
+<p>The bullet points below summarises the base64 scale:</p>
 <ul>
 <li>range 0 to 25 is represented by: ASCII uppercase letters <code>-&gt; [A-Z]</code>;</li>
 <li>range 26 to 51 is represented by: ASCII lowercase letters <code>-&gt; [a-z]</code>;</li>
@@ -549,7 +549,7 @@ <h3 data-number="4.4.1" class="anchored" data-anchor-id="sec-6bit-transf"><span
 <li><code>output[1]</code> is produced by taking the last two bits from <code>input[0]</code>, then, move them four positions to the left.</li>
 <li><code>output[2]</code> and <code>output[3]</code> are the character <code>=</code>.</li>
 </ul>
-<p>If these bulletpoints were a bit confusing for you, you may find the <a href="#tbl-transf-6bit" class="quarto-xref">Table&nbsp;<span>4.1</span></a> more intuitive. This table unifies all this logic into a simple table. Notice that this table also provides the exact expression in Zig that creates the corresponding byte in the output.</p>
+<p>If these bullet points were a bit confusing for you, you may find the <a href="#tbl-transf-6bit" class="quarto-xref">Table&nbsp;<span>4.1</span></a> more intuitive. This table unifies all this logic into a simple table. Notice that this table also provides the exact expression in Zig that creates the corresponding byte in the output.</p>
 <div id="tbl-transf-6bit" class="quarto-float quarto-figure quarto-figure-center anchored">
 <figure class="quarto-float quarto-float-tbl figure">
 <figcaption class="quarto-float-caption-top quarto-float-caption quarto-float-tbl" id="tbl-transf-6bit-caption-0ceaefa1-69ba-4598-a22c-09a6ac19f8ca">

docs/Chapters/09-data-structures.html

@@ -744,7 +744,7 @@ <h2 data-number="11.3" class="anchored" data-anchor-id="linked-lists"><span clas
 <span id="cb20-17"><a href="#cb20-17" aria-hidden="true" tabindex="-1"></a>    three.insertAfter(&amp;four); <span class="co">// {1, 2, 3, 4, 5}</span></span>
 <span id="cb20-18"><a href="#cb20-18" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span></code><button title="Copy to Clipboard" class="code-copy-button"><i class="bi"></i></button></pre></div>
 </div>
-<p>There are other methods available from the linked list object, depending if this object is a singly linked list or a doubly linked list, that might be very useful for you. You can find a summary of them in the bulletpoints below:</p>
+<p>There are other methods available from the linked list object, depending if this object is a singly linked list or a doubly linked list, that might be very useful for you. You can find a summary of them in the bullet points below:</p>
 <ul>
 <li><code>remove()</code> to remove a specific node from the linked list.</li>
 <li>if singly linked list, <code>len()</code> to count how many nodes there is in the linked list.</li>