migrate xsnap to endo

[dckc]

@kriskowal @warner and everybody,

The folks at moddable just refactored xsnap between platform and application:
agoric-labs/xsnap-pub@c2cebe7

and they provided xsnap-ava.c, which has our pipe I/O and event loop (it's a bit of a misnomer, but no matter for now).
https://github.com/agoric-labs/xsnap-pub/blob/master/xsnap/sources/xsnap-ava.c

This was somewhat prompted by me wishing that our collaboration could use less copy-and-paste and more sharing.

I'm already in the process of copying / moving xsnap from agoric-sdk to endo; maybe now is a good time to reconcile things?
https://github.com/Agoric/agoric-sdk/blob/master/packages/xsnap/src/xsnap.c
https://github.com/endojs/endo/blob/535-ava-xs/packages/xsnap/src/xsnap.c

I tried to look at diffs between xsnap/src/xsnap.c and xsnap-ava.c and while I didn't see anything wrong, it looks like a lot of work to be sure that nothing was lost in translation.

Other questions that come to mind:

• submodules are tedious; is this as good as it gets? do we want another one?
• how should binary artifacts be packaged?

[kriskowal]

What if we move xsnap to endojs/endo and give Peter and Patrick collaborator access instead of syncing another repository?

…

On Tue, Apr 20, 2021 at 8:23 AM Dan Connolly ***@***.***> wrote: @kriskowal <https://github.com/kriskowal> @warner <https://github.com/warner> and everybody, The folks at moddable just refactored xsnap between platform and application: ***@***.*** <agoric-labs/xsnap-pub@c2cebe7> and they provided xsnap-ava.c, which has our pipe I/O and event loop (it's a bit of a misnomer, but no matter for now). https://github.com/agoric-labs/xsnap-pub/blob/master/xsnap/sources/xsnap-ava.c This was somewhat prompted by me wishing that our collaboration could use less copy-and-paste and more sharing. I'm already in the process of copying / moving xsnap from agoric-sdk to endo; maybe now is a good time to reconcile things? https://github.com/Agoric/agoric-sdk/blob/master/packages/xsnap/src/xsnap.c https://github.com/endojs/endo/blob/535-ava-xs/packages/xsnap/src/xsnap.c I tried to look at diffs between xsnap/src/xsnap.c and xsnap-ava.c and while I didn't see anything wrong, it looks like a lot of work to be sure that nothing was lost in translation. Other questions that come to mind: - submodules are tedious; is this as good as it gets? do we want another one? - how should binary artifacts be packaged? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#681>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAOXBXUJPJ2PMDYKX245C3TJWMAFANCNFSM43IMP43Q> .

[dckc]

What if we move xsnap to endojs/endo ...

I'm leaning that direction, yes...

... and give Peter and Patrick collaborator access instead of syncing another repository?

I wonder if they would see access as a "gift". It would put a burden on them to yarn test any contributions and such. yarn and the whole npm world is outside their normal workflow.

[dckc]

When xsnap is moved out of agoric-sdk, how should the binary get built? postinstall?

[kriskowal]

I believe postinstall is the current best option. npm doesn’t parameterize packages by architecture.

…

On Tue, Apr 20, 2021 at 4:52 PM Dan Connolly ***@***.***> wrote: When xsnap is moved out of agoric-sdk, how should the binary get built? postinstall? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#681 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAOXBULFU5MAU6EVGYCQ53TJYHTXANCNFSM43IMP43Q> .

[dckc]

For testnet monitoring, we made some tweaks to the moddable SDK: agoric-labs/moddable#5

Are we going to maintain a branch? ugh.

[dckc]

Using agoric-labs required some fix-up in the deployment mode of build.js:

Agoric/agoric-sdk@a1a2693

as @warner notes,

we need to make sure to not add another git submodule which happens to be hosted at a matching url

[dckc]

Moddable refined metering to cover stack operations. But now that we've forked again, integrating it is non-trivial. Our agoric-labs ag-testnet branch is "5 commits ahead, 19 commits behind Moddable-OpenSource:public"

p.s. escalated to its own issue: Agoric/agoric-sdk#3139

[dckc]

@kriskowal @dtribble @warner and I just discussed this

1. Agoric keeps xsnap.c and such in agoric-sdk. As @phoddie pointed out, on Apr 19, moddable provided a xsnap: platform vs application refactor c2cebe7; we have not yet integrated it. We should reconcile these. (But not urgently; we're inclined to accept the technical debt in favor of other priorities just now.)
2. Once we reconcile them, we should figure out how to manage things going forward
   • refactor: xsnap-native submodule (WIP) #682 is a start at using a submodule for the C code such as xsnap.c, but it has fallen behind.

All this is separate from the issue of keeping the main XS sources in sync, which see Agoric/agoric-sdk#3139

[dckc]

Having makeSnapstore in the @agoric/xsnap package is a bit awkward, as @warner just noted in Agoric/agoric-sdk#2848 (comment)

It has moved back and forth between SwingSet and xsnap, but it probably doesn't belong in either.

[dckc]

The technical debt around the xsnap: platform vs application refactor is addressed as of agoric-sdk/pull/3607 Aug 13 85b252c .

So it's more straightforward to migrate the package to endo.

This would probably be a good time to move ava-xs to its own package.

This is not urgent, AFAIK.