nextBTreeItems() and nextTreeSetItems():  ditto.

the recursion (iteration is quite natural here -- it was tail-recursive).

self, which effectively turned the error into a fatal error.  Fixed.

code, are bogus when PERSISTENCE is #define'd.  Repair them.

a BTree is empty if and only if its firstbucket pointer is
NULL, so there's no need to keep checking nonzero inside the
loop.  Also, the pointers here are all local, so there's no
need to incref and decref them -- the apparent necessity was
just an artifact of using the bucket assignment macros.  So
stopped using those macros, and the need for incref/decref
operations went away too.

PyVar_AssignB(), ASSIGNB(), ASSIGNBC():  Turned out these
are no longer used anywhere anymore, so removed them.

PER_UNUSE():  New macro to capture the endlessly repeated
PER_ALLOW_DEACTIVATION + PER_ACCESSED pair.  As the comment
says, so sue me <wink>.

Bucket_deleteNextBucket():  Documented & simplified.

of verifying that BTree invariants are satisfied, raising AssertionError
if they're not.  Nothing calls this method by magic; it's for debugging.

some of this code is needed, and to help track down an odd bug Guido is
seeing.  assert()s won't trigger except in a debug build.

The old ZEO test suite does not accept description as a keyword arg.
Luckily the description is only there to help debug problems; it isn't
required for successful completion of the test.

PyMalloc(), PyRealloc():  Call malloc() and realloc() directly instead
of PyMem_Malloc() and PyMem_Realloc().  If the latter are used, then
memory must be freed via PyMem_Free(), but PyMem_Free() isn't called
anywhere -- memory is released via raw system free().  It would probably
be better to change all uses of free() instead, but that's A Project (well,
compared to this ...).

is now almost as simple as it's been trying to be <wink>.

mean any of no error, an expected index error, or an unexpected error;
naturally, callers conflated those.  The return value now distinguishes
among the cases.

BTreeItems_seek():  Use the new form of PreviousBucket().

purpose wasn't clear, and the few places that bothered to call them seemed
to be trying to cater to empty buckets.  But empty buckets aren't legitimate
in a BTree (or, if they are, lots of BTree code is broken).

BTreeItems struct:  finished figuring out what's in this, and documented it.

BTreeItems_seek():  rewrote and simplified, to avoid use of the now-
removed XYZBucketOffset() functions.  Repaired places where bucket access
time wasn't getting updated.  There are still insecurities in its use of
PreviousBucket() (for another day).

BTreeItems_slice():  now that I know what it is <wink>, create an empty
slice in the intended way.

NewBTreeItems():  documented its calling sequence, and added code to
protect against a NULL highbucket argument.

BTree_maxminKey():  no longer calls the XYZBucketOffset() functions.

a BTree in an invalid state.  Normally, _BTree_set() repairs this before
return, but in case of error may not.  Now it does.

an error return leaked references.

a BTree in an invalid state when called with an empty BTree.  I still
need to change callers to ensure that the BTree is never left in that
invalid state (it can be now).

between the Zope2 and Zope3 versions.

deletion endcases uncovered by the new degenerate-BTree tests.  The
degenerate testDeletes() and testEmptyFirstBucketReportedByGuido() are
enabled now.

disabled for now, because it dies in lots of ways.  I hope, but don't know,
that they're all related to "Guido's bug".

Also backported the "Guido's bug" test case from the Zope3 project.  This
is also disabled for now.

changed() in cPersistence.c now calls the jar's register() method.
Connection's register() method just calls get_transaction().register().

This redirection would allow specialized Connection's to change the
default policy on how the transaction manager is selected without
hacking the Transaction module.

The cPersistence.c code is based on _PyPersist_RegisterDataManager()
from the Zope3 code.

XXX Should start still do path munging?

search returned a seemingly random slice of the tree.  A new test on the
painfully constructed highly-degenerate BTree turned up lots of these.
It turns out that BTree_rangeSearch had a much harder job than it
thought it had <0.7 wink>.

for lo > hi either, except if they happened to be in the same bucket.  All
sorts of strange results followed (the range should be empty if lo > hi,
and is after this patch).

passed in, it was quite possible for this to return *low > *high, and the
caller could crash due to trying to create a list with "negative length".
Changed the routine to consider a range empty if min>max on input, and added
test cases that fail before this patch.

legitimate) BTree.  New test testDegenerateBasicOps() does basic sanity
checks on it.  More tests against this tree will follow.

classes entirely (like for IITreeSets), and to run other test classes
twice.

plus cleanup of a previous such fix.

bucket reference.

BTree_rangeSearch():  Fixed one place likewise.

little on redundant activations.

key S in a bucket in a BTree is deleted, doing a range search on the
BTree with S on the high end may claim that the range is empty even when
it's not.  It proved difficult to fix this correctly and efficiently in
all cases (our BTrees don't like "searching backwards").  The
implementation here is a new and non-recursive one (in effect, to do
this efficiently you have to remember the deepest point in the tree where
it was *possible* to "go one left" of where binary search tells you to go;
an iterative algorithm makes that part all but obvious).  Alas, the
number of uses of persistence macros is amazing, unfortunately making
this still-hairy algorithm hard to follow.

testPathologicalRangeSearch():  uncommented the lines that failed
before this patch.  They pass now.

Insecurity:  The test case only exercises the simplest possible form
of the failure.  Any failing case is hard to provoke, even the simplest.
The hairier failing cases require generating degenerate trees, deep
and with some interior nodes near the top having just one or two children
(since the tree needs to be deep too, that isn't easy to provoke).  I'll
think about how to provoke this without needing to build up multi-million
element trees first; maybe using __setstate__ directly is the answer.