Rename cairo-rs to cairo-vm

.gitignore

@@ -11,8 +11,8 @@
 **/*.swp
 bench/results
 .python-version
-cairo-rs-env/*
-cairo-rs-pypy-env/*
+cairo-vm-env/*
+cairo-vm-pypy-env/*
 cairo/
 
 ensure-no_std/Cargo.lock

CHANGELOG.md

@@ -12,13 +12,13 @@
 
 * build: remove dependency to `thiserror` (use `thiserror-no-std/std` instead)
 
-* chore: use LambdaWorks' implementation of bit operations for `Felt252` [#1291](https://github.com/lambdaclass/cairo-rs/pull/1291)
+* chore: use LambdaWorks' implementation of bit operations for `Felt252` [#1291](https://github.com/lambdaclass/cairo-vm/pull/1291)
 
 * update `cairo-lang-starknet` and `cairo-lang-casm` dependencies to v2.0.0-rc5 [#1297](https://github.com/lambdaclass/cairo-vm/pull/1297)
 
 #### [0.8.0] - 2023-6-26
 
-* feat: Add feature `lambdaworks-felt` to `felt` & `cairo-vm` crates [#1218](https://github.com/lambdaclass/cairo-vm/pull/1281)
+* feat: Add feature `lambdaworks-felt` to `felt` & `cairo-vm` crates [#1281](https://github.com/lambdaclass/cairo-vm/pull/1281)
 
     Changes under this feature:
   * `Felt252` now uses *LambdaWorks*' `FieldElement` internally

README.md

@@ -138,7 +138,7 @@ Currently, as this VM is under construction, it's missing some of the features o
 There are two ways to use non-standard hints in this VM:
 
 - Extend the cairo-vm code and build your own binary using the interface [HintProcessor](docs/hint_processor/README.md).
-- Use [cairo-rs-py](https://github.com/lambdaclass/cairo-rs-py) which supports running any hint in a Python interpreter.
+- Use [cairo-vm-py](https://github.com/lambdaclass/cairo-vm-py) which supports running any hint in a Python interpreter.
 
 ### Running a function in a Cairo program with arguments
 
@@ -258,7 +258,7 @@ You can find more detailed instructions in the [CONTRIBUTING.md](CONTRIBUTING.md
 ## 🌞 Related Projects
 
 - [starknet_in_rust](https://github.com/lambdaclass/starknet_in_rust): implementation of Starknet in Rust, powered by the cairo-vm.
-- [cairo-rs-py](https://github.com/lambdaclass/cairo-rs-py): Bindings for using cairo-vm from Python code.
+- [cairo-vm-py](https://github.com/lambdaclass/cairo-vm-py): Bindings for using cairo-vm from Python code.
 
 ## 📚 Documentation
 

docs/python_rust_integration_specs.md

@@ -10,17 +10,17 @@ In order to allow cairo-vm to execute any Python code embedded into a Cairo prog
 * Have an external crate which encapsulates the Python hint execution, and which is able to both run cairo-vm, and be imported as a Python module so that the VM can be ran from a Python process.
 
 ### SPECIFICATION
-* FFI integration and functionality will be encapsulated in a crate external to cairo-vm. This crate will be called cairo-rs-py.
-* The crate cairo-rs-py will behave as a cairo-vm 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.
+* FFI integration and functionality will be encapsulated in a crate external to cairo-vm. This crate will be called cairo-vm-py.
+* The crate cairo-vm-py will behave as a cairo-vm VM wrapper, which can also be imported as a Python module. 
+* The cairo-vm-py VM can be run for a set number of steps.
+* The cairo-vm-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 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.
+* The cairo-vm-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-vm-py VMs, allowing for multiple coexisting VMs.
 * When instantiated by a Python interpreter, that same interpreter will be used to execute Python hints. 
 * Python hints have limited access to the running context (code paths, modules, scopes created by previous hints).
 * The syscall handler will be instantiated before the VM run and should be available on the hint locals.
-* 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.
+* An instance of a cairo-vm-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 different VM instances.
@@ -35,5 +35,5 @@ In order to allow cairo-vm to execute any Python code embedded into a Cairo prog
 
 * Nice to have: 
 	* Drop the GIL during Rust operation to allow to parallelism when using multi-threads instead of process.
-	* The cairo-rs-py VM can be instantiated by a Rust program, still allowing Python hints in Cairo programs.
-	* Python hints are supported when running the cairo-rs-py standalone binary (as opposed to importing it from Python) only with the CPython interpreter.
+	* The cairo-vm-py VM can be instantiated by a Rust program, still allowing Python hints in Cairo programs.
+	* Python hints are supported when running the cairo-vm-py standalone binary (as opposed to importing it from Python) only with the CPython interpreter.

vm/Cargo.toml

@@ -1,8 +1,11 @@
 [package]
 name = "cairo-vm"
 description = "Blazing fast Cairo interpreter"
-repository = "https://github.com/lambdaclass/cairo-vm/"
-readme= "../README.md"
+version.workspace = true
+edition.workspace = true
+license.workspace = true
+repository.workspace = true
+readme.workspace = true
 
 [features]
 default = ["std", "with_mimalloc"]

vm/src/types/program.rs

@@ -25,7 +25,7 @@ use std::path::Path;
 // a `CairoRunner` becomes a bottleneck, but the following solutions were tried and
 // discarded:
 // - Store only a reference in `CairoRunner` rather than cloning; this doesn't work
-//   because then we need to introduce explicit lifetimes, which broke `cairo-rs-py`
+//   because then we need to introduce explicit lifetimes, which broke `cairo-vm-py`
 //   since PyO3 doesn't support Python objects containing structures with lifetimes.
 // - Directly pass an `Arc<Program>` to `CairoRunner::new()` and simply copy that:
 //   there was a prohibitive performance hit of 10-15% when doing so, most likely

vm/src/vm/runners/builtin_runner/mod.rs

@@ -39,7 +39,7 @@ pub const KECCAK_BUILTIN_NAME: &str = "keccak_builtin";
 pub const POSEIDON_BUILTIN_NAME: &str = "poseidon_builtin";
 pub const SEGMENT_ARENA_BUILTIN_NAME: &str = "segment_arena_builtin";
 
-/* NB: this enum is no accident: we may need (and cairo-rs-py *does* need)
+/* NB: this enum is no accident: we may need (and cairo-vm-py *does* need)
  * structs containing this to be `Send`. The only two ways to achieve that
  * are either storing a `dyn Trait` inside an `Arc<Mutex<&dyn Trait>>` or
  * making the type itself `Send`. We opted for not complicating the user nor