oyvindln
oyvindln
Yup, we need to do some work on the documentation, the API is quite low-level so it can be a bit difficult to figure it out. It may also be...
That data has a [gzip](http://www.zlib.org/rfc-gzip.html) wrapper around it. The core miniz_oxide doesn't support gzip directly, flate2 will deal with the wrapper if the correct decoder struct is used. Adding support...
Yeah sounds like a good idea.
From what I can see the callback functionality is not used by flate2 any of the tests or examples. It's only used by miniz_zip. So, unless the plan is to...
>That got me thinking that we really don't need rusty API, because flate2 will be better at it anyway. Yeah we don't need the high level writer stuff as that...
The benchmarks I posted on the issue in the flate2 issue were [these] from my deflate encoder. I simply replaced flate2 with flate2-oxide. (I don't think there is an easy...
It turns out directly comparing with miniz-backed flate2 is a bit complicated, as the compiler doesn't like that there are two crates that link to 2 versions of a c...
Ah, that's nice. Then we could do the same for performance comparisons.
I managed to improve match copying in tinfl_oxide a bit. loading/storing u64 and other larger types didn't seem to help, but adding a special case for 3-length matches helped a...
Yeah, C code can jump to random places using switch and goto, something miniz and many C/C++ decoders makes use of. We need to find some way around that in...