hyperuuid-wasm 0.9.0 → 1.0.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 8b35d26b737a64df74f7a10783112899a0386bbd7dd7b7aa6387b4cbd5fb3c09
-  data.tar.gz: c37cd5f4d1bc6ad5eef8d181aa263ac61212c73f4f73640724f63e53a9797f61
+  metadata.gz: 23b7842046b78dff468073474bdb004a03c6d4710ff13a7ff3f048c879d141f9
+  data.tar.gz: 04204e9e6c775cb35a8370b53ffd8fc8c7538ad9220fffc5a05fc7e76c07ec7a
 SHA512:
-  metadata.gz: 1580f8edd7863896d8b646db61e5918aa7efcaa22db88995e2c6aa2d4456f8dd2698e1200e214191830b984aee8fcdd56f22f5da51985a48305401bf10b84201
-  data.tar.gz: e5a86147bafa4f1e9bfb266656e073f135286f07750dbb930cf6a8b10e9a3b45060e5a8daf73cd6c7162ee060a75f3e4f02c3a609c63fc8b94bbb26a0a46c653
+  metadata.gz: b1dd276963bf50735b2e9f7cd1be16dbeb7c7edebef8c027471cbaf6686237ef971b91f87f328a42650232b25e2bd5bd5d0cdb39309674fe2f5f743b58553a0d
+  data.tar.gz: 9e2ee0585a21dbdd3266ef635134e2013a09b3cb5538427a0b71df0e9126d4d9d3fbc7f8a0dc73f9b4ed5579c3f1c181e8d2de73b54e04c240b6e1eb8701637e

data/README.md

@@ -138,23 +138,20 @@ happens at most once per 2²⁶ UUIDs the process mints.
 
 ### Errors
 
-Two exceptions are this gem's own, and both carry the same message on every backend:
+Two exceptions describe a failed call, and both carry the same message on every backend:
 
 - `HyperUuid::TimestampOutOfRangeError` — the time cannot be embedded in a version 7: past
   its 48-bit millisecond field, or negative (a `Time` before the Unix epoch included).
 - `HyperUuid::RandomSourceError` — the operating system's random source failed.
 
-Through 0.3.0 these were reachable only as `HyperUuid::Runtime::TimestampOutOfRangeError` and
-`HyperUuid::Runtime::RandomSourceError`; those names remain, as aliases of the same classes.
-
 Everything else is a caller bug and raises Ruby's own error for it, checked once in the shared
 doors rather than left to whichever backend is live: a `TypeError` for a time that is not a
 `Time`, an Integer or `nil`, for a count that is not an Integer, for a namespace that is not a
 `Uuid` or a name that is not a `String`, for a version passed to `#rfc?` that is not an
-Integer; an `ArgumentError` for a count outside 0..`MAX_V7_BATCH`, for a layout other than
-`:rfc9562`/`:sql_server`, and for a batch too large for the platform to address (a 32-bit
-target such as ruby.wasm). The SQL Server conversions' one refusal (a value of the wrong
-version) comes from the core, as an `ArgumentError` worded the same on both backends.
+Integer; an `ArgumentError` for a count outside 0..`MAX_V7_BATCH` and for a layout other than
+`:rfc9562`/`:sql_server`. Two refusals come from the backend instead, each an `ArgumentError`
+worded the same on both: a batch too large for the platform to address (a 32-bit target such
+as ruby.wasm), and the SQL Server conversions' one refusal, a value of the wrong version.
 
 ### Is the native core there?
 
