-
Notifications
You must be signed in to change notification settings - Fork 228
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Payments are virtual objects. #2526
Conversation
self: Far(makeFarName(allegedName, ERTPKind.PAYMENT), { | ||
getAllegedBrand: () => state.brand, | ||
}), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure how well the Far(makeFarName(...
stuff is going to get along with the virtual object machinery. The construct is certainly ugly and very hard to parse visually. I would have written this as just:
self: {
getAllegedBrand: () => state.brand,
}
But if this object is going to be used as a presence we need to get that Far()
wrapper on there somehow.
The return value from paymentVOMaker
is going to get hardened. I don't know how harden
deals with objects with properties that are already hardened. I think that's OK, but this is one of those mysterious edge cases that I always have to either ask @erights about or just try and see what happens.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
harden
is idempotent. That part is fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was expecting the Far...
to be in the makeKind
invocationL
const paymentMaker = makeKind(Far(makeFarName(allegedName, ERTPKind.PAYMENT), paymentVOMaker);
I don't like needing the self:
section. There was a slightly different pattern that didn't require that, but I couldn't lay my hands on that issue yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As @dtribble said, harden()
is idempotent. However Far
is not: it only accepts unhardened objects (it mutates them before hardening them).
I have a branch in which makeKind
asserts that the maker it was given is applying Far
to the self
that it returns, under the theory that the maker should be doing harden
to the { init, self }
pair that it returns ("don't let objects out of your sight without hardening them first"), and Far()
cannot be applied to objects that are already hardened, therefore the maker must apply the Far
before it hardens { init, self }
.
(the assertion on that branch isn't very helpful, however, because if you make the most common mistake and don't harden the return value, it emits a particularly weird error message instead of something that would guide you towards the light)
It would certainly be more ergonomic to tell makeKind
the interface name, and then have makeKind
apply the Far()
itself, but that would require that the maker not harden its return value, which feels counter to the habit we're trying to teach developers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that integration is the right thing. It should happen within the same module. The init/self
is the squishy underbelly of constructing useful remote and persistent objects. They don't need to be hardened, given that they should never escape directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Retracted previous comment. I took "escape" out of context)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh good. To clarify for the future, I just meant that the internal description of what needs to be built -- paymentVOMaker
-- on line 9 gets used on line 18 and the result of that is what gets locked down by the process. The paymentVOMaker
should never escape.
c3982b7
to
f9cb176
Compare
Brought in the Fake Virtual Object Manager from #2543 and was able to get it to work in AVA tests! I'm now getting errors like the following, which I think might be a bug in how the virtual object version of WeakStore (or maybe the mocked version?) is treating the objects. It seems to expect a string key instead.
|
f9cb176
to
3adcc6a
Compare
looks like the tricky bit there is rolling up the import. I did it in a build step for SESboot. budleSource might work, though. Oh... and having avaXS depend on ERTP or SwingSet is awkward. hm. That suggests some sort of command-line option to inject scripts, like ava. Hm. also, these two globals should get added to the test compartment endowments https://github.com/Agoric/agoric-sdk/blob/master/packages/xsnap/src/avaHandler.js#L59 . Here's hoping I can get to this after a SES release today... |
I checked with Kate and we agreed it's best for me to push directly to this branch... |
76e249f
to
f5d8a0a
Compare
@@ -32,6 +34,8 @@ import '../../exported'; | |||
import '../internal-types'; | |||
|
|||
export function buildRootObject(powers, _params, testJigSetter = undefined) { | |||
console.log('makeKind in zcf', makeKind()); | |||
console.log('makeWeakStore in zcf', makeWeakStore()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are these console.log
statements temporary? I usually mark my temporary stuff with '@@'.
or is this advice out of date?
In general we need to remove unsolicited console.logs from our codebase
-- https://github.com/Agoric/agoric-sdk/wiki/agoric-sdk-unit-testing#patterns
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Temporary for debugging purposes. This is a draft
342eaec
to
582982b
Compare
7f7d604
to
7ec916c
Compare
@dckc, in order to get linting to pass, I had to make some tiny changes to |
Yes. I think I made similar changes on another branch so we may have merge conflicts coming... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. I skipped over xsnap/src/avaXS.js
, presuming someone else (@dckc ?) looked at it closely.
One nit about duplicated names.
makeAliceMaker() { | ||
return harden(makeAliceMaker(vatPowers.testLog)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can these two makeAliceMaker
functions have different names? Maybe the inner one is makeAliceMakerActual
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To understand this PR well requires me to understand out external store stuff more than I currently do. I definitely need to dive deeper into that. However, I do understand it well enough to see that this PR correctly uses it, so there's no need to delay this PR on that.
makeKind
is an endowment for accessing an external store. I understand why we might want to make this an ambient endowment. But why makeWeakStore
? And why makeWeakStore
and not makeStore
?
Placing them is the general eslint config so that they can be used without a /* global
declaration makes me uncomfortable. I would like to discuss this before this PR is merged. If we cannot resolve this quickly, it looks to me like that change could be split off from this PR. With that removed, I'm happy to LGTM this PR. Note: I may well have agreed to this global listing earlier, so I understand the frustration if I'm reversing myself. But that's part of why we review. Once implemented, an idea can look less pleasant than one imagined.
It seems that there are two makeWeakStore
s, our earlier vanilla one and the new external one. Again, I think I may have been the one to suggest that they be unified this way, but I would like to revisit this. However, IIUC, this specific issue does not need to delay this PR. It is more an issue with what has already been merged as part of the external store system.
I did not review any of the tests. If there are particular tests that you would especially like me to look at, please let me know.
I did not review the XS Ava changes. Please get @dckc 's reaction to those.
I'm submitting this review as "Comment" rather than "Request changes" because I don't know that changes are called for. Rather, we need to discuss.
The |
I can just rebase. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@katelynsills and I discussed. The only change needed in this PR is not to extend the eslint config list of assumed globals.
All my other concerns are with the external store abstractions that are already merged, which I need to investigate more deeply anyway, and separately. Attn @FUDCo
LGTM, thanks!
@FUDCo, I think these are questions for you. Should I copy this over into an issue for further discussion with @rights?
As discussed, I will remove from the eslint config, and use the |
Jinx :) |
7a7b08a
to
34f3379
Compare
@dckc This was the one xsnap change that remained after rebasing - should it be in this PR? Anything I missed that should be here? Thanks! |
The |
34f3379
to
022a488
Compare
022a488
to
e6a0924
Compare
First attempt to try to use virtual objects, just for payments in issuer.js in ERTP.
TODO:
paymentVOMaker
topaymentVOFactory
.agoric-sdk/packages/ERTP/src/issuer.js
Lines 163 to 170 in 55bdaf7
makeKind
andmakeWeakStore
, ensure unitTests passmakeKind
andmakeWeakStore
as globals in XS testsmakeKind
andmakeWeakStore
available in dapp tests#dapp-fungible-faucet-branch: prepare-test-env
#dapp-card-store-branch: prepare-test-env
#dapp-otc-branch: prepare-test-env
#dapp-oracle-branch: prepare-test-env
#dapp-pegasus-branch: prepare-test-env
#dapp-encouragement-branch: prepare-test-env
#dapp-simple-exchange-branch:prepare-test-env
#dapp-svelte-wallet-branch: prepare-test-env
#dapp-token-economy-branch: prepare-test-env
#documentation-branch: prepare-test-env