from both sides of the split debugger.
M Debugger.py
M EditorWindow.py

2. Remove extraneous comment

M Debugger.py       : Incorporate StackViewer, NamespaceViewer classes
M StackViewer.py    : remove import OldStackViewer
U OldStackViewer.py : remove file

standalone wrap() and fill() functions.  This should address the
misunderstanding that led to SF bug 577106.

have changed.

Uncomment a heading so that PendingDeprecationWarning doesn't seem so
out of place.

Further clarify the English-centricity of fix_sentence_endings.

implementation.

breaks other platforms (in this case, the hack for broken Cray systems in
turn caused failure on a Mac system broken in a different way).

From patch: [ 574532 ] Update freeze to use zlib 1.1.4

attributes of the TestResult.

TestResult object.  Add an example of how to get even more information for
apps that can use it.
Closes SF bug #558278.

binascii_crc32():  The previous patch forced this to return the same
result across platforms.  This patch deals with that, on a 64-bit box,
the *entry* value may have "unexpected" bits in the high four bytes.

Bugfix candidate.

classdesc -- just use "..." with prose explaining the correspondence
between keyword args and instance attributes.

Document 'width' along with the other instance attributes.

Describe default values consistently.

Typo fixes.

don't include a " -> None" for functions that have no return value.

Based on SF bug #574773.

Change the markup to be more like the rest of the documentation.

\py@sigline macro will wrap the argument list so it will not extend into
the right margin.
Substantially based on a contribution from Dave Cole.
This addresses one of the comments in SF bug #574742.

binascii_crc32():  Make this return a signed 4-byte result across
platforms.  The other way to make this platform-independent would be to
make it return an unsigned unbounded int, but the evidence suggests
other code out there treats it like a signed 4-byte int (e.g., existing
code writing the result with struct.pack "l" format).

Bugfix candidate.

This was mostly a matter of adding comments and light code rearrangement.
Upon untracking, gc_next is still set to NULL.  It's a cheap way to
provoke memory faults if calling code is insane.  It's also used in some
way by the trashcan mechanism.

line.

PyErr_SetFromWindowsErrWithFilename().

PyErr_SetFromWindowsErr().
Fixes SF# 576016, with additional markup.

it all inline.

object should now have a well-defined gc_refs value, with clear transitions
among gc_refs states.  As a result, none of the visit_XYZ traversal
callbacks need to check IS_TRACKED() anymore, and those tests were removed.
(They were already looking for objects with specific gc_refs states, and
the gc_refs state of an untracked object can no longer match any other
gc_refs state by accident.)
Added more asserts.
I expect that the gc_next == NULL indicator for an untracked object is
now redundant and can also be removed, but I ran out of time for this.

in gc_refs, even at the cost of putting back a test+branch in
visit_decref.

The good news:  since gc_refs became utterly tame then, it became
clear that another special value could be useful.  The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass.  Besides saving a pass over the generation, this
has a better effect:  most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time.  Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead.  This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.

Still, overall, it yields a significant (but not dramatic) boost in
collection speed.

1. You're not supposed to call this with a NULL argument, although the
   docs could be clearer about that.  The other visit_XYZ() functions
   don't bother to check.  This doesn't either now, although it does
   assert non-NULL-ness now.

2. It doesn't matter whether the object is currently tracked, so don't
   bother checking that either (if it isn't currently tracked, it may
   have some nonsense value in gc_refs, but it doesn't hurt to
   decrement gibberish, and it's cheaper to do so than to make everyone
   test for trackedness).

It would be nice to get rid of the other tests on IS_TRACKED.  Perhaps
trackedness should not be a matter of not being in any gc list, but
should be a matter of being in a new "untracked" gc list.  This list
simply wouldn't be involved in the collection mechanism.  A newly
created object would be put in the untracked list.  Tracking would
simply unlink it and move it into the gen0 list.  Untracking would do
the reverse.  No test+branch needed then.  visit_move() may be vulnerable
then, though, and I don't know how this would work with the trashcan.

"The regression" is actually due to that 2.2.1 had a bug that prevented
the regression (which isn't a regression at all) from showing up.  "The
regression" is actually a glitch in cyclic gc that's been there forever.

As the generation being collected is analyzed, objects that can't be
collected (because, e.g., we find they're externally referenced, or
are in an unreachable cycle but have a __del__ method) are moved out
of the list of candidates.  A tricksy scheme uses negative values of
gc_refs to mark such objects as being moved.  However, the exact
negative value set at the start may become "more negative" over time
for objects not in the generation being collected, and the scheme was
checking for an exact match on the negative value originally assigned.
As a result, objects in generations older than the one being collected
could get scanned too, and yanked back into a younger generation.  Doing
so doesn't lead to an error, but doesn't do any good, and can burn an
unbounded amount of time doing useless work.

A test case is simple (thanks to Kevin Jacobs for finding it!):

x = []
for i in xrange(200000):
    x.append((1,))

Without the patch, this ends up scanning all of x on every gen0 collection,
scans all of x twice on every gen1 collection, and x gets yanked back into
gen1 on every gen0 collection.  With the patch, once x gets to gen2, it's
never scanned again until another gen2 collection, and stays in gen2.

Bugfix candidate, although the code has changed enough that I think I'll
need to port it by hand.  2.2.1 also has a different bug that causes
bound method objects not to get tracked at all (so the test case doesn't
burn absurd amounts of time in 2.2.1, but *should* <wink>).