@agoric/swingset-liveslots 0.10.3-upgrade-19-dev-0754752.0 → 0.10.3-upgrade-18a-dev-4ee0508.0

package/src/vatstore-usage.md

@@ -1,197 +0,0 @@
-# How Liveslots Uses the Vatstore
-
-Each vat gets exclusive access to a portion of the kernel's `kvStore`, implemented with a simple prefix: when vat `v6` uses `syscall.vatstoreSet('key', 'value')`, the kvStore records the value in key `v6.vs.key`.
-
-Userspace gets an attenuated object named `vatPowers.vatstore`. When userspace calls `vatPowers.vatstore.set('key', 'value')`, liveslots performs `syscall.vatstoreSet('vvs.key', value)`, which results in a kernel kvStore entry under key `v6.vs.vvs.key`.
-
-The rest of the vat's keyspace is used by liveslots:
-
-* virtual object Kind metainformation
-* data for each virtual object
-* virtual collection metainformation and entries
-* reference counts for virtual objects (tracking references from other virtual objects)
-* export status for virtual objects
-* the id of the "baggage" object, delivered across vat upgrades
-
-This file describes the layout of the vatstore keyspace.
-
-# vref virtual/durable annotations
-
-When vats export object references into the kernel, they create "vrefs" as reference identifiers. For non-virtual objects (ephemeral "Remotables", held in RAM rather than the DB), these take the form of `o+NN` (e.g. `o+0`, `o+12`, `o+937`). Virtual and durable exported objects get an additional `v` or `d` annotation, so their vrefs start with e.g. `o+v99` or `o+v132` for virtual objects, and `o+d3` or `o+d77` for durable objects. The kernel can use these annotations to assist in the cleanup process when a vat is upgraded, and non-durable objects are abandoned.
-
-Kind handles are necessarily durable, as is the "baggage" object. Promises are necessarily ephemeral, so vat-allocated promise vrefs (aka "vpids") always use the `p+NN` form, and never have a `v` or `d` annotation.
-
-# Counters
-
-Liveslots maintains three durable counters to create the distinct vrefs that it transmits to the kernel. These counters are initialized when `startVat` is called to create the first incarnation of a vat (see `initialIDCounters` and `initializeIDCounters` in [liveslots.js](./liveslots.js)), and written to the vatstore at the end of each delivery as a JSON-serialized record at key `idCounters` (see `flushIDCounters`).
-
-* `exportID`: an integer indicating the ID of the next exported Remotable or defined Kind and incremented upon each allocation of such a value. Technically starts at 1, but that is mostly irrelevant because the root object itself is associated with 0 and many initial values are claimed before any userspace vat code has a chance to run (described below).
-* `collectionID`: an integer indicating the ID of the next collection and incremented upon each allocation of a new collection. Starts at 1, which is claimed by "[baggage](#baggage)".
-* `promiseID`: an integer indicating the ID for the next exported promise (including a promise implicitly created for outbound-message results) and incremented upon each allocation. Starts at 5.
-
-The current version of liveslots consumes the first ten exportIDs (covering `o+0` through `o+9`) during vat startup, leaving `10` as the first exportID available for userspace.
-
-* `o+0`: root object
-* `o+d1`: identifies the KindHandle Kind ID, each `o+d1/${kindHandleID}` instance of which is a KindHandle
-* `o+v2` through `o+v5`: KindHandles for the built-in [virtual collections](#virtualdurable-collections-aka-stores)
-* `o+d6` through `o+d9`: KindHandles for the built-in [durable collections](#virtualdurable-collections-aka-stores)
-* `o+10` / `o+v10` / `o+d10`: first available for userspace Remotables or Kinds
-
-
-# Virtual Object Kinds
-
-Vats can use `VatData.defineKind()` to define categories (classes) of virtual data (see [Virtual and Durable Objects](../../SwingSet/docs/virtual-objects.md)). The effective schema for each "Kind" contains an interface name, a set of `state` property names, and a list of facet names (which may be empty, indicating a single-facet Kind).
-
-The standard Kind is "single-facet", meaning that each instance of the virtual object yields exactly one "Representative". However many security patterns require a collection of "Facet" Representatives which share access to common state. These Facets are all created at the same time and returned in a single record called a "cohort".
-
-`defineKind` also specifies the runtime behavior: an `init` function called to create the initial state of each instance, a `behavior` record to provide methods for each instance, and an optional `finish` function to perform post-initialization tasks like registering the new object in a collection. `defineKind` returns a "kind constructor", typically named e.g. `makeFoo()` to make instances of the "foo" kind.
-
-Each time the kind constructor is called, a new "baseref" is allocated for the cohort, and the (one or multiple) facet Representatives are created. Each Representative/Facet gets a separate vref, all of which are extensions of the baseref.
-Those vrefs are used when interacting with the kernel (in `syscall.send` etc.), and in virtualized data (inside the capdata `slots` that point to other objects), but the vatstore keys that track GC refcounts and export status use the "baseref" instead.
-
-The baseref is built out of two pieces separated by a literal `/`:
-
-1. Prefixed Kind ID, e.g. `o+v11` or `o+d11`. These are allocated using the same exportID [counter](#counters) as exported Remotables (JavaScript objects marked with `Far`), meaning exported objects and Kind IDs share a numberspace.
-2. Instance ID, an integer. `1` for the first instance of each Kind and incremented for each subsequent instance.
-
-The vref for a Representative of a single-facet virtual Kind is just the `o+v${kindID}/${instanceID}` baseref. The vref for a Representative of a facet of a multi-facet virtual Kind extends that to `o+v${kindID}/${instanceID}:${facetID}`, where the additional component is:
-
-3. Facet ID, an integer. `0` for the first facet and incremented for each subsequent facet.
-
-In a c-list or virtualized data, you may see vrefs like these:
-
-* `o-3`: an imported Presence, pointing to some object in a different vat
-* `o+0`: the root object, a plain Remotable
-* `o+10`: another plain Remotable, exported from this vat or stored in virtualized data
-* `o+d11/1`: a Representative for the first instance of single-facet virtual Kind `o+v11`
-* `o+d11/2`: a Representative for the second instance of single-facet virtual Kind `o+v11`
-* `o+d12/1:0`: the first facet of the first instance of a multi-facet durable Kind `o+d12`
-* `o+d12/1:1`: the second facet of that same instance
-* `o+d12/2:0`: the first facet of a different instance
-* `o+d12/3:0`: the first facet of yet another different instance
-
-Each instance of a virtual object stores state in a vatstore key indexed by the baseref. If `o+d12/1:0` and `o+d12/1:1` are the facet vrefs for a cohort whose baseref is `o+d12/1`, the cohort's shared state will be stored by the virtual object manager in `vom.o+d12/1` as a JSON-serialized record. The keys of this record are property names: if the Kind uses `state.prop1`, the record will have a key named `prop1`. For each property, the value is a `{ body: string, slots: any[] }` capdata record with string-valued slot items (and unlike the treatment of capdata in many other parts of the system, it is not serialized independently of the enclosing structure).
-
-* `v6.vs.vom.o+d12/1` : `{"booleanProp":{"body":"true","slots":[]},"arrayProp":{"body":"[]","slots":[]}}`
-
-In the refcounting portion of the vatstore (`vom.rc.${baseref}`), you will see baserefs:
-
-* `v6.vs.vom.rc.o+10`: the count of virtualized references to plain Remotable `o+10` (held in RAM)
-* `v6.vs.vom.rc.o+d12/1`: the count of references to any member of the cohort for the first instance of durable Kind `o+d12`
-  * This Kind might be single-facet or multi-facet.
-  * References to distinct facets of the same cohort are counted independently. For example, if one object references both the first and second facets (`o+d12/1:0` and `o+d12/1:1`), it accounts for two increments to this value.
-
-In the export-status portion of the vatstore (`vom.es.${baseref}`), you will see baserefs, and any facets are tracked in the value, not the key:
-
-* `v6.vs.vom.es.o+10` records the export status for plain Remotable `o+10`
-  * value `r`: the plain Remotable has been exported and is "reachable" by the kernel
-  * value `s`: the Remotable was exported, the kernel dropped it, and is still "recognizable" by the kernel ("s" for "see", refer to [Garbage Collection in SwingSet](../../SwingSet/docs/garbage-collection.md) for details)
-  * If the kernel can neither reach nor recognize the export, the vatstore key will be missing entirely.
-* `v6.vs.vom.es.o+d12/1` records the export status for all facets of the durable object whose vref is `o+d12/1` (i.e., the first instance of durable Kind `o+d12`)
-  * If the Kind is single-facet, the value will be the same as for a plain Remotable: a single `r` or `s` character
-  * If the Kind is multi-facet, the value will be a string with one letter for each facet, in the same order as their Facet ID. `n` is used to indicate neither reachable nor recognizable. For example, a value of `rsnr` means there are four facets, the first (`o+d12/1:0`) and last (`o+d12/1:3`) are reachable, the second (`o+d12/1:1`) is recognizable, and the third (`o+d12/1:2`) is neither.
-
-
-# Durable Kinds
-
-Virtual objects are held on disk, which makes them suitable for high-cardinality data that is likely too large for our vat workers' limited RAM budget: many objects, most of which are "idle" at any given time. However virtual objects do not survive a vat upgrade. For this, vats should define one or more "Durable Kinds" instead.
-
-Durable Kinds are defined just like virtual Kinds, but they use a different constructor (`defineDurableKind` instead of `defineKind`), which requires a "handle" created by `makeKindHandle`. Durable virtual objects can only hold durable data in their `state`.
-
-The KindHandle is a durable virtual object of a special internal Kind. This is the first Kind allocated, so usually it gets exportID 1 to use as a Kind ID, and the kind handles for virtual and durable Kinds get vrefs like `o+d1/${kindHandleID}`.
-
-
-# Kind Metadata
-
-For each virtual object kind that is defined, we store a metadata record for purposes of scanning directly through the defined kinds when a vat is stopped or upgraded. For durable kinds this record is stored in `vom.dkind.${kindID}`; for non-durable kinds it is stored in `vom.vkind.${kindID}`. Currently this metadata takes the form of a JSON-serialized record with the following properties:
-* `kindID`, the kind ID as a numeric string (redundantly with the storage key)
-* `tag`, the tag string as provided in the `defineKind` or `makeKindHandle` call
-* `nextInstanceID`, an integer that is present only for durable kinds. It ensures that all versions share a single sequence of unique instance IDs. `nextInstanceID` is added to the metadata record upon allocation of the first instance of the kind and updated after each subsequent allocation.
-* `unfaceted`, a property with boolean value `true` that is present only for single-facet durable kinds.
-* `facets`, an array that is present only for multi-facet durable kinds. Its elements are the names of the kind's facets, in the same order as the assignment of facet indices within the cohort record.
-
-`unfaceted` and `facets` are required so that kind definitions in upgraded versions of the containing vat are maintained in a backwards compatible manner over time.
-
-# Virtual/Durable Collections (aka Stores)
-
-Liveslots provides vats with a handful of "virtual collection" types for storing high-cardinality data on disk rather than in RAM. Each instance of one of these types is described as a "[Store](../../store/docs/store-taxonomy.md)". They provide limited range queries and offer a single fixed sort index: numbers sort as usual, BigInts sort as usual but separate from numbers, strings sort lexicographically by UTF-8 encoding, and object references sort by insertion order.
-
-Collections are created by functions on the `VatStore` global:
-
-* `makeScalarBigMapStore`
-* `makeScalarBigWeakMapStore`
-* `makeScalarBigSetStore`
-* `makeScalarBigWeakSetStore`
-
-Each function accepts a boolean `durable` option, so there are currently 8 collection types.
-
-Each collection type is assigned a Kind index, just like the user-defined Kinds. The 8 collection types are allocated before userspace gets a chance to call `defineKind` or `defineDurableKind`, so they claim earlier exportID numbers as described [above](#counters).
-
-These index values are stored in `storeKindIDTable`, as a mapping from the collection type name ("scalarMapStore", "scalarDurableMapStore", "scalarWeakSetStore", etc.) to the integer of their ID. The current table assignments are:
-
-* `v6.vs.storeKindIDTable` : `{"scalarMapStore":2,"scalarWeakMapStore":3,"scalarSetStore":4,"scalarWeakSetStore":5,"scalarDurableMapStore":6,"scalarDurableWeakMapStore":7,"scalarDurableSetStore":8,"scalarDurableWeakSetStore":9}`
-
-which means `2` is the Kind ID for non-durable merely-virtual "scalarMapStore", instances of which will have vrefs like `o+v2/${collectionID}`.
-
-Each new store, regardless of type, is allocated the next available collectionID [counter](#counters). This is an incrementing integer that starts at 1, and forms a numberspace independent of the exportID counter used by exported Remotables and Kind IDs. The same collectionID numberspace is shared by all collection types. So unlike virtual objects (where the instanceID in `o+v${kindID}/${instanceID}` is scoped to `o+v${kindID}`), for collections the collectionID in `o+v${collectionType}/${collectionID}` is global to the entire vat. No two stores will have the same collectionID, even if they are of different types.
-
-The interpretation of a vref therefore varies based on whether the initial "type" portion before a slash (`o+v${exportID}` or `o+d${exportID}`) identifies a collection type or a virtual object kind:
-
-* `o+d6/1`: `6` is a collection type in the storeKindIDTable ("scalarDurableMapStore"), so `o+d6/1` refers to the first collection (of any type) in the vat
-* `o+d7/1`: `7` is also a collection type in the storeKindIDTable ("scalarDurableWeakMapStore"), so `o+d7/1` is guaranteed not to coexist with `o+d6/1`
-* `o+d7/2`: refers to the second collection (of any type) in the vat, which has type `7` ("scalarDurableWeakMapStore")
-* `o+v5/3`: refers to the third collection (of any type) in the vat, which has type `5` ("scalarWeakSetStore")
-* `o+v5/4`: refers to the fourth collection (of any type) in the vat, also a scalarWeakSetStore
-* `o+v11/1`: `11` is not a collection type in the storeKindIDTable, so is instead a kind and `o+v11/1` refers to the first instance of that kind
-* `o+v11/2`: refers to the second instance of that kind
-
-
-# Baggage
-
-Most collections are created by userspace code, but to support vat upgrade, liveslots creates one special collection named "baggage". This is a `scalarDurableMapStore` that is passed into the third argument of `buildRootObject`.
-
-This object needs to be pre-generated because the second (and subsequent) versions of the vat will use it to reach all other durable objects from their predecessors, so v2 can remember things that were stored by v1. The most significant values of "baggage" are the KindHandles for durable Kinds made by v1. V2 will need these to call `defineDurableKind` and re-attach behavior for each one. Each version must re-attach behavior for *all* durable Kinds created by its predecessors.
-
-The above rules about kindID and collectionID allocation result in the baggage being associated with vref `o+d6/1`, indicating that it is a scalarDurableMapStore (`o+d6` is used for that collection type) and also that it is the first collection of any type allocated in the vat. This value is also stored under key `baggageID` (see `provideBaggage` in [collectionManager.js](./collectionManager.js)).
-* `v6.vs.baggageID` : `o+d6/1`
-
-If userspace version 1 starts `buildRootObject` by calling `makeScalarBigWeakSetStore()` and then three `makeScalarSetStore()`s, the collections are likely to be assigned `o+v5/2`, `o+v4/3`, `o+v4/4`, and `o+v4/5` respectively. Such collectionIDs start with `2` because `1` is claimed by baggage.
-
-
-# Collection Data Records
-
-We examine a vat which performs the following at startup:
-
-```js
-const initFoo = arg => ({ prop1: arg });
-const fooBehavior = {
-  getProp1: ({ state }) => state.prop1,
-};
-const makeFoo = VatData.defineKind('foo', initFoo, fooBehavior);
-const foo = makeFoo(1);
-const foo2 = makeFoo(2);
-const c1 = VatData.makeScalarBigMapStore('mylabel');
-c1.init('key1', foo);
-c1.init('key2', foo);
-c1.init('key3', foo);
-c1.init('key4', foo2);
-```
-
-Each collection stores a number of metadata keys in the vatstore, all with a prefix of `vc.${collectionID}.|` (note that the collection *type* is not a part of the key, only the collection *index*). The currently defined metadata keys (copied from the record for the "mylabel" Kind stored in `c1`) are:
-
-* `v6.vs.vc.2.|entryCount`: `4` (the size of the collection as a numeric string, incremented with each call to `c1.init` and decremented with each call to `c1.delete`)
-* `v6.vs.vc.2.|nextOrdinal`: `1` (a numeric string counter used to allocate index values for Objects used as keys, see `generateOrdinal` in [collectionManager.js](./collectionManager.js))
-* `v6.vs.vc.2.|schemata`: `{"label":"mylabel","body":"#[{\\"#tag\\":\\"match:scalar\\",\\"payload\\":\\"#undefined\\"}]","slots":[]}`
-
-The `schemata` is a capdata serialization of the debugging label provided in the `make*Store` call that created the collection, plus the Matcher constraints recorded for the collection. These constraints can limit keys to be just strings, or numbers, etc. (see [Patterns](https://github.com/endojs/endo/tree/master/packages/patterns)). The schemata consists of an array in which the first element is a schema for the keys and the second is a separate schema for the values.
-
-Each entry in the collection gets put into a single vatstore entry with a capdata-serialized value:
-
-* `v6.vs.vc.2.skey1`: `{"body":"#\"$0.Alleged: foo\"","slots":["o+d9/1"]}`
-* `v6.vs.vc.2.skey2`: `{"body":"#\"$0.Alleged: foo\"","slots":["o+d9/1"]}`
-* `v6.vs.vc.2.skey3`: `{"body":"#\"$0.Alleged: foo\"","slots":["o+d9/1"]}`
-* `v6.vs.vc.2.skey4`: `{"body":"#\"$0.Alleged: foo\"","slots":["o+d9/2"]}`
-
-The key string for each entry (e.g. `skey1`) is formed by serializing the key object. Strings get a simple `s` prefix. Other objects use more complex encodings, designed to allow numbers (floats and BigInts, separately) to sort numerically despite the kvStore keys sorting lexicographically. See Endo [encodePassable.js](https://github.com/endojs/endo/blob/master/packages/marshal/src/encodePassable.js) for details. Object references involve an additional kvStore entry, to manage the mapping from Object to ordinal and back.
-
-For weak stores, the collection manager also maintains inbound-reference database keys of the form `vom.ir.${vref}|${collectionID}`, where in this case `${vref}` is the vref of a virtual object, store, import, or remotable, and `${collectionID}` is the collectionID of a weak store in which the given vref is used as a key. This enables the collection manager to locate and remove collection entries whose keys are being garbage collected. Note that mere presence or absence of such a key in the database is significant but the value associated with it is not.

package/src/virtualObjectManager.d.ts

@@ -1,44 +0,0 @@
-export function makeVirtualObjectManager(syscall: any, vrm: import("./virtualReferences.js").VirtualReferenceManager, allocateExportID: () => number, getSlotForVal: (val: object) => string | undefined, requiredValForSlot: (slot: string) => object, registerValue: any, serialize: ToCapData<string>, unserialize: FromCapData<string>, assertAcceptableSyscallCapdataSize: any, liveSlotsOptions?: import("./types.js").LiveSlotsOptions, { WeakMap, WeakSet }?: {
-    WeakMap: typeof globalThis.WeakMap;
-    WeakSet: typeof globalThis.WeakSet;
-}): {
-    initializeKindHandleKind: () => void;
-    defineKind: <P extends Array<any>, S, F>(tag: string, init: (...args: P) => S, facet: F, options?: DefineKindOptions<import("@agoric/swingset-liveslots").KindContext<S, F>>) => (...args: P) => import("@agoric/swingset-liveslots").KindFacet<F>;
-    defineKindMulti: <P extends Array<any>, S, B>(tag: string, init: (...args: P) => S, behavior: B, options?: DefineKindOptions<import("@agoric/swingset-liveslots").MultiKindContext<S, B>>) => (...args: P) => import("@agoric/swingset-liveslots").KindFacets<B>;
-    defineDurableKind: <P extends Array<any>, S, F>(kindHandle: DurableKindHandle, init: (...args: P) => S, facet: F, options?: DefineKindOptions<import("@agoric/swingset-liveslots").KindContext<S, F>>) => (...args: P) => import("@agoric/swingset-liveslots").KindFacet<F>;
-    defineDurableKindMulti: <P extends Array<any>, S, B>(kindHandle: DurableKindHandle, init: (...args: P) => S, behavior: B, options?: DefineKindOptions<import("@agoric/swingset-liveslots").MultiKindContext<S, B>>) => (...args: P) => import("@agoric/swingset-liveslots").KindFacets<B>;
-    makeKindHandle: (tag: string) => DurableKindHandle;
-    insistAllDurableKindsReconnected: () => void;
-    VirtualObjectAwareWeakMap: {
-        new (): {
-            has(key: any): any;
-            get(key: any): any;
-            set(key: any, value: any): /*elided*/ any;
-            delete(key: any): any;
-        };
-    };
-    VirtualObjectAwareWeakSet: {
-        new (): {
-            has(value: any): any;
-            add(value: any): /*elided*/ any;
-            delete(value: any): any;
-        };
-    };
-    flushStateCache: () => void;
-    getRetentionStats: () => {
-        definedDurableKinds: number;
-        nextInstanceIDs: number;
-    };
-    testHooks: {
-        countWeakKeysForCollection: (collection: any) => any;
-        definedDurableKinds: Set<any>;
-        nextInstanceIDs: Map<any, any>;
-    };
-    canBeDurable: (specimen: any) => boolean;
-};
-export type VirtualObjectManager = ReturnType<typeof makeVirtualObjectManager>;
-import type { ToCapData } from '@endo/marshal';
-import type { FromCapData } from '@endo/marshal';
-import type { DefineKindOptions } from '@agoric/swingset-liveslots';
-import type { DurableKindHandle } from '@agoric/swingset-liveslots';
-//# sourceMappingURL=virtualObjectManager.d.ts.map

package/src/virtualObjectManager.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"virtualObjectManager.d.ts","sourceRoot":"","sources":["virtualObjectManager.js"],"names":[],"mappings":"AA2TO,kDApDI,GAAC,OACD,OAAO,wBAAwB,EAAE,uBAAuB,oBAExD,MAAM,MAAM,iBAEZ,CAAC,GAAG,EAAE,MAAM,KAAK,MAAM,GAAG,SAAS,sBAGnC,CAAC,IAAI,EAAE,MAAM,KAAK,MAAM,iBACxB,GAAC,aAED,UAAU,MAAM,CAAC,eACjB,YAAY,MAAM,CAAC,sCACnB,GAAC,qBAED,OAAO,YAAY,EAAE,gBAAgB,yBACrC;IAAE,OAAO,EAAE,yBAAc,CAAC;IAAC,OAAO,EAAE,yBAAc,CAAA;CAAE;;iEAnItC,GAAG,kHAC0B,GAAG;sEAGjB,GAAG,0HAE1B,GAAG;0FAKc,GAAG,kHAEpB,GAAG;+FAIX,GAAG,0HACiB,GAAG;0BAsiCnB,MAAM,KACJ,iBAAiB;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAqI/B;mCAEa,UAAU,CAAC,OAAO,wBAAwB,CAAC;+BA/zChB,eAAe;iCAAf,eAAe;uCAFpB,4BAA4B;uCAD5B,4BAA4B"}

package/src/virtualReferences.d.ts

@@ -1,61 +0,0 @@
-/**
- * @param {*} syscall  Vat's syscall object, used to access the vatstore operations.
- * @param {(val: object) => string | undefined} getSlotForVal  A function that returns the
- *   object ID (vref) for a given object, if any.  their corresponding export
- *   IDs
- * @param {(slot: string) => object} requiredValForSlot  A function that
- *   converts an object ID (vref) to an object.
- * @param {*} FinalizationRegistry  Powerful JavaScript intrinsic normally denied
- *   by SES
- * @param {*} WeakRef  Powerful JavaScript intrinsic normally denied
- *   by SES
- * @param {*} addToPossiblyDeadSet  Function to record objects whose deaths
- *   should be reinvestigated
- * @param {*} addToPossiblyRetiredSet  Function to record dead objects whose
- *   retirement should be reinvestigated
- * @param {boolean} relaxDurabilityRules True IFF the associated swingset is
- *   running with relaxed durability rules
- */
-export function makeVirtualReferenceManager(syscall: any, getSlotForVal: (val: object) => string | undefined, requiredValForSlot: (slot: string) => object, FinalizationRegistry: any, WeakRef: any, addToPossiblyDeadSet: any, addToPossiblyRetiredSet: any, relaxDurabilityRules: boolean): {
-    registerDroppedCollection: (target: any, descriptor: any) => void;
-    isDurable: (vref: string) => boolean;
-    isDurableKind: (kindID: string) => boolean;
-    registerKind: (kindID: string, reanimator?: (string: any, boolean: any) => object, deleter?: (string: any) => boolean, durable?: boolean) => void;
-    rememberFacetNames: (kindID: string, facetNames: string[] | null) => void;
-    getFacet: (kindID: any, facets: any, facetIndex: any) => any;
-    getFacetNames: (kindID: any) => any;
-    reanimate: (baseRef: string) => any;
-    addReachableVref: (vref: any) => void;
-    removeReachableVref: (vref: any) => boolean;
-    updateReferenceCounts: (beforeSlots: any, afterSlots: any) => void;
-    getReachablePromiseRefCount: (p: any) => number;
-    addRecognizableValue: (value: any, recognizer: string | (Map<string, any> | Set<string>), recognizerIsVirtual?: boolean) => void;
-    removeRecognizableVref: (vref: string, recognizer: string | (Map<string, any> | Set<string>), recognizerIsVirtual?: boolean) => void;
-    removeRecognizableValue: (value: any, recognizer: string | (Map<string, any> | Set<string>), recognizerIsVirtual?: boolean) => void;
-    vrefKey: (value: any) => string | undefined;
-    isPresenceReachable: (vref: string) => boolean;
-    isVrefRecognizable: (vref: any) => boolean;
-    setExportStatus: (vref: any, exportStatus: any) => void;
-    isVirtualObjectReachable: (baseRef: string) => boolean;
-    deleteVirtualObject: (baseRef: string) => [boolean, string[]];
-    ceaseRecognition: (vref: string) => boolean;
-    setDeleteCollectionEntry: (fn: any) => void;
-    getRetentionStats: () => {
-        remotableRefCounts: number;
-        vrefRecognizers: number;
-        kindInfoTable: number;
-    };
-    initializeIDCounters: () => void;
-    allocateNextID: (name: any) => number;
-    flushIDCounters: () => void;
-    testHooks: {
-        getReachableRefCount: (vref: any) => number | undefined;
-        countCollectionsForWeakKey: (vref: any) => number;
-        getDroppedCollectionRegistry: () => any;
-        remotableRefCounts: Map<any, number>;
-        vrefRecognizers: Map<string, Set<Map<string, any> | Set<string>>>;
-        kindInfoTable: Map<any, any>;
-    };
-};
-export type VirtualReferenceManager = ReturnType<typeof makeVirtualReferenceManager>;
-//# sourceMappingURL=virtualReferences.d.ts.map

package/src/virtualReferences.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"virtualReferences.d.ts","sourceRoot":"","sources":["virtualReferences.js"],"names":[],"mappings":"AAUA;;;;;;;;;;;;;;;;;GAiBG;AACH,qDAjBW,GAAC,iBACD,CAAC,GAAG,EAAE,MAAM,KAAK,MAAM,GAAG,SAAS,sBAGnC,CAAC,IAAI,EAAE,MAAM,KAAK,MAAM,wBAExB,GAAC,WAED,GAAC,wBAED,GAAC,2BAED,GAAC,wBAED,OAAO;;sBAqQL,MAAM,KAEJ,OAAO;4BAfT,MAAM,KAEJ,OAAO;2BA9CT,MAAM,eACN,CAAC,MAAM,KAAA,EAAE,OAAO,KAAA,KAAK,MAAM,YAC3B,CAAC,MAAM,KAAA,KAAK,OAAO,YACnB,OAAO;iCASP,MAAM,cACN,MAAM,EAAE,GAAC,IAAI;;;yBA8Eb,MAAM;;;;;kCAmPN,GAAC,cACD,MAAM,mCAAW,wBACjB,OAAO;mCA2BP,MAAM,cACN,MAAM,mCAAW,wBACjB,OAAO;qCAgCP,GAAC,cACD,MAAM,mCAAW,wBACjB,OAAO;;gCAvIP,MAAM,KAEJ,OAAO;;;wCAzaT,MAAM,KAEJ,OAAO;mCAoBT,MAAM,KAEJ,CAAC,OAAO,EAAE,MAAM,EAAE,CAAC;6BAwiBrB,MAAM,KAEJ,OAAO;;;;;;;;;;;;;;;;;;EA+LrB;sCACa,UAAU,CAAC,OAAO,2BAA2B,CAAC"}

package/src/vpid-tracking.md

@@ -1,92 +0,0 @@
-# Promise/VPID Management in Liveslots
-
-Kernels and vats communicate about promises by referring to their VPIDs: vat(-centric) promise IDs. These are strings like `p+12` and `p-23`. Like VOIDs (object IDs), the plus/minus sign indicates which side of the boundary allocated the number (`p+12` and `o+12` are allocated by the vat, `p-13` and `o-13` are allocated by the kernel). But where the object ID sign also indicates which side "owns" the object (i.e. where the behavior lives), the promise ID sign is generally irrelevant.
-
-Instead, we care about which side holds the resolution authority for a promise (referred to as being its **decider**). This is not indicated by the VPID sign, and in fact is not necessarily static. Liveslots does not currently have any mechanism to allow one promise to be forwarded to another, but if it acquires this some day, then the decider of a promise could shift from kernel to vat to kernel again before it finally gets resolved. And there *are* sequences that allow a vat to receive a reference to a promise in method arguments before receiving a message whose result promise uses that same VPID (e.g., `p1 = p2~.foo(); x~.bar(p1)`, then someone resolves `p2` to `x`. Consider also tildot-free code like `{ promise: p1, resolve: resolveP1 } = makePromiseKit(); p2 = E(p1).push('queued'); await E(observer).push(p2); resolveP1(observer);` with an observer whose `push` returns a prompt response). In such cases, the decider is initially the kernel but that authority is transferred to a vat later.
-
-Each Promise starts out in the "unresolved" state, then later transitions irrevocably to the "resolved" state. Liveslots frequently (but not always) pays attention to this transition by calling `then` to attach fulfillment/rejection settlement callbacks. To handle resolution cycles, liveslots remembers the resolution of old promises in a `WeakMap` for as long as the Promise exists. Consequently, for liveslots' purposes, every Promise is either resolved (a callback has fired and liveslots remembers the settlement), or unresolved (liveslots has not yet seen a resolution that settles it).
-
-There are roughly four ways that liveslots might become aware of a promise:
-
-* serialization: a Promise instance is serialized, either for the arguments of an outbound `syscall.send` or `syscall.resolve`, the argument of `watchPromise()`, or to be stored into virtualized data (e.g. `bigMapStore.set(key, promise)`, or assignment to a property of a virtual object)
-* creation for outbound result: liveslots allocates a VPID for the `result` of an outbound `syscall.send`, and creates a new Promise instance to give back to userspace
-* deserialization: the arguments of an inbound `dispatch.deliver` or `dispatch.notify` are deserialized, and a new Promise instance is created
-* inbound result: the kernel-allocated `result` VPID of an inbound `dispatch.deliver` is associated with the Promise we get back from `HandledPromise.applyMethod`
-
-A Promise may be associated with a VPID even though the kernel does not know about it (i.e. the VPID is not in the kernel's c-list for that vat). This can occur when a Promise is stored into virtual data without also being sent to (or received from) the kernel, although note that every Promise associated with a durable promise watcher _is_ sent to the kernel so it can be rejected during vat upgrade. A Promise can also be resolved but still referenced in vdata and forgotten by the kernel (the kernel's knowledge is temporary; it retires VPIDs from c-lists upon `syscall.resolve` or `dispatch.notify` as appropriate). So a VPID might start out stored only in vdata, then get sent to the kernel, then get resolved, leaving it solely in vdata once more.
-
-Each unresolved VPID has a decider: either the kernel or a vat. It can remain unresolved for arbitrarily long, but becomes resolved by the first of the following events:
-
-* if liveslots learns about local resolution of the corresponding Promise by userspace, then liveslots will perform a `syscall.resolve()` (prompting 'notify' deliveries to other subscribed vats)
-* if liveslots learns about resolution by inbound notify, then liveslots will unregister it as necessary and inform userspace of the resolution
-* if the vat is terminated, the kernel internally rejects all remaining vat-decided KPIDs without involving the vat
-* if the vat is upgraded, each of those terminate-associated rejections is followed by a 'notify' delivery to the new incarnation
-
-Liveslots tracks promises in the following data structures:
-
-* `slotToVal` / `valToSlot` : these manage *registration*, the mapping from VPID to Promise and vice versa. These also register objects (Presences, Remotables, and Representatives) to/from VOIDs, and device nodes.
-  * to support GC of objects, `slotToVal.get(vref)` is a WeakRef, and `valToSlot` is a WeakMap
-  * liveslots uses independent strong references to maintain object/promise lifetimes
-* `exportedVPIDs`: a `Map<VPID, Promise>`: all Promises currently known to the kernel and decided by the vat
-* `importedVPIDs`: a `Map<VPID, PromiseKit>`: all Promises currently known to the kernel and decided by the kernel
-* `remotableRefCounts`: a `Map<Object|Promise, Number>`: all Promises (and Remotables) referenced by virtual data
-
-The kernel's c-list for a vat contains all VPIDs in `exportedVPIDs` and `importedVPIDs`. The vat is the decider for `exportedVPIDs`, while the kernel is the decider for `importedVPIDs`. For every VPID in `exportedVPIDs`, we've used `then` on the Promise instance to arrange for a `syscall.resolve` when it settles (becomes fulfilled or rejected). For every VPID key of the `importedVPIDs` Map, the corresponding value is a `[resolve, reject]` "**pRec**", so one of the functions can be called during `dispatch.notify`. Every VPID in `slotToVal` is either in `exportedVPIDs` but not `importedVPIDs`, `importedVPIDs` but not `exportedVPIDs`, or neither.
-
-If a VPID in `importedVPIDs` is resolved (by the kernel, via `dispatch.notify`), the VPID is removed from `importedVPIDs`. If a VPID in `exportedVPIDs` is resolved (by the vat, i.e. liveslots observes invocation of a previously-added settlement callback), liveslots invokes `syscall.resolve` and removes the VPID from `exportedVPIDs`. The c-list for a vat will not contain a VPID for any resolved promise.
-
-The `slotToVal`/`valToSlot` registration must remain until all of the following are true:
-
-* the kernel is no longer aware of the VPID
-* the Promise is not present in any virtual data
-* the promise is not being watched by a `promiseWatcher`.
-
-If the registration were to be lost while any of the above conditions were still true, a replacement Promise might be created while the original was still around, causing confusion.
-
-## Maintaining Strong References
-
-Remember that the `slotToVal` registration uses a WeakRef, so being registered there does not keep the Promise object alive.
- 
-`exportedVPIDs` and `importedVPIDs` keep their Promise alive in their value. vdata keeps it alive through the key of `remotableRefCounts`. `promiseWatcher` uses an internal `ScalarBigMapStore` to keep the Promise alive.
-
-## Promise/VPID Management Algorithm
-
-* When a Promise is first serialized (it appears in `convertValToSlot`), a VPID is assigned and the VPID/Promise mapping is registered in `valToSlot`/`slotToVal`
-  * at this point, there is not yet a strong reference to the Promise
-* When a VPID appears in the serialized arguments of `syscall.send` or `syscall.resolve`:
-  * if the VPID already exists in `exportedVPIDs` or `importedVPIDs`: do nothing
-  * else: use `followForKernel` to add the VPID to `exportedVPIDs` and attach `.then(onFulfill, onReject)` callbacks that will map fulfillment/rejection to `syscall.resolve()`
-* When a `followForKernel` settlement callback is executed:
-  * do `syscall.resolve()`
-  * remove from `exportedVPIDs`
-  * if `remotableRefCounts` reports 0 references: unregister from `valToSlot`/`slotToVal`
-* When the kernel delivers a `dispatch.notify`:
-  * retrieve the `[resolve, reject]` pRec from `importedVPIDs`
-  * invoke the appropriate function with the deserialized argument
-  * if `remotableRefCounts` reports 0 references: unregister from `valToSlot`/`slotToVal`
-* When the vdata refcount for a VPID drops to zero:
-  * if the VPID still exists in `exportedVPIDs` or `importedVPIDs`: do nothing
-  * else: unregister from `valToSlot`/`slotToVal`
-* When a new VPID is deserialized (it appears in `convertSlotToVal`), this must be the arguments of a delivery (not vdata)
-  * use `makePipelinablePromise` to create a HandledPromise for the VPID
-  * add the Promise and its `resolve`/`reject` pair to `importedVPIDs`
-  * register the Promise in `valToSlot`/`slotToVal`
-  * use `syscall.subscribe` to request a `dispatch.notify` delivery when the kernel resolves this promise
-* When a VPID appears as the `result` of an outbound `syscall.send`: (_note overlap with the preceding_)
-  * use `allocateVPID` to allocate a new VPID
-  * use `makePipelinablePromise` to create a HandledPromise for the VPID
-  * add the Promise and its `resolve`/`reject` pair to `importedVPIDs`
-  * register the Promise in `valToSlot`/`slotToVal`
-  * use `syscall.subscribe` to request a `dispatch.notify` delivery when the kernel resolves this promise
-* When a VPID appears as the `result` of an inbound `dispatch.deliver`, the vat is responsible for deciding it:
-  * construct a promise `res` to capture the userspace-provided result
-  * if the VPID is present in `importedVPIDs`: retrieve the `[resolve, reject]` pRec and use `resolve(res)` to forward eventual settlement of `res` to settlement of the previously-imported promise, then remove the VPID from `importedVPIDs`
-  * else: register marshaller association between the VPID and `res`
-  * in either case, use `followForKernel` to add the VPID to `exportedVPIDs` and attach `.then(onFulfill, onReject)` callbacks that will map fulfillment/rejection to `syscall.resolve()`
-
-
-If the serialization is for storage in virtual data, the act of storing the VPID will add the Promise to `remotableRefCounts`, which maintains a strong reference for as long as the VPID is held. When it is removed from virtual data (or the object/collection is deleted), the refcount will be decremented. When the refcount drops to zero, we perform the `exportedVPIDs`/`importedVPIDs` check and then maybe unregister the promise.
-
-If the serialization is for the arguments of an outbound `syscall.send` or `syscall.resolve` (or `syscall.callNow`, or `syscall.exit`), the VPID will be added to `exportedVPIDs`.
-
-If the *un*serialization occurred when processing the arguments of an *in*bound `dispatch.deliver` or `dispatch.notify`, the VPID (and the "promise kit" trio of Promise, `resolve`, and `reject`) will be stored in `importedVPIDs`.

package/src/watchedPromises.d.ts

@@ -1,31 +0,0 @@
-/**
- * @template V
- * @template {any[]} [A=unknown[]]
- * @typedef {[watcher: import('./types.js').PromiseWatcher<V, A>, ...args: A]} PromiseWatcherTuple
- */
-/**
- * @param {object} options
- * @param {*} options.syscall
- * @param {import('./virtualReferences.js').VirtualReferenceManager} options.vrm
- * @param {import('./virtualObjectManager.js').VirtualObjectManager} options.vom
- * @param {*} options.collectionManager
- * @param {import('@endo/marshal').ConvertValToSlot<any>} options.convertValToSlot
- * @param {import('@endo/marshal').ConvertSlotToVal<any>} options.convertSlotToVal
- * @param {(vref: any) => boolean} options.maybeExportPromise
- */
-export function makeWatchedPromiseManager({ syscall, vrm, vom, collectionManager, convertValToSlot, convertSlotToVal, maybeExportPromise, }: {
-    syscall: any;
-    vrm: import("./virtualReferences.js").VirtualReferenceManager;
-    vom: import("./virtualObjectManager.js").VirtualObjectManager;
-    collectionManager: any;
-    convertValToSlot: import("@endo/marshal").ConvertValToSlot<any>;
-    convertSlotToVal: import("@endo/marshal").ConvertSlotToVal<any>;
-    maybeExportPromise: (vref: any) => boolean;
-}): {
-    preparePromiseWatcherTables: () => void;
-    loadWatchedPromiseTable: (revivePromise: (vref: any) => Promise<any>) => void;
-    providePromiseWatcher: <V, A extends any[]>(kindHandle: import("./vatDataTypes.js").DurableKindHandle, fulfillHandler?: (value: V, ...args: A) => void, rejectHandler?: (reason: any, ...args: A) => void) => import("./types.js").PromiseWatcher<V, A>;
-    watchPromise: <P extends Promise<any>, A extends any[]>(p: P, watcher: import("./types.js").PromiseWatcher<Awaited<P>, A>, ...args: A) => void;
-};
-export type PromiseWatcherTuple<V, A extends any[] = unknown[]> = [watcher: import("./types.js").PromiseWatcher<V, A>, ...args: A];
-//# sourceMappingURL=watchedPromises.d.ts.map

package/src/watchedPromises.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"watchedPromises.d.ts","sourceRoot":"","sources":["watchedPromises.js"],"names":[],"mappings":"AASA;;;;GAIG;AAEH;;;;;;;;;GASG;AACH,6IARG;IAAmB,OAAO,EAAlB,GAAC;IACiE,GAAG,EAArE,OAAO,wBAAwB,EAAE,uBAAuB;IACU,GAAG,EAArE,OAAO,2BAA2B,EAAE,oBAAoB;IAC7C,iBAAiB,EAA5B,GAAC;IACsD,gBAAgB,EAAvE,OAAO,eAAe,EAAE,gBAAgB,CAAC,GAAG,CAAC;IACU,gBAAgB,EAAvE,OAAO,eAAe,EAAE,gBAAgB,CAAC,GAAG,CAAC;IACb,kBAAkB,EAAlD,CAAC,IAAI,EAAE,GAAG,KAAK,OAAO;CAChC;;6CAgHY,CAAC,IAAI,EAAE,GAAG,KAAK,OAAO,CAAC,GAAG,CAAC,KACzB,IAAI;4BAiBJ,CAAC,EACO,CAAC,SAAR,GAAG,EAAG,cACT,OAAO,mBAAmB,EAAE,iBAAiB,mBAC7C,CAAC,KAAK,EAAE,CAAC,EAAE,GAAG,IAAI,EAAE,CAAC,KAAK,IAAI,kBAC9B,CAAC,MAAM,EAAE,GAAG,EAAE,GAAG,IAAI,EAAE,CAAC,KAAK,IAAI,KAC/B,OAAO,YAAY,EAAE,cAAc,CAAC,CAAC,EAAE,CAAC,CAAC;mBAmC3C,CAAC,SAAS,OAAO,CAAC,GAAG,CAAC,EAAE,CAAC,SAAS,GAAG,EAAE,KAAK,CAAC,WAAW,OAAO,YAAY,EAAE,cAAc,CAAC,OAAO,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,WAAW,CAAC,KAAK,IAAI;EAsE3I;gCA9PY,CAAC,EACQ,CAAC,SAAT,GAAG,EAAG,gBACP,CAAC,OAAO,EAAE,OAAO,YAAY,EAAE,cAAc,CAAC,CAAC,EAAE,CAAC,CAAC,EAAE,GAAG,IAAI,EAAE,CAAC,CAAC"}

package/test/dummyMeterControl.d.ts

@@ -1,2 +0,0 @@
-export function makeDummyMeterControl(): import("../src/types.js").MeterControl;
-//# sourceMappingURL=dummyMeterControl.d.ts.map

package/test/dummyMeterControl.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"dummyMeterControl.d.ts","sourceRoot":"","sources":["dummyMeterControl.js"],"names":[],"mappings":"AAEA,gFAmDC"}

package/test/engine-gc.d.ts

@@ -1,3 +0,0 @@
-export default engineGC;
-declare const engineGC: GCFunction;
-//# sourceMappingURL=engine-gc.d.ts.map

package/test/engine-gc.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"engine-gc.d.ts","sourceRoot":"","sources":["engine-gc.js"],"names":[],"mappings":";AAoBA,mCAAwB"}

package/test/gc-and-finalize.d.ts

@@ -1,5 +0,0 @@
-export function makeGcAndFinalize(gcPower: any): () => Promise<void>;
-export function watchCollected(target: any): Promise<true> & {
-    result: boolean;
-};
-//# sourceMappingURL=gc-and-finalize.d.ts.map

package/test/gc-and-finalize.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"gc-and-finalize.d.ts","sourceRoot":"","sources":["gc-and-finalize.js"],"names":[],"mappings":"AAkEA,qEAwBC;AAwBD;YAbsD,OAAO;EAkB5D"}

package/test/liveslots-helpers.d.ts

@@ -1,63 +0,0 @@
-/**
- * @param {object} [options]
- * @param {boolean} [options.skipLogging]
- * @param {Map<string, string>} [options.kvStore]
- */
-export function buildSyscall(options?: {
-    skipLogging?: boolean | undefined;
-    kvStore?: Map<string, string> | undefined;
-}): {
-    syscall: {
-        send(targetSlot: any, methargs: any, resultSlot: any): void;
-        subscribe(target: any): void;
-        resolve(resolutions: any): void;
-        dropImports(slots: any): void;
-        retireImports(slots: any): void;
-        retireExports(slots: any): void;
-        exit(isFailure: any, info: any): void;
-        vatstoreGet(key: any): any;
-        vatstoreGetNextKey(priorKey: any): any;
-        vatstoreSet(key: any, value: any): void;
-        vatstoreDelete(key: any): void;
-    };
-    fakestore: Map<any, any>;
-    log: any[];
-};
-export function makeDispatch(syscall: any, build: any, vatID?: string, liveSlotsOptions?: {}, vatParameters?: undefined): Promise<{
-    dispatch: any;
-    testHooks: any;
-}>;
-/**
- * @param {import('ava').ExecutionContext} t
- * @param {Function} buildRootObject
- * @param {string} vatName
- * @param {object} [options]
- * @param {boolean} [options.forceGC]
- * @param {Map<string, string>} [options.kvStore]
- * @param {number} [options.nextPromiseImportNumber]
- * @param {boolean} [options.skipLogging]
- * @param {any} [options.vatParameters]
- */
-export function setupTestLiveslots(t: import("ava").ExecutionContext, buildRootObject: Function, vatName: string, options?: {
-    forceGC?: boolean | undefined;
-    kvStore?: Map<string, string> | undefined;
-    nextPromiseImportNumber?: number | undefined;
-    skipLogging?: boolean | undefined;
-    vatParameters?: any;
-}): Promise<{
-    v: {
-        t: import("ava").ExecutionContext<unknown>;
-        log: any[];
-        fakestore: Map<any, any>;
-        dumpFakestore: () => void;
-    };
-    dispatch: any;
-    dispatchMessage: (message: any, ...args: any[]) => Promise<string>;
-    dispatchMessageSuccessfully: (message: any, ...args: any[]) => Promise<any>;
-    dispatchDropExports: (...vrefs: any[]) => Promise<void>;
-    dispatchRetireExports: (...vrefs: any[]) => Promise<void>;
-    dispatchRetireImports: (...vrefs: any[]) => Promise<void>;
-    testHooks: any;
-}>;
-export function findSyscallsByType(log: any, type: any): any;
-//# sourceMappingURL=liveslots-helpers.d.ts.map

package/test/liveslots-helpers.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"liveslots-helpers.d.ts","sourceRoot":"","sources":["liveslots-helpers.js"],"names":[],"mappings":"AAgBA;;;;GAIG;AACH,uCAHG;IAA0B,WAAW;IACC,OAAO;CAAC;;;;;;;;;;;;;;;;EA2GhD;AAED;;;GA2BC;AAUD;;;;;;;;;;GAUG;AACH,sCAVW,OAAO,KAAK,EAAE,gBAAgB,sCAE9B,MAAM,YAEd;IAA0B,OAAO;IACK,OAAO;IACpB,uBAAuB;IACtB,WAAW;IACf,aAAa,GAA3B,GAAG;CAAyB;;;;;;;;;;;;;;GA4GtC;AAED,6DAEC"}

package/test/util.d.ts

@@ -1,25 +0,0 @@
-/**
- * @param {(d: unknown) => void} [onDispatchCallback ]
- */
-export function buildDispatch(onDispatchCallback?: (d: unknown) => void): {
-    log: any[];
-    dispatch: (vatDeliverObject: any) => void;
-};
-/**
- * @param {unknown} target
- * @param {string | symbol} method
- * @param {any[]} args
- * @param {unknown} result
- */
-export function makeMessage(target: unknown, method: string | symbol, args?: any[], result?: unknown): unknown[];
-export function makeStartVat(vatParameters: any): any[];
-export function makeBringOutYourDead(): string[];
-export function makeResolutions(resolutions: any): any[];
-export function makeResolve(target: any, result: any): any[];
-export function makeReject(target: any, result: any): (string | any[][])[];
-export function makeDropExports(...vrefs: any[]): (string | any[])[];
-export function makeRetireExports(...vrefs: any[]): (string | any[])[];
-export function makeRetireImports(...vrefs: any[]): (string | any[])[];
-export { vstr };
-import { vstr } from './vat-util.js';
-//# sourceMappingURL=util.d.ts.map

package/test/util.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"util.d.ts","sourceRoot":"","sources":["util.js"],"names":[],"mappings":"AAKA;;GAEG;AACH,mDAFW,CAAC,CAAC,EAAE,OAAO,KAAK,IAAI;;;EAwC9B;AAED;;;;;GAKG;AACH,oCALW,OAAO,UACP,MAAM,GAAG,MAAM,SACf,GAAG,EAAE,WACL,OAAO,aAOjB;AAED,wDAEC;AAED,iDAEC;AAED,yDAGC;AAED,6DAGC;AAED,2EAIC;AAED,qEAGC;AAED,uEAGC;AAED,uEAGC;;qBAjGoB,eAAe"}

