Handle CALL_ID == CALLER_ID not ACCT_ID

[iamchrissmith]

In writing the proof for DS-auth, I need to cover the condition where CALLER_ID == ACCT_ID this was creating a problem in displaying the results because call_id was CALLER_ID but the v2n object was still expecting ACCT_ID.

To correct this I abstracted the getting of the contract to a helper function and added a condition to handle if the CALLER_ID == ACCT_ID and CALLER_ID is passed as CALL_ID.

Let me know if this is too narrow of a solution or would cause problems in cases outside my situation.

[iamchrissmith]

i see that the buildbot is failing. The error is HEAD not based on 'origin/master' which I'm guessing is based on the fact that i'm working off my fork. I did that since i don't have permission to push to this repo. Let me know if i need to do something else to get buildbot to be happy

[MrChico]

Hey @iamchrissmith the buildbot fail happens since your a little behind master. If you rebase on top of master you should get a nice buildbot test and we can merge this

[iamchrissmith]

also, i saw this comment:

klab/lib/evmv.js

Lines 45 to 46 in 0ed666b

	// TODO - use var to contractname map to get the contractname
	// and use it to get the right contract here

Since i'm touching this piece of code, I'd be happy to do that here, but I wasn't sure what exactly it was referring to. LMK if I can/should add something in for that

[MrChico]

There's other cases where this occurs as well. Whenever ACCT_ID has been stipulated to be equal to smth else, the <id> cell can take hold a different value, so the contract lookup fails. I just ran into this with <id> Owner </id>.

Might be a better idea to look at what the value of the <id> cell is at the first node and set that to be the contract name, for a more general solution

[iamchrissmith]

Is that not what it already happening here: https://github.com/dapphub/klab/blob/master/lib/clean-evm-node.js#L5?

I'm not seeing a situation in my FV out dir where <id> is set to anything other than ACCT_ID so I may be looking in the wrong place or not understanding the structure of the state when its being parsed

[iamchrissmith]

@MrChico Should we just set it to ACCT_ID or will the v2n have other call_ids that we need to track? I just ran into one where it was set to Owner but should be looking up with ACCT_ID