From 8f774ea9cd06af54f0ffcce4eeb6c3c8859fc538 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Wed, 15 Nov 2023 15:59:17 +0100 Subject: [PATCH] Fix typos (#4563) undefined --- CONTRIBUTING.md | 4 ++-- README.md | 4 ++-- node/node.md | 8 ++++---- rosetta/infra/README.md | 2 +- scripts/package/readme.md | 4 ++-- 5 files changed, 11 insertions(+), 11 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 1b5abab6b..a1c670b1a 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -11,7 +11,7 @@ This [github document](https://help.github.com/articles/creating-a-pull-request/) provides some guidance on how to create a pull request in github. ## PR requirement -To pursue engineering excellence, we have insisted on the highest stardard on the quality of each PR. +To pursue engineering excellence, we have insisted on the highest standard for the quality of each PR. * For each PR, please run [golint](https://github.com/golang/lint), [goimports](https://godoc.org/golang.org/x/tools/cmd/goimports), to fix the basic issues/warnings. * Make sure you understand [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/). @@ -21,7 +21,7 @@ To pursue engineering excellence, we have insisted on the highest stardard on th The best practice is to reorder and squash your local commits before the PR submission to create an atomic and self-contained PR. This [book chapter](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History) provides detailed explanation and guidance on how to rewrite the local git history. -For exampple, a typical workflow is like the following. +For example, a typical workflow is like the following. ```bash # assuming you are working on a fix of bug1, and use a local branch called "fixes_of_bug1". diff --git a/README.md b/README.md index 998832b35..5d2b1bd4c 100644 --- a/README.md +++ b/README.md @@ -174,7 +174,7 @@ To run this test, do: make test-rpc ``` This test starts a localnet (within the Docker container), **ensures it reaches a consensus**, and runs a series of tests to ensure correct RPC behavior. -This test also acts as a preliminary integration test (more through tests are done on the testnets). +This test also acts as a preliminary integration test (more thorough tests are done on the testnets). > The tests ran by this command can be found [here](https://github.com/harmony-one/harmony-test/tree/master/localnet). If you wish to debug further with the localnet after the tests are done, open a new shell and run: @@ -194,7 +194,7 @@ To run this test, do: make test-rosetta ``` This test starts a localnet (within the Docker container), **ensures it reaches a consensus**, and runs the Construction & Data API checks using the [rosetta-cli](https://github.com/coinbase/rosetta-cli). -This test also acts as a preliminary integration test (more through tests are done on the testnets). +This test also acts as a preliminary integration test (more thorough tests are done on the testnets). > The config for this test can be found [here](https://github.com/harmony-one/harmony-test/blob/master/localnet/configs/localnet_rosetta_test_s0.json) & [here](https://github.com/harmony-one/harmony-test/blob/master/localnet/configs/localnet_rosetta_test_s1.json) Similar to the RPC tests, if you wish to debug further with the localnet after the tests are done, open a new shell and run: diff --git a/node/node.md b/node/node.md index a783df5ea..168c7edeb 100644 --- a/node/node.md +++ b/node/node.md @@ -3,7 +3,7 @@ ### Services In Harmony network, a node can be treated as one of the roles: validator, leader, beacon validator, -beacon leader depending on its context. With each role, a node can run a certian set of services. +beacon leader depending on its context. With each role, a node can run a certain set of services. For example, a leader needs to run explorer support service, syncing support service etc.. while a normal validator does not run such many. @@ -13,8 +13,8 @@ service etc.. while a normal validator does not run such many. To support such behavior, we architecture Node logic with service manager which can wait for actions which each triggers its management operation such as starting some service, stopping some service. -Each service needs to implement minimal interace behavior like Start, Stop so that the service -manager can handle those operation. +Each service needs to implement minimal interface behavior like Start, Stop so that the service +manager can handle those operations. ```go // ServiceInterface is the collection of functions any service needs to implement. @@ -26,7 +26,7 @@ type ServiceInterface interface { ### Creating a service. -To create a service, you need to have an struct which implements above interface function +To create a service, you need to have a struct which implements above interface function `StartService`, `StopService`. Since different services may have different ways to be created you may need to have a method diff --git a/rosetta/infra/README.md b/rosetta/infra/README.md index 2c7d620c4..c04f99850 100644 --- a/rosetta/infra/README.md +++ b/rosetta/infra/README.md @@ -108,7 +108,7 @@ Note that the directory structure for `/root/data` (== `./data`) should look som ``` ### Inspecting Logs -If you mount `./data` on the host to `/root/data` in the container, you van view the harmony node logs at +If you mount `./data` on the host to `/root/data` in the container, you can view the harmony node logs at `./data/logs/` on your host machine. ### View rosetta request logs diff --git a/scripts/package/readme.md b/scripts/package/readme.md index 9ea4af409..510bc387f 100644 --- a/scripts/package/readme.md +++ b/scripts/package/readme.md @@ -19,7 +19,7 @@ The default blockchain DBs are stored in `/home/harmony/harmony_db_?` directory. The configuration of harmony process is in `/etc/harmony/harmony.conf`. # Package Manager -Please take sometime to learn about the package managers used on Fedora/Debian based distributions. +Please take some time to learn about the package managers used on Fedora/Debian based distributions. There are many other package managers can be used to manage rpm/deb packages like [Apt], or [Yum] @@ -128,7 +128,7 @@ The default configuration is for validators on mainnet. No need to run `harmony- * `systemctl status harmony` to check status of node # Change node configuration -The node configuration file is in `/etc/harmony/harmony.conf`. Please edit the file as you needed. +The node configuration file is in `/etc/harmony/harmony.conf`. Please edit the file as you need. ```bash sudo vim /etc/harmony/harmony.conf ```