rain
With constantinople you can also consider `extcodehash`
> > With constantinople you can also consider `extcodehash` > > Yeah, I was planning to take care of it in another PR. Are you still considering extcodehash?
To clarify: this is to future proof ds-proxy against gas pricing changes in the EVM. @gbalabasquer @NiklasKunkel want to restate any opinions here?
I think you can relax it in client code. Just maybe have a guard around when it goes back into the evm.
@kennyrowe can you expand on the use case here? You're doing a networked local testnet or something?
Related: makerdao/maker-otc#10, with travis based solutions makerdao/maker-otc#29 and makerdao/maker-otc#31 (using dapple docker image). All these PRs do is get a dapple install and run `dapple test`, so the solution isn't...
Not sure where you are with this atm - guess it is mixed up with the chain forking work. Anyway, just noting that my current workaround for using dapple test...
Would be good to be able to pin a version of a subpackage across the whole project. Then you know that e.g. your dappsys version is the same throughout all...
@dbrock: hadn't seen the `--remote` flag before, thanks! This won't help when you don't control your subpackages though (or at least their dependencies)
amusingly this means that any ci test failures won't have shown up.