- 10 Jun, 2002 5 commits
-
-
Tim Peters authored
and Zope3 branch versions of this function. No semantic change.
-
Shane Hathaway authored
-
Tim Peters authored
-
Tim Peters authored
to figure out to fix the off-by-1 bug in BTreeItems_slice().
-
Tim Peters authored
-
- 09 Jun, 2002 6 commits
-
-
Tim Peters authored
"next" functions, these can return a PER_USE() error *after* decrefing the keys and values left over from the last call. But they don't mark the iteration as terminated, so finiSetIteration() will also try to decref the leftovers. The fix is to mark the iteration as terminated when these functions fail.
-
http://collector.zope.org/Zope/419Tim Peters authored
"BTreeItems slice contains 1 too many elements" This also fixes many related glitches, such as that giving an out-of-bound slice index raised IndexError instead of clipping. BTreeItems_slice(): Emulate Python slicing semantics in all cases. testBTrees.py: new testSlicing() tests in MappingBase and NormalSetTests to ensure that slicing of .keys()/.items()/.values() works exactly the same way as slicing of Python lists, in all one-sided, two-sided and whole-structure ([:]) cases, with both negative and positive slice indices, and mixtures of + and -, and whether in bounds or out of bounds.
-
Tim Peters authored
-
Tim Peters authored
-
Tim Peters authored
-
Tim Peters authored
+ Documented the arguments. + Used BUCKET_SEARCH. + Vastly reduced nesting. + Changed the "*changed" argument to get set true whenever PER_CHANGED is called, i.e. whenever the bucket mutates. The purpose of *changed wasn't documented, and its only use was in the BTree set routine, which is known to have at least one bug. So it wasn't clear what the purpose of *changed was. What it did do is get set true if and only if the key was found in the bucket and its value was replaced, and I couldn't imagine a plausible reason for why the BTree set routine could care about that alone (all other calls to _bucket_set pass NULL, so there were no other clues). + Fixed all places where error returns didn't finish the persistence dance.
-
- 08 Jun, 2002 6 commits
-
-
Tim Peters authored
micro-optimized BUCKET_SEARCH macro. Change _bucket_get() to use it (more later).
-
Tim Peters authored
way out of date (prints stuff and asserts instead of raising unittest failures).
-
Tim Peters authored
does.
-
Tim Peters authored
-
Tim Peters authored
iteration protocol a destructor (finiSetIteration()), to plug assorted leaks of keys, values and even BTree nodes.
-
Tim Peters authored
-
- 07 Jun, 2002 2 commits
-
-
Jim Fulton authored
modifications were needed in Zope (only two files). A lot of unused (or rarely) features were removed from the Interface package. Slightly deeper imports are needed.
-
Tim Peters authored
initSetIteration(), because it specifically doesn't want to bother getting values out of mappings.
-
- 06 Jun, 2002 2 commits
-
-
Tim Peters authored
-
Jeremy Hylton authored
-
- 05 Jun, 2002 2 commits
-
-
Tim Peters authored
Elsewhere, repaired all other known cases where uses of the TEST_KEY_OR_SET macro did early exits without finishing persistence dances (Jeremy confirmed that's a Bad Thing -- creates unghostifiable cache hogs).
-
Tim Peters authored
a persistence dance on the buckets/sets it handles directly by itself. If so, a similar but different change is also needed on the Zope3 branch.
-
- 03 Jun, 2002 2 commits
-
-
Tim Peters authored
-
Tim Peters authored
SetIteration structs.
-
- 02 Jun, 2002 2 commits
-
-
Tim Peters authored
-
Tim Peters authored
Added lots of comments as a result. Redid parts of multiunion() because it was clearly leaking references tucked away inside its SetIteration struct. Added XXX comments in another place I'm pretty sure is leaking similar references in error cases (but am too tired to fix that now, if so).
-
- 01 Jun, 2002 2 commits
-
-
Tim Peters authored
-
Tim Peters authored
this now copies the keys into the work area in one gulp via memcpy, instead of iterating over them one at a time. Yields a nice speedup when it applies (and it usually should apply!).
-
- 31 May, 2002 11 commits
-
-
Tim Peters authored
from a sequence of ints in reverse-sorted order (a quadratic-time proposition). That doesn't test anything interesting in context, though. So fiddled it to do a larger input, but it runs much faster now.
-
Tim Peters authored
-
Tim Peters authored
-
Tim Peters authored
to squash delicate code duplication and for speed. + This is optimized in several subtle ways over the current method. This is documented in Maintainer.txt, along with a correctness proof. + I'll replace all the BTree searches with this soon. For now I just changed _BTree_get(). I *suspect* this also fixes a subtle bug introduced by the recent "don't ignore comparison error" patch: if a comparison did trigger an exception, the function just returned without doing the PER_ALLOW_DEACTIVATION + PER_ACCESSED dance. _BTree_get() does that dance again now.
-
Tim Peters authored
-
Tim Peters authored
-
Tim Peters authored
follows from that.
-
Tim Peters authored
neglected to change the name in new comments barely an hour old.
-
Tim Peters authored
"value" to "child". All the rest is mechanical name-changing. Next step is to change the decl of child from PyObject* to Sized*.
-
Tim Peters authored
the common initial fields (pyobject hair, persistence hair, 'size', and 'len'). I think Jim wants the data decls split into a separate file, but I'm unclear on why so am not doing that now. Renamed stuff for consistency. Added some comments. More BTree comments will end up in Maintainer.txt.
-
Tim Peters authored
+ Added interface docs. + Gave it a new "newsize" argument, for when the caller can gain speed by knowing in advance how many additional elements are needed. This isn't used yet, but will be by multiunion and planned "lopsided merge" optimizations (the intent is to grow the bucket big enough in one shot, then memcpy a large slice into the bucket). + When doubling the size, now sets a MemoryError exception on int overflow.
-