RubyGems - couchbase - Versions diffs - 3.0.0.alpha.3 → 3.0.1 - Mend

couchbase 3.0.0.alpha.3 → 3.0.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (1683) hide show

data/ext/third_party/snappy/.appveyor.yml DELETED

@@ -1,36 +0,0 @@
-# Build matrix / environment variables are explained on:
-# https://www.appveyor.com/docs/appveyor-yml/
-# This file can be validated on: https://ci.appveyor.com/tools/validate-yaml
-version: "{build}"
-environment:
-  matrix:
-    # AppVeyor currently has no custom job name feature.
-    # http://help.appveyor.com/discussions/questions/1623-can-i-provide-a-friendly-name-for-jobs
-    - JOB: Visual Studio 2019
-      APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2019
-      CMAKE_GENERATOR: Visual Studio 16 2019
-platform:
-  - x86
-  - x64
-configuration:
-  - RelWithDebInfo
-  - Debug
-build_script:
-  - git submodule update --init --recursive
-  - mkdir build
-  - cd build
-  - if "%platform%"=="x86" (set CMAKE_GENERATOR_PLATFORM="Win32")
-      else (set CMAKE_GENERATOR_PLATFORM="%platform%")
-  - cmake --version
-  - cmake .. -G "%CMAKE_GENERATOR%" -A "%CMAKE_GENERATOR_PLATFORM%"
-      -DCMAKE_CONFIGURATION_TYPES="%CONFIGURATION%" -DSNAPPY_REQUIRE_AVX2=ON
-  - cmake --build . --config %CONFIGURATION%
-  - cd ..
-test_script:
-  - build\%CONFIGURATION%\snappy_unittest

data/ext/third_party/snappy/.gitignore DELETED

@@ -1,8 +0,0 @@
-# Editors.
-*.sw*
-.vscode
-.DS_Store
-# Build directory.
-build/
-out/

data/ext/third_party/snappy/.travis.yml DELETED

@@ -1,98 +0,0 @@
-# Build matrix / environment variables are explained on:
-# http://about.travis-ci.org/docs/user/build-configuration/
-# This file can be validated on: http://lint.travis-ci.org/
-language: cpp
-dist: bionic
-osx_image: xcode11.3
-compiler:
-- gcc
-- clang
-os:
-- linux
-- osx
-env:
-- BUILD_TYPE=Debug CPU_LEVEL=AVX
-- BUILD_TYPE=Debug CPU_LEVEL=AVX2
-- BUILD_TYPE=RelWithDebInfo CPU_LEVEL=AVX
-- BUILD_TYPE=RelWithDebInfo CPU_LEVEL=AVX2
-jobs:
-  exclude:
-  # Travis OSX servers seem to run on pre-Haswell CPUs. Attempting to use AVX2
-  # results in crashes.
-  - env: BUILD_TYPE=Debug CPU_LEVEL=AVX2
-    os: osx
-  - env: BUILD_TYPE=RelWithDebInfo CPU_LEVEL=AVX2
-    os: osx
-  allow_failures:
-  # Homebrew's GCC is currently broken on XCode 11.
-  - compiler: gcc
-    os: osx
-addons:
-  apt:
-    sources:
-    - sourceline: 'deb http://apt.llvm.org/bionic/ llvm-toolchain-bionic-10 main'
-      key_url: 'https://apt.llvm.org/llvm-snapshot.gpg.key'
-    - sourceline: 'ppa:ubuntu-toolchain-r/test'
-    packages:
-    - clang-10
-    - cmake
-    - gcc-9
-    - g++-9
-    - ninja-build
-  homebrew:
-    packages:
-    - cmake
-    - gcc@9
-    - llvm@10
-    - ninja
-    update: true
-install:
-# The following Homebrew packages aren't linked by default, and need to be
-# prepended to the path explicitly.
-- if [ "$TRAVIS_OS_NAME" = "osx" ]; then
-    export PATH="$(brew --prefix llvm)/bin:$PATH";
-  fi
-# Fuzzing is only supported on Clang. Perform fuzzing on Debug builds.
-- if [ "$CXX" = "clang++" ] && [ "$BUILD_TYPE" = "Debug" ]; then
-    export FUZZING=1;
-  else
-    export FUZZING=0;
-  fi
-# /usr/bin/gcc points to an older compiler on both Linux and macOS.
-- if [ "$CXX" = "g++" ]; then export CXX="g++-9" CC="gcc-9"; fi
-# /usr/bin/clang points to an older compiler on both Linux and macOS.
-#
-# Homebrew's llvm package doesn't ship a versioned clang++ binary, so the values
-# below don't work on macOS. Fortunately, the path change above makes the
-# default values (clang and clang++) resolve to the correct compiler on macOS.
-- if [ "$TRAVIS_OS_NAME" = "linux" ]; then
-    if [ "$CXX" = "clang++" ]; then export CXX="clang++-10" CC="clang-10"; fi;
-  fi
-- echo ${CC}
-- echo ${CXX}
-- ${CXX} --version
-- cmake --version
-before_script:
-- mkdir -p build && cd build
-- cmake .. -G Ninja -DCMAKE_BUILD_TYPE=$BUILD_TYPE
-    -DSNAPPY_REQUIRE_${CPU_LEVEL}=ON -DSNAPPY_FUZZING_BUILD=${FUZZING}
-    -DCMAKE_INSTALL_PREFIX=$HOME/.local
-- cmake --build .
-- cd ..
-script:
-- build/snappy_unittest
-- if [ -f build/snappy_compress_fuzzer ]; then
-    build/snappy_compress_fuzzer -runs=1000 -close_fd_mask=3;
-  fi
-- if [ -f build/snappy_uncompress_fuzzer ]; then
-    build/snappy_uncompress_fuzzer -runs=1000 -close_fd_mask=3;
-  fi
-- cd build && cmake --build . --target install

