feat: 53:kread-start proposal

[dckc]

This is a port of Agoric/agoric-sdk#8361 to this framework.

closes: Agoric/agoric-sdk#8329
closes: Agoric/agoric-sdk#8376

• installs bundles, minting IST if necessary
• impersonates privileged accounts
• runs core eval
• polls until initialization is done

It's working locally.

XXX lots of copy-and-paste from 49

[turadg]

I started reviewing from the top which included core-eval-support.js, then I realized it's just copied over and any cleanup should apply to all versions. Perhaps some shared lib code.

The other feedback is code quality and optimization that needed block landing. This is test code which we can refactor and iterate upon freely.

[turadg]

I don't think this is necessary for tests. The arguments I've heard for minimizing ambient authority don't apply:

• testability (this is the test itself)
• security (this is a test environment)

The levels of indirection with io in this repo are just cognitive overhead imo

[dckc]

Yes, we haven't made much progress in convincing each other.

[dckc]

I see it the other way around: it's not necessary to sprinkle ambient authority all over test code. That would be more cognitive overhead, for me.

[turadg]

consider noting that the reason for the extreme Ava timeout is there's a lot of work done here.

Going forward I think it behooves us to have a straightforward script like performActions.ts

[dckc]

sure... if the code weren't already working, I would not likely approach it this way.

Though I did do a little bit of performActions.ts style work way back in the beginning, and since switching to test() style, I have gotten a lot of mileage out of being able to run just selected tests.

[dckc]

ah. mis-read at first. you're suggesting adding a comment. got it.

[turadg]

gotten a lot of mileage out of being able to run just selected tests

That makes sense for tests! If it's really testing something that doesn't depend on anything happening, then I think that makes sense in Ava. E.g. that bundles aren't already installed. But that can be in yarn ava pre.test.js in eval.sh before the action is performed.

[turadg]

I assume these values aren't read anywhere?

Suggested change

	bundles: [
	'/Users/wietzes/.agoric/cache/b1-51085a4ad4ac3448ccf039c0b54b41bd11e9367dfbd641deda38e614a7f647d7f1c0d34e55ba354d0331b1bf54c999fca911e6a796c90c30869f7fb8887b3024.json',
	'/Users/wietzes/.agoric/cache/b1-a724453e7bfcaae1843be4532e18c1236c3d6d33bf6c44011f2966e155bc7149b904573014e583fdcde2b9cf2913cb8b337fc9daf79c59a38a37c99030fcf7dc.json',
	],

[dckc]

Hm. What gives that impression? They're used in many places. all the calls to bundleDetail.

In particular, to fetch and install the bundles:

      const { id, fileName, endoZipBase64Sha512 } = bundleDetail(bundle);
...
      const bundleRd = await assets.storedPath(fileName);

The storedPath should perhaps be called provideStorePath. It downloads the file if necessary.

[turadg]

What gives that impression?

That they refer to paths that are only on Wietze's machine.

I've since learned that it parses out the b1-….json. I suggest omitting the leading path.

[turadg]

ditto

Suggested change

	bundles: [
	'/Users/wietzes/.agoric/cache/b1-853acd6ba3993f0f19d6c5b0a88c9a722c9b41da17cf7f98ff7705e131860c4737d7faa758ca2120773632dbaf949e4bcce2a2cbf2db224fa09cd165678f64ac.json',
	'/Users/wietzes/.agoric/cache/b1-0c3363b8737677076e141a84b84c8499012f6ba79c0871fc906c8be1bb6d11312a7d14d5a3356828a1de6baa4bee818a37b7cb1ca2064f6eecbabc0a40d28136.json',
	],