pipermerriam on master
Implement get_transaction_recei… (compare)
pipermerriam on master
Remove last occurrences of apos… (compare)
18 days later, ACD is noisy because of the difficulty bomb. :/
TL;DR: There might be an out-of-schedule call on Friday.
py-evm... I want to do essentially what is done in this exercise: https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/ -- but using
pythereum, and using the nice boilerplate project template that you have in the cookbooks. My question is where in the
py-evmAPI or source would I find the logic that does the same thing
pyethereum? Or, perhaps I'm totally going about this the wrong way, in which case my question is even more general: What's a good starting place for simple DB/State/Trie understanding of the evm?
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.