chore: Sync with Gitbook

chore: Sync with Gitbook

Author: dongwon8247

.gitbook/assets/17_gnokey_query.png.png

@@ -1,14 +1,13 @@
 # Gnoland Developer Portal
 
-Welcome to the Gnoland Developer Portal! 
+Welcome to the Gnoland Developer Portal!
 
 The purpose of this guide is to invite new developers into the world of Gnolang, a new programming language powering the Gnoland blockchain, by providing all the resources you need to become a Gnolang expert.
 
 _(This is an early-stage, in-progress draft. Your contributions are welcome. Please take a look at the_ [_contribution guidelines_](https://github.com/onbloc/gnoland-tutorials/blob/main/CONTRIBUTION.md)_.)_
 
 You can read the docs in [Gitbook](https://onbloc.gitbook.io/gnoland-developer-portal/) or [GitHub](https://github.com/onbloc/gnoland-tutorials).
 
-
 ## Table of Contents
 
 * Introduction to Gnoland

.gitbook/assets/22_gnoscan.png

@@ -1,6 +1,6 @@
 # Deploy and Call Realms
 
-There are two methods of deploying and calling realms. 
+There are two methods of deploying and calling realms.
 
 1. With the blockchain: You can use the subcommands of [`gnokey`](../cli/gnokey.md) such as [`addpkg`](../cli/gnokey.md#subcommands), to deploy a realm to the Gnoland blockchain, and [`maketx call`](../cli/gnokey.md#call), to call available realms in the Gnoland blockchain.
 2. Without a blockchain: You can use [`gno`](../cli/gno.md), which allows you to use the GnoVM without a blockchain in a local environment. This method is fast and allows you to use development patterns such as TDD. However, it does not facilitate the capability for external parties to participate in testing since it's done locally.

README.md

@@ -4,14 +4,14 @@ A realm refers to a specific instance of a smart contract that can be written in
 
 Before we dive in, let's first study the differences between realms and packages.
 
-#### ****[**Realms**](https://github.com/gnolang/gno/tree/master/examples/gno.land/r)****
+#### [**Realms**](https://github.com/gnolang/gno/tree/master/examples/gno.land/r)
 
 * Smart contracts in Gnolang.
 * Realms are stateful.
 * The default import path is `gno.land/r/~~~`.
 * Each realm has the capability to publicly export the function `Render(path string) string`, which performs rendering when passed a valid markdown as a parameter for the specified `path`.
 
-#### ****[**Packages**](https://github.com/gnolang/gno/tree/master/examples/gno.land/p/demo)****
+#### [**Packages**](https://github.com/gnolang/gno/tree/master/examples/gno.land/p/demo)
 
 * A unit that contains functionalities and utilities that can be used in realms.
 * Packages are stateless.

docs/building-a-realm/deploy-and-call-realms.md

@@ -54,8 +54,6 @@ func ImpossibleInc() {
 
 Let's break down the code by each segment.
 
-
-
 ```go
 var myVar = 1
 
@@ -76,8 +74,6 @@ The code block above displays the variable & constant declaration code (and 2 fu
 
 As a result, once the code above is executed, the `initlVar` variable with only a declared data type, but without an initial value, is assigned with a value of `1000`.
 
-
-
 ```go
 func get() int {
 	return myVar
@@ -116,8 +112,6 @@ The `Dec()` function decrements the value of `myVar`. However, as it does not po
 
 The `ImpossibleInc()` function at the end results in an error as it attempts to modify the value of the constant.
 
-
-
 ### Test Code
 
 ```go

docs/building-a-realm/overview.md

@@ -30,8 +30,6 @@ We first import packages and realms that we'll be using in the `foo` realm. Then
 
 > **Note:** The `admin` address will be the only address that can can mint or burn tokens.
 
-
-
 ```go
 func assertIsAdmin() error {
 	caller := std.GetOrigCaller()
@@ -44,8 +42,6 @@ func assertIsAdmin() error {
 
 The `assertIsAdmin()` function implements a logic to check if the caller of the admin-only function is the `admin` address. This concept is similar to the `require` or `modifer` in Solidity.
 
-
-
 ```go
 func init() {
 	foo = grc20.NewAdminToken("Foo Token", "FOO", 4)
@@ -61,8 +57,6 @@ The `init()` function resets the package and creates the `foo` token with the fo
 
 Then, the function mints 100 `foo` tokens to the `admin` address.
 
-
-
 ```go
 func Mint(address users.AddressOrName, amount uint64) error {
 	if err := assertIsAdmin(); err != nil {
@@ -83,8 +77,6 @@ func Burn(address users.AddressOrName, amount uint64) error {
 
 The `Mint` function and the `Burn` function respectively handles minting and burning of tokens. Both functions verify that the caller is the admin using the `assertIsAdmin()` function declared above.
 
-
-
 ```go
 func TotalSupply() uint64 {
 	return foo.TotalSupply()
@@ -156,11 +148,11 @@ Other functions implement the specifications of ERC20 with 2 additional function
 
 `FaucetWithoutAdmin`: Mints 200 `foo` tokens to an address (public).
 
-`Allowance`: Returns the amount `owner`'s tokens that the `spender` can transfer on behalf of the `owner`. 
+`Allowance`: Returns the amount `owner`'s tokens that the `spender` can transfer on behalf of the `owner`.
 
 `Approve`: Grants the `spender` with the authority to send a defined amount of `caller`'s `foo` tokens on behalf of the `caller`.
 
-TransferFrom: The `spender` sends `owner`'s tokens on behalf of the `owner`. 
+TransferFrom: The `spender` sends `owner`'s tokens on behalf of the `owner`.
 
 ####
 
@@ -295,9 +287,7 @@ func assertGRC20Balance(t *testing.T, addr users.AddressOrName, expectedBal uint
 }
 ```
 
-> **Tip:** the `users` realm enables users to register addresses with usernames([example](https://onbloc.gitbook.io/gnoland-developer-portal/tutorials/interact-with-gnoland#register-as-a-user)) on  `/r/demo/users` for simplicity and convenience. 
-
-
+> **Tip:** the `users` realm enables users to register addresses with usernames([example](https://onbloc.gitbook.io/gnoland-developer-portal/tutorials/interact-with-gnoland#register-as-a-user)) on `/r/demo/users` for simplicity and convenience.
 
 Let's assume that 3 addresses have been registered as users as the following:
 

docs/building-a-realm/realm-examples/first.gno.md

@@ -26,9 +26,7 @@ var (
 
 ```
 
-The code imports libraries, packages, and realms that it needs for implementation. Then, it initializes two variables to define the `admin` address, set the name of the NFT as `FooNFT`,  its symbol as `FNFT`.
-
-
+The code imports libraries, packages, and realms that it needs for implementation. Then, it initializes two variables to define the `admin` address, set the name of the NFT as `FooNFT`, its symbol as `FNFT`.
 
 ```go
 func assertIsAdmin(address std.Address) {
@@ -58,8 +56,6 @@ func Burn(tid grc721.TokenID) {
 
 The functions contained in the code above ensure that only the `admin` address has access to minting and burning of tokens.
 
-
-
 ```go
 func init() {
  mintNNFT(admin, 10)
@@ -76,15 +72,13 @@ func mintNNFT(owner std.Address, n uint64) {
 
 The `init` function above mints 10 NFT tokens to the admin address. You can see from the mint function that it takes the address to receive the tokens and the amount of tokens to mint as arguments.
 
-
-
 The logic of minting an NFT is more complex compared to that of `grc20`, due to the characteristics of NFT as follows:
 
 * All NFTs are identified by a unique uint256 `TokenID` value.
 * The `ID` cannot be modified as long as the contract is functional.
 * A common practice of numbering IDs is to start from 0 and increase it by 1 in sequential order.
 
-For example, If we want to mint NFTs from a contract, we need to know the number of NFTs minted so far from the contract, and specify `TokenID` which starts minting new NFTs. 
+For example, If we want to mint NFTs from a contract, we need to know the number of NFTs minted so far from the contract, and specify `TokenID` which starts minting new NFTs.
 
 Let's assume there's an NFT contract that:
 
@@ -93,8 +87,6 @@ Let's assume there's an NFT contract that:
 
 And, if we want to mint 10 NFTs, `TokenID` will be `10`\~`19`.
 
-
-
 ```go
 func BalanceOf(user users.AddressOrName) uint64 {
 	balance, err := foo.BalanceOf(user.Resolve())
@@ -155,12 +147,10 @@ Other functions are defined in the grc721 specification, each with the following
 * `OwnerOf`: Checks the owner address of a token, specified by its `id`.
 * `IsApprovedForAll`: Checks if all tokens of the `owner` has been approved for the `operator`.
 * `GetApproved`: Checks the address of the operator that's been approved of a token, specified by its `id`.
-* `Approve`: Approves a token owned by the `caller` to [a ](#user-content-fn-1)[^1]user. The token is specified by its `id`.
+* `Approve`: Approves a token owned by the `caller` to a user. The token is specified by its `id`.
 * `SetApprovalForAll`: Approves all tokens owned by the owner to a user.
 * `TransferFrom`: Transfers a token from the `from` address to the `to` address. The token is specified by its `id`.
 
-
-
 ### Test Code
 
 ```go
@@ -265,5 +255,3 @@ func shouldNoPanic(t *testing.T, f func()) {
 	f()
 }
 ```
-
-[^1]: 

docs/building-a-realm/realm-examples/foo.gno.md

@@ -100,8 +100,6 @@ Functions that make changes to the state must have a subject for change, hence m
 
 This method involves seemingly fewer options compared to `gnokey maketx call` method. However, passing the argument can be quite confusing: the realm path that exposes the `Render()` function must be placed in the `--data` option, and the arguments in a new line (`\n`).
 
-
-
 If we return to our realm code, we can see that the other function, `Hello()`, also doesn't cause any state changes to the blockchain.
 
 Any other function besides `Render()` can be invoked with `gnokey query vm/qeval`.

docs/building-a-realm/realm-examples/foo721.gno.md

@@ -2,8 +2,6 @@
 
 The `realm` realm provides a guide on how to import packages in a test environment (`gno`) and the production environment (`gnokey addpkg`) along with precautions to note.
 
-
-
 First, let's write a test package:
 
 ```go
@@ -119,32 +117,22 @@ func TestGetPrivateVar(t *testing.T) {
 
 <figure><img src="../../../.gitbook/assets/gor_04_02_gnodev.png" alt=""><figcaption></figcaption></figure>
 
-We can confirm that the test has been successfully passed in the test environment using `gno`.&#x20;
-
-
+We can confirm that the test has been successfully passed in the test environment using `gno`.
 
 <figure><img src="../../../.gitbook/assets/gor_04_03_realm_addpkg.png" alt=""><figcaption></figcaption></figure>
 
 The package gets added successfully in the production environment.
 
-
-
 <figure><img src="../../../.gitbook/assets/gor_04_04_render_call.png" alt=""><figcaption></figcaption></figure>
 
 Calling `Render()` and `GetPublicVar()` using the `gnokey maketx call` also works as expected.
 
-
-
 <figure><img src="../../../.gitbook/assets/gor_04_06_call_get_private.png" alt=""><figcaption></figcaption></figure>
 
 However, unlike the results in `gno`, we run into an issue when calling the `getPrivateVar()` function using the `gnokey maketx call` command in the production environment.
 
-
-
 <figure><img src="../../../.gitbook/assets/gor_04_07_query_get_private.png" alt=""><figcaption></figcaption></figure>
 
 On the other hand, calling the `getPrivateVar()` function using the `gnokey query vm/qeval` command works successfully.
 
-
-
 > **Note:** As of testnet3, we have run into unexpected results when using access modifiers with `gno`, `maketx`, and `query`. We suspect the cause to be one of the following: GnoVM, Gnokey Query, or gno. For now, we can get around this error by changing the lowercase to the uppercase to publicly access the functions. We will update this section once we determine the cause of this phenomenon.