What's next...

[MiloszKrajewski]

1.0.3

• [x] block fast encoder
• [x] block high encoder
• [x] block decoder
• [x] stream encoder (dependent blocks)
• [x] stream decoder (dependent blocks)
• [x] frame decoder
• [x] frame encoder
• [x] checksum in header
• [x] friendly(ier?) API
• [x] provide read-only Position and Length (if available)

1.1.0

• [x] stream encoder (independent blocks)
• [x] stream decoder (independent blocks)
• [x] signing assemblies

1.1.3

• [x] add LegacyLz4Stream (compatible with lz4net, but not lz4 frame)

1.2.1-beta

• [x] porting 1.9.2
• [x] explicit support for both 32 and 64 environments

1.2.5

• [x] provide read-only Position and Length for compression stream (nothing fancy, just symmetry)
• [x] add true async read/write interface
• [x] add full async support (ie: DisposeAync for .NET Standard 2.1)

1.3.0

• [x] reduce allocations / use memory pool
• [x] stream abstraction

1.3.3

• [x] block (encoded) checksum
• [x] content (decoded) checksum

vNext

• [ ] abstract frame encoder/decoder state machine
• [ ] predefined dictionaries

Not planned

• [ ] fast decoder loop (gotos across scopes, not a thing in C#)

Note: block checksum and content checksum are not required (and may be ignored) Note: frame encoder/decoder now pulls data from stream, which means it needs to "understand" async. I would love to remove this dependency, and make it a pure state machine, which will still allow to build "async" solution on top of it.

[Krakean]

Note: lz4 1.8.2 introduces important bugfix but also breaking changes

You mean released 1.8.1.2 or 1.8.2 that one which is in dev branch? Just to be sure :) And, if we speak about 1.8.2-dev, what important bugfix it made?

Also, I suppose you want 1.0.0-alpha be compatible with 1.8.1(.2?) that you initially picked up, but later anyway plan to upgrade to later version of lz4 with those breaking changes (imho there is nothing wrong in breaking changes, user always can stay with old/previously released version)?

[MiloszKrajewski]

1.8.2 fixes some low probability/high impact security issue. It won't happen on PC but might happen on IoT devices. So, I'm not too concerned but still it is worth to port it, as once ported it freezes for a while. It is not a interface breaking change (so no problem for you), but produced output is not binary identical so lots of my unit tests will start to fail.

[Krakean]

@MiloszKrajewski got it. :) if there is no problem for PC, so no reason to rush then with bringing 1.8.2 update :) 1.8.1.2 I assume will be fine for 1.0.0 final.

[Krakean]

@MiloszKrajewski development stalled? :-\

[MiloszKrajewski]

Yup. I had a bug and a mental block for a while. And then, after returning from holiday, found and fixed problem in one day. Anyway, last thing to do is: more tests (stressing it a little bit) and friendlier API.

[Krakean]

@MiloszKrajewski good to see you back. By the way, any plans to update fresh version of lz4? :) As I assume your source code is based on lz4 1.8.1 (deprecated one?), and now 1.8.2 is available

[MiloszKrajewski]

I just release to nuget and wrote some docs on main page. I'll wait for some API feedback and try to port next version. As long as it is just bug fixes it should be relatively easy, but if there are breaking changes it may take while.

[Krakean]

@MiloszKrajewski Well, since major version hasn't been changed, I guess its just minor fixes + optimizations, so I guess it shouldn't take much time :) Plus, would be nice if you will add to readme.md some benchmarks, just have some speed comparing to C's lz4.

[Krakean]

@MiloszKrajewski

try to port next version

Seems like development a bit stalled, but curious, any progress on this?

[Krakean]

@MiloszKrajewski ping :)

[Krakean]

@MiloszKrajewski Hello Milosz, when you plan to continue development on this library? Or its no longer maintained?

[MiloszKrajewski]

Yes, I do. I'm just doing some online courses now and all my evenings are consumed by writing Scala. I'll come back to this project soon. Do you have any urgent bugs/issues?

[Krakean]

@MiloszKrajewski

I'll come back to this project soon.

Glad to hear :)

Do you have any urgent bugs/issues?

Nah, not at the moment at least :) Just worry about this project future, its the only C# native decent compression library which is suitable for games. Cant wait to see update sources to latest lz4 master with optimized decompression :) Block/content checksum also would be nice to see

[Krakean]

@MiloszKrajewski Hello Milosz No update to lz4 v1.9.1 in near feature? :-\ It has decent decomp speed optimizations which are really nice to have.

[MiloszKrajewski]

I pulled 1.9.1 and compared it with 1.8 and change are quite drastic so no tweaking, it would require full port again. On the radar, but functional changes (like true async/await) would take precedence I think. I can try latest 1.8.x though, but I'm not sure if this makes sense.

[Krakean]

@MiloszKrajewski

I can try latest 1.8.x though, but I'm not sure if this makes sense.

Its better than nothing at all :)

but functional changes (like true async/await) would take precedence I think.

Oh, good. Any approximate estimates on new version? :)

[Krakean]

@MiloszKrajewski Hello Milosz Any progress on v1.9.1? As I can see by existing of the branch '191' you decided to integrate 1.9.1 after all, right?

[MiloszKrajewski]

New version 1.2.1-beta released

[kylemc]

I see 'add true async read/write interface' in vNext above, but I also wrote up #34 to explain the value to me. Without a fix, I'll have to look for other fast compression options. Thanks.