Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 10 2017 22:42
    @jpitts banned @etherchamp1_twitter
  • Jun 05 2016 10:33
    @chriseth banned @adamskee
chriseth
@chriseth
@agatsoh the state of the art debugger is mix
agatsoh
@agatsoh
what do they ask questions about solidity on stackexchange :smile: ?
agatsoh
@agatsoh
@chriseth In the example that you gave if we have both the contracts deployed.
and have the addresses of both contracts on the blockchain
will h = new Helper("abc", true); make a new contract ?
agatsoh
@agatsoh
contract Helper {
            bytes3 name;
            bool flag;

            function getName() returns (bytes3 ret) { return name; }
            function getFlag() returns (bool ret) { return flag; }
        }
        contract Main {
            Helper h;
            function init(address helperAddress){ h= Helper(helperAddress) }
            function getFlag() returns (bool ret) { return h.getFlag(); }
            function getName() returns (bytes3 ret) { return h.getName(); }
            })
just a variation will this work ?
agatsoh
@agatsoh
The stackexchange is amazing !!!!! Thanks a lot @chriseth
Niran Babalola
@niran
I'm experiencing unexpected behavior that is consistent between the go, python, java, and JS EVMs. When a transaction runs out of gas, what's supposed to happen? I sent the same transaction twice with different amounts of gas. With 3,000,000 gas, it succeeds. Without specifying the amount of gas, web3 sent 90,000 gas and crashed with a bad JUMPDEST. Looking at the VM trace, the contract subtracts the gas for a call from the amount of gas remaining, but that value ends up rolling over to a negative number (or a large unsigned integer). I suspect this is involved in the bad JUMPDEST crash, but I don't know how a Solidity contract could ever generate a bad JUMPDEST.
Looking for guidance on whether this is a bug and where to file it.
Niran Babalola
@niran
Sounds like not a bug. I think we should get that information into all the documentation that references JUMPDEST though.
Piper Merriam
@pipermerriam
Are there utilities anywhere for producing a cryptographic signature for arbitrary input using an ethereum account key-pair?
If you need an account, you should be able to sign in here: https://area51.stackexchange.com/proposals/89704/ethereum (or ask anyone here for an invite)
@pipermerriam I rolled my own code that I'll paste in an answer on Stack Overflow.
Niran Babalola
@niran
@pipermerriam Answered!
Simon de la Rouviere
@simondlr
Internall, it seems Solidity places some guards in place when issuing call(). It doesn’t automatically forward ALL the gas to the sub-call. It subtracts some gas to keep around. However, I’m not exactly sure how it determines what amount of gas to keep around. Does anyone know? @chriseth?
chriseth
@chriseth
@agatsoh yes to both questions
chriseth
@chriseth
@simondlr this is one of the quirky places of the EVM. You cannot just say "send all my gas along with the call", you always have to give an explicit number. We do have the GAS opcode which gives us the amount of gas still available, but the problem is that performing the call itself also costs some gas, so we have to subtract the amount of gas the call costs from the value provided by GAS, and we also have to subtract the amount of gas it costs to perform the subtraction...
RJ Catalano
@VoR0220
Lol. Wow. Definitely quirky.
Terek Judi
@terekjudi
Getting the following error when trying to run eth, any ideas on how to resolve this: 'symbol lookup error: /usr/lib/libdevcrypto.so: undefined symbol: _ZN8CryptoPP10RandomPool34GenerateIntoBufferedTransformationERNS_22BufferedTransformationERKSsy'
Terek Judi
@terekjudi
I couldn't figure it out so I removed cpp-ethereum and re-installed it again and it fixed the problem. Thx
can anyone help me with this one ?
agatsoh
@agatsoh
with regards to the above question I want to add that I found out one thing
agatsoh
@agatsoh
Please disregard the question there was problem with my script
Simon de la Rouviere
@simondlr
@tcoulter answered. :)
@agatsoh please don’t delete the questions, even if it’s a trivial answer. I made effort looking through your code to give an answer, and it will help others in the future if they experience similar problems.
agatsoh
@agatsoh
@simondlr but nevertheless I found a small bug in this exercise. Will update regarding this.
@simondlr should I edit this question a bit because I found the answer myself
Illya Havsiyevych
@illya13
hi, does now returns unix time ?
any idea why it returns 0 in online compiler ?
oh, ignore
now (uint): current block timestamp (alias for block.timestamp)
agatsoh
@agatsoh
@simondlr i gave the answer for my own question I was struggling with this for 2 days
Simon de la Rouviere
@simondlr
That's part of the issue. The real issue was, was that (before you edited the question), the parameter was called "bankAddress". And you didn't use that in your code.
agatsoh
@agatsoh
@simondlr yes yes I agree to that
it was a typo because I was checking this issue and trying different things out. I am sorry for that @simondlr
Simon de la Rouviere
@simondlr
No worries. Glad it got figured out!
chriseth
@chriseth
@illya13 now returns the timestamp of the current block. The EVM simulator in the browser-compiler uses a very limited blockchain whose timestamp is not set to the current time, that should be fixed :-)
chriseth
@chriseth
please review: chriseth/browser-solidity#91
Nikolai Mushegian
@nmushegian
How exactly does solidity force the transaction to go out of gas on throw?