remove code not beloging to code runner & other core modules; disable code generator and move contract code to its own module
cleanup pipeline; start preparing for plugin based pipeline file generation
initial work to write pipeline files through an api
add action events to pipeline; generate contracts json and js files
move old pipeline to its own module; generate basic artifacts
re-add missing plugins function
add basic embarkjs provider registration
refactor embark-whisper; move whisper api; execute whisper code in console
add api to register help cmds in console; start moving hardcoded help cmds out
cleanup embark-graph
add todos
In https://github.com/embark-framework/embark/commit/87d92b6091 we've introduced a feature in our test runner
to report exact gas costs used when calling Smart Contract methods that
cause computation.
Embark keeps a list of deployed contracts in memory and for all transactions
happening during tests, it'll match them to the contracts that performed them
to produce the report logs.
Unfortunately, we've been [resetting that memory](https://github.com/embark-framework/embark/commit/87d92b6091#diff-92b4f79a0473160fe700440b1ced5204R140) of deployed contracts
after every test, making it practically impossible for Embark to find
matching contracts for any transactions, because contracts aren't necessarily
redeployed per spec, resulting in no additional transaction logs whatsoever.
This commit ensures that the memory is never erased and at the same time
ensures it's not leaking infinitely in case multiple contracts are
deployed multiple times in the same process over several specs.
We've introduced a regression in 536a4029ba where the default
`value` sent to payable Smart Contract methods is `-1`, resulting in errors as it's not
a valid value.
For payable methods inside of the contract interatction section of cockpit, the value input has been updated to pass wei to the API. The input field now accepts value like `100 ether` or 25 szabo`. The value entered is automatically converted to wei and shown to the user in real time.
Additionally, the input is validated for a correct value, with an error shown to the user for incorrectly entered values.
A tooltip has been added to help the user enter correct values.
UI updates can be seen in video here: https://monosnap.com/file/642cHH2HxDeiFLzB2VLqHP9GuqoRfz
This is due to a bug that has been introduced in d10c0b7951 where we end up
sending values as numbers to web3's `toWei()` utility. The `value` is always sent as number
and in fact always defined, so we just need to check for it's type and convert it to a string
according to `toWei()`'s API.
When running tests against non-simulated blockchain nodes, even for simplex
Smart Contracts, deployment transactions would exceed the block gas limit.
E.g. running `embark blockchain` in one process and `embark test --node embark`
in another, inside our demo application, will throw an error when Embark attempts
to deploy its `SimpleStorage`:
```
Compiling contracts
Compilation done
[SimpleStorage]: error deploying =SimpleStorage= due to error: Returned error: exceeds block gas limit
Error deploying contracts. Please fix errors to continue.
Error deploying contracts. Please fix errors to continue.
terminating due to error
Error deploying contracts. Please fix errors to continue.
```
The reason for that is because in https://github.com/embark-framework/embark/pull/1650, we've introduced a static
gas estimation for Smart Contract deployment that is just right below Ganache's
maximum gas limit of `6721975`, since Ganache tends to underestimate gas for
complex Smart Contracts due to its [low base fee](8ad1ab29de/lib/utils/gasEstimation.js (L33-L39)).
The static gas estimation would apply any time we're in a test context, but we
didn't take into account the case where tests are executed against nodes
other than the simulated environment.
As mentioned in the comments in the linked PR:
> If this is not spec'ed at all, I wonder what complications it could cause when
> at some point we maybe switch to not using Ganache anymore for tests, or even
> the user itself (which I think is a reasonable thing to do).
This causes the error described above because we easily reach the block gas limit
with just two Smart Contracts and Embark already deploys a few Smart Contracts for
ENS.
So basically what we want is to use the static gas estimation when we know
the node we're connecting to is Ganache. In all other cases we can rely on the
standardized gas estimation offered by the node.
Adjust the API endpoints to augment transaction objects with a timestamp
property from their corresponding blocks. This removes the necessity to copy
the timestamp property from a block to its transactions in the client.
Introduce a `formatTimestampForDisplay` util function in Cockpit for
consistently transforming timestamps into relative or absolute dates, depending
on whether a date is sometime during the last day.
The property is set/available on EmbarkJS in the artifacts, i.e. in a browser
build; but sometime since v3.2.4 it was no longer availble in the cli dashboard
environment.
`EmbarkJS.Messages.isAvailable()` in some cases return synchronously (when whisper isn't
set up), in other cases asynchronously. This actually breaks our demo application for
the following reason:
We check for Whisper's availability via:
```
EmbarkJS.Messages.Providers.whisper.getWhisperVersion((err, _version) => {
if (err) {
return console.log(err);
}
this.setState({whisperEnabled: true});
});
```
There's a couple of problems here:
- This code will break right away when whisper isn't available, resulting in an error:
```
Cannot read property _requestManager of undefined
```
- The reason this error happens is because there's no `web3` object available inside
our EmbarkJS.Messages code. Even though there **is** a web3 object, EmbarkJS.Messages
doesn't know about this because it only sets it when its `setProvider()` API is called,
which effectively doesn't happen at all when Whisper isn't enabled on the connected
node
- While this could be fixed with a simple check on whether EmbarkJS.Messages' internal
`web3` references is a thing, really what should be used in the demo is the `isAvailable()`
API.
`isAvailable()` should always return a promise (similar to `EmbarkJS.Storage.isAvailable()`.
This commit ensures that `isAvailable()` always returns a promise and changes the demo
template to use `isAvailable()` over `getWhisperVersion()`.
Iuri Matias
Andre Medeiros
Jonathan Rainville
Michael Bradley, Jr
Pascal Precht
emizzle