import E without env-options, message-breakpoints? without track-turns?

[dckc]

I'm working on a core-eval that's essentially one 20 line function. With comments and such, 2415 bytes. But because it imports E, the bundle is 10x that size: 33,849 bytes:

Size	Name
3222	compartment-map.json
2415	@aglocal/portfolio-deploy-v0.1.0/src/usdc-resolve.build.js
412	@endo/env-options-v1.1.11/index.js
4170	@endo/env-options-v1.1.11/src/env-options.js
5646	@endo/eventual-send-v1.3.4/src/E.js
338	@endo/eventual-send-v1.3.4/src/exports.js
3891	@endo/eventual-send-v1.3.4/src/message-breakpoints.js
853	@endo/eventual-send-v1.3.4/src/no-shim.js
2750	@endo/eventual-send-v1.3.4/src/track-turns.js

I'd rather not spend those bytes on message-breakpoints.js and env-options.js. I don't need them for debugging.

track-turns.js might be important at runtime, but this thing is pretty simple, so I'd like to have the option to do without that too.

To what extent is this feasible?

cc @kriskowal @erights

[dckc]

cc @michaelfig

[michaelfig]

I have a plan (cf "the eventual-send API redesign slides") where the guts of E would be part of a vetted shim (hence no contribution to the bundle) and a ponyfill module to flesh out the API built upon that shim. It will take work, but it is feasible.

[mhofman]

In this case I'm wondering if we couldn't get away with a @endo/eventual-send/simple.js that does the minimal E implementation. Actually eventual-send should already be available in the bootstrap vat, can we somehow get it from the environment?

[michaelfig]

can we somehow get [E] from the environment?

Ah, yes! I didn't see the forest for the trees. I was thinking that the script was importing other modules that themselves import @endo/far or @endo/eventual-send, but having looked at it now, it doesn't.

globalThis.E is supplied to each Compartment that evaluates a core-eval. So, @dckc, you can just comment out the unnecessary import like so, and it would still work:

// import { E } from '@endo/eventual-send'; // not necessary; we have globalThis.E in the core-eval's Compartment.

[dckc]

No; this isn't a script evaluated in the core eval compartment. It's a bundle for use with evaluateBundleCap, whose endowments are...

  const endowments = {
    VatData: globalThis.VatData,
    console,
    // See https://github.com/Agoric/agoric-sdk/issues/9515
    assert: globalThis.assert,
    Base64: globalThis.Base64, // Present only on XSnap
    URL: globalThis.URL, // Absent only on XSnap
  };

[erights]

Minimal version of track-turns.js without any debugging support:

/**
 * @template {((...args: any[]) => any) | undefined}T
 * @param {T} funcs
 * @returns {T}
 */
export const trackTurns = funcs => funcs;

[erights]

(Could someone explain the advantage of discussions over issue threads? I ask because there is a huge disadvantage: the absence of bidirectional linking.)

[dckc]

Lower barrier to entry, for the writer.

And less obligation to address them, for the maintainers.