chore: Sync Endo 2025-07-11#11594
Conversation
Deploying agoric-sdk with
|
| Latest commit: |
b1a59fe
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://e3236950.agoric-sdk.pages.dev |
| Branch Preview URL: | https://kris-sync-endo-2025-07-12-05.agoric-sdk.pages.dev |
fc09c20 to
7cc43e4
Compare
a59c694 to
1f66a39
Compare
| // This test runs at the cusp of meter failure and is sensitive to changes to | ||
| // the underlying platform. | ||
| t.log( | ||
| 'adjust the remaining computrons figure if this test fails due to platform changes and run a benchmark to check the wallclock impact', |
There was a problem hiding this comment.
Nice! From this message, how would someone find out how to "run a benchmark to check the wallclock impact"?
There was a problem hiding this comment.
Going to have to ask in chat for now. The lore for this is too fresh to commit to ink. When we do, we’ll want to record it in MAINTAINERS.md with all else of the kind.
|
endojs/endo#1538 stopped exporting |
b426b32 to
b1a59fe
Compare
|
This pull request has been removed from the queue for the following reason: The pull request #11594 has been manually updated. If you want to requeue this pull request, you can post a |
|
@Mergifyio requeue |
✅ The queue state of this pull request has been cleaned. It can be re-embarked automatically |
@endo/immutable-arraybuffer1.1.2@endo/immutable-arraybufer/shim-hermes.jsand absorbs the necessary features into@endo/immutable-arraybuffer/shim.js. We are not qualifying this as a breaking change since the feature did not exist long enough to become relied upon.@endo/marshal1.8.0ENDO_RANK_STRINGSto change the rank ordering of strings from the current (incorrect) ordering by UTF-16 code unit used by JavaScript's<and.sort()operations to (correct and OCapN-conformant) ordering by Unicode code point. It currently defaults to "utf16-code-unit-order", matching the previously-unconditional behavior.@endo/pass-style1.6.3isObjectis ambiguous. It is unclear whether it includes functions or not. (It does.) To avoid this confusion, we're deprecatingisObjectand suggesting to use the new exportisPrimitiveinstead, that has the opposite answer. IOW, for allx,isObject(x) === !isPrimitive(x)@endo/patterns1.7.0@endo/marshalintroduces an environment variable config optionENDO_RANK_STRINGSto change the rank ordering of strings from the current (incorrect) ordering by UTF-16 code unit used by JavaScript's<and.sort()operations to (correct and OCapN-conformant) ordering by Unicode code point. It currently defaults to "utf16-code-unit-order", matching the previously-unconditional behavior.@endo/patternsprovides acompareKeyspartial order that delegates some ordering, including strings, to the rank ordering provided by@endo/marshal. So when theENDO_RANK_STRINGSdefault is not overridden, thencompareKeysalso follows the (incorrect) UTF-16 code unit order. But when it is overridden, thencompareKeysalso follows the (correct) Unicode code-point order.q, producing an uninformative rendering of these nested patterns. Now this quoting is done withqp, which renders these nested patterns into readable Justin source code.@endo/pass-style1.6.2ArrayBuffer.prototype.transferToImmutable.@endo/compartment-mapper1.6.2require.extensionsin CommonJS modules to increase ecosystem compatibility.@endo/immutable-arraybuffer1.1.1structuredCloneearly so that scuttling all properties ofglobalThisafter initializing@endo/immutable-arraybufferor@endo/immutable-arraybuffer/shim.jsdoes not interfere with this module's designed behavior.@endo/pass-stylev1.6.1BROKEN BUT PATCHED in 1.6.2, contains a fix but published with broken dependency versions. Inadvertently published without amending workspace protocol dependencies.
ArrayBuffer.prototype.transferToImmutableand recognizes immutable ArrayBuffers as having a pass-style ofbyteArrayon platforms have asliceToImmutable, even if that is emulated with a shim usingslice, even if they lacktransferToImmutable.