ethereum / remix-project Goto Github PK

Would be nice to support the EPM packaging spec: ethereum/EIPs#190

in Memory, 0 grey and non zero char black

change it to one that is not polling but register to OS event

In the state view of remix, it would be nice if we can click on a stack element and jump to the instruction where the element is produced.

Alternatively, moving the mouse cursor on to a stack element can change the color of the instruction that produces/consumes the stack element.

Structs containing mappings in memory are not handled properly. The mapping has to be completely ignored (i.e. it occupies zero space) when the struct is used in memory.

contract c {
    struct X {
        uint a;
        mapping(uint => uint) b;
        uint c;
    }
    X x;
    function f() constant returns (uint) {
        x.a  = 1;
        x.b[2]=3;
        x.c = 4;
        X memory y = x;
        y.c = 9;
    }
}

Right now, those methods marked as constant are run as an eth_call, while others are run as a transaction eth_sendTransaction.

It would be nice to have an option to run time as a call.

If a contract calls another, the "loaded address" in the "Step Details" tab shows the current loaded contract, at least most of the time.
Example:
http://etherscan.io/remix?txhash=0xea9332a2d33b659e1520c3927741bdc1d15bcd13601c413220bc8de9c271d917
Location 4019
VM trace Step 699
Execution step 259

There is a call to 0xbd5af6f705e4582c3f2b368ccf278ce39c3cfc17 but the "loaded address" doesn't keep track of this.

Rationale: I use the remix debugger to quickly fly over the instructions (with the slider) to see which internal calls happen. If loaded address doesn't change correctly, you have to manually click through every step.

as a reference:

like this explains the evm in detail, it would be useful for the community to understand how Remix works such that developers can get a good understanding of where modifications can be made and what the dependancies are.

There were perhaps a lot of improvements in the last 8 months.

• require newer version of ACE in package.json
• regenerate mode-solidity using the new version
• merge mode-solidity with upstream (long term)

If that the feature is provided by the client

For debugging existing contracts compiled with old compiler versions, it might make sense to use a given source code, even though the bytecode on chain does not match perfectly. This could be very useful to at least display storage variables correctly (local variables and source references will not work).

Considering the following contract:

pragma solidity ^0.4.19;
contract A {
    
    function testme() public{
        
    }
}

It uses gas for input (transaction cost): 4*68 = 272 + 21000 = 21272 - this is correct in Remix. But I cannot verify the execution cost:

It uses the following instructions according to the debugger:

Which is in sum 119 gas, but the instruction details in the Remix logger shows 128.

The instruction cost is the same as shown in Appendix G in the Yellowpaper, this is something I could verify. But I cannot verify where the 9 gas are coming from.

We should add a warning for this cause the bytecode of lib will contains a slot for its self reference.

library lib {
function create () returns (address)
{
child k = new child();
return address(k);
}
function getFromLib() returns (uint) {
    return 45;
}
}
contract child {
function get () returns (uint) {
return lib.getFromLib();
}
}

It should do a full equality check if the current transaction is not a creation transaction.

so we can use local exe instead of looking at the env path

Different colours for storage, memory and stack variables
The fact whether a variable is a value-type, stored in storage or memory often makes a huge difference. Similar to how other IDEs highlight variables depending on whether they are local variables or class members, Mix could make that distinction clear to the programmer.
Credit for the idea goes to @LianaHus

Perhaps use the solidityPack from ethereumjs-abi:

var abi = require('ethereumjs-abi')
var BN = require('bn.js')

abi.soliditySHA3(
    [ "address", "address", "uint", "uint" ],
    [ new BN("43989fb883ba8111221e89123897538475893837", 16), 0, 10000, 1448075779 ]
).toString('hex')

Helpful for larger contracts > 700 lines.
List all "// TODO ..." and make it "clickable" with jump-to-line action

EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs. The EditorConfig project consists of a file format for defining coding styles

More: http://editorconfig.org

(It also has a javascript implementation)

Display key, value instead of a complex hashedjey, key; value if all the keys are known.

Include easy way to use code snippet, code pattern.
could be a list of solidity code snippet that user would drag and drop to the editor.
There were post in reddit of a github repo that contain only solidity common pattern

From ethereum/solidity#3258.

Depends on ethereum/remix-ide#921.

It would be nice to warn if using assembly instructions which modify the control flow (e.g. they abort execution). All of them are available in the higher level language and in many cases using them there makes more sense.

Assembly instructions to highlight: invalid, return, revert, selfdestruct

cc @soad003, you might be interested

Hey,

In the following example -

contract AbstractToken {
    function totalSupply() external constant returns (uint256 totalSupply);
}

contract Token is AbstractToken {
    uint256 public totalSupply = 0;
}

Remix won't allow the user to create an instance of Token ("This contract does not implement all functions and thus cannot be created"), even though the auto generated compiler function for totalSupply matches the abstract interface signature.