data/ext/third_party/snappy/AUTHORS DELETED

	@@ -1 +0,0 @@
1	- opensource@google.com

data/ext/third_party/snappy/CONTRIBUTING.md DELETED

@@ -1,26 +0,0 @@
-# How to Contribute
-We'd love to accept your patches and contributions to this project. There are
-just a few small guidelines you need to follow.
-## Contributor License Agreement
-Contributions to this project must be accompanied by a Contributor License
-Agreement. You (or your employer) retain the copyright to your contribution,
-this simply gives us permission to use and redistribute your contributions as
-part of the project. Head over to <https://cla.developers.google.com/> to see
-your current agreements on file or to sign a new one.
-You generally only need to submit a CLA once, so if you've already submitted one
-(even if it was for a different project), you probably don't need to do it
-again.
-## Code reviews
-All submissions, including submissions by project members, require review. We
-use GitHub pull requests for this purpose. Consult
-[GitHub Help](https://help.github.com/articles/about-pull-requests/) for more
-information on using pull requests.
-Please make sure that all the automated checks (CLA, AppVeyor, Travis) pass for
-your pull requests. Pull requests whose checks fail may be ignored.

data/ext/third_party/snappy/NEWS DELETED

@@ -1,188 +0,0 @@
-Snappy v1.1.8, January 15th 2020:
-  * Small performance improvements.
-  * Removed snappy::string alias for std::string.
-  * Improved CMake configuration.
-Snappy v1.1.7, August 24th 2017:
-  * Improved CMake build support for 64-bit Linux distributions.
-  * MSVC builds now use MSVC-specific intrinsics that map to clzll.
-  * ARM64 (AArch64) builds use the code paths optimized for 64-bit processors.
-Snappy v1.1.6, July 12th 2017:
-This is a re-release of v1.1.5 with proper SONAME / SOVERSION values.
-Snappy v1.1.5, June 28th 2017:
-This release has broken SONAME / SOVERSION values. Users of snappy as a shared
-library should avoid 1.1.5 and use 1.1.6 instead. SONAME / SOVERSION errors will
-manifest as the dynamic library loader complaining that it cannot find snappy's
-shared library file (libsnappy.so / libsnappy.dylib), or that the library it
-found does not have the required version. 1.1.6 has the same code as 1.1.5, but
-carries build configuration fixes for the issues above.
-  * Add CMake build support. The autoconf build support is now deprecated, and
-    will be removed in the next release.
-  * Add AppVeyor configuration, for Windows CI coverage.
-  * Small performance improvement on little-endian PowerPC.
-  * Small performance improvement on LLVM with position-independent executables.
-  * Fix a few issues with various build environments.
-Snappy v1.1.4, January 25th 2017:
-  * Fix a 1% performance regression when snappy is used in PIE executables.
-  * Improve compression performance by 5%.
-  * Improve decompression performance by 20%.
-Snappy v1.1.3, July 6th 2015:
-This is the first release to be done from GitHub, which means that
-some minor things like the ChangeLog format has changed (git log
-format instead of svn log).
-  * Add support for Uncompress() from a Source to a Sink.
-  * Various minor changes to improve MSVC support; in particular,
-    the unit tests now compile and run under MSVC.
-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/ext/third_party/snappy/README.md DELETED

@@ -1,148 +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, 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.
-Building
-========
-You need the CMake version specified in [CMakeLists.txt](./CMakeLists.txt)
-or later to build:
-```bash
-mkdir build
-cd build && cmake ../ && make
-```
-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 [home page](docs/README.md) 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
-```c++
-snappy::Compress(input.data(), input.size(), &output);
-```
-and similarly
-```c++
-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
-  https://github.com/google/googletest
-You probably also want the gflags library for handling of command-line flags;
-you can find it at
-  https://gflags.github.io/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, 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 GitHub. For the latest version, a bug tracker,
-and other information, see https://github.com/google/snappy.