Fix: typos (#733)

* Fix: typo

Fix: typo

* Fix: typos

Fix: typos

* Fix: typos

Fix: typos

* Fix: typos

Fix: typos

README.md

@@ -143,7 +143,7 @@ cargo bench
 
 ### Cairo
 * From Cairo Documentation: [How Cairo Works](https://www.cairo-lang.org/docs/how_cairo_works/index.html#how-cairo-works)
-* [Cairo – a Turing-complete STARK-friendly CPU architecturer](https://eprint.iacr.org/2021/1063)
+* [Cairo – a Turing-complete STARK-friendly CPU architecture](https://eprint.iacr.org/2021/1063)
 * [A Verified Algebraic Representation of Cairo Program Execution](https://arxiv.org/pdf/2109.14534.pdf)
 * [Cairo Verifier](https://github.com/patrickbiel01/Cairo_Verifier) in Rust
 

docs/hint_processor/README.md

@@ -26,7 +26,7 @@ The purpose of this method is to organize the data related to hints in the way i
 This method is called at the start of each VM step when there is a hint to execute.
 It receives the dynamic structure created by `compile_hint` along with the program constants and a set of proxies containing a limited access to the VM's Internals:
 
-* `exec_scopes_proxy` is the hint's gateaway to interact with the execution_scopes in the VM and share data bewteen hints without inserting them into the cairo execution. It provides methods to create and remove scopes and to modify the current scope, along with several helper methods to allow inserting and retrieving variables of specific types. This proxy only allows modifying the current scope, which is the last available scope before the hint's execution (Note that calling enter_scope and exit_scope wont change the current scope for the duration of the hint´s execution)
+* `exec_scopes_proxy` is the hint's gateway to interact with the execution_scopes in the VM and share data between hints without inserting them into the cairo execution. It provides methods to create and remove scopes and to modify the current scope, along with several helper methods to allow inserting and retrieving variables of specific types. This proxy only allows modifying the current scope, which is the last available scope before the hint's execution (Note that calling enter_scope and exit_scope won't change the current scope for the duration of the hint´s execution)
 * `vm_proxy` is the hint's gateway to the internal values of the VM, it provides mutable references to the memory segment manager and the run context, and immutable references to the builtin runners and the program's prime, it also contains a memory proxy:
 * `MemoryProxy`: It grants a more limited access to the VM's memory, providing the necessary methods to modify it in a controlled manner.
 
@@ -44,12 +44,12 @@ The following helper functions are provided in hint_processor_utils.rs to simpli
 
 These methods take the HintReference associated to the variable along with the hint's ApTracking data.
 
-Note: When handling pointer type variables, computing the address and using it to get the variable from memory might not lead to the correct value (as the variable refrence may contain an immediate value that has to be added to the ptr itself), so using the functiom get_ptr_from_reference is strongly recomended.
-Note: Cairo's memory is write-once, read-only, so when using `insert_value_from_reference` its important to first make sure that the variable doesnt contain any value (for example, it may be defined as local but never written) to avoid inconsistent memory errors
+Note: When handling pointer type variables, computing the address and using it to get the variable from memory might not lead to the correct value (as the variable reference may contain an immediate value that has to be added to the ptr itself), so using the function get_ptr_from_reference is strongly recommended.
+Note: Cairo's memory is write-once, read-only, so when using `insert_value_from_reference` it's important to first make sure that the variable doesn't contain any value (for example, it may be defined as local but never written) to avoid inconsistent memory errors
 
 ## BuiltinHintProcessor
 
-The BuiltinHintProcessor is the default hint exector of the VM, it is able to execute hints from the common library + sha256
+The BuiltinHintProcessor is the default hint executor of the VM, it is able to execute hints from the common library + sha256
 
 ## Usage Example
 

docs/hint_processor/hint_design.md

@@ -2,7 +2,7 @@
 
 ## Requirements for hints
 - Must cairo-rs support reuse of existing hints in starknet? Is it enough to enable re-writing these hints as python-embedded-in-cairo that uses a new API to interface with the cairo-rs VM state?
-- Aside from mutable access to the memory manager and the registers, what do non-builtin hints require in terms of mutating the VM state? Is there anything that is explicitly not allowed or desireable, or that is currently allowed but would be better restricted?
+- Aside from mutable access to the memory manager and the registers, what do non-builtin hints require in terms of mutating the VM state? Is there anything that is explicitly not allowed or desirable, or that is currently allowed but would be better restricted?
 - What is the medium-long term plan for hints? Be able to implement hints as rust-embedded-in-cairo, support python hints ad aeternum, add support for more languages?
 - We should go through the implementation of the syscall hints and think how they can be implemented with the current cairo-rs code, what is missing, etc.
 
@@ -40,8 +40,8 @@ Notes
 - How to provide the embedded python interpreter access to cairo-rs VM state?
 - How hard will converting between type representations be? 
 - One possibility that can be explored is writing a new implementation of MemorySegmentManager in python which works together with the python embedding mechanism, so that hints that get passed a reference to the MSM will be able to access cairo-rs instead of the python vm
-- Another possibility that might be necesary is modifying the starknet hints in python to use a new interface mechanism.
-- Of the three embedding options, cpython seems the most straighforward but also limited, pyo3 the most powerful, and rustpython the least mature
+- Another possibility that might be necessary is modifying the starknet hints in python to use a new interface mechanism.
+- Of the three embedding options, cpython seems the most straightforward but also limited, pyo3 the most powerful, and rustpython the least mature
 - From [here](https://www.infoworld.com/article/3664124/how-to-use-rust-with-python-and-python-with-rust.html):
       An important caveat with both cpython and PyO3 is to always minimize the number of times data is passed back and forth between the two languages.
       Each call from Python to Rust or vice versa incurs some overhead.
@@ -55,7 +55,7 @@ Notes
 	- How to provide access to vm state, and allow state modification by hints?
 	- Should the hint code running in python intermittingly call an API to modify cairo-rs VM state, or should it run in completion, and send changes back to cairo-rs once done?
 	- Should this protocol send and receive a full vm state representation, or just some representation of the changes to state made by the hint?
-	- Open question: aside from the the api to indirectly modify cairo-rs vm state, what else is needed to allow hints to run? dependencies?
+	- Open question: aside from the api to indirectly modify cairo-rs vm state, what else is needed to allow hints to run? dependencies?
 	- How will having this python codebase affect testing, packaging, running, etc?
 	- (+) more easily extensible to other languages?
 	- (-) likely more overhead from state (de)serialization

docs/python_rust_integration_specs.md

@@ -14,7 +14,7 @@ In order to allow cairo-rs to execute any Python code embedded into a Cairo prog
 * The crate cairo-rs-py will behave as a cairo-rs VM wrapper, which can also be imported as a Python module. 
 * The cairo-rs-py VM can be run for a set number of steps.
 * The cairo-rs-py VM can be run for a set number of steps, paused, and then continue its execution.
-* Variables defined by a hint can only be accessed by hints implemented in the same language, i.e., Rust hints are aware only of variables defined by Rust hints and Python hints are aware only of variables defined by Python hints. By Rust hints we refer to those implemented by the builtin hint processor.	 	
+* Variables defined by a hint can only be accessed by hints implemented in the same language, i.e., Rust hints are aware only of variables defined by Rust hints and Python hints are aware only of variables defined by Python hints. By Rust hints we refer to those implemented by the built-in hint processor.	 	
 * The cairo-rs-py VM can be instantiated by a Python interpreter as a regular object. 
 * A Rust or Python program can instantiate one or more independent cairo-rs-py VMs, allowing for multiple coexisting VMs.
 * When instantiated by a Python interpreter, that same interpreter will be used to execute Python hints. 
@@ -23,7 +23,7 @@ In order to allow cairo-rs to execute any Python code embedded into a Cairo prog
 * An instance of a cairo-rs-py VM will be running either a cairo program interpretation loop or a Python hint, but not both at the same time.
 	* i.e. hints do not run concurrently 
 	* The VM state shared with hints can only be accessed by a single hint at a time.
-	* The VM memory is private to a VM instance and cannot be shared across differents VM instances.
+	* The VM memory is private to a VM instance and cannot be shared across different VM instances.
 	* An instance of a VM will always run on the same thread.
 	* Multiple instances of a VM can run on the same thread.
 * Hint interaction with the VM will be restricted to: