Skip to content
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

Stop importing harden #1244

Merged
merged 6 commits into from
Jul 2, 2020
Merged

Stop importing harden #1244

merged 6 commits into from
Jul 2, 2020

Conversation

FUDCo
Copy link
Contributor

@FUDCo FUDCo commented Jun 30, 2020

A very, very large number of mostly superficial changes to eliminate importation of @agoric/harden, since harden is now a global in the SES environment.

Interestingly, testing this turned up a considerable number of tests that needed to import @agoric/install-ses. These imports have been added, and various package.json files adjusted to reflect the many new uses of @agoric/install-ses and the disappearance of @agoric/harden.

Since these changes intersect with a large swath of our code base, I've tagged a number of different people as reviewers, but you don't all need to review all of it, just the pieces you worry about. I'm thinking the following:

  • @warner SwingSet, asssert, captp, same-structure, marshall, sparse-ints, store, swingset-runner, weak-store
  • @Chris-Hibbert and/or @katelynsills ERTP, notifier, registrar, spawner, sharing-service, zoe
  • @michaelfig eventual-send, agoric-cli, cosmic-swingset, produce-promise
  • @kriskowal bundle-source, import-manager

Of course if I've mistakenly assigned you a wrong thing, ignore it, and if you see I've assigned something to somebody else that you really should look at, look at it. None of this is magic, just trying to spread the load.

@warner
Copy link
Member

warner commented Jun 30, 2020

Yeah, a lot of those files were being used both from vats under swingset (where they can rely upon a harden global) and by non-swingset unit tests (where they must import @agoric/harden instead).

Once the big zoe branch lands, we'll need to rebase and update this PR; I'm sure they added a bunch of new files/tests. We might consider making these changes one package at a time, if that makes it easier to keep up with trunk.

@FUDCo FUDCo force-pushed the stop-importing-harden branch 6 times, most recently from aa31945 to 94761da Compare June 30, 2020 23:43
Copy link
Contributor

@katelynsills katelynsills left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@michaelfig
Copy link
Member

One complication. @kriskowal do we have JSDoc typing for globalThis.harden yet? If not, we should make an issue.

Copy link
Member

@michaelfig michaelfig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@kriskowal
Copy link
Member

One complication. @kriskowal do we have JSDoc typing for globalThis.harden yet? If not, we should make an issue.

No, we don’t have TS tooling in SES yet, to the best of my knowledge.

Copy link
Member

@kriskowal kriskowal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉

Copy link
Member

@warner warner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like the XS test works by compiling two programs into C code and then running them. The first program is the equivalent of running a tape loader against all the test/test*.js files in packages/eventual-send:

cd packages/eventual-send
node -r esm $TAPE/bin/tape-xs-build.js $PWD test/test*.js
noflake mcconfig -m -p x-cli-lin test-xs-manifest.json
$MODDABLE/build/bin/lin/release/eventual-send

The second is the same but looking at packages/marshal. Both of those packages now include test.js files that do install-ses. SES includes @agoric/babel-standalone. That includes a regexp that looks like:

  function parseSourceMapInput(str) {
    return JSON.parse(str.replace(/^\)]}'[^\n]*\n/, ''));
  }

which appears to break in XS with:

/home/runner/work/agoric-sdk/agoric-sdk/node_modules/@agoric/babel-standalone/babel.js:21342: error: ^\)] invalid character!

cc @phoddie : is there a difference between the RegExp engine used in XS and the one that we were getting from Node? I see https://github.com/Moddable-OpenSource/moddable/blob/public/documentation/xs/XS%20Differences.md#conformance says Unicode property escapes aren't loaded by default, but that doesn't look like unicode to me. https://github.com/Moddable-OpenSource/moddable/blob/public/documentation/xs/XS%20Conformance.md#built-ins-1 lists a few RegExp tests which fail but I can't tell if any of them would cover this

@FUDCo I think the best thing to do here would be to switch these tests to use other agoric-sdk packages, which do not use install-ses. That way we'd still get some basic assurance that the XS makefiles still work. I'll open a separate issue to figure out the RegExp thing.

Change .github/workflows/ag-solo-xs.yml to use, say, same-structure and weak-store instead of eventual-send and marshal. And add a note with the regexp that XS didn't like, and a pointer here. I think that should let the CI test pass again.

All the other parts look good to me, modulo the comments below.

/* global Compartment harden */
// eslint-disable-next-line no-redeclare
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this disable marker can go away, it referred to something that used to be in the /* global */ marker that it used to precede

@@ -1,12 +1,11 @@
/* global harden */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@michaelfig does this impact any typescript checking? or is that an incomplete experiment?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this impacts typing. It's not an incomplete experiment, it actually worked (i.e. provided typechecking for the files).

I wrote:

One complication. @kriskowal do we have JSDoc typing for globalThis.harden yet? If not, we should make an issue.

I will probably be the one to make the issue and implement it.

@@ -1,14 +1,12 @@
import harden from '@agoric/harden';
/* global harden */

function build(E, log) {
const obj0 = {
bootstrap(argv, _vats) {
if (argv[0] === 'harden') {
log('harden-1');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This clause was testing that vats can still do require('@agoric/harden'). Since we're removing both the users of that feature and the bundle-source ability to reach it, we should also remove this test entirely (delete vat-imports-1.js and test-vat-imports.js), and we should remove the code that used to support it (the if (what === '@agoric/harden') in vatRequire in controller.js). Note that we must leave vatRequire in place, even though it no longer accepts any names, until #362 is fixed.

@@ -8,7 +8,7 @@ test('SwingSet bug', async t => {
const bundle = await rollup({
input: require.resolve('../encouragementBotCommsWavyDot/bootstrap.js'),
treeshake: false,
external: ['@agoric/evaluate', '@agoric/nat', '@agoric/harden'],
external: ['@agoric/evaluate', '@agoric/nat'],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This list should match the contents of vatRequire in controller.js. If vatRequire is now empty, this list should be too. I should have emptied it out when I landed the new-SES branch, sorry :).

globals: {
'@agoric/harden': 'harden',
},
// globals: {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@michaelfig can we delete this config file now? I think I got rid of the bundling step, but missed the config file.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that can be deleted.

@phoddie
Copy link

phoddie commented Jul 2, 2020

is there a difference between the RegExp engine used in XS and the one that we were getting from Node?

The implementation in XS is independent of Node. An introduction of our RegExp engine is available on our blog. Of course, it should be conforming to ECMA-262, except where documented.

The RegExp you note above does fail to parse with XS and succeed in Safari. We'll take a look. Thank you for the report.

warner added a commit that referenced this pull request Jul 2, 2020
We learned (in #1244) that the XS RegExp engine rejects several of the regexp
literals that appear in the SES shim (via babel-standalone). The XS test
works by compiling some other unit tests (eventual-send and marshal) into a C
executable, then running it. #1244 added `install-ses` to most packages,
including those two, which means XS is now being exposed to SES-shim code
that it wasn't seeing before, triggering the rejection bug.

When XS is updated to tolerate these cases, we'll turn this test back on.

closes #1251
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants