Write state diff to CSV #2
@ -26,6 +26,7 @@ import (
|
||||
|
|
||||
"github.com/ethereum/go-ethereum/log"
|
||||
"github.com/ethereum/go-ethereum/rlp"
|
||||
"github.com/ethereum/go-ethereum/trie"
|
||||
"github.com/ethereum/go-ethereum/common/hexutil"
|
||||
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
|
||||
)
|
||||
|
||||
type Builder interface {
|
||||
@ -156,7 +157,7 @@ func (sdb *builder) buildDiffEventual(accounts map[common.Address]*state.Account
|
||||
|
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
|
||||
|
||||
codeBytes, err := sdb.chainDB.Get(val.CodeHash)
|
||||
|
||||
codeHash := common.ToHex(val.CodeHash)
|
||||
|
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
|
||||
codeHash := hexutil.Encode(val.CodeHash)
|
||||
|
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
|
||||
hexRoot := val.Root.Hex()
|
||||
|
||||
if created {
|
||||
@ -222,7 +223,7 @@ func (sdb *builder) buildDiffIncremental(creations map[common.Address]*state.Acc
|
||||
|
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
|
||||
NewValue: createdAcc.Balance,
|
||||
OldValue: deletedAcc.Balance,
|
||||
}
|
||||
codeHash := common.ToHex(createdAcc.CodeHash)
|
||||
|
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
|
||||
codeHash := hexutil.Encode(createdAcc.CodeHash)
|
||||
|
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
|
||||
|
||||
nHexRoot := createdAcc.Root.Hex()
|
||||
oHexRoot := deletedAcc.Root.Hex()
|
||||
@ -258,7 +259,7 @@ func (sdb *builder) buildStorageDiffsEventual(sr common.Hash, creation bool) (ma
|
||||
|
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
|
||||
if it.Leaf() {
|
||||
log.Debug("Found leaf in storage", "path", pathToStr(it))
|
||||
path := pathToStr(it)
|
||||
value := common.ToHex(it.LeafBlob())
|
||||
|
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
|
||||
value := hexutil.Encode(it.LeafBlob())
|
||||
|
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
|
||||
if creation {
|
||||
storageDiffs[path] = DiffString{NewValue: &value}
|
||||
} else {
|
||||
@ -292,11 +293,11 @@ func (sdb *builder) buildStorageDiffsIncremental(oldSR common.Hash, newSR common
|
||||
|
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
|
||||
if it.Leaf() {
|
||||
log.Debug("Found leaf in storage", "path", pathToStr(it))
|
||||
path := pathToStr(it)
|
||||
value := common.ToHex(it.LeafBlob())
|
||||
|
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
|
||||
value := hexutil.Encode(it.LeafBlob())
|
||||
|
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
|
||||
if oldVal, err := oldTrie.TryGet(it.LeafKey()); err != nil {
|
||||
log.Error("Failed to look up value in oldTrie", "path", path, "error", err)
|
||||
} else {
|
||||
hexOldVal := common.ToHex(oldVal)
|
||||
|
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
|
||||
hexOldVal := hexutil.Encode(oldVal)
|
||||
|
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
|
||||
storageDiffs[path] = DiffString{OldValue: &hexOldVal, NewValue: &value}
|
||||
}
|
||||
}
|
||||
@ -311,10 +312,10 @@ func (sdb *builder) buildStorageDiffsIncremental(oldSR common.Hash, newSR common
|
||||
|
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
|
||||
|
||||
func (sdb *builder) addressByPath(path []byte) (*common.Address, error) {
|
||||
// db := core.PreimageTable(sdb.chainDb)
|
||||
log.Debug("Looking up address from path", "path", common.ToHex(append([]byte("secure-key-"), path...)))
|
||||
|
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
|
||||
log.Debug("Looking up address from path", "path", hexutil.Encode(append([]byte("secure-key-"), path...)))
|
||||
|
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
|
||||
// if addrBytes,err := db.Get(path); err != nil {
|
||||
if addrBytes, err := sdb.chainDB.Get(append([]byte("secure-key-"), hexToKeybytes(path)...)); err != nil {
|
||||
log.Error("Error looking up address via path", "path", common.ToHex(append([]byte("secure-key-"), path...)), "error", err)
|
||||
|
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
|
||||
log.Error("Error looking up address via path", "path", hexutil.Encode(append([]byte("secure-key-"), path...)), "error", err)
|
||||
|
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
|
||||
return nil, err
|
||||
} else {
|
||||
addr := common.BytesToAddress(addrBytes)
|
||||
|
||||
|
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉 Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas? That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between `make(byte[], 0)` and `[]byte{}` was inadvertent, so I'll switch them both to be the same for consistency.
The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to `collectDiffNodes` - where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).
I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
|
||||
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a
NodeIteratorinitialized withmake([]byte, 0)enables us to track down deletions while initializing it withmake([]byte{})yields creations.I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a
NodeIteratorinitialized withmake([]byte, 0)enables us to track down deletions while initializing it withmake([]byte{})yields creations.I may be missing something but it looks like the
creationarg is unused (and I think that's true all the way up to the calls ofbuildDiffEventual), so we may be able to remove itI may be missing something but it looks like the
creationarg is unused (and I think that's true all the way up to the calls ofbuildDiffEventual), so we may be able to remove itYep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between
make(byte[], 0)and[]byte{}was inadvertent, so I'll switch them both to be the same for consistency.The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to
collectDiffNodes- where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between
make(byte[], 0)and[]byte{}was inadvertent, so I'll switch them both to be the same for consistency.The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to
collectDiffNodes- where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?