-
Notifications
You must be signed in to change notification settings - Fork 207
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
Stop importing harden #1244
Conversation
d6cf911
to
519a6a2
Compare
Yeah, a lot of those files were being used both from vats under swingset (where they can rely upon a 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. |
aa31945
to
94761da
Compare
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.
LGTM!
One complication. @kriskowal do we have JSDoc typing for globalThis.harden yet? If not, we should make an issue. |
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.
LGTM!
No, we don’t have TS tooling in SES yet, to the best of my knowledge. |
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.
🎉
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.
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
:
agoric-sdk/.github/workflows/ag-solo-xs.yml
Lines 71 to 74 in 36d63fc
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.
packages/SwingSet/src/controller.js
Outdated
/* global Compartment harden */ | ||
// eslint-disable-next-line no-redeclare |
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.
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 */ |
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.
@michaelfig does this impact any typescript checking? or is that an incomplete experiment?
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.
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'); |
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.
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'], |
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.
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: { |
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.
@michaelfig can we delete this config file now? I think I got rid of the bundling step, but missed the config file.
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.
Yes, that can be deleted.
b097460
to
da04e94
Compare
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. |
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
d7e821d
to
57aadad
Compare
57aadad
to
e94f4d3
Compare
A very, very large number of mostly superficial changes to eliminate importation of
@agoric/harden
, sinceharden
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 variouspackage.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:
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.