Skip to content

Pure Rust - #248

Open
milesgranger wants to merge 3 commits into
masterfrom
milesgranger/libcramjam-pure
Open

milesgranger wants to merge 3 commits into
masterfrom
milesgranger/libcramjam-pure

Conversation

@milesgranger

Copy link
Copy Markdown
Owner

Probably nothing to see here, just experimenting.
xref cramjam/libcramjam#31

…ted benchmarks

- All codecs now route through the pure-Rust libcramjam (path dep for now —
  CI needs a git/crates pin before merge); Python API unchanged.
- Compressor.flush() keeps the C libraries' sync-flush semantics on every
  codec (xz's flush no longer raises NotImplementedError); finish() only
  writes the stream tail. tests/test_streaming_semantics.py pins this plus
  the xz RAW/LZMA1/BCJ/SHA-256 surface.
- benchmarks: test_lzma points at cramjam.xz (cramjam.experimental.lzma is
  gone); README tables regenerated with the pure-Rust build + a C-vs-Rust
  comparison section.
Switch the cramjam-python dependency from the local path (../libcramjam) to the
pushed git branch so CI and wheel builds resolve the pure-Rust libcramjam
without a local checkout. Cargo.lock pins it to the current branch tip.

The cramjam-js (wasm) workspace member is unchanged and still uses the
published libcramjam 0.7.0.
PyPy's cffi _lzma can decode a BCJ (branch/call/jump) filtered stream but
can't set up a BCJ filter chain for encoding — lzma.compress(filters=[BCJ,
LZMA2]) raises LZMA_PROG_ERROR ('Internal error'). That is a stdlib/PyPy
limitation, not a cramjam issue: the forward direction (our BCJ encoder,
decoded by both liblzma and ourselves) still validates. Guard the reverse
'liblzma-encoded input decodes with ours' check so it skips where the
interpreter's lzma can't produce the reference stream; it still runs on
CPython.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant