GitBook: [2.0.0] 23 pages modified

knowledge_aquamarine/marine/marine-rs-sdk.md

@@ -333,8 +333,8 @@ Since we are compiling to a wasm32-wasi target with `ftype` constrains, the basi
 Let's have a look at an implementation example:
 
 ```rust
-use marine_rs_sdk::marine;
-use marine_rs_sdk::module_manifest;
+use fluence::marine;
+use fluence::module_manifest;
 
 module_manifest!();
 
@@ -350,13 +350,13 @@ mod tests {
     use fluence_test::marine_test;   # 2
 
     #[marine_test(config_path = "../Config.toml", modules_dir = "../artifacts")] # 3
-    fn empty_string(greeting: marine_test_env::greeting::ModuleInterface) {
+    fn empty_string() {
         let actual = greeting.greeting(String::new());  # 4 
         assert_eq!(actual, "Hi, ");
     }
 
     #[marine_test(config_path = "../Config.toml", modules_dir = "../artifacts")]
-    fn non_empty_string(greeting: marine_test_env::greeting::ModuleInterface) {
+    fn non_empty_string() {
         let actual = greeting.greeting("name".to_string());
         assert_eq!(actual, "Hi, name");
     }
@@ -364,11 +364,11 @@ mod tests {
 ```
 
 1. We wrap a basic _greeting_ function with the `[marine`\] macro which results in the greeting.wasm module
-2. We wrap our tests as usual with `[cfg(test)]` and import the marine _test crate._ Do **not** import _super_ or the _local crate_. 
-3. Instead, we apply the `[marine_test]` macro to each of the test functions by providing the path to the config file, e.g., Config.toml, and the directory containing the Wasm module we obtained after compiling our project with `marine build`. Moreover, we add the type of the test as an argument in the function signature. It is imperative that project build precedes the test runner otherwise the required Wasm file will ne missing.
-4. The target of our tests is the `pub fn greeting` function. Since we are calling the function from the Wasm module we must prefix the function name with the module namespace -- `greeting` in this example case as specified in the function argument.
+2. We wrap our tests as usual with `[cfg(test)]` and import the fluence _test crate._ Do **not** import _super_ or the _local crate_. 
+3. Instead, we apply the `[marine_test]` to each of the test functions by providing the path to the config file, e.g., Config.toml, and the directory containing the Wasm module we obtained after compiling our project with `marine build`. It is imperative that project compilation proceeds the test runner otherwise there won't be the required Wasm file.
+4. The target of our tests is the `pub fn greeting` function. Since we are calling the function from the Wasm module we must prefix the function name with the module namespace -- `greeting` in this example case.
 
-Now that we have our Wasm module and tests in place, we can proceed with `cargo test --release.` Note that using the `release`flag vastly improves the import speed of the necessary Wasm modules.  
+Now that we have our Wasm module and tests in place, we can proceed with `cargo test --release.` Note that using the `release`vastly improves the import speed of the necessary Wasm modules.  
 
 ### Features
 

quick-start/2.-hosted-services.md

@@ -2,7 +2,7 @@
 
 In the previous example, we used a local, browser-native service to facilitate the string generation and communication with another browser. The real power of the Fluence solution, however, is that services can be hosted on one or more nodes, easily reused and composed into decentralized applications with Aqua.
 
-### Creating A Wasm Module
+### Creating A WebAssembly Module
 
 In this section, we develop a simple `HelloWorld` service and host it on a peer-to-peer node of the Fluence testnet. In your VSCode IDE, change to the `2-hosted-services` directory and open the `src/main.rs` file:
 
@@ -56,13 +56,13 @@ mod tests {
     use marine_rs_sdk_test::marine_test;
 
     #[marine_test(config_path = "../configs/Config.toml", modules_dir = "../artifacts")]
-    fn non_empty_string() {
+    fn non_empty_string(hello_world: marine_test_env::hello_world::ModuleInterface) {
         let actual = hello_world.hello("SuperNode".to_string());
         assert_eq!(actual.msg, "Hello from: \nSuperNode".to_string());
     }
 
     #[marine_test(config_path = "../configs/Config.toml", modules_dir = "../artifacts")]
-    fn empty_string() {
+    fn empty_string(hello_world: marine_test_env::hello_world::ModuleInterface) {
         let actual = hello_world.hello("".to_string());
         assert_eq!(actual.msg, "Hello from: \n");
     }
@@ -71,7 +71,7 @@ mod tests {
 ```
 
   
- To run our tests, we can use the familiar[`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html) . However, we don't really care all that much about our native Rust functions being tested but want to test our WebAssembly functions. This is where the extra code in the test module comes into play. In short., we are running `cargo test` against the exposed interfaces of the `hello_world.wasm` module and  in order to do that, we need the `marine_test` macro and provide it with both the modules directory, i.e., the `artifacts` directory, and the location of the `Config.toml` file. Note that the `Config.toml` file specifies the module metadata and optional module linking data. Moreover, we need to call our Wasm functions from the module namespace, i.e. `hello_world.hello` instead of the standard `hello` -- see lines 13 and 19 above.
+ To run our tests, we can use the familiar[`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html) . However, we don't really care all that much about our native Rust functions being tested but want to test our WebAssembly functions. This is where the extra code in the test module comes into play. In short., we are running `cargo test` against the exposed interfaces of the `hello_world.wasm` module and  in order to do that, we need the `marine_test` macro and provide it with both the modules directory, i.e., the `artifacts` directory, and the location of the `Config.toml` file. Note that the `Config.toml` file specifies the module metadata and optional module linking data. Moreover, we need to call our Wasm functions from the module namespace, i.e. `hello_world.hello` instead of the standard `hello` -- see lines 13 and 19 above, which we specify as an argument in the test function signature \(lines 11 and 17, respectively\).
 
 From the VSCode terminal, we now run our tests with the`cargo +nightly test --release` command. Please note that if `nightly` is your default, you don't need it in your `cargo test` command.
 
@@ -115,7 +115,7 @@ result: Object({"msg": String("Hello from: \nFluence"), "reply": String("Hello b
 
 We can explore the available interfaces with the `i` command and see that the interfaces we marked with the `marine` macro in our Rust code above are indeed exposed and available for consumption. Using the `call` command, still in the REPL, we can access any available function in the module namespace, e.g., `call hello_word hello [<string arg>]`. You can exit the REPL with the `ctrl-c` command.
 
-### Exporting Wasm Interfaces To Aqua
+### Exporting WebAssembly Interfaces To Aqua
 
 In anticipation of future needs, note that `marine` allows us to export  the Wasm interfaces ready for use in Aqua. In your VSCode terminal, navigate to the \`\` directory