feat(HandledPromise): add unwrap method to allow sync access to presences

[michaelfig]

Closes #412

The new HandledPromise.unwrap(p) synchronously returns p if it is a presence, or the presence corresponding to the HandledPromise p that was fulfilled with resolveWithPresence.

If no synchronous presence can be found, unwrap throws a TypeError.

[michaelfig]

Renamed from antiResolve in Agoric/eventual-send#24

[erights]

LGTM

[michaelfig]

@dckc can you give any hints as to why the eventual-send xs test suite is failing?

[michaelfig]

@dckc can you give any hints as to why the eventual-send xs test suite is failing?

Specifically,

# cc eventual-send
**
GLib:ERROR:../../../../glib/ghash.c:377:g_hash_table_lookup_node: assertion failed: (hash_table->ref_count > 0)
/home/runner/work/_temp/b8a7edd6-dfb4-489e-9abb-e43ffb2efec0.sh: line 7:  3176 Aborted                 (core dumped) $MODDABLE/build/bin/lin/release/eventual-send
##[error]Process completed with exit code 134.

[dckc]

Those symptoms look vaguely familiar, but I don't recall the diagnosis nor treatment.

I moved away from running the eventual-send tests that way as of Jan 18
dckc@799d82a#diff-de1df6d3a0175ca0f98d344f02455a96

[michaelfig]

I moved away from running the eventual-send tests that way as of Jan 18

Would you be able to make (or point me to) a PR that does the eventual-send tests the new way? I will gladly merge those changes, and try this .unwrap PR again. I just want to make sure I'm not regressing with .unwrap.

[dckc]

Would you be able to make (or point me to) a PR that does the eventual-send tests the new way? I will gladly merge those changes, and try this .unwrap PR again.

I have dckc#1 but it's a monster at +4,429 −1,317 with code of varying quality. When I moved away from running the tests for the eventual-send package, I moved to running the tests for the SwingSet package, and the changes to get it to work were substantial.

I just want to make sure I'm not regressing with .unwrap.

To diagnose the failure, I would probably try a debug build. Where the automated build does mcconfig -m -p x-cli-lin test-xs-manifest.json, try mcconfig -m -p lin -d test-xs-manifest.json instead, while you have xsbug running. Failing that, gdb works the x-cli-lin executables as susual; sometimes it's even helpful on on non-debug builds.

Unfortunately, a hash table lookup failure can be far from the source of the problem where the hash table was put in a corrupted state in the first place.

Perhaps send me a calendar invite for a time when I can show you how I debug such things?

[michaelfig]

The failing xs test passes with the change in agoric-labs/tape-xs#4