release: v10.18.0 — JP3D AsyncSequence progress reporting#454
Merged
Conversation
Ships progressStream() extensions on JP3DDecoder, JP3DROIDecoder,
JP3DEncoder, and JP3DStreamWriter — modern Swift-concurrency progress
API alongside the existing setProgressCallback(_:) closure surface
(both remain supported indefinitely). Closes the deferred Phase 3 from
v10.17.0's plan with focused MINOR scope.
The progressStream() method is `async` so the relay closure is
installed on the actor BEFORE the stream is returned — no race window
where early progress events get missed. Lifecycle behaviour explicitly
codified:
* Calling progressStream() twice overwrites the first stream's
writer (first stream's continuation receives no further events
but isn't explicitly finished)
* The stream doesn't auto-finish at operation completion
(consumers break based on observed progress or rely on Task
cancellation)
* setProgressCallback(_:) after progressStream() overwrites the
relay (use one or the other, not both)
Consumer pattern:
let decoder = JP3DDecoder()
let stream = await decoder.progressStream()
async let observer: Void = {
for await progress in stream {
updateUI(progress)
}
}()
let result = try await decoder.decode(data)
_ = await observer
Validation:
- V10_30_ProgressStreamParityTests 4/4 PASS release mode
* JP3DDecoder + JP3DEncoder deliver events during real operations
* JP3DROIDecoder stream surface available + safe (decoder body
doesn't currently fire progressCallback — pre-existing upstream
gap, documented in test header)
* setProgressCallback after progressStream still fires correctly
- swift test --filter JP3D regression 532/532 PASS
- Mandatory commit gate (release mode) 7/7 PASS
MINOR per RELEASING.md — pure additive surface: 4 new public extension
methods, zero existing API change, codestream bytes byte-identical to
v10.17.0, no perf change on warm or cold paths. Also bumps getVersion()
constant 10.17.0 → 10.18.0.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
progressStream()extensions onJP3DDecoder,JP3DROIDecoder,JP3DEncoder,JP3DStreamWriter— modern Swift-concurrency progress API alongside the existingsetProgressCallback(_:)closure surface (both remain supported indefinitely).asyncmethod, documented overwrite semantics) is implemented cleanly.What's New
JP3DDecoder.progressStream()async, returnsAsyncStream<JP3DDecoderProgress>JP3DROIDecoder.progressStream()async, returnsAsyncStream<JP3DDecoderProgress>(surface available; upstream body doesn't currently fire events — documented)JP3DEncoder.progressStream()async, returnsAsyncStream<JP3DEncoderProgress>JP3DStreamWriter.progressStream()async, returnsAsyncStream<JP3DStreamProgress>Correctness gate (release mode)
V10_30_ProgressStreamParityTests4/4 PASS (JP3DDecoder + JP3DEncoder deliver events; JP3DROIDecoder surface safe; setProgressCallback overwrite of progressStream's relay still fires)swift test --filter JP3Dregression 532/532 PASS (1 pre-existing skip)J2KMedicalCorpusEncodePerformanceTests2/2 PASSJ2KMedicalCorpusPerformanceTests2/2 PASSJ2KStrictCrossCodecValidationTests3/3 PASSMandatory commit gate: 7/7 PASS release mode.
Lifecycle design
asyncmethod → relay closure is installed on the actor before the stream is returned (no race window for early progress events).progressStream()twice overwrites the first stream's writer; first stream's continuation receives no further events but isn't explicitly finished (consumer'sbreak/cancel terminates iteration).setProgressCallback(_:)afterprogressStream()overwrites the stream-relay closure — use one or the other, not both.breakbased on observed progress or rely onTaskcancellation.Test plan
getVersion()bumped 10.17.0 → 10.18.0🤖 Generated with Claude Code