Fix typos again

Found via `codespell -L rouge,intial,reseting,stap,fith`

Author: kianmeng

chapters/beam_loader.asciidoc

@@ -175,7 +175,7 @@ OpCase(move_return_x):
     }
 -----------------------------
 
-All the implementor has to do is to define the `MoveReturn` macro in `beam_emu.c` and
+All the implementer has to do is to define the `MoveReturn` macro in `beam_emu.c` and
 the instruction is complete.
 
 [[macro_arguments]]

chapters/c.asciidoc

@@ -397,7 +397,7 @@ either beam instructions or BIFs, depending on their complexity.
 Library functions are basic Erlang functions such as 'lists:length/1' that are part of the Erlang language. They could be implemented as BEAM instructions,
 BIFS, or in Erlang.
 
-BIFs are efficient as they are writen in C and optimized for performance within the BEAM.
+BIFs are efficient as they are written in C and optimized for performance within the BEAM.
 The disadvantages with BIFs are that long-running BIFs can block BEAM schedulers, affecting system responsiveness. They have limited extensibility as they are fixed within the runtime system.
 
 Most Erlang users will never need to write a BIF, but it is good to know what they are and how they work. Also if you are writing an EEP (Erlang Enhancement Proposal) you might need to write a BIF to implement the new functionality.
@@ -449,7 +449,7 @@ BIF_RETTYPE math_factorial_1(BIF_ALIST_1)
     long factorial = 1;
     Eterm result;
 
