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()`.
Effectively deprecate the `embarkjs-connector-web3` package but don't introduce
a breaking change by simply not loading the plugin if it's specified in a
DApp's `embark.json`. If the deprecated plugin is specified, display a message
indicating the plugin was ignored and suggesting it be removed from the
project's `embark.json` and `package.json`.
This PR adds a command to get full account details from the contradts config that includes info like private key.
The existing, and similar command, `blockchain:provider:contract:accounts:get` would only return account addresses if they existed, and not the full account info.
This check was already made when sending messages to whisper channel, however, we didn't
perform the same check when subscribing to channels within cockpit.
This has been a problem in Cockpit as well and was fixed accordingly.
Whisper doesn't allow subscribing to channels with names that have less
than 4 characters.
This could be fixed in different ways, one being on the library level
(e.g. have embark check for the given length and not subscribing when it
doesn't pass the check), the other one being on the application/ui level.
The reason it makes sense to solve this in the application layers is because
we keep the it open for users of EmbarkJS.Messages APIs to handle errors
the way they want.
Fixes#1666
Templates used for rendering data inside helpers need to all over their local variables
passed down so they can be evaluated against some context object.
We didn't pass down the i18n `__()` function to the paginator template of our custom
theme resulting in compilation errors during site generation.
This commit fixes it.
The webserver's job is to serve files generated by Embark's built-in pipeline,
however, since v4 users can choose they front-end tool to take care of building,
bundling and packing their DApps. Usually these tools come with a built-in
dev server as well.
Therefore, when the pipeline is turned off (which also soon will be the default),
there's not need start a webserver.
In https://github.com/embark-framework/embark/pull/1119 we've introduced a feature where
users can provide an already compiled ABI for Smart Contracts so they can be used
without the need to compiling them again.
This also means that, internally, those Smart Contract object won't have any
bytecode attached to it.
Later on, in 387d33a076, we've introduced a warning
which is rendered when a Smart Contract's bytecode is too large. The check expects
a Smart Contract object to have bytecode associated to it, which will break the code
in cases where a Smart Contract has already an ABI and therefore didn't need compilation.
This commit ensures we only check a Smart Contract's bytecode when bytecode exists for
the Smart Contract in question.
The previous link was pointing to readthedocs.io, which wasn't active. So here I've replaced it with the link to the official documentation on the Embark website.
When trying to either sending, or listening to whisper channels within
Embark's consoles (CLI and Cockpit), the console outputs an error that
`EmbarkJS` isn't defined.
E.g. running:
```
> EmbarkJS.Messages.listenTo({ topic: ['somechannel'])
```
Outputs:
```
EmbarkJS is not defined
```
This seemed very odd as outputting `EmbarkJS` and all of its members
worked totally fine.
It turns out that both methods, `listenTo()` and `sendMessage()`, in
`EmbarkJS.Messages` are not necessarily what one thinks they are.
EmbarkJS decorates both methods to create some options that need to be
available in the delegate, two of them being `EmbarkJS.Utils.toAscii`
and `EmbarkJS.Utils.fromAscii` (ac76a40a61/packages/embarkjs-whisper/src/index.js (L43-L62) and ac76a40a61/packages/embarkjs-whisper/src/index.js (L64-L73))
These two global references to `EmbarkJS` are the only ones in `embarkjs-whisper`
and they are not the same reference as the `EmbarkJS` sandbox global
registered in the VM here ac76a40a61/packages/embark-code-runner/src/index.ts (L33).
In other words, the `EmbarkJS is not defined` message actually refers
to the `EmbarkJS` in the wrapping method, not the one registered with
the VM, which is also why inspecting the `EmbarkJS` object through the
VM works fine.
Since the `toAscii()` and `fromAscii()` methods in use are really just
facades around `web3.utils.[fromAscii|toAscii]()`, we can replace the
global EmbarkJS dependency with web3 utils that are already available
anyways.
Pascal Precht
Michael Bradley, Jr
Jonathan Rainville
Iuri Matias
emizzle
Robin Percy
Shailendra Shukla
André Medeiros
Ricardo Guilherme Schmidt