Was tested on solidity 0.4.11

Note that solc actually compiles Token with no error.

See ethereum/solidity#2254

Edit: the issue is also valid when the abstract parent is an interface instead of a contract.

remix$ npm install
npm WARN deprecated [email protected]: We're super 😸 excited that you're trying to use ES2015 syntax, but instead of making more yearly presets 😭 , Babel now has a better preset that we recommend you use instead: npm install babel-preset-env --save-dev. preset-env without options will compile ES2015+ down to ES5 just like using all the presets together and thus is more future proof. It also allows you to target specific browsers so that Babel can do less work and you can ship native ES2015+ to user 😎 ! We are also in the process of releasing v7, so please give http://babeljs.io/blog/2017/09/12/planning-for-7.0 a read and help test it out in beta! Thanks so much for using Babel 🙏, please give us a follow on Twitter @babeljs for news on Babel, join slack.babeljs.io for discussion/development and help support the project at opencollective.com/babel

I think it would be the best to follow Solidity as closely as possible:

• "string" - string literal
• hex"0011ff" - bytes literal
• 0x1234 / 123 - numbers

The external remix API should be documented.

Suggestions by https://www.reddit.com/user/ItsAConspiracy :

Seems that top warning [fallback function] isn't quite right, since the contract can receive ether from user accounts or from contracts using call.value.

I think there are times when it's worthwhile to use >2300 gas in the fallback: specifically, when you prefer to throw rather than accepting the ether without crediting the sender. If your only options are to either throw or update storage, you might as well try to update storage, since it'll throw anyway if it runs out of gas.

Suppress the warning if the fallback is not marked payable.

• warn user if storage not complete
• allow scrolling down

Redirecting from solidity. It's all explained here: ethereum/solidity#3136

Browser-Solidity should support unit tests for contracts written in javascript using the web3 framework.
This requires several changes:

• allow files to be non-solidity (i.e. javascript)
• allow javascript files to be run against the current web3 object
• potentially integrate a test-runner to render test results nicely

Use solc.license() to retrieve the text - it will be very long though.

Depends on ethereum/solc-js#121.

comment from gitter
@yann300 @chriseth I'm running Remix as a Chrome extension but I'm getting destructive behaviour often when it starts up... It asks to overwrite local files with files from 'the cloud'. As an extension I have no idea what it thinks 'the cloud' is or where it stores these often older versions of my files but it does keep a set in local storage also. Regardless, I'm never sure which set are current and have on numerous occasions had days worth of work reverted by some older set of the same files.... Any ideas?

When creating an instance of c1 with the following code, the constructor automatically creates an instance of c2. For debugging purposes it would be extremely helpful if this nested instance myC2 would be shown in the contracts tab and I could, e.g. see its address and call its functions:

contract c1 {
    c2 myC2;
    function c1() {
        myC2 = new c2();
    }
    
    function getC1() constant returns (uint) {
        return 1;
    }
}

contract c2 {
    function getC2() constant returns (uint) {
        return 2;
    }
}

Depends on ethereum/remix-ide#223.

Assess the performance of both the UI and the trace retrieval / reformatting / data enrichment functions.

Since Remix already fetches all the available functions and also allows running the functions, this feature should be reasonable and feasible to implement.
It can save hours for numerous developers rewriting these codes all over again!
Thanks :)

When deploying & interacting with a contract, and setting a value, it's confusing when that value does not update in response.

It would be nice if the contract values updated when a new block had a new value associated.

Maybe this would require polling, and would be a performance concern?

Please provide a way to change the gas price per transaction.
The current default makes it very easy to work with libraries and proxy contracts.

The slider could benefit from markers that show internal and external function calls similar to a flame diagram in a browser debugger / profiler: https://pbs.twimg.com/media/Ci2HjxgWEAImxDB.png

In a similar way to https://github.com/ethereum/browser-solidity/issues/153 we could auto-save and synchronize files / projects to swarm.

This will be much more crude than github because swarm does not have version tracking. Can we use mango?

A very simple version of this would automatically publish all files in a project and display (and update) the root hash for the project.

A still quite simple version would connect this via ENS and display (and update) a name that links to the root hash for the project. If there are conflicts, you only have the option to ignore local or ignore remote changes.

@Arachnid just made me aware of "reverse ens records" and the fact that you can store contract ABI there. The deployed contract has to register its reverse record as part of its constructor (or at any time, but the registrar has to be called from that contract).
Since this process is similar to the "publish to swarm" process, we could add a button next to that button "publish ABI to ENS" or something like that.

Clicking the button would check that

1. we are connected to a node,
2. some contract we deployed in the past has a reverse record (and some of the accounts we control is registered as the controller),
3. we still know the ABI to that contract

We can iterate over all contracts we deployed in the past, potentially offer a drop-down selector and also display error messages if none matched.