-    /* Check the arguemnt and return an error if it is not a positive integer.
+    /* Check the argument and return an error if it is not a positive integer.
        When defining a BIF with BIF_ALIST_X the arguments are named
        BIF_ARG_1, BIF_ARG_2 etc.
        To signal ann error use BIF_ERROR(BIF_P, BADARG);
@@ -629,7 +629,7 @@ tuple and call 'math_factorial_trap_1'.
 Now when we come back from a yield we might already have a bignum so we
 restructure the code a bit to handle this case.
 
-We check our iterator and every 1000 interations we save the state and yield. We also save the state and yield when we have a bignum.
+We check our iterator and every 1000 iterations we save the state and yield. We also save the state and yield when we have a bignum.
 
 ```c
 static Export math_factorial_trap_export;
@@ -719,7 +719,7 @@ bignum_loop:
             // Increment i so we don't get stuck in a loop. with i % 1000 == 0.
             // Save state: {(i+1), i!, n} and yield.
 
-            // Store the tuple with the sate on the heap
+            // Store the tuple with the state on the heap
             big_size = BIG_SIZE(big_val(big_factorial));
             hp = HAlloc(BIF_P, 4 + big_size + 1);
             big_hp = hp + 4;
@@ -790,7 +790,7 @@ It was a calm night, one of those rare occasions where everything in the system
 
 In the aftermath, the investigation revealed a peculiar sequence of events. The BEAM schedulers, designed to gracefully balance work and sleep, had been too eager to shut down when the workload diminished. Only a single scheduler remained active, handling the entirety of the system's operations.
 
-As fate would have it, this lone scheduler stumbled upon a task: converting a 4MB term into a binary for logging purposes. This seemingly routine operation invoked the term_to_binary function—a built-in function (BIF). Instead of breaking its workload into manageable chunks, it perfomed all the work until done and then reported it had used only 20 reductions.
+As fate would have it, this lone scheduler stumbled upon a task: converting a 4MB term into a binary for logging purposes. This seemingly routine operation invoked the term_to_binary function—a built-in function (BIF). Instead of breaking its workload into manageable chunks, it performed all the work until done and then reported it had used only 20 reductions.
 
 This non-yielding nature proved to be a fatal flaw. The single scheduler became entirely consumed, unable to handle other tasks or respond to the system's needs. Erlang's HEART mechanism, ever vigilant, detected the unresponsiveness and concluded that the node was beyond saving. With grim efficiency, it killed the node.
 

chapters/compiler.asciidoc

@@ -894,7 +894,7 @@ parse_json({cons, Line, Head, Tail})   -> {cons, Line, parse_json(Head),
 parse_json({nil, Line})                -> {nil, Line};
 %% Json String -> <<String>>
 parse_json({string, Line, String})     -> str_to_bin(String, Line);
-%% Json Integer -> Intger
+%% Json Integer -> Integer
 parse_json({integer, Line, Integer})   -> {integer, Line, Integer};
 %% Json Float -> Float
 parse_json({float, Line, Float})       -> {float, Line, Float};

chapters/debugging.asciidoc

@@ -4,7 +4,7 @@
 === Introduction
 This chapter goes into the various methods for finding and fixing bugs without disrupting the services in progress. We will explore testing techniques, tools, and frameworks that aid in testing and debugging your code. We'll also shed light on some common bug sources, such as deadlocks, message overflow, and memory issues, providing guidance on identifying and resolving these problems.
 
-Debugging is the process of identifying and eliminating errors, or "bugs," from software. While Erlang offers step-by-step debugging tools like the link:http://erlang.org/doc/apps/debugger/debugger_chapter.html[_Debugger_], the most effective debugging methods often rely on Erlang's tracing facilities. These facilities will be thoroughly discussed in Chapter xref:CH-Tracing[]. In this chapter We will touch on system level tracing witth dtrace and systemtap.
+Debugging is the process of identifying and eliminating errors, or "bugs," from software. While Erlang offers step-by-step debugging tools like the link:http://erlang.org/doc/apps/debugger/debugger_chapter.html[_Debugger_], the most effective debugging methods often rely on Erlang's tracing facilities. These facilities will be thoroughly discussed in Chapter xref:CH-Tracing[]. In this chapter We will touch on system level tracing with dtrace and systemtap.
 
 This chapter also explores the concept of "Crash Dumps," which are human-readable text files generated by the Erlang Runtime System when an unrecoverable error occurs, such as running out of memory or reaching an emulator limit. Crash Dumps are invaluable for post-mortem analysis of Erlang nodes, and you will learn how to interpret and understand them.
 
@@ -601,7 +601,7 @@ This dump suggests that the system crashed due to a memory allocation failure (`
 1. Slogan
     Indicates the reason for the crash. Common slogans include:
     - `eheap_alloc: Cannot allocate X bytes of memory` (Memory exhaustion)
-    - `Init terminating in do_boot ()` (Pobably an erro in the boot script)
+    - `Init terminating in do_boot ()` (Pobably an error in the boot script)
     - `Could not start kernel pid` (Probably a bad argument in config)
 
 2. System Information

chapters/io.asciidoc

@@ -270,7 +270,7 @@ PortSettings)`.
 A file descriptor port is opened with `{fd, In, Out}` as the
 `PortName`. This class of ports is used by some internal ERTS servers
 like the old shell. They are considered to not be very efficient and
-hence seldom used. Also the filedescriptors are non negative intgers
+hence seldom used. Also the filedescriptors are non negative integers
 representing open file descriptors in the OS. The file descriptor can
 not be an erlang I/O server.
 
@@ -389,7 +389,7 @@ By scheduling signals to/from the port asynchronously, Erlang ensures that proce
 
 Now this means that the erlang send operation is not always asynchronous. If the port is busy the send operation will block until the port is not busy anymore. This is a problem if you have a lot of processes sending data to the same port. The solution is to use a port server that can handle the backpressure and make sure that the send operation is always asynchronous.
 
-Let's do an example based on the offical port driver example:
+Let's do an example based on the official port driver example:
 link:https://www.erlang.org/doc/system/c_portdriver.html#c-driver[erlang.org:c-driver].
 
 Let us use the original complex c function, adding 1 or multiplying by 2.
@@ -481,15 +481,15 @@ That also worked as expected: we sent 10 messages and got the results back in th
 ```erlang
 5> busy_port:test_async_bar().
 Send: {bar,1}
-Shouldnt ! be async...
+Shouldn't ! be async...
 Send: {bar,2}
-Shouldnt ! be async...
+Shouldn't ! be async...
 Send: {bar,3}
-Shouldnt ! be async...
+Shouldn't ! be async...
 Send: {bar,4}
-Shouldnt ! be async...
+Shouldn't ! be async...
 Send: {bar,5}
-Shouldnt ! be async...
+Shouldn't ! be async...
 Send: {bar,6}
 Send: {bar,7}
 Send: {bar,8}

chapters/live.asciidoc

@@ -7,7 +7,7 @@
 In this chapter we will look at how to run a live system in a
 production environment and how to release your code for that system.
 
-In order to have reliable 24/7 server we need to beable to release new
+In order to have reliable 24/7 server we need to be able to release new
 features and bugfixes with as little disruption as possible to the
 running system. In this chapter we will learn about the tools provided
 by the runtime to handle releases.

chapters/processes.asciidoc

@@ -1332,7 +1332,7 @@ xref:erlang_process_memory_5[]:
  +-------+  +-------+  +-------+  +-------+
 ----
 
-The process dictionary is a very straighforward ((hash table))
+The process dictionary is a very straightforward ((hash table))
 implementation. In fact the PD memory area is just the plain bucket array,
 and each slot is either ((`NIL`)) (the empty list) if the bucket is empty,
 or otherwise it's a tagged pointer to data on the heap -- a simple tuple

chapters/profiling.asciidoc

@@ -184,7 +184,7 @@ Takeaway: Although each call to factorial/1 is extremely fast, its high call cou
 ===== cprof example
 
 The cprof tool uses breakpoints to count calls, a lightweight approach
-that doesn't requre recompilation or any trace messages.
+that doesn't require recompilation or any trace messages.
 But you do not get a full call graph, nor do you get timing information.
 
 [source,erlang]

chapters/type_system.asciidoc

@@ -358,7 +358,7 @@ Note however that for longer term representation of large amounts of data,
 lists can use a lot of memory. Suppose you have a million small integers,
 each of which could be represented in 2 bytes. On a 64-bit Erlang system,
 representing this as a list `[1234, 2001, ...]` would use one million cons
-cells each holding a 64-bit immedate integer and a 64-bit pointer to the
+cells each holding a 64-bit immediate integer and a 64-bit pointer to the
 next cell in the list, i.e., 16 bytes per cell. That's 16 megabytes instead
 of 2. It would be more space-efficient to pack this data into a binary, but
 it all depends on how you need to access these numbers.

code/book/src/generate_op_doc.erl

@@ -71,10 +71,10 @@ format_opcode(Opcode, Deprecated) ->
 
 
 strip(S) ->
- [ esacpe(Char)
+ [ escape(Char)
   || Char <- string:strip(S, right, 10)].
 
-esacpe(Char) ->
+escape(Char) ->
     case Char of
         $| -> "\|";
         $\n -> " ";