@@ -194,7 +191,7 @@ bytes = HyperUuid.new_v7_batch_bytes(1000)
 first = bytes[0, 16]        # ready for a BINARY(16) bind parameter
 ```
 
-**About 40x faster than `new_v7_batch`** for a 1000-UUID batch (4.9 µs versus 202 µs). The native call is identical — the difference is that `new_v7_batch` then allocates a `Uuid` object and its byte Strings for every item on top of it. This hands back the bytes the native core already produced, untouched.
+**About 41x faster than `new_v7_batch`** for a 1000-UUID batch (4.9 µs versus 202 µs). The native call is identical — the difference is that `new_v7_batch` then allocates a `Uuid` object and its byte Strings for every item on top of it. This hands back the bytes the native core already produced, untouched.
 
 The catch, and it inverts the advice: **if you need `Uuid` objects, keep using `new_v7_batch`.** Slicing these bytes into objects yourself just relocates the identical allocations into your own code, and measures no better — sometimes worse. Reach for the byte form only when bytes are the destination: a bind parameter, a wire format, a bulk load.
 
@@ -229,7 +226,7 @@ Batch generation still amortizes per-call cost on both backends — one native c
 | `new_v7` × 1000 (individual) | 3,742 |
 | `new_v7_batch(1000)` | 4,850 (**1.3x**) |
 
-The multiplier is small on this backend for the best reason available: the individual calls are cheap, so there is little waste left to amortize, and what `new_v7_batch` spends its 206 µs on is building a thousand `Uuid` objects — the byte form above does the same native work in 5 µs. On the Fiddle backend, where each call costs 1.4 µs, the same batch is 6.7x the loop. If you need v5/v7, need many at once, or need this Ruby service's IDs to agree byte-for-byte with a Go or Python service's, that's what this gem is for — and now it's the fast option too, not just the capable one.
+The multiplier is small on this backend for the best reason available: the individual calls are cheap, so there is little waste left to amortize, and what `new_v7_batch` spends its 206 µs on (in this table's run; 202 µs in the bytes-versus-objects run above) is building a thousand `Uuid` objects — the byte form above does the same native work in 4.9 µs. On the Fiddle backend, where each call costs 1.4 µs, the same batch is 6.7x the loop. If you need v5/v7, need many at once, or need this Ruby service's IDs to agree byte-for-byte with a Go or Python service's, that's what this gem is for — and now it's the fast option too, not just the capable one.
 
 ## Backends
 
@@ -256,34 +253,42 @@ backend where Ruby threads run the core truly in parallel — each through its o
 buffer, with the core's v7 counter shared and atomic. `spec/hyperuuid_spec.rb`'s "concurrent
 callers" examples run under both.
 
-**Ractors.** Main Ractor only, on every backend: called from another Ractor the doors raise
-`Ractor::UnsafeError`.
+**Ractors.** Main Ractor only, on every backend: called from another Ractor the doors raise a
+`Ractor::Error` (`Ractor::IsolationError`, or `Ractor::UnsafeError`, by door and backend).
 
 ## Verifying provenance
 
-Every gem RubyGems.org serves — the universal fallback, each of the seven precompiled
-platform gems and `hyperuuid-wasm` — carries its own GitHub build-provenance attestation, signed directly by
-this repo's own `release.yml` (the `rubygems-publish` job attests `ruby/pkg/*.gem` right
-before the push), so plain `--repo` verifies any of them:
+Every gem RubyGems.org serves — the universal fallback, each of the seven precompiled platform
+gems and `hyperuuid-wasm` — verifies from the release tag alone: the release attestation,
+signed by this repository's `release.yml` at the tag, names every one of them, with the
+release inventory as its predicate.
+
+```sh
+gem fetch hyperuuid -v <version> --platform <platform>   # or omit --platform for the universal gem
+gh attestation verify hyperuuid-<version>-<platform>.gem --repo SkunkWerkx/HyperUuid \
+  --source-ref refs/tags/v<version> --predicate-type https://github.com/SkunkWerkx/.github/predicates/release/v1
+```
+
+Each gem's build provenance is this repository's too: the `ruby-pack` job attests
+`ruby/pkg/*.gem` as soon as they are built and `rubygems-publish` pushes those preserved
+bytes, so plain `--repo` verifies it:
 
 ```sh
-gem fetch hyperuuid -v X.Y.Z --platform <platform>   # or omit --platform for the universal gem
-gh attestation verify hyperuuid-X.Y.Z-<platform>.gem --repo SkunkWerkx/HyperUuid
+gh attestation verify hyperuuid-<version>-<platform>.gem --repo SkunkWerkx/HyperUuid
 ```
 
-That's the release's second layer of checking, not the only one: before any gem gets built,
-the same job verifies every native binary it packs — the Fiddle libraries, the Magnus
-extensions (one per Ruby ABI per platform), the `wasm32-wasip1` archives — against *their own*
-attestations — those are signed from `SkunkWerkx/.github` by `hyper-build-native.yml` and
-`hyper-build-wasm.yml`, so
-that check needs `--signer-repo SkunkWerkx/.github` added — and refuses to proceed on an
-unverified one. RubyGems.org has no unpublish and no
-duplicate-version overwrite, so this all happens while a bad artifact is still reversible.
-The release run's job summary then re-fetches every gem from the CDN and records
-attested-vs-served digests, turning "rubygems.org stores an upload verbatim" into a
-per-release measurement rather than an assumption — see
-[csharp/README.md's provenance section](../csharp/README.md#native-binary-provenance) for
-more on why `--signer-repo` is needed for some artifacts here and not others.
+That is the release's second layer of checking, not the only one: before any gem is built, the
+same job verifies every native binary it packs — the Fiddle libraries, the Magnus extensions
+(one per Ruby ABI per platform), the `wasm32-wasip1` archives — against *their own* build
+provenance, signed from `SkunkWerkx/.github` by `hyper-build-native.yml` and
+`hyper-build-wasm.yml` (so that check needs `--signer-repo SkunkWerkx/.github` added), and
+refuses to proceed on an unverified one. RubyGems.org has no unpublish and no
+duplicate-version overwrite, so all of this happens while a bad artifact is still reversible,
+and the push itself is a separate dispatch from the preserved bytes. The release run then
+re-fetches every gem from rubygems.org and fails unless each matches the attested bytes
+exactly, turning "rubygems.org stores an upload verbatim" into a per-release check rather than
+an assumption. The root README's [Provenance](../README.md#provenance) section has the whole
+picture.
 
 ## Install
 
@@ -401,6 +406,12 @@ which read the clock through WASI.
 - **No Rust toolchain.** The gem's `extconf.rb` only hands rbwasm the prebuilt archive, and
   rbwasm downloads its own wasi-sdk. The first `rbwasm build` compiles Ruby itself and takes
   15–20 minutes; later builds reuse it.
+- **macOS with Homebrew: limit pkg-config to `openssl@3`.** Run the build as
+  `PKG_CONFIG_LIBDIR="$(brew --prefix openssl@3)/lib/pkgconfig" bundle exec rbwasm build …`.
+  Without it Homebrew's pkg-config files reach into the build twice: its `openssl` is OpenSSL
+  4, which the native Ruby rbwasm builds first does not compile against, and its `libyaml`
+  is a macOS library that psych then links into the wasm interpreter, which fails for Ruby
+  4.0.
 - **Static linking only,** into ruby.wasm's default `wasm32-unknown-wasip1` interpreter.
   rbwasm's dynamic-linking build (a pic target, for the component model) is not supported.
 - **Size.** rbwasm packs every gem's files into the interpreter, the archives included, so the

data/lib/hyperuuid/runtime.rb

@@ -15,13 +15,6 @@ module HyperUuid
   # A Ruby gem's files are plain files on disk once installed, so native/{rid}/{lib} can be
   # dlopen'd directly, with no extraction step.
   module Runtime
-    # The package's two exceptions live on HyperUuid itself (errors.rb). These are the names
-    # they had through 0.3.0, kept as aliases of the very same classes so a
-    # `rescue HyperUuid::Runtime::TimestampOutOfRangeError` written against an earlier
-    # release still catches.
-    RandomSourceError = HyperUuid::RandomSourceError
-    TimestampOutOfRangeError = HyperUuid::TimestampOutOfRangeError
-
     # One copy of the out-of-range message for the Fiddle backend and for the doors' own
     # range check in hyperuuid.rb; the Magnus extension (rust/src/ruby_ext.rs) carries the
     # same text, and spec/native_backend_spec.rb pins that the two agree.

data/lib/hyperuuid.rb

@@ -19,7 +19,7 @@ require_relative "hyperuuid/runtime"
 module HyperUuid
   # This gem's own version — distinct from the RFC 9562 UUID *versions* (v4/v5/v7) the rest
   # of this module generates.
-  VERSION = "0.9.0"
+  VERSION = "1.0.0"
 
   # The widest batch count, and the longest v5 name in bytes, the native ABI carries (a u32).
   # (The millisecond count is a u64; unix_millis_from refuses anything wider.)

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: hyperuuid-wasm
 version: !ruby/object:Gem::Version
-  version: 0.9.0
+  version: 1.0.0
 platform: ruby
 authors:
 - Brian Buvinghausen