I'm only seeing "undefined reference to ..." errors in the CMake
build on a specific machine; I'm not sure why they're only cropping
up in that scenario.

I think these functions are only referenced from dead functions,
and in other environments the chains get dead-stripped.

(We weren't including all of them)

Our previous directory names:
include/
lib_python/2.7/
lib_python/2.7_Modules/
lib_python/2.7_Objects/
lib_python/2.7_Python/

new directory names:
from_cpython/Include/
from_cpython/Lib/
from_cpython/Modules/
from_cpython/Objects/
from_cpython/Python/

Sorry for the huge diff, but I think this makes way more sense.

Was using the 'n' format character which expects a Py_ssize_t*, but was passing an int*.
Switch to using the 'i' character.

Add a Gitter chat badge to README.md

Cmake small updates to match Makefile

Previously we were compiling against the system headers, and then
linking against a different libstdc++.  Fixes #252.

Also, move the gtest install section into the "required dependencies"
section since you need it to pass "make check".

Trying to fix Issue #171

fix bug #171: a first attempt

There are two tricky things left that I don't think we can support soon:
- MultipartConversionError uses multiple inheritance
- structseq.c sets a tp_dealloc

The structseq_dealloc function is a "simple" destructer (functionality is
covered by our GC), so we can just comment it out.  Ideally we'd have some
way of automatically determining that it's a no-op so that we don't have
to run it.

Ie run lint.py tester.py under Pyston, and use Pyston on the setup.py
script to build our test extension modules.

Pass SELF_HOST=1 to make to invoke this behavior

Looks like for now this only changes double-closing-angle-brackets
(now formats "> >" as ">>" in templates), but apparently it has
effects on raw string literals as well.

Starting to really hit critical mass in terms of having enough
API support that it's easier to copy additional API functions over.