docs: update docs and metadata
authorzooko <zooko@zooko.com>
Sat, 4 Dec 2010 19:00:54 +0000 (00:30 +0530)
committerzooko <zooko@zooko.com>
Sat, 4 Dec 2010 19:00:54 +0000 (00:30 +0530)
Ignore-this: 2d00ae4418ae817ccc0e5838818683a7

darcs-hash:4df3a64cd36607211b8d4d612e49fca62d36c409

12 files changed:
zfec/README.rst [new file with mode: 0644]
zfec/README.txt [deleted file]
zfec/fec.cabal
zfec/haskell/Codec/FEC.hs
zfec/setup.py
zfec/zfec/__init__.py
zfec/zfec/cmdline_zfec.py
zfec/zfec/cmdline_zunfec.py
zfec/zfec/easyfec.py
zfec/zfec/fec.c
zfec/zfec/fec.h
zfec/zfec/filefec.py

diff --git a/zfec/README.rst b/zfec/README.rst
new file mode 100644 (file)
index 0000000..77f1f39
--- /dev/null
@@ -0,0 +1,303 @@
+zfec
+====
+
+Efficient, portable, programmable erasure coding a.k.a. forward error
+correction. Generate redundant blocks of information such that if some
+of the blocks are lost then the original data can be recovered from
+the remaining blocks. This package includes command-line tools, C API,
+Python API, and Haskell API.
+
+
+Intro and Licence
+-----------------
+
+This package implements an "erasure code", or "forward error correction code".
+
+You may use this package under the GNU General Public License, version 2 or, at
+your option, any later version.  You may use this package under the Transitive
+Grace Period Public Licence, version 1.0 or, at your option, any later version.
+(You may choose to use this package under the terms of either licence, at your
+option.)  See the file COPYING.GPL for the terms of the GNU General Public
+License, version 2.  See the file COPYING.TGPPL.html for the terms of the
+Transitive Grace Period Public Licence, version 1.0.
+
+The most widely known example of an erasure code is the RAID-5 algorithm which
+makes it so that in the event of the loss of any one hard drive, the stored data
+can be completely recovered.  The algorithm in the zfec package has a similar
+effect, but instead of recovering from the loss of only a single element, it can
+be parameterized to choose in advance the number of elements whose loss it can
+tolerate.
+
+This package is largely based on the old "fec" library by Luigi Rizzo et al.,
+which is a mature and optimized implementation of erasure coding.  The zfec
+package makes several changes from the original "fec" package, including
+addition of the Python API, refactoring of the C API to support zero-copy
+operation, a few clean-ups and optimizations of the core code itself, and the
+addition of a command-line tool named "zfec".
+
+
+Installation
+------------
+
+This package is managed with the "setuptools" package management tool.  To build
+and install the package directly into your system, just run "python ./setup.py
+install".  If you prefer to keep the package limited to a specific directory so
+that you can manage it yourself (perhaps by using the "GNU stow") tool, then
+give it these arguments: "python ./setup.py install
+--single-version-externally-managed
+--record=${specificdirectory}/zfec-install.log --prefix=${specificdirectory}"
+
+To run the self-tests, execute "python ./setup.py test" (or if you have Twisted
+Python installed, you can run "trial zfec" for nicer output and test options.)
+This will run the tests of the C API, the Python API, and the command-line
+tools.
+
+To run the tests of the Haskell API:
+    % runhaskell haskell/test/FECTest.hs
+
+Note that in order to run the Haskell API tests you must have installed the
+library first due to the fact that the interpreter cannot process FEC.hs as it
+takes a reference to an FFI function.
+
+
+Community
+---------
+
+The source is currently available via darcs on the web with the command:
+
+darcs get http://allmydata.org/source/zfec/trunk
+
+More information on darcs is available at http://darcs.net
+
+Please join the zfec mailing list and submit patches:
+
+<http://allmydata.org/cgi-bin/mailman/listinfo/zfec-dev>
+
+
+Overview
+--------
+
+This package performs two operations, encoding and decoding.  Encoding takes
+some input data and expands its size by producing extra "check blocks", also
+called "secondary blocks".  Decoding takes some data -- any combination of
+blocks of the original data (called "primary blocks") and "secondary blocks",
+and produces the original data.
+
+The encoding is parameterized by two integers, k and m.  m is the total number
+of blocks produced, and k is how many of those blocks are necessary to
+reconstruct the original data.  m is required to be at least 1 and at most 256,
+and k is required to be at least 1 and at most m.
+
+(Note that when k == m then there is no point in doing erasure coding -- it
+degenerates to the equivalent of the Unix "split" utility which simply splits
+the input into successive segments.  Similarly, when k == 1 it degenerates to
+the equivalent of the unix "cp" utility -- each block is a complete copy of the
+input data.)
+
+Note that each "primary block" is a segment of the original data, so its size is
+1/k'th of the size of original data, and each "secondary block" is of the same
+size, so the total space used by all the blocks is m/k times the size of the
+original data (plus some padding to fill out the last primary block to be the
+same size as all the others).  In addition to the data contained in the blocks
+themselves there are also a few pieces of metadata which are necessary for later
+reconstruction.  Those pieces are: 1.  the value of K, 2.  the value of M, 3.
+the sharenum of each block, 4.  the number of bytes of padding that were used.
+The "zfec" command-line tool compresses these pieces of data and prepends them
+to the beginning of each share, so each the sharefile produced by the "zfec"
+command-line tool is between one and four bytes larger than the share data
+alone.
+
+The decoding step requires as input k of the blocks which were produced by the
+encoding step.  The decoding step produces as output the data that was earlier
+input to the encoding step.
+
+
+Command-Line Tool
+-----------------
+
+The bin/ directory contains two Unix-style, command-line tools "zfec" and
+"zunfec".  Execute "zfec --help" or "zunfec --help" for usage instructions.
+
+Note: a Unix-style tool like "zfec" does only one thing -- in this case erasure
+coding -- and leaves other tasks to other tools.  Other Unix-style tools that go
+well with zfec include "GNU tar" or "7z" a.k.a. "p7zip" for archiving multiple
+files and directories into one file, "7z" or "rzip" for compression, and "GNU Privacy
+Guard" for encryption or "sha256sum" for integrity.  It is important to do
+things in order: first archive, then compress, then either encrypt or sha256sum,
+then erasure code.  Note that if GNU Privacy Guard is used for privacy, then it
+will also ensure integrity, so the use of sha256sum is unnecessary in that case.
+Note that if 7z is used for archiving then it also does compression, so you
+don't need a separate compressor in that case.
+
+
+Performance
+-----------
+
+On my Athlon 64 2.4 GHz workstation (running Linux), the "zfec" command-line
+tool encoded a 160 MB file with m=100, k=94 (about 6% redundancy) in 3.9
+seconds, where the "par2" tool encoded the file with about 6% redundancy in 27
+seconds.  zfec encoded the same file with m=12, k=6 (100% redundancy) in 4.1
+seconds, where par2 encoded it with about 100% redundancy in 7 minutes and 56
+seconds.
+
+The underlying C library in benchmark mode encoded from a file at about 4.9
+million bytes per second and decoded at about 5.8 million bytes per second.
+
+On Peter's fancy Intel Mac laptop (2.16 GHz Core Duo), it encoded from a file at
+about 6.2 million bytes per second.
+
+On my even fancier Intel Mac laptop (2.33 GHz Core Duo), it encoded from a file
+at about 6.8 million bytes per second.
+
+On my old PowerPC G4 867 MHz Mac laptop, it encoded from a file at about 1.3
+million bytes per second.
+
+Here is a paper analyzing the performance of various erasure codes and their
+implementations, including zfec:
+
+http://www.usenix.org/events/fast09/tech/full_papers/plank/plank.pdf
+
+Zfec shows good performance on different machines and with different values of
+K and M. It also has a nice small memory footprint.
+
+
+API
+---
+
+Each block is associated with "blocknum".  The blocknum of each primary block is
+its index (starting from zero), so the 0'th block is the first primary block,
+which is the first few bytes of the file, the 1'st block is the next primary
+block, which is the next few bytes of the file, and so on.  The last primary
+block has blocknum k-1.  The blocknum of each secondary block is an arbitrary
+integer between k and 255 inclusive.  (When using the Python API, if you don't
+specify which secondary blocks you want when invoking encode(), then it will by
+default provide the blocks with ids from k to m-1 inclusive.)
+
+- C API
+
+  fec_encode() takes as input an array of k pointers, where each
+  pointer points to a memory buffer containing the input data (i.e.,
+  the i'th buffer contains the i'th primary block).  There is also a
+  second parameter which is an array of the blocknums of the secondary
+  blocks which are to be produced.  (Each element in that array is
+  required to be the blocknum of a secondary block, i.e. it is
+  required to be >= k and < m.)
+
+  The output from fec_encode() is the requested set of secondary
+  blocks which are written into output buffers provided by the caller.
+
+  Note that this fec_encode() is a "low-level" API in that it requires
+  the input data to be provided in a set of memory buffers of exactly
+  the right sizes.  If you are starting instead with a single buffer
+  containing all of the data then please see easyfec.py's "class
+  Encoder" as an example of how to split a single large buffer into
+  the appropriate set of input buffers for fec_encode().  If you are
+  starting with a file on disk, then please see filefec.py's
+  encode_file_stringy_easyfec() for an example of how to read the data
+  from a file and pass it to "class Encoder".  The Python interface
+  provides these higher-level operations, as does the Haskell
+  interface.  If you implement functions to do these higher-level
+  tasks in other languages than Python or Haskell, then please send a
+  patch to zfec-dev@allmydata.org so that your API can be included in
+  future releases of zfec.
+
+  fec_decode() takes as input an array of k pointers, where each
+  pointer points to a buffer containing a block.  There is also a
+  separate input parameter which is an array of blocknums, indicating
+  the blocknum of each of the blocks which is being passed in.
+
+  The output from fec_decode() is the set of primary blocks which were
+  missing from the input and had to be reconstructed.  These
+  reconstructed blocks are written into output buffers provided by the
+  caller.
+
+
+- Python API
+
+  encode() and decode() take as input a sequence of k buffers, where a
+  "sequence" is any object that implements the Python sequence
+  protocol (such as a list or tuple) and a "buffer" is any object that
+  implements the Python buffer protocol (such as a string or array).
+  The contents that are required to be present in these buffers are
+  the same as for the C API.
+
+  encode() also takes a list of desired blocknums.  Unlike the C API,
+  the Python API accepts blocknums of primary blocks as well as
+  secondary blocks in its list of desired blocknums.  encode() returns
+  a list of buffer objects which contain the blocks requested.  For
+  each requested block which is a primary block, the resulting list
+  contains a reference to the apppropriate primary block from the
+  input list.  For each requested block which is a secondary block,
+  the list contains a newly created string object containing that
+  block.
+
+  decode() also takes a list of integers indicating the blocknums of
+  the blocks being passed int.  decode() returns a list of buffer
+  objects which contain all of the primary blocks of the original data
+  (in order).  For each primary block which was present in the input
+  list, then the result list simply contains a reference to the object
+  that was passed in the input list.  For each primary block which was
+  not present in the input, the result list contains a newly created
+  string object containing that primary block.
+
+  Beware of a "gotcha" that can result from the combination of mutable
+  data and the fact that the Python API returns references to inputs
+  when possible.
+
+  Returning references to its inputs is efficient since it avoids
+  making an unnecessary copy of the data, but if the object which was
+  passed as input is mutable and if that object is mutated after the
+  call to zfec returns, then the result from zfec -- which is just a
+  reference to that same object -- will also be mutated.  This
+  subtlety is the price you pay for avoiding data copying.  If you
+  don't want to have to worry about this then you can simply use
+  immutable objects (e.g. Python strings) to hold the data that you
+  pass to zfec.
+
+- Haskell API
+
+  The Haskell code is fully Haddocked, to generate the documentation, run
+    % runhaskell Setup.lhs haddock
+
+
+Utilities
+---------
+
+The filefec.py module has a utility function for efficiently reading a file and
+encoding it piece by piece.  This module is used by the "zfec" and "zunfec"
+command-line tools from the bin/ directory.
+
+
+Dependencies
+------------
+
+A C compiler is required.  To use the Python API or the command-line
+tools a Python interpreter is also required.  We have tested it with
+Python v2.4, v2.5, v2.6, and v2.7.  For the Haskell interface, GHC >=
+6.8.1 is required.
+
+
+Acknowledgements
+----------------
+
+Thanks to the author of the original fec lib, Luigi Rizzo, and the folks that
+contributed to it: Phil Karn, Robert Morelos-Zaragoza, Hari Thirumoorthy, and
+Dan Rubenstein.  Thanks to the Mnet hackers who wrote an earlier Python wrapper,
+especially Myers Carpenter and Hauke Johannknecht.  Thanks to Brian Warner and
+Amber O'Whielacronx for help with the API, documentation, debugging,
+compression, and unit tests.  Thanks to Adam Langley for improving the C API and
+contributing the Haskell API.  Thanks to the creators of GCC (starting with
+Richard M. Stallman) and Valgrind (starting with Julian Seward) for a pair of
+excellent tools.  Thanks to my coworkers at Allmydata -- http://allmydata.com --
+Fabrice Grinda, Peter Secor, Rob Kinninmont, Brian Warner, Zandr Milewski,
+Justin Boreta, Mark Meras for sponsoring this work and releasing it under a Free
+Software licence. Thanks to Jack Lloyd, Samuel Neves, and David-Sarah Hopwood.
+
+
+Enjoy!
+
+Zooko Wilcox-O'Hearn
+
+2010-12-04
+
+Boulder, Colorado
diff --git a/zfec/README.txt b/zfec/README.txt
deleted file mode 100644 (file)
index 8c3b51f..0000000
+++ /dev/null
@@ -1,273 +0,0 @@
- * Intro and Licence
-
-This package implements an "erasure code", or "forward error correction code".
-
-You may use this package under the GNU General Public License, version 2 or, at
-your option, any later version.  You may use this package under the Transitive
-Grace Period Public Licence, version 1.0 or, at your option, any later version.
-(You may choose to use this package under the terms of either licence, at your
-option.)  See the file COPYING.GPL for the terms of the GNU General Public
-License, version 2.  See the file COPYING.TGPPL.html for the terms of the
-Transitive Grace Period Public Licence, version 1.0.  In addition, Allmydata,
-Inc. offers other licensing terms.  If you would like to inquire about a
-commercial relationship with Allmydata, Inc., please contact
-partnerships@allmydata.com and visit http://allmydata.com .
-
-The most widely known example of an erasure code is the RAID-5 algorithm which
-makes it so that in the event of the loss of any one hard drive, the stored data
-can be completely recovered.  The algorithm in the zfec package has a similar
-effect, but instead of recovering from the loss of only a single element, it can
-be parameterized to choose in advance the number of elements whose loss it can
-tolerate.
-
-This package is largely based on the old "fec" library by Luigi Rizzo et al.,
-which is a mature and optimized implementation of erasure coding.  The zfec
-package makes several changes from the original "fec" package, including
-addition of the Python API, refactoring of the C API to support zero-copy
-operation, a few clean-ups and optimizations of the core code itself, and the
-addition of a command-line tool named "zfec".
-
-
- * Installation
-
-This package is managed with the "setuptools" package management tool.  To build
-and install the package directly into your system, just run "python ./setup.py
-install".  If you prefer to keep the package limited to a specific directory so
-that you can manage it yourself (perhaps by using the "GNU stow") tool, then
-give it these arguments: "python ./setup.py install
---single-version-externally-managed
---record=${specificdirectory}/zfec-install.log --prefix=${specificdirectory}"
-
-To run the self-tests, execute "python ./setup.py test" (or if you have Twisted
-Python installed, you can run "trial zfec" for nicer output and test options.)
-This will run the tests of the C API, the Python API, and the command-line
-tools.
-
-To run the tests of the Haskell API:
-  % runhaskell haskell/test/FECTest.hs
-
-Note that in order to run the Haskell API tests you must have installed the
-library first due to the fact that the interpreter cannot process FEC.hs as it
-takes a reference to an FFI function.
-
-
- * Community
-
-The source is currently available via darcs on the web with the command:
-
-darcs get http://allmydata.org/source/zfec/trunk
-
-More information on darcs is available at http://darcs.net
-
-Please join the zfec mailing list and submit patches:
-
-<http://allmydata.org/cgi-bin/mailman/listinfo/zfec-dev>
-
-
- * Overview
-
-This package performs two operations, encoding and decoding.  Encoding takes
-some input data and expands its size by producing extra "check blocks", also
-called "secondary blocks".  Decoding takes some data -- any combination of
-blocks of the original data (called "primary blocks") and "secondary blocks",
-and produces the original data.
-
-The encoding is parameterized by two integers, k and m.  m is the total number
-of blocks produced, and k is how many of those blocks are necessary to
-reconstruct the original data.  m is required to be at least 1 and at most 256,
-and k is required to be at least 1 and at most m.
-
-(Note that when k == m then there is no point in doing erasure coding -- it
-degenerates to the equivalent of the Unix "split" utility which simply splits
-the input into successive segments.  Similarly, when k == 1 it degenerates to
-the equivalent of the unix "cp" utility -- each block is a complete copy of the
-input data.)
-
-Note that each "primary block" is a segment of the original data, so its size is
-1/k'th of the size of original data, and each "secondary block" is of the same
-size, so the total space used by all the blocks is m/k times the size of the
-original data (plus some padding to fill out the last primary block to be the
-same size as all the others).  In addition to the data contained in the blocks
-themselves there are also a few pieces of metadata which are necessary for later
-reconstruction.  Those pieces are: 1.  the value of K, 2.  the value of M, 3.
-the sharenum of each block, 4.  the number of bytes of padding that were used.
-The "zfec" command-line tool compresses these pieces of data and prepends them
-to the beginning of each share, so each the sharefile produced by the "zfec"
-command-line tool is between one and four bytes larger than the share data
-alone.
-
-The decoding step requires as input k of the blocks which were produced by the
-encoding step.  The decoding step produces as output the data that was earlier
-input to the encoding step.
-
-
- * Command-Line Tool
-
-The bin/ directory contains two Unix-style, command-line tools "zfec" and
-"zunfec".  Execute "zfec --help" or "zunfec --help" for usage instructions.
-
-Note: a Unix-style tool like "zfec" does only one thing -- in this case erasure
-coding -- and leaves other tasks to other tools.  Other Unix-style tools that go
-well with zfec include "GNU tar" or "7z" a.k.a. "p7zip" for archiving multiple
-files and directories into one file, "7z" or "rzip" for compression, and "GNU Privacy
-Guard" for encryption or "sha256sum" for integrity.  It is important to do
-things in order: first archive, then compress, then either encrypt or sha256sum,
-then erasure code.  Note that if GNU Privacy Guard is used for privacy, then it
-will also ensure integrity, so the use of sha256sum is unnecessary in that case.
-Note that if 7z is used for archiving then it also does compression, so you
-don't need a separate compressor in that case.
-
-
- * Performance
-
-On my Athlon 64 2.4 GHz workstation (running Linux), the "zfec" command-line
-tool encoded a 160 MB file with m=100, k=94 (about 6% redundancy) in 3.9
-seconds, where the "par2" tool encoded the file with about 6% redundancy in 27
-seconds.  zfec encoded the same file with m=12, k=6 (100% redundancy) in 4.1
-seconds, where par2 encoded it with about 100% redundancy in 7 minutes and 56
-seconds.
-
-The underlying C library in benchmark mode encoded from a file at about 4.9
-million bytes per second and decoded at about 5.8 million bytes per second.
-
-On Peter's fancy Intel Mac laptop (2.16 GHz Core Duo), it encoded from a file at
-about 6.2 million bytes per second.
-
-On my even fancier Intel Mac laptop (2.33 GHz Core Duo), it encoded from a file
-at about 6.8 million bytes per second.
-
-On my old PowerPC G4 867 MHz Mac laptop, it encoded from a file at about 1.3
-million bytes per second.
-
-Here is a paper analyzing the performance of various erasure codes and their
-implementations, including zfec:
-
-http://www.usenix.org/events/fast09/tech/full_papers/plank/plank.pdf
-
-Zfec shows good performance on different machines and with different values of
-K and M. It also has a nice small memory footprint.
-
-
- * API
-
-Each block is associated with "blocknum".  The blocknum of each primary block is
-its index (starting from zero), so the 0'th block is the first primary block,
-which is the first few bytes of the file, the 1'st block is the next primary
-block, which is the next few bytes of the file, and so on.  The last primary
-block has blocknum k-1.  The blocknum of each secondary block is an arbitrary
-integer between k and 255 inclusive.  (When using the Python API, if you don't
-specify which secondary blocks you want when invoking encode(), then it will by
-default provide the blocks with ids from k to m-1 inclusive.)
-
- ** C API
-
-fec_encode() takes as input an array of k pointers, where each pointer points to
-a memory buffer containing the input data (i.e., the i'th buffer contains the
-i'th primary block).  There is also a second parameter which is an array of the
-blocknums of the secondary blocks which are to be produced.  (Each element in
-that array is required to be the blocknum of a secondary block, i.e. it is
-required to be >= k and < m.)
-
-The output from fec_encode() is the requested set of secondary blocks which are
-written into output buffers provided by the caller.
-
-Note that this fec_encode() is a "low-level" API in that it requires the input
-data to be provided in a set of memory buffers of exactly the right sizes.  If
-you are starting instead with a single buffer containing all of the data then
-please see easyfec.py's "class Encoder" as an example of how to split a single
-large buffer into the appropriate set of input buffers for fec_encode().  If you
-are starting with a file on disk, then please see filefec.py's
-encode_file_stringy_easyfec() for an example of how to read the data from a file
-and pass it to "class Encoder".  The Python interface provides these
-higher-level operations, as does the Haskell interface.  If you implement
-functions to do these higher-level tasks in other languages than Python or
-Haskell, then please send a patch to zfec-dev@allmydata.org so that your API can
-be included in future releases of zfec.
-
-
-fec_decode() takes as input an array of k pointers, where each pointer points to
-a buffer containing a block.  There is also a separate input parameter which is
-an array of blocknums, indicating the blocknum of each of the blocks which is
-being passed in.
-
-The output from fec_decode() is the set of primary blocks which were missing
-from the input and had to be reconstructed.  These reconstructed blocks are
-written into output buffers provided by the caller.
-
-
- ** Python API
-
-encode() and decode() take as input a sequence of k buffers, where a "sequence"
-is any object that implements the Python sequence protocol (such as a list or
-tuple) and a "buffer" is any object that implements the Python buffer protocol
-(such as a string or array).  The contents that are required to be present in
-these buffers are the same as for the C API.
-
-encode() also takes a list of desired blocknums.  Unlike the C API, the Python
-API accepts blocknums of primary blocks as well as secondary blocks in its list
-of desired blocknums.  encode() returns a list of buffer objects which contain
-the blocks requested.  For each requested block which is a primary block, the
-resulting list contains a reference to the apppropriate primary block from the
-input list.  For each requested block which is a secondary block, the list
-contains a newly created string object containing that block.
-
-decode() also takes a list of integers indicating the blocknums of the blocks
-being passed int.  decode() returns a list of buffer objects which contain all
-of the primary blocks of the original data (in order).  For each primary block
-which was present in the input list, then the result list simply contains a
-reference to the object that was passed in the input list.  For each primary
-block which was not present in the input, the result list contains a newly
-created string object containing that primary block.
-
-Beware of a "gotcha" that can result from the combination of mutable data and
-the fact that the Python API returns references to inputs when possible.
-
-Returning references to its inputs is efficient since it avoids making an
-unnecessary copy of the data, but if the object which was passed as input is
-mutable and if that object is mutated after the call to zfec returns, then the
-result from zfec -- which is just a reference to that same object -- will also
-be mutated.  This subtlety is the price you pay for avoiding data copying.  If
-you don't want to have to worry about this then you can simply use immutable
-objects (e.g. Python strings) to hold the data that you pass to zfec.
-
- ** Haskell API
-
-The Haskell code is fully Haddocked, to generate the documentation, run
-  % runhaskell Setup.lhs haddock
-
-
- * Utilities
-
-The filefec.py module has a utility function for efficiently reading a file and
-encoding it piece by piece.  This module is used by the "zfec" and "zunfec"
-command-line tools from the bin/ directory.
-
-
- * Dependencies
-
-A C compiler is required.  To use the Python API or the command-line tools a
-Python interpreter is also required.  We have tested it with Python v2.4 and
-v2.5.  For the Haskell interface, GHC >= 6.8.1 is required.
-
-
- * Acknowledgements
-
-Thanks to the author of the original fec lib, Luigi Rizzo, and the folks that
-contributed to it: Phil Karn, Robert Morelos-Zaragoza, Hari Thirumoorthy, and
-Dan Rubenstein.  Thanks to the Mnet hackers who wrote an earlier Python wrapper,
-especially Myers Carpenter and Hauke Johannknecht.  Thanks to Brian Warner and
-Amber O'Whielacronx for help with the API, documentation, debugging,
-compression, and unit tests.  Thanks to Adam Langley for improving the C API and
-contributing the Haskell API.  Thanks to the creators of GCC (starting with
-Richard M. Stallman) and Valgrind (starting with Julian Seward) for a pair of
-excellent tools.  Thanks to my coworkers at Allmydata -- http://allmydata.com --
-Fabrice Grinda, Peter Secor, Rob Kinninmont, Brian Warner, Zandr Milewski,
-Justin Boreta, Mark Meras for sponsoring this work and releasing it under a Free
-Software licence. Thanks to Jack Lloyd, Samuel Neves, and David-Sarah Hopwood.
-
-
-Enjoy!
-
-Zooko Wilcox-O'Hearn
-2010-05-24
-Boulder, Colorado
index 064820438c01c2e0e21b1a41a628f97d6f99be83..9043b9608efb44f28f6eceb6d74727fd7e452a94 100644 (file)
@@ -1,7 +1,7 @@
 name:            fec
 version:         0.1.1
 license:         GPL
-license-file:    README.txt
+license-file:    README.rst
 author:          Adam Langley <agl@imperialviolet.org>
 maintainer:      Adam Langley <agl@imperialviolet.org>
 description:     This code, based on zfec by Zooko, based on code by Luigi
index b3b5db723470f4b846a496d5ef4ed394cf6cdba1..a389eff6bd123b5827400018e483e66f588cb095 100644 (file)
@@ -2,7 +2,7 @@
 -- |
 -- Module:    Codec.FEC
 -- Copyright: Adam Langley
--- License:   GPLv2+|TGPPLv1+ (see README.txt for details)
+-- License:   GPLv2+|TGPPLv1+ (see README.rst for details)
 --
 -- Stability: experimental
 --
index c45b1448c3e2557269be7f6c5b842a5a93a32154..f3474d9cd54966f5f5f4ac2c1009a617805297f5 100755 (executable)
@@ -7,7 +7,7 @@
 #
 # This file is part of zfec.
 #
-# See README.txt for licensing information.
+# See README.rst for licensing information.
 
 import glob, os, re, sys
 
@@ -133,42 +133,30 @@ if "--reporter=bwverbose-coverage" in sys.argv:
 if "sdist_dsc" in sys.argv:
     setup_requires.append('stdeb')
 
-data_fnames=[ 'COPYING.GPL', 'changelog', 'COPYING.TGPPL.html', 'TODO', 'README.txt' ]
+data_fnames=[ 'COPYING.GPL', 'changelog', 'COPYING.TGPPL.html', 'TODO', 'README.rst' ]
 
 # In case we are building for a .deb with stdeb's sdist_dsc command, we put the
 # docs in "share/doc/$PKG".
 doc_loc = "share/doc/" + PKG
 data_files = [(doc_loc, data_fnames)]
 
-def _setup(test_suite):
-    setup(name=PKG,
-          version=verstr,
-          description='a fast erasure codec which can be used with the command-line, C, Python, or Haskell',
-          long_description='Fast, portable, programmable erasure coding a.k.a. "forward error correction": the generation of redundant blocks of information such that if some blocks are lost then the original data can be recovered from the remaining blocks.  The zfec package includes command-line tools, C API, Python API, and Haskell API',
-          author='Zooko O\'Whielacronx',
-          author_email='zooko@zooko.com',
-          url='http://allmydata.org/trac/'+PKG,
-          license='GNU GPL',
-          install_requires=["argparse >= 0.8", "pyutil >= 1.3.19"],
-          tests_require=tests_require,
-          packages=find_packages(),
-          include_package_data=True,
-          data_files=data_files,
-          setup_requires=setup_requires,
-          classifiers=trove_classifiers,
-          entry_points = { 'console_scripts': [ 'zfec = %s.cmdline_zfec:main' % PKG, 'zunfec = %s.cmdline_zunfec:main' % PKG ] },
-          ext_modules=[Extension(PKG+'._fec', [PKG+'/fec.c', PKG+'/_fecmodule.c',], extra_link_args=extra_link_args, extra_compile_args=extra_compile_args, undef_macros=undef_macros, define_macros=define_macros),],
-          test_suite=test_suite,
-          zip_safe=False, # I prefer unzipped for easier access.
-          )
-
-test_suite_name=PKG+".test"
-try:
-    _setup(test_suite=test_suite_name)
-except Exception, le:
-    # to work around a bug in Elisa v0.3.5
-    # https://bugs.launchpad.net/elisa/+bug/263697
-    if "test_suite must be a list" in str(le):
-        _setup(test_suite=[test_suite_name])
-    else:
-        raise
+setup(name=PKG,
+      version=verstr,
+      description='a fast erasure codec which can be used with the command-line, C, Python, or Haskell',
+      long_description = open('README.rst').read(),
+      author='Zooko O\'Whielacronx',
+      author_email='zooko@zooko.com',
+      url='http://tahoe-lafs.org/trac/'+PKG,
+      license='GNU GPL',
+      install_requires=["argparse >= 0.8", "pyutil >= 1.3.19"],
+      tests_require=tests_require,
+      packages=find_packages(),
+      include_package_data=True,
+      data_files=data_files,
+      setup_requires=setup_requires,
+      classifiers=trove_classifiers,
+      entry_points = { 'console_scripts': [ 'zfec = %s.cmdline_zfec:main' % PKG, 'zunfec = %s.cmdline_zunfec:main' % PKG ] },
+      ext_modules=[Extension(PKG+'._fec', [PKG+'/fec.c', PKG+'/_fecmodule.c',], extra_link_args=extra_link_args, extra_compile_args=extra_compile_args, undef_macros=undef_macros, define_macros=define_macros),],
+      test_suite=PKG+".test",
+      zip_safe=False, # I prefer unzipped for easier access.
+      )
index d3e742f4d39830e12f7bbd68deec64612aca5454..475acf987b7ba0af4ad7b3f2bd3cf80bf7213a0d 100644 (file)
@@ -28,4 +28,4 @@ quiet_pyflakes=[__version__, Error, Encoder, Decoder, cmdline_zunfec, filefec, c
 #
 # This file is part of zfec.
 #
-# See README.txt for licensing information.
+# See README.rst for licensing information.
index c1389be63bb3378f1c8cb4d58b0e9a0cf581830c..2eee2b0e2726e9e754021472ac41e6e69184627e 100755 (executable)
@@ -69,4 +69,4 @@ def main():
 #
 # This file is part of zfec.
 #
-# See README.txt for licensing information.
+# See README.rst for licensing information.
index f7d7f0c71d5e8af1898de32516eaafb20d10ec6d..8fc0c040dfd7a325ff2a6fe1cba0b093852aab0a 100755 (executable)
@@ -63,4 +63,4 @@ def main():
 # 
 # This file is part of zfec.
 #
-# See README.txt for licensing information.
+# See README.rst for licensing information.
index 997000a909b3444cbe8097722750ca39a2d7cc6b..dd209e788d7602dd5dd69fcefd13e89d124fc237 100644 (file)
@@ -61,4 +61,4 @@ class Decoder(object):
 # 
 # This file is part of zfec.
 # 
-# See README.txt for licensing information.
+# See README.rst for licensing information.
index a18a4f69bfc26473473e1d59037c72d2f7dedb1b..751c00a77ebad4cec3f5169d7abcf9cc7d38c43b 100644 (file)
@@ -529,7 +529,7 @@ fec_decode(const fec_t* code, const gf*restrict const*restrict const inpkts, gf*
  *
  * This file is part of zfec.
  *
- * See README.txt for licensing information.
+ * See README.rst for licensing information.
  */
 
 /*
index 2ebab3249ea61d075826d826b071ea32d8ce9ef6..249fe666f495f647892b73d234d769f5e77e4c77 100644 (file)
@@ -1,7 +1,7 @@
 /**
  * zfec -- fast forward error correction library with Python interface
  *
- * See README.txt for documentation.
+ * See README.rst for documentation.
  */
 
 #include <stddef.h>
@@ -64,7 +64,7 @@ void fec_decode(const fec_t* code, const gf*restrict const*restrict const inpkts
  * 
  * This file is part of zfec.
  * 
- * See README.txt for licensing information.
+ * See README.rst for licensing information.
  */
 
 /*
index 25b6513a5e84f682653368aac963e1ebbe2b74d5..48f3d9d790edac6b15b9cf433f99d2af9b1d274f 100644 (file)
@@ -501,4 +501,4 @@ def encode_file_stringy_easyfec(inf, cb, k, m, chunksize=4096):
 #
 # This file is part of zfec.
 #
-# See README.txt for licensing information.
+# See README.rst for licensing information.