diff --git a/src/basic-syntax/assert-and-abort.md b/src/basic-syntax/assert-and-abort.md index 66302ad4..3aeb3cc9 100644 --- a/src/basic-syntax/assert-and-abort.md +++ b/src/basic-syntax/assert-and-abort.md @@ -40,7 +40,7 @@ The `assert!` macro is a built-in macro that can be used to assert a condition. ## Error constants -To make error codes more descriptive, it is a good practice to define error constants. Error constants are defined as `const` declarations and are usually prefixed with `E` followed by a camel case name. Error constatns are no different from other constants and don't have special handling. So their addition is purely a practice for better code readability. +To make error codes more descriptive, it is a good practice to define error constants. Error constants are defined as `const` declarations and are usually prefixed with `E` followed by a camel case name. Error constants are no different from other constants and don't have special handling. So their addition is purely a practice for better code readability. ```move {{#include ../../samples/sources/basic-syntax/assert-and-abort.move:error_const}} diff --git a/src/basic-syntax/visibility.md b/src/basic-syntax/visibility.md index a0355891..c2825ca5 100644 --- a/src/basic-syntax/visibility.md +++ b/src/basic-syntax/visibility.md @@ -7,7 +7,7 @@ Every module member has a visibility. By default, all module members are *privat A function or a struct defined in a module which has no visibility modifier is *private* to the module. It can't be called from other modules. ```move -module book::internal_visbility { +module book::internal_visibility { // This function can be called from other functions in the same module fun internal() { /* ... */ } @@ -24,11 +24,11 @@ module book::internal_visbility { ```move module book::try_calling_internal { - use book::internal_visbility; + use book::internal_visibility; // Different module -> can't call internal() fun try_calling_internal() { - internal_visbility::internal(); + internal_visibility::internal(); } } ``` diff --git a/src/hello-sui/module-structure.md b/src/hello-sui/module-structure.md index ed5fa140..22dc677b 100644 --- a/src/hello-sui/module-structure.md +++ b/src/hello-sui/module-structure.md @@ -51,7 +51,7 @@ The function takes the `Postcard` as the first argument and a value of the `addr ## Keeping the Object -A very common scenario is transfering the object to the caller. This can be done by calling the `send_to` function with the sender address. It can be read from the `ctx` argument, which is a `TxContext` type. +A very common scenario is transferring the object to the caller. This can be done by calling the `send_to` function with the sender address. It can be read from the `ctx` argument, which is a `TxContext` type. ```move {{#include ../../postcard/sources/postcard.move:keep}} diff --git a/src/programmability/epoch-and-time.md b/src/programmability/epoch-and-time.md index 86c41da1..d7f05405 100644 --- a/src/programmability/epoch-and-time.md +++ b/src/programmability/epoch-and-time.md @@ -18,7 +18,7 @@ It is also possible to get the unix timestamp of the epoch start: {{#include ../../samples/sources/programmability/epoch-and-time.move:epoch_start}} ``` -Normally, epochs are used in staking and system operations, however, in custom scenarios they can be used to emulate 24h periods. They are cricital if an application relies on the staking logic or needs to know the current validator set. +Normally, epochs are used in staking and system operations, however, in custom scenarios they can be used to emulate 24h periods. They are critical if an application relies on the staking logic or needs to know the current validator set. ## Time diff --git a/src/programmability/sui-framework.md b/src/programmability/sui-framework.md index 8795b9b5..48535a91 100644 --- a/src/programmability/sui-framework.md +++ b/src/programmability/sui-framework.md @@ -49,7 +49,7 @@ Just like with [Standard Library](./../basic-syntax/standard-library.md), some o Modules: + sui::address -- sui::authethicator_state +- sui::authenticator - sui::bag - sui::balance - sui::bcs @@ -93,7 +93,7 @@ Modules: - sui::ecdsa_r1 - sui::ecvrf - sui::ed25519 -- sui::groth16 +- sui::"groth16" - sui::group_ops - sui::hash - sui::hmac diff --git a/src/your-first-move/generating-docs.md b/src/your-first-move/generating-docs.md index c435eb8e..0834bbe9 100644 --- a/src/your-first-move/generating-docs.md +++ b/src/your-first-move/generating-docs.md @@ -51,7 +51,7 @@ BUILDING Book Samples > Alternatively, you can use `move test --doc` - this can be useful if you want to test and generate documentation at the same time. For example, as a part of your CI/CD pipeline. -Once the build is complete, the documentation will be available in the `build/docs` directory. Each modile will have its own `.md` file. The documentation for the `hello_world` module will be available in the `build/docs/hello_world.md` file. +Once the build is complete, the documentation will be available in the `build/docs` directory. Each module will have its own `.md` file. The documentation for the `hello_world` module will be available in the `build/docs/hello_world.md` file.
Click to see an example of the `hello_world.md` contents diff --git a/src/your-first-move/hello-world.md b/src/your-first-move/hello-world.md index 2ae50781..cb90a104 100644 --- a/src/your-first-move/hello-world.md +++ b/src/your-first-move/hello-world.md @@ -39,7 +39,7 @@ hello_world Expect the user to know how to use a terminal and a text editor? --> -If the output looks like this, then everything is fine, and we can proceed. The folder structure of the package is the folowing: +If the output looks like this, then everything is fine, and we can proceed. The folder structure of the package is the following: ```bash hello_world