- Booleans weren't being sent correctly (it always assumed true)
- Booleans now are shown on the results
- Handling result visualization when there's more than one parameter
- UI shows error screen if contract doesn't exist or fails fetching data
- Menu shows selected state and icons can be specified
- Component created for card alerts
Changed the online event to `once` and set it to be bound every time the node goes offline.
The above changes handle the case where:
1) `embark run` runs and starts geth.
2) geth is killed manually
3) `embark blockchain` is run in separate process to restart geth
4) the `embark run` process detects this change and restarts the web3 provider and recompiles/deploys/builds
Every time `embark blochain` is restarted, an error is appended and all are emitted from the `eth-block-tracker`. This is a bug but can't figure out where it originates. The downside is that if, for example, `embark blockchain` is restarted 4 times, there will be 4 errors emitted from the `eth-block-tracker`. Because of this, errors emitted from `eth-block-tracker` have been reduced to trace to avoid clogging the logs.
First case - run `embark run` which starts a blockchain node, then manually kill the `geth` process. Would throw `{ [Error: connect ECONNREFUSED 127.0.0.1:8543] message: 'connect ECONNREFUSED 127.0.0.1:8543', code: -32603 }` error and ruins the dashboard.
Second case, 1) run `embark blockchain` 2) run `embark run` 3) kill `embark blockchain` throws the error `{ [Error: connect ECONNREFUSED 127.0.0.1:8543] message: 'connect ECONNREFUSED 127.0.0.1:8543', code: -32603 }` and ruins the dashboard.
The first case was solved by having the child blockchain process that spawns geth listen for geth exit, then kill itself.
The second case required updating of `eth-block-tracker` to v4.0.1 inside of the `embark-web3-provider-engine`. v4.0.1 was a major version update and introduced breaking changes. Those changes were handled inside of `embark-web3-provider-engine`, covered in **blocker** PR https://github.com/jrainville/provider-engine/pull/1.
First case - run `embark run` which starts a blockchain node, then manually kill the `geth` process. Would throw `{ [Error: connect ECONNREFUSED 127.0.0.1:8543] message: 'connect ECONNREFUSED 127.0.0.1:8543', code: -32603 }` error and ruins the dashboard.
Second case, 1) run `embark blockchain` 2) run `embark run` 3) kill `embark blockchain` throws the error `{ [Error: connect ECONNREFUSED 127.0.0.1:8543] message: 'connect ECONNREFUSED 127.0.0.1:8543', code: -32603 }` and ruins the dashboard.
The first case was solved by having the child blockchain process that spawns geth listen for geth exit, then kill itself.
The second case required updating of `eth-block-tracker` to v4.0.1 inside of the `embark-web3-provider-engine`. v4.0.1 was a major version update and introduced breaking changes. Those changes were handled inside of `embark-web3-provider-engine`, covered in **blocker** PR https://github.com/jrainville/provider-engine/pull/1.
Removed a condition that detects if `mineWhenNeeded === true`. While reaslistically, the `defaultAccount` will only be populated when `mineWhenNeeded` is set, there is no need to check for this when falling back to the blockchain account.
When there is no account/password specified for swarm, there was an error shown in the logs (asking for address/password), and the swarm process would quit.
This PR changes the behaviour so that if a swarm address/password are not specified in the config, it attempts to use the blockchain address/password specified in `config/blockchain > account`. If `config/blockchain > account > address` doesn’t exist, the first account controlled by the node is used (provided by `web3.eth.getAccounts`, along with the password from `config/blockchain > account > password`.
Cargo in fact, bundles up subsequent tasks in to an array, so any tasks that are not immediately run get bundled in to another run later. This helps when lots of changes have been made in a short period of time.
For file changes that do not require a webpack run, ie HTML, the assets will still be copied to the output directory, but webpack will not run (as it’s too slow).
Add persistent automatically loaded history file for repl console
and Embark dashboard.
Default location of the history file is stored in DEFAULT_CMD_HISTORY_PATH
pointing to DAPP_PATH/.embark/cmd_history.
The history is automatically saved and loaded on startup.
test/console: Pass Embark object to constructor.
Update console test to pass Embark object to constructor.
Refs: https://github.com/embark-framework/embark/issues/939
When `mineWhenNeeded` is true (occurs in zero-config) and an account on the node exists, a password is required to be specified `config/blockchain.js > account > password` so that the existing account can be unlocked by geth (the `—unlock` cli option).
Addons
- New chain initialization and genesis management
- Option to choose client to use
- Option to "ping forever" for Geth
- Creation and unlock of accounts at client's start
- Utility to fund accounts with ethers
- Miner settings inside the ethereum client
- Workaround to CORS problem: origin is now http://embark
- Several double callback's checks
Updates
- Boilerplate, templates, configuration files and demo stuff
- Messages and i18n strings
- Tests
Fixes
- Geth client now uses miner.gastarget instead of the deprecated targetGasLimit
- Workaround for shh_version with Parity
Reworks of other PRs into the new code
- Included delayed proxy
- Send ready only when the proxy is started
- Start HTTP and WS proxies individually
- Async setupProxy
- Fixed datadir for GethMiner
to configure pipeline specific options like TypeScript support.
At the time this has been added, `core/config` didn't handle the loading
of configuration files for pipeline related tasks yet.
This commit ensures a dapp's `pipeline.json` will be loaded and used to
configure Embark's webpack process as part of Embark's `Config` initialization.
As part of a bigger refactoring to make Embark's build pipeline pluggable,
this commit moves the watcher into its own plugin module so it can be
consumed via Embark's event bus.
It also introduces new command handlers for all watcher related APIs respectively:
- watcher:start
- watcher:stop
- watcher:restart
In cases a blockchain client exits before Embark is done doing its work,
the current error message doesn't provide any pointers to why this
happened.
Running `$ embark blockchain` separately could yield more information by
the underlying process.
This is the first step of refactoring Embark's pipeline abstraction into
dedicated plugin modules that take advantage of Embark's event system.
With this commit we're moving `Pipeline` into `lib/modules/pipeline` and
introduce a new command handler `pipeline:build`. Embark's engine now
requests builds via this command handler.
Notice that `Watch` still lives in `lib/pipeline` as this is a step-by-step
refactoring to reduce chances of introducing regressions.
Always deploy the contract regardless if already deployed
when 'track' field in the contract configuration is specified
and set to false.
In line with #938 requirements:
* If a contract has the track field set to false, that contract
will always deploy.
* If the track field is set to true, then the existing deployment
tracking mechanism will be active for that contract.
* If the field is not set, it should be assumed to true by default
Refs: https://github.com/embark-framework/embark/issues/938
Jonathan Rainville
Iuri Matias
Anthony Laibe
Richard Ramos
Michael Bradley, Jr
RJ Catalano
emizzle
hodlbank
Cryptomental
Dan Lipert
Subramanian Venkatesan
Giuseppe Bertone
Moksh Jain
Pascal Precht