-
Notifications
You must be signed in to change notification settings - Fork 212
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
feat: default to xs-worker in chain #2995
Conversation
I'm testing this now.. dynamic vats still seem to be using the local worker, not XS. Investigating... |
#2998 fixes the issue, let's land it first. I started a chain, and restarted it, and things seem to look good. Startup is an order of magnitude faster (23s vs 247s). Restart is 20x faster (13.3s vs 244s). I'd appreciate someone else doing a smoke test (following the Getting Started instructions and installing/testing a dapp). Please review/land #2998, then get a second-opinion smoke test, then land. Yay! |
I asked @ski to take it for a spin; expect to hear from him in the next day or so. |
do you want me to rebase rather than that merge, @warner ? |
@warner @erights test-innerVat.js was sensitive to engine-specific messages for ReferenceError. But it also showed that when the XS supervisor reports an error in setBundle, the message was being censored before being passed back to the kernel. In ecf24f9 I changed the |
I'm seeing a problem when a load generator is pointed at this version.. please wait on landing it until I can investigate the cause. p.s. for follow-up, see #3012 |
@warner and I just agreed that this should be chain only, not ag-solo. Again, the trick is that this is due for today's release, presumably at the testnet meeting in 20 minutes; I'm not available for a bit for reasons I mentioned. @michaelfig @rowgraus be advised. |
Local workers offer richer debug support. Plus, we're seeing some instability using XS in ag-solo.
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 to me, I think we're ready!
For anyone following along, we're making the solo machine use Node.js (local
) vats so that the agoric start
developer environment (aka "simchain") provide a better debugging experience, especially the stack traces. Making dynamic vats use XS is much faster (because we don't have to rewrite the code with the metering transform), but XS doesn't provide very nice stack traces.
BTW I hear that the CI failure will go away when @Chris-Hibbert lands a pending treasury fix. |
Thanks, @kriskowal , for listening to the story behind this PR. |
I suggest that this:
closes #2473 commit to XS
closes #2521 XS devnet experience
closes #2837 xsnap swingset metering
test:xs-worker
in zoeYou may want to browse xsnap issues; I made an effort to label all relevant issues.
FYI @dtribble @rowgraus
since #3012 has come up, this is stacked on #3023