carver on master
EIP-2565 calculation of modexp … Add newsfragment EIP 2565 Merge pull request #1976 from k… (compare)
Istanbul(and a couple other things) is released:
I have a feeling someone'll have to take over PR #1885 from me, or provide a lot of guidance.
lint failures are all for improper definitions/returns in low-level API classes:
VirtualMachineAPI; and some related abstract classes.
Take a look at this CI job most errors are an either-or choice, and I don't know which one is "correct".
eth/chains/base.py:250: error: Unexpected keyword argument "chain_context" for "VirtualMachineAPI" eth/abc.py:2270: note: "VirtualMachineAPI" defined here
which means something unexpected may be happening.
@/all Muir Glacier support is here:
<Christoph> @Pet3ris I'm afraid I can not answer this without diving into the code myself. One thing I suggest is to run py-evm with log level
0 to get full tracing output. Then you'll see output such as: https://gist.github.com/cburgdorf/41ce3a9c9502d2f194c9e54454e6a689
You can search for the output in Py-EVM and sprinkle the code paths with
breakpoint() statements and then use the debugger to examine from there. That's how I'd approach it.
vm.state.coinbaseetc., but I'd like to find something like
vm.current_transaction.computation.memoryto get other elements
def debug2(self, message: str, *args: Any, **kwargs: Any) -> None: if self.debug: if "COMPUTATION STARTING" in message: ExtendedDebugLoggerWithBytecode.collected =  print(len(ExtendedDebugLoggerWithBytecode.collected)) ExtendedDebugLoggerWithBytecode.collected.append((message, args, kwargs)) print(self.evm) print(self.evm.chain) print(self.evm.chain.get_vm().state) print(self.evm.chain.get_vm().state.block_number) ExtendedDebugLoggerWithBytecode.block_number = ( self.evm.chain.get_vm().state.block_number ) print(self.evm.chain.get_vm().state.coinbase)
Okay, so the part I'm still missing a bit is "why". Are you trying to answer a single question about the stack or memory? Or is there some other kind of motivation?
Right now, I've got:
So I'm wondering if there might be a different approach than 2. In general, the architecture is going to fight arbitrary inspection of some arbitrary thing that's currently happening. You'll usually need a reference to the object you want to know about. So 3 is going to be a pain. Assuming 2 is fixed, you might consider patching into the Computation object to generate logs from there instead. Or patching into the Executor to save a reference to the most recent generated computation somewhere. Both of these will have subtleties.
If 2 isn't fixed, then it depends a lot on what 1 is. Maybe if you're trying to answer a single question, then it could make sense to drop a conditional breakpoint in somewhere, or craft a transaction that generates the final state you want, etc, etc.
what would be the dangers? are there multiple computations potentially occuring within one transaction?
Yeah, not a danger, just something that might give confusing results without understanding carefully, since there are new computations created recursively, for example during
CALL style opcodes.