style: Fixing some typos

.benchmarks/README.md

@@ -19,7 +19,7 @@ Things to take into account:
 - All benchmarks on a package will be shown on the same graph.
 - The value on `package` and `benchmarks` are regular expressions.
 - You have to explicitly add your new package here to make it appears on generated graphs.
-- If you have benchmarks on the same package that takes much more time pero op than the rest, you should divide it into a separate graph for visibility. In this example we can see how we separated tests from the gnolang package into the ones finishing with `Equality` and `LoopyMain`, because `LoopyMain` is taking an order of magnitude more time per operation than the other tests:
+- If you have benchmarks on the same package that takes much more time per op than the rest, you should divide it into a separate graph for visibility. In this example we can see how we separated tests from the gnolang package into the ones finishing with `Equality` and `LoopyMain`, because `LoopyMain` is taking an order of magnitude more time per operation than the other tests:
 ```yaml
       - name: Equality benchmarks (gnovm)
         benchmarks: [ '.Equality' ]
@@ -31,4 +31,4 @@ Things to take into account:
 
 ## Add new checks for PRs
 
-If we want to add a new package to check all the fast benchmarks on it on every PR, we should have a look into [gobenchdata-checks.yml](./gobenchdata-checks.yml).
+If we want to add a new package to check all the fast benchmarks on it on every PR, we should have a look into [gobenchdata-checks.yml](./gobenchdata-checks.yml).

docs/concepts/effective-gno.md

@@ -723,7 +723,7 @@ See also: https://github.com/gnolang/gno/tree/master/examples/gno.land/r/demo/wu
 
 <!-- TODO:
 
-- packages and realms versionning
+- packages and realms versioning
 - code generation
 - unit tests, fuzzing tests, example tests, txtar
 - shipping non-contract stuff with the realm: client, documentation, assets

examples/gno.land/p/demo/cford32/README.md

@@ -42,7 +42,7 @@ lexical ordering. However, values [0,2^34) have a "double encoding", which if
 mixed together lose the lexical ordering property.
 
 The Uint64 encoding is most useful for generating string versions of Uint64 IDs.
-Practically, it allows you to retain sleek and compact IDs for your applcation
+Practically, it allows you to retain sleek and compact IDs for your application
 for the first 2^34 (>17 billion) entities, while seamlessly rolling over to the
 full encoding should you exceed that. You are encouraged to use it unless you
 have a requirement or preferences for IDs consistently being always the same

examples/gno.land/p/demo/cford32/cford32.gno

@@ -41,7 +41,7 @@
 //
 // The Uint64 encoding is most useful for generating string versions of Uint64
 // IDs. Practically, it allows you to retain sleek and compact IDs for your
-// applcation for the first 2^34 (>17 billion) entities, while seamlessly
+// application for the first 2^34 (>17 billion) entities, while seamlessly
 // rolling over to the full encoding should you exceed that. You are encouraged
 // to use it unless you have a requirement or preferences for IDs consistently
 // being always the same size.