Subject: CVS commit: pkgsrc/devel/hs-vector-algorithms
From: Ryosuke Moro
Date: 2015-12-13 15:11:25
Message id: 20151213141126.0AD46FB83@cvs.NetBSD.org

Log Message:
Update to 0.7.0.1

Changes from http://hub.darcs.net/dolio/vector-algorithms/changes
TAG 0.7.0.1
	dolio	August 13, 2015

Version bump
	dolio	August 13, 2015

Bump upper bound on vector
	bgamari	August 11, 2015

Updated base bound due to unsafeShiftR
	Pointed out by Adam Bergmark
	dolio	May 05, 2015

TAG 0.7
	dolio	May 05, 2015

Updated copyrights in license file
	dolio	May 05, 2015

Copyright updates
	dolio	April 27, 2015

Moved the gallop searches to the search module
	Also added versions that don't take bounds
	dolio	April 27, 2015

Finished explaining the timsort algorithm
	dolio	April 27, 2015

Improved intro and heap documentation.
	dolio	April 26, 2015

Made an argument stricter in the timsort searches
	dolio	April 26, 2015

Added an option to build with llvm
	dolio	April 23, 2015

Implemented insertion in the heap module.
	dolio	April 21, 2015

Fixed a comment in AmericanFlag caused by a replace
	dolio	April 19, 2015

Added dump-simpl flag to benchmark build
	dolio	April 19, 2015

Resolved version bump conflict
	dolio	April 19, 2015

TAG 0.6.0.4
	dolio	April 01, 2015

Allow building with primitive 0.6
	dolio	April 01, 2015

Fix maintainance of invariant for length of runs
	Timsort maintains a list of sorted segments (called ?runs?) in an list
	called ?runLen?. To ensure that a small array suffices for this, timsort
	imposes an invariant on the lengths of runs: each run must be shorter
	than the preceding run in ?runs? and the sum of the lengths of two
	consecutive runs must be lower than the length of the run preceding the
	two runs. In effect, the (reverted) sequence of run lengths grows at
	least as fast as the fibonacci sequence. The operation that adds a new
	run to the list of runs (and merges runs, if necessary) makes sure that
	the new list ?runLen? satisfies

	runLen [n-2] > runLen [n-1] + runLen [n]
	runLen [n-1] > runLen [n]

	It has recently been discovered that this doesn't suffice to maintain
	the invariant for all triples of consecutive runs:

	http://envisage-project.eu/proving-android-java-and-python-sorting-algorithm-is-broken-and-how-to-fix-it/

	This patch fixes this problem.

	Correctness of the new implementation has been checked with QuickCheck:
	https://gist.github.com/timjb/cca12b004a0c782ca622
	timjb	February 26, 2015

Added a cabal flag to dump core
	dolio	February 10, 2015

cabal updates: added copyright and bumped the upcoming version
	dolio	February 10, 2015

Implement timsort
	Differences from timsort.txt: Galloping is used only once, when an element is
	chosen 7 times from the same run; this threshold is not updated according to
	how successful galloping is.
	timjb	February 08, 2015

Files:
RevisionActionfile
1.5modifypkgsrc/devel/hs-vector-algorithms/Makefile
1.2modifypkgsrc/devel/hs-vector-algorithms/PLIST
1.6modifypkgsrc/devel/hs-vector-algorithms/buildlink3.mk
1.3modifypkgsrc/devel/hs-vector-algorithms/distinfo