snappy 0.0.12 → 0.0.13

data/vendor/snappy/Makefile.am

@@ -1,23 +0,0 @@
-ACLOCAL_AMFLAGS = -I m4
-
-# Library.
-lib_LTLIBRARIES = libsnappy.la
-libsnappy_la_SOURCES = snappy.cc snappy-sinksource.cc snappy-stubs-internal.cc snappy-c.cc
-libsnappy_la_LDFLAGS = -version-info $(SNAPPY_LTVERSION)
-
-include_HEADERS = snappy.h snappy-sinksource.h snappy-stubs-public.h snappy-c.h
-noinst_HEADERS = snappy-internal.h snappy-stubs-internal.h snappy-test.h
-
-# Unit tests and benchmarks.
-snappy_unittest_CPPFLAGS = $(gflags_CFLAGS) $(GTEST_CPPFLAGS)
-snappy_unittest_SOURCES = snappy_unittest.cc snappy-test.cc
-snappy_unittest_LDFLAGS = $(GTEST_LDFLAGS)
-snappy_unittest_LDADD = libsnappy.la $(UNITTEST_LIBS) $(gflags_LIBS) $(GTEST_LIBS)
-TESTS = snappy_unittest
-noinst_PROGRAMS = $(TESTS)
-
-EXTRA_DIST = autogen.sh testdata/alice29.txt testdata/asyoulik.txt testdata/baddata1.snappy testdata/baddata2.snappy testdata/baddata3.snappy testdata/geo.protodata testdata/fireworks.jpeg testdata/html testdata/html_x_4 testdata/kppkn.gtb testdata/lcet10.txt testdata/paper-100k.pdf testdata/plrabn12.txt testdata/urls.10K
-dist_doc_DATA = ChangeLog COPYING INSTALL NEWS README format_description.txt framing_format.txt
-
-libtool: $(LIBTOOL_DEPS)
-	$(SHELL) ./config.status --recheck

data/vendor/snappy/NEWS

