An error occurred fetching the project authors.
  1. 17 Jun, 2002 2 commits
  2. 14 Jun, 2002 1 commit
  3. 13 Jun, 2002 7 commits
    • Tim Peters's avatar
      BTree_rangeSearch(): Repaired more cases where a should-be empty range · ec844e47
      Tim Peters authored
      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>.
      ec844e47
    • Tim Peters's avatar
      BTree_rangeSearch(): Like its bucket counterpart, this wasn't checking · 5183dc97
      Tim Peters authored
      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).
      5183dc97
    • Tim Peters's avatar
      BTree_rangeSearch(): Squash another case of bucket-leak-on-PER_USE-failure, · d9e0c3eb
      Tim Peters authored
      plus cleanup of a previous such fix.
      d9e0c3eb
    • Tim Peters's avatar
      BTree_maxminKey(): Fixed three places where a PER_USE failure leaked a · 71098d51
      Tim Peters authored
      bucket reference.
      
      BTree_rangeSearch():  Fixed one place likewise.
      71098d51
    • Tim Peters's avatar
      BTree_findRangeEnd(): Rearranged the persistence macros to cut down a · a0e097bb
      Tim Peters authored
      little on redundant activations.
      a0e097bb
    • Tim Peters's avatar
      BTree_findRangeEnd(): Fixed "the range search bug": if the smallest · d82d25a3
      Tim Peters authored
      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.
      d82d25a3
    • Tim Peters's avatar
      BTree_lastBucket(): documented what this returns (between who owns · 130af61d
      Tim Peters authored
      references, what must not be and what may be a ghost, and exactly what
      "last" means, it was surprisingly unclear).  Also simplified the
      implementation (to my eyes -- it's arguable, but I'm the one working
      on it, so my eyes count <wink>).  I believe this routine is key to
      fixing the range-search bug efficiently.
      130af61d
  4. 12 Jun, 2002 1 commit
  5. 11 Jun, 2002 6 commits
  6. 10 Jun, 2002 2 commits
  7. 08 Jun, 2002 1 commit
  8. 06 Jun, 2002 1 commit
  9. 31 May, 2002 6 commits
  10. 30 May, 2002 2 commits
  11. 28 May, 2002 1 commit
  12. 27 Mar, 2002 1 commit
  13. 08 Mar, 2002 1 commit
    • Jeremy Hylton's avatar
      (Possibly) correct use of Python memory APIs. · ff24f9df
      Jeremy Hylton authored
      Fix SF bug #516768 reported by Dave Wallace.
      
      Replace use of PyMem_DEL() with PyObject_Del() on object dealloc
      functions.  The use of PyMem_DEL() is incorrect for object
      deallocation, because it only ever calls the low-level free().  If a
      custom allocator like pymalloc is used, it needs to be called to free
      the memory.
      
      Also replace bare malloc() and realloc() with PyMem_Malloc() and
      PyMem_Realloc().  I think this isn't a strict bug fix, but a would be
      nice.  It guarantees that BTrees objects get their memory from the
      same allocator as the Python core.
      ff24f9df
  14. 28 Feb, 2002 1 commit
  15. 21 Feb, 2002 1 commit
  16. 20 Feb, 2002 1 commit
  17. 11 Feb, 2002 1 commit
  18. 28 Nov, 2001 1 commit
  19. 12 Sep, 2001 1 commit
  20. 13 Aug, 2001 1 commit
  21. 20 Jun, 2001 1 commit