Remove usage/naming of gaia / XrnApp / simd (#123)

* Remove usage/naming of `gaia` / `XrnApp` / `simd` * updated cmd docs * review changes * update comment gaia > regen Co-authored-by: Amaury Martiny <[email protected]> Co-authored-by: Cory Levinson <[email protected]> Co-authored-by: Anil Kumar Kammari <[email protected]>
regen-network · Nov 6, 2020 · 9aa595a · 9aa595a
1 parent cefcdf8
commit 9aa595a
Show file tree

Hide file tree

Showing 10 changed files with 36 additions and 58 deletions.
diff --git a/app/addr_prefixes.go b/app/addr_prefixes.go
@@ -9,17 +9,17 @@ import (
 
 const (
 	// Bech32PrefixAccAddr defines the Bech32 prefix of an account's address
-	Bech32PrefixAccAddr = "xrn:"
+	Bech32PrefixAccAddr = "regen:"
 	// Bech32PrefixAccPub defines the Bech32 prefix of an account's public key
-	Bech32PrefixAccPub = "xrn:pub"
+	Bech32PrefixAccPub = "regen:pub"
 	// Bech32PrefixValAddr defines the Bech32 prefix of a validator's operator address
-	Bech32PrefixValAddr = "xrn:valoper"
+	Bech32PrefixValAddr = "regen:valoper"
 	// Bech32PrefixValPub defines the Bech32 prefix of a validator's operator public key
-	Bech32PrefixValPub = "xrn:valoperpub"
+	Bech32PrefixValPub = "regen:valoperpub"
 	// Bech32PrefixConsAddr defines the Bech32 prefix of a consensus node address
-	Bech32PrefixConsAddr = "xrn:valcons"
+	Bech32PrefixConsAddr = "regen:valcons"
 	// Bech32PrefixConsPub defines the Bech32 prefix of a consensus node public key
-	Bech32PrefixConsPub = "xrn:valconspub"
+	Bech32PrefixConsPub = "regen:valconspub"
 )
 
 func init() {

diff --git a/app/genesis.go b/app/genesis.go
@@ -14,7 +14,7 @@ import (
 // object provided to it during init.
 type GenesisState map[string]json.RawMessage
 
-// NewDefaultGenesisState generates the default state for gaia.
+// NewDefaultGenesisState generates the default state for regen.
 func NewDefaultGenesisState() GenesisState {
 	encCfg := MakeEncodingConfig()
 	return ModuleBasics.DefaultGenesis(encCfg.Marshaler)

diff --git a/app/regen/cmd/root.go b/app/regen/cmd/root.go
@@ -35,7 +35,7 @@ import (
 	genutilcli "github.com/cosmos/cosmos-sdk/x/genutil/client/cli"
 )
 
-// NewRootCmd creates a new root command for simd. It is called once in the
+// NewRootCmd creates a new root command for regen. It is called once in the
 // main function.
 func NewRootCmd() (*cobra.Command, params.EncodingConfig) {
 	encodingConfig := app.MakeEncodingConfig()

diff --git a/app/regen/cmd/testnet.go b/app/regen/cmd/testnet.go
@@ -47,14 +47,14 @@ var (
 func testnetCmd(mbm module.BasicManager, genBalIterator banktypes.GenesisBalancesIterator) *cobra.Command {
 	cmd := &cobra.Command{
 		Use:   "testnet",
-		Short: "Initialize files for a simapp testnet",
+		Short: "Initialize files for a regen testnet",
 		Long: `testnet will create "v" number of directories and populate each with
 necessary files (private validator, genesis, config, etc.).
 
 Note, strict routability for addresses is turned off in the config file.
 
 Example:
-	simd testnet --v 4 --output-dir ./output --starting-ip-address 192.168.10.2
+	regen testnet --v 4 --output-dir ./output --starting-ip-address 192.168.10.2
 	`,
 		RunE: func(cmd *cobra.Command, _ []string) error {
 			clientCtx := client.GetClientContextFromCmd(cmd)
@@ -82,7 +82,7 @@ Example:
 	cmd.Flags().Int(flagNumValidators, 4, "Number of validators to initialize the testnet with")
 	cmd.Flags().StringP(flagOutputDir, "o", "./mytestnet", "Directory to store initialization data for the testnet")
 	cmd.Flags().String(flagNodeDirPrefix, "node", "Prefix the directory name for each node with (node results in node0, node1, ...)")
-	cmd.Flags().String(flagNodeDaemonHome, "simd", "Home directory of the node's daemon configuration")
+	cmd.Flags().String(flagNodeDaemonHome, "regen", "Home directory of the node's daemon configuration")
 	cmd.Flags().String(flagStartingIPAddress, "192.168.0.1", "Starting IP address (192.168.0.1 results in persistent peers list [email protected]:46656, [email protected]:46656, ...)")
 	cmd.Flags().String(flags.FlagChainID, "", "genesis file chain-id, if left blank will be randomly created")
 	cmd.Flags().String(server.FlagMinGasPrices, fmt.Sprintf("0.000006%s", sdk.DefaultBondDenom), "Minimum gas prices to accept for transactions; All fees in a tx must meet this minimum (e.g. 0.01photino,0.001stake)")

diff --git a/default.nix b/default.nix
@@ -1,5 +1,5 @@
 let
-  xrn_build = pkg:
+  regen_build = pkg:
     with import <nixpkgs>{};
     buildGoModule rec {
       name = "regen-ledger";
@@ -18,6 +18,5 @@ let
       };
     };
 in {
-  xrnd = (xrn_build "cmd/xrnd");
-  xrncli = (xrn_build "cmd/xrncli");
+  regen = (regen_build "app/regen");
 }
diff --git a/docker-compose.yml b/docker-compose.yml
@@ -3,7 +3,7 @@ services:
   postgres:
     image: mdillon/postgis:11
     environment:
-      - POSTGRES_DB=xrn
+      - POSTGRES_DB=regen
     ports:
       - "5433:5432"
     volumes:

diff --git a/docs/SPEC.md b/docs/SPEC.md
@@ -34,9 +34,9 @@ prerequisite reading:
 * [RDF 1.1 Concepts and Abstract Syntax](https://www.w3.org/TR/rdf11-concepts/)
 * [Sparql 1.1 Query Language](https://www.w3.org/TR/sparql11-query/)
 
-## XRN URI Scheme
+## Regen URI Scheme
 
-Regen Ledger defines its own URI scheme with the `xrn` prefix for usage
+Regen Ledger defines its own URI scheme with the `regen` prefix for usage
 in various modules. The semantics of this URI scheme will be defined
 in each module as they arise. In the future, this information may be
 consolidated into a single reference section.
@@ -140,9 +140,9 @@ graphs and datasets although the procedure for storing them is similar.
 
 To store data on-chain, a valid RDF dataset can be submitted in a
 supported format (JSON-LD currently). The URI for a graph will be of the
-format `xrn://<block-height>/graph/<hash>` where `block-height` is the
+format `regen://<block-height>/graph/<hash>` where `block-height` is the
 hex-encoded block height at which the data was committed `<hash>` is the [URDNA2015](https://json-ld.github.io/normalization/spec/)
-hash of the data. Likewise, datasets get the URI `xrn://<block-height>/dataset/<hash>`.
+hash of the data. Likewise, datasets get the URI `regen://<block-height>/dataset/<hash>`.
 Note that all simple graphs will be accessible from the dataset URI's
 as well as they are also valid datasets.
 
@@ -176,13 +176,13 @@ later section.
 #### Named graphs
 
 Each graph that is stored on-chain should be available
-as the named graph `xrn://<block-height>/graph/<hash>` in the RDF data set.
+as the named graph `regen://<block-height>/graph/<hash>` in the RDF data set.
 
 #### `SERVICE` endpoints
 
 Each dataset that is stored on or off-chain should be accessible as the
 dataset at the [Sparql 1.1. Federation](https://www.w3.org/TR/2013/REC-sparql11-federated-query-20130321/)
-`SERVICE` endpoint `xrn://<block-height>/dataset/<hash>`. Compliant index databases should
+`SERVICE` endpoint `regen://<block-height>/dataset/<hash>`. Compliant index databases should
 overload the handling of service endpoint queries to either pull the dataset from the chain
 if the dataset is stored on-chain or retrieve the dataset from the URL provided
 on-chain which is supposed to permanently reference this data. In either case,

diff --git a/docs/getting_started.md b/docs/getting_started.md
@@ -4,59 +4,38 @@
 
 ### Building from source
 
-Prerequisites: The [Go](https://golang.org/doc/install) compiler **version 1.11** (we use
+Prerequisites: The [Go](https://golang.org/doc/install) compiler **version 1.15.x** (we use
 go modules) or later and GNU make. The go bin path (usually `$HOME/go/bin`) should be
 on your system `PATH`.
 
-Run `make install` to build the code.`xrnd` is the blockchain daemon. `xrncli`
-is the command line blockchain client. Both of them provide help messages when run.
-
-#### Go 1.13
-
-If you are running Go 1.13, there are a few minor changes that will need to be made to `Makefile` and `go.mod` to use properly formatted pseudo-versions.
-
-In `Makefile` (line 80):
-
-```
--       go install -mod=readonly $(BUILD_FLAGS) ./cmd/xrnd
-+       go install $(BUILD_FLAGS) ./cmd/xrnd
-```
-
-In `go.mod` (lines 18, 48):
-
-```
--    github.com/leanovate/gopter v0.0.0-20190000000000-6e7780f59df75750618bf30eeafcb1a88e457fcb
-+    github.com/leanovate/gopter v0.0.0-20190326081808-6e7780f59df7
-...
-...
--  replace github.com/cosmos/cosmos-sdk => github.com/regen-network/cosmos-sdk v0.0.0-0.20190329021654-281da889de6ca3c7784d5570fd95de78d7d23a59
-+  replace github.com/cosmos/cosmos-sdk => github.com/regen-network/cosmos-sdk v0.0.0-20190827142854-281da889de6c
-```
+Run `make build` to build the code.`regen` is the blockchain daemon and command line blockchain client. and it can provide help messages when run.
 
+#### Requirements
+Go - `1.15.x`
 
 ## Configuring the command line client
 
 By default the command line client will connect to a [local node](#running-a-local-node).
 To connect to a testnet, you must know the testnet's chain ID and the address of the node. More information on the current testnet can be found in the [testnets repository](https://github.com/regen-network/testnets).
 
-`xrncli` can be configured to connect to a testnet node automatically by setting these
-parameters in `$HOME/.xrncli/config/config.toml`. This file can be generated
+`regen` can be configured to connect to a testnet node automatically by setting these
+parameters in `$HOME/.regen/config/config.toml`. This file can be generated
 automatically by running:
 
 ```sh
-xrncli init --chain-id [chain ID] --node [node address]
+regen init --chain-id [chain ID] --node [node address]
 ```
 
 Check current testnet status [here](https://github.com/regen-network/testnets).
 
-Run `xrncli status` to see if you are able to connect to the block-chain node.
+Run `regen status` to see if you are able to connect to the block-chain node.
 
 ### Creating a key
 
 To run any transactions you must have a key. A new one can be generated using:
 
 ```sh
-xrncli keys add [key-name]
+regen keys add [key-name]
 ```
 
 Make sure you save the seed mnemonic in a safe place!
@@ -66,12 +45,12 @@ Make sure you save the seed mnemonic in a safe place!
 Initialize the node config
 
 ```sh
-xrnd init
+regen init
 ```
 
 Start the node
 ```sh
-xrnd start
+regen start
 ```
 
-Local node config will be saved to `~/.xrnd` and the chain ID can be found in `~/.xrnd/config/genesis.json`.
+Local node config will be saved to `~/.regen` and the chain ID can be found in `~/.regen/config/genesis.json`.
diff --git a/docs/writing_specs.org b/docs/writing_specs.org
@@ -32,11 +32,11 @@ With these three purposes in mind, specification documents are designed to be us
 * Component Specifications
   Each component (defined as an independent build artifact or separate running process) should have its own ~README.org~ file. We expect have the following components so far:
   * Server
-    * ~xrnd~ blockchain node
+    * ~regen~ blockchain node
     * Postgis index of blockchain data
     * Jena index of blockchain data
   * Client
-    * ~xrncli~ blockchain client. (Documentation shouldn't duplicate what is available in CLI help)
+    * ~regen~ blockchain client. (Documentation shouldn't duplicate what is available in CLI help)
     * Mobile client SDK's - javascript, android, iOS
 
 * Regen Ledger Module Specifications
@@ -79,7 +79,7 @@ With these three purposes in mind, specification documents are designed to be us
    The rationale for why the implementation described above was chosen should be documented in this section. Where necessary a *Rationale:* paragraph should be included inline in other sections to provide clarity on more specific behavioral choices.
 
 ** CLI Tutorial (optional)
-   A tutorial walk-through of using the module using the ~xrncli~ command line tool.
+   A tutorial walk-through of using the module using the ~regen~ command line tool.
 
 * Tests Specifications (experimental)
   Test specifications can be written in the [[https://docs.cucumber.io/gherkin/][Gherkin]] syntax in ~.feature~ files or as Org Babel in ~README.org~, but ~.feature~ files are preferred for the long term as Gherkin isn't so pretty in documentation. A suitable BDD testing framework such as [[https://cucumber.io][Cucumber]] or [[https://github.com/DATA-DOG/godog][godog]] should be used to execute the specifications. Gherkin specs SHOULD ALWAYS be written by developers and reviewed by the product team and NEVER by developers in isolation. Gherkin-based tests should not be a replacement for other more comprehensive tests that ensure program correctness. Their primary purpose is to serve as a communication tool for aligning product and design. Please read this comment by the creator of Cucumber: https://news.ycombinator.com/item?id=10194242. This is also helpful to give context: http://blog.jonasbandi.net/2010/03/classifying-bdd-tools-unit-test-driven.html.
diff --git a/sims.mk b/sims.mk
@@ -15,7 +15,7 @@ sim-regen-custom-genesis-fast:
 		-Enabled=true -NumBlocks=100 -BlockSize=200 -Commit=true -Seed=99 -Period=5 -v -timeout 24h
 
 sim-regen-fast:
-	@echo "Running quick Gaia simulation. This may take several minutes..."
+	@echo "Running quick Regen simulation. This may take several minutes..."
 	@go test -mod=readonly $(APP_DIR) -run TestFullAppSimulation -Enabled=true -NumBlocks=100 -BlockSize=200 -Commit=true -Seed=99 -Period=5 -v -timeout 24h
 
 sim-regen-import-export: runsim