@@ -1,128 +0,0 @@
-Snappy v1.1.2, February 28th 2014:
-
-This is a maintenance release with no changes to the actual library
-source code.
-
-  * Stop distributing benchmark data files that have unclear
-    or unsuitable licensing.
-
-  * Add support for padding chunks in the framing format.
-
-
-Snappy v1.1.1, October 15th 2013:
-
-  * Add support for uncompressing to iovecs (scatter I/O).
-    The bulk of this patch was contributed by Mohit Aron.
-
-  * Speed up decompression by ~2%; much more so (~13-20%) on
-    a few benchmarks on given compilers and CPUs.
-
-  * Fix a few issues with MSVC compilation.
-
-  * Support truncated test data in the benchmark.
-
-
-Snappy v1.1.0, January 18th 2013:
-
-  * Snappy now uses 64 kB block size instead of 32 kB. On average,
-    this means it compresses about 3% denser (more so for some
-    inputs), at the same or better speeds.
-
-  * libsnappy no longer depends on iostream.
-
-  * Some small performance improvements in compression on x86
-    (0.5–1%).
-
-  * Various portability fixes for ARM-based platforms, for MSVC,
-    and for GNU/Hurd.
-
-
-Snappy v1.0.5, February 24th 2012:
-
-  * More speed improvements. Exactly how big will depend on
-    the architecture:
-
-    - 3–10% faster decompression for the base case (x86-64).
-
-    - ARMv7 and higher can now use unaligned accesses,
-      and will see about 30% faster decompression and
-      20–40% faster compression.
-
-    - 32-bit platforms (ARM and 32-bit x86) will see 2–5%
-      faster compression.
-
-    These are all cumulative (e.g., ARM gets all three speedups).
-
-  * Fixed an issue where the unit test would crash on system
-    with less than 256 MB address space available,
-    e.g. some embedded platforms.
-
-  * Added a framing format description, for use over e.g. HTTP,
-    or for a command-line compressor. We do not have any
-    implementations of this at the current point, but there seems
-    to be enough of a general interest in the topic.
-    Also make the format description slightly clearer.
-
-  * Remove some compile-time warnings in -Wall
-    (mostly signed/unsigned comparisons), for easier embedding
-    into projects that use -Wall -Werror.
-
-
-Snappy v1.0.4, September 15th 2011:
-
-  * Speeded up the decompressor somewhat; typically about 2–8%
-    for Core i7, in 64-bit mode (comparable for Opteron).
-    Somewhat more for some tests, almost no gain for others.
-  
-  * Make Snappy compile on certain platforms it didn't before
-    (Solaris with SunPro C++, HP-UX, AIX).
-
-  * Correct some minor errors in the format description.
-
-
-Snappy v1.0.3, June 2nd 2011:
-
-  * Speeded up the decompressor somewhat; about 3-6% for Core 2,
-    6-13% for Core i7, and 5-12% for Opteron (all in 64-bit mode).
-
-  * Added compressed format documentation. This text is new,
-    but an earlier version from Zeev Tarantov was used as reference.
-
-  * Only link snappy_unittest against -lz and other autodetected
-    libraries, not libsnappy.so (which doesn't need any such dependency).
-
-  * Fixed some display issues in the microbenchmarks, one of which would
-    frequently make the test crash on GNU/Hurd.
-
-
-Snappy v1.0.2, April 29th 2011:
-
-  * Relicense to a BSD-type license.
-
-  * Added C bindings, contributed by Martin Gieseking.
-
-  * More Win32 fixes, in particular for MSVC.
-
-  * Replace geo.protodata with a newer version.
-
-  * Fix timing inaccuracies in the unit test when comparing Snappy
-    to other algorithms.
-
-
-Snappy v1.0.1, March 25th 2011:
-
-This is a maintenance release, mostly containing minor fixes.
-There is no new functionality. The most important fixes include:
-
-  * The COPYING file and all licensing headers now correctly state that
-    Snappy is licensed under the Apache 2.0 license.
-
-  * snappy_unittest should now compile natively under Windows,
-    as well as on embedded systems with no mmap().
-
-  * Various autotools nits have been fixed.
-
-
-Snappy v1.0, March 17th 2011:
-
-  * Initial version.

data/vendor/snappy/README

@@ -1,135 +0,0 @@
-Snappy, a fast compressor/decompressor.
-
-
-Introduction
-============
-
-Snappy is a compression/decompression library. It does not aim for maximum
-compression, or compatibility with any other compression library; instead,
-it aims for very high speeds and reasonable compression. For instance,
-compared to the fastest mode of zlib, Snappy is an order of magnitude faster
-for most inputs, but the resulting compressed files are anywhere from 20% to
-100% bigger. (For more information, see "Performance", below.)
-
-Snappy has the following properties:
-
- * Fast: Compression speeds at 250 MB/sec and beyond, with no assembler code.
-   See "Performance" below.
- * Stable: Over the last few years, Snappy has compressed and decompressed
-   petabytes of data in Google's production environment. The Snappy bitstream
-   format is stable and will not change between versions.
- * Robust: The Snappy decompressor is designed not to crash in the face of
-   corrupted or malicious input.
- * Free and open source software: Snappy is licensed under a BSD-type license.
-   For more information, see the included COPYING file.
-
-Snappy has previously been called "Zippy" in some Google presentations
-and the like.
-
-
-Performance
-===========
- 
-Snappy is intended to be fast. On a single core of a Core i7 processor
-in 64-bit mode, it compresses at about 250 MB/sec or more and decompresses at
-about 500 MB/sec or more. (These numbers are for the slowest inputs in our
-benchmark suite; others are much faster.) In our tests, Snappy usually
-is faster than algorithms in the same class (e.g. LZO, LZF, FastLZ, QuickLZ,
-etc.) while achieving comparable compression ratios.
-
-Typical compression ratios (based on the benchmark suite) are about 1.5-1.7x
-for plain text, about 2-4x for HTML, and of course 1.0x for JPEGs, PNGs and
-other already-compressed data. Similar numbers for zlib in its fastest mode
-are 2.6-2.8x, 3-7x and 1.0x, respectively. More sophisticated algorithms are
-capable of achieving yet higher compression rates, although usually at the
-expense of speed. Of course, compression ratio will vary significantly with
-the input.
-
-Although Snappy should be fairly portable, it is primarily optimized
-for 64-bit x86-compatible processors, and may run slower in other environments.
-In particular:
-
- - Snappy uses 64-bit operations in several places to process more data at
-   once than would otherwise be possible.
- - Snappy assumes unaligned 32- and 64-bit loads and stores are cheap.
-   On some platforms, these must be emulated with single-byte loads 
-   and stores, which is much slower.
- - Snappy assumes little-endian throughout, and needs to byte-swap data in
-   several places if running on a big-endian platform.
-
-Experience has shown that even heavily tuned code can be improved.
-Performance optimizations, whether for 64-bit x86 or other platforms,
-are of course most welcome; see "Contact", below.
-
-
-Usage
-=====
-
-Note that Snappy, both the implementation and the main interface,
-is written in C++. However, several third-party bindings to other languages
-are available; see the Google Code page at http://code.google.com/p/snappy/
-for more information. Also, if you want to use Snappy from C code, you can
-use the included C bindings in snappy-c.h.
-
-To use Snappy from your own C++ program, include the file "snappy.h" from
-your calling file, and link against the compiled library.
-
-There are many ways to call Snappy, but the simplest possible is
-
-  snappy::Compress(input.data(), input.size(), &output);
-
-and similarly
-
-  snappy::Uncompress(input.data(), input.size(), &output);
-
-where "input" and "output" are both instances of std::string.
-
-There are other interfaces that are more flexible in various ways, including
-support for custom (non-array) input sources. See the header file for more
-information.
-
-
-Tests and benchmarks
-====================
-
-When you compile Snappy, snappy_unittest is compiled in addition to the
-library itself. You do not need it to use the compressor from your own library,
-but it contains several useful components for Snappy development.
-
-First of all, it contains unit tests, verifying correctness on your machine in
-various scenarios. If you want to change or optimize Snappy, please run the
-tests to verify you have not broken anything. Note that if you have the
-Google Test library installed, unit test behavior (especially failures) will be
-significantly more user-friendly. You can find Google Test at
-
-  http://code.google.com/p/googletest/
-
-You probably also want the gflags library for handling of command-line flags;
-you can find it at
-
-  http://code.google.com/p/google-gflags/
-
-In addition to the unit tests, snappy contains microbenchmarks used to
-tune compression and decompression performance. These are automatically run
-before the unit tests, but you can disable them using the flag
---run_microbenchmarks=false if you have gflags installed (otherwise you will
-need to edit the source).
-
-Finally, snappy can benchmark Snappy against a few other compression libraries
-(zlib, LZO, LZF, FastLZ and QuickLZ), if they were detected at configure time.
-To benchmark using a given file, give the compression algorithm you want to test
-Snappy against (e.g. --zlib) and then a list of one or more file names on the
-command line. The testdata/ directory contains the files used by the
-microbenchmark, which should provide a reasonably balanced starting point for
-benchmarking. (Note that baddata[1-3].snappy are not intended as benchmarks; they
-are used to verify correctness in the presence of corrupted data in the unit
-test.)
-
-
-Contact
-=======
-
-Snappy is distributed through Google Code. For the latest version, a bug tracker,
-and other information, see
-
-  http://code.google.com/p/snappy/

data/vendor/snappy/autogen.sh

@@ -1,7 +0,0 @@
-#! /bin/sh -e
-rm -rf autom4te.cache
-aclocal -I m4
-autoheader
-libtoolize --copy
-automake --add-missing --copy
-autoconf

data/vendor/snappy/configure.ac

@@ -1,133 +0,0 @@
-m4_define([snappy_major], [1])
-m4_define([snappy_minor], [1])
-m4_define([snappy_patchlevel], [2])
-
-# Libtool shared library interface versions (current:revision:age)
-# Update this value for every release!  (A:B:C will map to foo.so.(A-C).C.B)
-# http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
-m4_define([snappy_ltversion], [3:1:2])
-
-AC_INIT([snappy], [snappy_major.snappy_minor.snappy_patchlevel])
-AC_CONFIG_MACRO_DIR([m4])
-
-# These are flags passed to automake (though they look like gcc flags!)
-AM_INIT_AUTOMAKE([-Wall])
-
-LT_INIT
-AC_SUBST([LIBTOOL_DEPS])
-AC_PROG_CXX
-AC_LANG([C++])
-AC_C_BIGENDIAN
-AC_TYPE_SIZE_T
-AC_TYPE_SSIZE_T
-AC_CHECK_HEADERS([stdint.h stddef.h sys/mman.h sys/resource.h windows.h byteswap.h sys/byteswap.h sys/endian.h sys/time.h])
-
-# Don't use AC_FUNC_MMAP, as it checks for mappings of already-mapped memory,
-# which we don't need (and does not exist on Windows).
-AC_CHECK_FUNC([mmap])
-
-GTEST_LIB_CHECK([], [true], [true # Ignore; we can live without it.])
-
-AC_ARG_WITH([gflags],
-  [AS_HELP_STRING(
-    [--with-gflags],
-    [use Google Flags package to enhance the unit test @<:@default=check@:>@])],
-    [],
-    [with_gflags=check])
-
-if test "x$with_gflags" != "xno"; then
-  PKG_CHECK_MODULES(
-    [gflags],
-    [libgflags],
-    [AC_DEFINE([HAVE_GFLAGS], [1], [Use the gflags package for command-line parsing.])],
-    [if test "x$with_gflags" != "xcheck"; then
-      AC_MSG_FAILURE([--with-gflags was given, but test for gflags failed])
-    fi])
-fi
-
-# See if we have __builtin_expect.
-# TODO: Use AC_CACHE.
-AC_MSG_CHECKING([if the compiler supports __builtin_expect])
- 
-AC_TRY_COMPILE(, [
-    return __builtin_expect(1, 1) ? 1 : 0
-], [
-    snappy_have_builtin_expect=yes
-    AC_MSG_RESULT([yes])
-], [
-    snappy_have_builtin_expect=no
-    AC_MSG_RESULT([no])
-])
-if test x$snappy_have_builtin_expect = xyes ; then
-    AC_DEFINE([HAVE_BUILTIN_EXPECT], [1], [Define to 1 if the compiler supports __builtin_expect.])
-fi
-
-# See if we have working count-trailing-zeros intrinsics.
-# TODO: Use AC_CACHE.
-AC_MSG_CHECKING([if the compiler supports __builtin_ctzll])
-
-AC_TRY_COMPILE(, [
-    return (__builtin_ctzll(0x100000000LL) == 32) ? 1 : 0
-], [
-    snappy_have_builtin_ctz=yes
-    AC_MSG_RESULT([yes])
-], [
-    snappy_have_builtin_ctz=no
-    AC_MSG_RESULT([no])
-])
-if test x$snappy_have_builtin_ctz = xyes ; then
-    AC_DEFINE([HAVE_BUILTIN_CTZ], [1], [Define to 1 if the compiler supports __builtin_ctz and friends.])
-fi
-
-# Other compression libraries; the unit test can use these for comparison
-# if they are available. If they are not found, just ignore.
-UNITTEST_LIBS=""
-AC_DEFUN([CHECK_EXT_COMPRESSION_LIB], [
-  AH_CHECK_LIB([$1])
-  AC_CHECK_LIB(
-    [$1],
-    [$2],
-    [
-      AC_DEFINE_UNQUOTED(AS_TR_CPP(HAVE_LIB$1))
-      UNITTEST_LIBS="-l$1 $UNITTEST_LIBS"
-    ],
-    [true]
-  )
-])
-CHECK_EXT_COMPRESSION_LIB([z], [zlibVersion])
-CHECK_EXT_COMPRESSION_LIB([lzo2], [lzo1x_1_15_compress])
-CHECK_EXT_COMPRESSION_LIB([lzf], [lzf_compress])
-CHECK_EXT_COMPRESSION_LIB([fastlz], [fastlz_compress])
-CHECK_EXT_COMPRESSION_LIB([quicklz], [qlz_compress])
-AC_SUBST([UNITTEST_LIBS])
-
-# These are used by snappy-stubs-public.h.in.
-if test "$ac_cv_header_stdint_h" = "yes"; then
-    AC_SUBST([ac_cv_have_stdint_h], [1])
-else
-    AC_SUBST([ac_cv_have_stdint_h], [0])
-fi
-if test "$ac_cv_header_stddef_h" = "yes"; then
-    AC_SUBST([ac_cv_have_stddef_h], [1])
-else
-    AC_SUBST([ac_cv_have_stddef_h], [0])
-fi
-if test "$ac_cv_header_sys_uio_h" = "yes"; then
-    AC_SUBST([ac_cv_have_sys_uio_h], [1])
-else
-    AC_SUBST([ac_cv_have_sys_uio_h], [0])
-fi
-
-# Export the version to snappy-stubs-public.h.
-SNAPPY_MAJOR="snappy_major"
-SNAPPY_MINOR="snappy_minor"
-SNAPPY_PATCHLEVEL="snappy_patchlevel"
-
-AC_SUBST([SNAPPY_MAJOR])
-AC_SUBST([SNAPPY_MINOR])
-AC_SUBST([SNAPPY_PATCHLEVEL])
-AC_SUBST([SNAPPY_LTVERSION], snappy_ltversion)
-
-AC_CONFIG_HEADERS([config.h])
-AC_CONFIG_FILES([Makefile snappy-stubs-public.h])
-AC_OUTPUT

data/vendor/snappy/format_description.txt

@@ -1,110 +0,0 @@
-Snappy compressed format description
-Last revised: 2011-10-05
-
-
-This is not a formal specification, but should suffice to explain most
-relevant parts of how the Snappy format works. It is originally based on
-text by Zeev Tarantov.
-
-Snappy is a LZ77-type compressor with a fixed, byte-oriented encoding.
-There is no entropy encoder backend nor framing layer -- the latter is
-assumed to be handled by other parts of the system.
-
-This document only describes the format, not how the Snappy compressor nor
-decompressor actually works. The correctness of the decompressor should not
-depend on implementation details of the compressor, and vice versa.
-
-
-1. Preamble
-
-The stream starts with the uncompressed length (up to a maximum of 2^32 - 1),
-stored as a little-endian varint. Varints consist of a series of bytes,
-where the lower 7 bits are data and the upper bit is set iff there are
-more bytes to be read. In other words, an uncompressed length of 64 would
-be stored as 0x40, and an uncompressed length of 2097150 (0x1FFFFE)
-would be stored as 0xFE 0xFF 0x7F.
-
-
-2. The compressed stream itself
-
-There are two types of elements in a Snappy stream: Literals and
-copies (backreferences). There is no restriction on the order of elements,
-except that the stream naturally cannot start with a copy. (Having
-two literals in a row is never optimal from a compression point of
-view, but nevertheless fully permitted.) Each element starts with a tag byte,
-and the lower two bits of this tag byte signal what type of element will
-follow:
-
-  00: Literal
-  01: Copy with 1-byte offset
-  10: Copy with 2-byte offset
-  11: Copy with 4-byte offset
-
-The interpretation of the upper six bits are element-dependent.
-
-
-2.1. Literals (00)
-
-Literals are uncompressed data stored directly in the byte stream.
-The literal length is stored differently depending on the length
-of the literal:
-
- - For literals up to and including 60 bytes in length, the upper
-   six bits of the tag byte contain (len-1). The literal follows
-   immediately thereafter in the bytestream.
- - For longer literals, the (len-1) value is stored after the tag byte,
-   little-endian. The upper six bits of the tag byte describe how
-   many bytes are used for the length; 60, 61, 62 or 63 for
-   1-4 bytes, respectively. The literal itself follows after the
-   length.
-
-
-2.2. Copies
-
-Copies are references back into previous decompressed data, telling
-the decompressor to reuse data it has previously decoded.
-They encode two values: The _offset_, saying how many bytes back
-from the current position to read, and the _length_, how many bytes
-to copy. Offsets of zero can be encoded, but are not legal;
-similarly, it is possible to encode backreferences that would
-go past the end of the block (offset > current decompressed position),
-which is also nonsensical and thus not allowed.
-
-As in most LZ77-based compressors, the length can be larger than the offset,
-yielding a form of run-length encoding (RLE). For instance,
-"xababab" could be encoded as
-
-  <literal: "xab"> <copy: offset=2 length=4>
-
-Note that since the current Snappy compressor works in 32 kB
-blocks and does not do matching across blocks, it will never produce
-a bitstream with offsets larger than about 32768. However, the
-decompressor should not rely on this, as it may change in the future.
-
-There are several different kinds of copy elements, depending on
-the amount of bytes to be copied (length), and how far back the
-data to be copied is (offset).
-
-
-2.2.1. Copy with 1-byte offset (01)
-
-These elements can encode lengths between [4..11] bytes and offsets
-between [0..2047] bytes. (len-4) occupies three bits and is stored
-in bits [2..4] of the tag byte. The offset occupies 11 bits, of which the
-upper three are stored in the upper three bits ([5..7]) of the tag byte,
-and the lower eight are stored in a byte following the tag byte.
-
-
-2.2.2. Copy with 2-byte offset (10)
-
-These elements can encode lengths between [1..64] and offsets from
-[0..65535]. (len-1) occupies six bits and is stored in the upper
-six bits ([2..7]) of the tag byte. The offset is stored as a
-little-endian 16-bit integer in the two bytes following the tag byte.
-
-
-2.2.3. Copy with 4-byte offset (11)
-
-These are like the copies with 2-byte offsets (see previous subsection),
-except that the offset is stored as a 32-bit integer instead of a
-16-bit integer (and thus will occupy four bytes).