bos at serpentine.com
Thu Sep 1 16:49:10 EDT 2016
It would be valuable to target a general-purpose package, if only because
the existing Python zstd bindings (somewhere on github) are not good.
You're right that zstd is a big win over zlib in every way.
On Thu, Sep 1, 2016 at 12:01 AM, Gregory Szorc <gregory.szorc at gmail.com>
> I got caught up in the zstd 1.0 release excitement and started writing a
> proper Python C extension for it (one that uses the streaming API and
> doesn't use custom framing like the existing python-zstd package does). The
> result of what I was able to hack together in a few hours is available at
> https://hg.mozilla.org/users/gszorc_mozilla.com/hg/rev/zstd (see the p1
> changeset for the C code).
> It compiles, but that's about it. The compress API basically no-ops (I
> need to plug in iterator foo). The decompress API segfaults and the API
> needs refined. It's also my first time writing a Python C extension, so I'm
> sure I'm doing several things wrong. And I know the style doesn't match
> Mercurial conventions. I'm not sure if I should strive for tailoring this
> to Mercurial's usage or try to release it as a standalone package...
> If anyone wants to take the code and run with it, go for it. I can stamp
> another license on the code if someone asks.
> I'd also like to invite a larger discussion around supporting zstd in the
> official Mercurial distribution. It seems like an all-around better
> compression format than zlib and supporting zstd seems like a relatively
> easy way to gain significant performance and size efficiency wins on many
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mercurial-devel