package/test/vat-util.d.ts

@@ -1,9 +0,0 @@
-export function extractMessage(vatDeliverObject: any): {
-    facetID: any;
-    method: any;
-    args: import("@endo/marshal").CapData<string>;
-    result: any;
-};
-export function ignore(p: any): void;
-export function vstr(v: any): string;
-//# sourceMappingURL=vat-util.d.ts.map

package/test/vat-util.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"vat-util.d.ts","sourceRoot":"","sources":["vat-util.js"],"names":[],"mappings":"AAMA;;;;;EAQC;AAED,qCAKC;AAEM,qCAAyC"}

package/test/waitUntilQuiescent.d.ts

@@ -1,3 +0,0 @@
-/** @import {PromiseKit} from '@endo/promise-kit' */
-export function waitUntilQuiescent(): Promise<void>;
-//# sourceMappingURL=waitUntilQuiescent.d.ts.map

package/test/waitUntilQuiescent.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"waitUntilQuiescent.d.ts","sourceRoot":"","sources":["waitUntilQuiescent.js"],"names":[],"mappings":"AAGA,oDAAoD;AAKpD,oDAWC"}

package/tools/fakeCollectionManager.d.ts

@@ -1,14 +0,0 @@
-export function makeFakeCollectionManager(vrm: any, fakeStuff: any, _options?: {}): {
-    getValForSlot: any;
-    setValForSlot: any;
-    registerEntry: any;
-    deleteEntry: any;
-    dumpStore: any;
-    makeScalarBigMapStore: <K, V>(label?: string, options?: StoreOptions) => MapStore<K, V>;
-    makeScalarBigWeakMapStore: <K, V>(label?: string, options?: StoreOptions) => WeakMapStore<K, V>;
-    makeScalarBigSetStore: <K>(label?: string, options?: StoreOptions) => SetStore<K>;
-    makeScalarBigWeakSetStore: <K>(label?: string, options?: StoreOptions) => WeakSetStore<K>;
-    provideBaggage: () => any;
-    flushSchemaCache: () => void;
-};
-//# sourceMappingURL=fakeCollectionManager.d.ts.map