Ronny Chan

The current API for `decompress` is very simple and matches up well with the existing one-shot functions. One downside of such a design is that the `LzBuffer`s are still one-shot...

cc @gendx

I encountered a situation where simply resetting the decoder state was not enough but since the decoder is being reused for each raw LZMA chunk, the unpacked size was also...

This doesn't need to be a breaking release if `default` imports everything. It would be an opt-out rather than opt-in but can be done without a major version increment. Might...

I did some internal refactoring to expose [the raw decoder as a primitive](https://docs.rs/lzma-rs-headerless/0.4.1-api-alpha/lzma_rs_headerless/decompress/struct.LzmaDecoder.html) where the LZMA compression parameters are encoded aas const generics. I also did a similar wrapper for...

* Fair criticism of using const generics. In my fork the motivation was mostly for expressiveness (i.e. an `LzmaDecoder` would be type-incompatible with an `LzmaDecoder`) but I'm open to feature-gating...

I am working on porting [libchdr](https://github.com/rtissera/libchdr/) to Rust, which directly interfaces with the LZMA SDK and [sets the dictSize and other LZMA params explicitly](https://github.com/rtissera/libchdr/blob/master/src/libchdr_chd.c#L516). My current solution is to vendor...

#74 covers this for LZMA1, but I'm not sure how the current design of the LZMA2 decoder can take a useful `dict_size` parameter.

I've been doing some experiments in https://github.com/chyyran/lzma-rs/commits/feature-perf-experiments and found that const generics in `BitTree` and `RangeCoder` doesn't actually contribute that much performance benefit, *except for large dictionaries*. Without const generics...

`Vec2D` from #77 lets us easily experiment with different backing stores for the `literal_probs` array which is the main allocation. I used [arrayvec](https://crates.io/crates/arrayvec) which gives us a nice API over...