makerdao / maker-user

DEPRECATED ! MakerUser mixin contract and support code. Maker implementation is in `maker-core`.
GNU Affero General Public License v3.0
1 stars 6 forks source link

devnet deployment, access to frontends #6

Open jorisbontje opened 8 years ago

jorisbontje commented 8 years ago

In my quest to get a working devnet deployment of Maker, I have created the following deployment script (deploy_mock.ds):

var mock_registry = new MakerUserMockRegistry()
export mock_registry
var mkr_frontend = mock_registry.get('MKR')
export mkr_frontend
var dai_frontend = mock_registry.get('DAI')
export dai_frontend
var eth_frontend = mock_registry.get('ETH')
export eth_frontend

After execution, I get the promising result:

$ dapple run deploy_mock.ds
Using local solc installation...
Deploying to environment "default"...
Connected to RPC client, block height is 24
simulated successfully
DEPLOYED: MakerUserMockRegistry = 0x7c13eeb1e44c4cfd2f8c2c8926ef096dfb6df047
GAS COST: 2485259 for "new MakerUserMockRegistry"
CONFIRMED deploy after 1 blocks!
CALLED: MakerUserMockRegistry("0x7c13eeb1e44c4cfd2f8c2c8926ef096dfb6df047").get(MKR)
RETURN: 0x000000000000000000000000e100d8e527cf994e206cd2cbdb41438c2ac3c604
CALLED: MakerUserMockRegistry("0x7c13eeb1e44c4cfd2f8c2c8926ef096dfb6df047").get(DAI)
RETURN: 0x000000000000000000000000267adf857866f89415dd4bf7e2fecd4bfb884a0b
CALLED: MakerUserMockRegistry("0x7c13eeb1e44c4cfd2f8c2c8926ef096dfb6df047").get(ETH)
RETURN: 0x00000000000000000000000063bde31f182124d6fe9c5347cb598efe55571bba

.
  Successfully deployed!

After manually removing trailing zeroes; I even get contract code at the returned addresses!

However the generated dappfile is rather messed up:

  default:
    objects:
      mock_registry:
        class: MakerUserMockRegistry
        address: '0x7c13eeb1e44c4cfd2f8c2c8926ef096dfb6df047'
      mkr_frontend:
        class: !<tag:yaml.org,2002:js/undefined> ''
        address: !<tag:yaml.org,2002:js/undefined> ''
      dai_frontend:
        class: !<tag:yaml.org,2002:js/undefined> ''
        address: !<tag:yaml.org,2002:js/undefined> ''
      eth_frontend:
        class: !<tag:yaml.org,2002:js/undefined> ''
        address: !<tag:yaml.org,2002:js/undefined> ''

Am I doing this right? Is there a way to cast returned values to addresses; and how should I run this to create a valid dappfile?

nmushegian commented 8 years ago

The token registry has a getToken which returns the value as an address. @mhhf would know if our DSL would support casting it to an address, and could diagnose the dappfile issue.

jorisbontje commented 8 years ago

if I replace get with getToken; then I run into https://github.com/nexusdev/dapple/issues/218

$ dapple run deploy_mock.ds
Using local solc installation...
Deploying to environment "default"...
Connected to RPC client, block height is 19
simulated successfully
DEPLOYED: MakerUserMockRegistry = 0x6f19b7c6a78c9195e55c0f9515eb121a7896091b
GAS COST: 2485259 for "new MakerUserMockRegistry"
CONFIRMED deploy after 1 blocks!

.
  could not unlock signer account
mhhf commented 8 years ago

var eth_frontend = mock_registry.get('ETH') export eth_frontend

Since here a bytes32 or address is returned, dapple don't have a default way to infer the correct contract type to this. Also only exports of object types (address + class ) are supported atm. We should discuss the support of this feature along with DappleScript's type system here: https://github.com/nexusdev/dapple/issues/227

Is this mandatory or just something you run up into?

nmushegian commented 8 years ago
mhhf commented 8 years ago

@nmushegian while this is true for the code and solidity_interface:

[...]
 function getToken(bytes32 symbol) internal constant returns (DSToken t) {
        return _M.getToken(symbol);
    }
[...]

The contract ABI isn't contract type aware:

[...]
{
    "constant": false,
    "inputs": [
      {
        "name": "symbol",
        "type": "bytes32"
      }
    ],
    "name": "getToken",
    "outputs": [
      {
        "name": "",
        "type": "address"
      }
    ],
    "type": "function"
  }
[...]

So for an inference(export), some sort of custom interface parsing has to be done.