fixed a couple of typos

burningTyger · burningTyger · commit a0dbd9cdf655 · 2014-11-12T23:30:24.000+01:00
diff --git a/_posts/2014-11-12-rubinius-3-0-part-3-the-instructions.markdown b/_posts/2014-11-12-rubinius-3-0-part-3-the-instructions.markdown
@@ -82,7 +82,7 @@ Joking aside, what it shows is that there is a deep structure shared by differen
 
 These different representations are equivalent from the view of preserving the fundamental semantics, or _meaning_, of the program. So, why do we use these different forms?
 
-The reason is, they provide different advantages. The AST is easy to understand and easy to process. Once the source code is parsed, the virtual machine can begin executing the program immediately. However, the AST takes up quite a bit of space and requires doing some things over and over. The effort to optimize the tree to remove unneeded steps can be complex. On the other hand, bytecode takes more time to generate but removes some redundant steps in the process. Further optimizing the bytecode can often be performed just by looking at a sequence of a few instructions, something called _peephole optimization_
+The reason is, they provide different advantages. The AST is easy to understand and easy to process. Once the source code is parsed, the virtual machine can begin executing the program immediately. However, the AST takes up quite a bit of space and requires doing some things over and over. The effort to optimize the tree to remove unneeded steps can be complex. On the other hand, bytecode takes more time to generate but removes some redundant steps in the process. Further optimizing the bytecode can often be performed just by looking at a sequence of a few instructions, something called _peephole optimization_.
 
 The main takeaway is that a Ruby program can have many representations. In the next post, we'll even look at a Ruby program represented by [LLVM](http://llvm.org) IR. Any one of these general classes of representations, like trees, may itself have multiple forms. For example, the object graph and the s-expression above are both forms of trees. In the same way, "bytecode" instructions can have different forms. But before we get to that, let's talk about the general design of an instruction set.
 
@@ -108,7 +108,7 @@ My answer to this is that we need to convert the semantic cone into a semantic c
 
 ## Kinds of Instructions
 
-In Rubinius, every _executable context_, every script body, class or module body, block, or method, is represented by a CompiledCode instance. Every compiled code object has a separate executor, or "function" that executes that compiled code's "instructions". These instructions may by bytecode, or they may be machine code generated by the JIT compiler.
+In Rubinius, every _executable context_, every script body, class or module body, block, or method, is represented by a CompiledCode instance. Every compiled code object has a separate executor, or "function" that executes that compiled code's "instructions". These instructions may be bytecode, or they may be machine code generated by the JIT compiler.
 
 ### Stack Instructions
 
