We didn't support "true" as the annotation for a while, so I think
we were just lying about it.  Now that we support true, I converted all
of them to true except for a couple that are easy to see are false.

(This was a merge issue from two slightly-conflicting PRs that separately
passed the tests.)

pyElements: Use specialiced iterators for known types

Eval

__name__ for builtin functions

cmake auto update libunwind and libpypa git submodules

pyston (calibration)                      :    0.8s stock1: 0.8 (+0.8%)
pyston interp2.py                         :    5.9s stock1: 6.1 (-3.1%)
pyston raytrace.py                        :    7.5s stock1: 7.8 (-4.5%)
pyston nbody.py                           :   10.1s stock1: 9.9 (+1.5%)
pyston fannkuch.py                        :    6.7s stock1: 6.8 (-1.5%)
pyston chaos.py                           :   21.3s stock1: 22.6 (-5.8%)
pyston spectral_norm.py                   :   26.1s stock1: 27.9 (-6.7%)
pyston fasta.py                           :   17.7s stock1: 18.8 (-5.6%)
pyston pidigits.py                        :   16.1s stock1: 16.1 (+0.0%)
pyston richards.py                        :   10.2s stock1: 10.0 (+2.3%)
pyston deltablue.py                       :    2.4s stock1: 2.3 (+4.8%)
pyston (geomean-0b9f)                     :   10.1s stock1: 10.3 (-1.9%)

Fix compvar '1 is 1.0' and '1.0 is 1' handling

I thought I had already updated libpypa to the new build with the correct fixes,
but somehow hadn't?

Libunwind seems to have gotten a commit that breaks our usage of unw_get_proc_info_by_ip;
it got added 3 months ago so anyone who's been using the Makefile build for longer
than that wouldn't run into it.

We're hanging trying to output some diagnostic information if we die at the wrong point.
This doesn't address the underlying issue, but at least we'll start getting useful
results from Travis-CI.

It looks like the underlying issue (libunwind can't find the interpreter function)
only happens with the cmake build, and I can't tell why yet.

Most of the time this just gets ignored (its usually the parent module,
and functions don't usually care about that) but here it doesn't.

exceptionNew just calls __new__, but some exceptions have
important __init__ methods that need to be called.

Well, I think those exceptions might be broken (they should probably
set that data in __init__) but this is still a good anyway.

I'm not sure why clang doesn't warn about these, since it's supposed to support
the -Wconst-qual warning that these violate.

Conflicts:
	Makefile
	from_cpython/CMakeLists.txt
	src/runtime/capi.cpp
	src/runtime/types.cpp

I added a bugfix to this branch for merging

add tp_getattr support, PyCFunction_NewEx, and most of PyNumber_Int's behavior

In typeCallInternal, we used to expand out any starargs in order to take a look
at the first arg (and change it when passing it).

We had a bug in this code, and rather than make that code more complicated
to fix it, just call back into callFunc to resolve it.  This is kind of tricky
since callFunc will call typeCall, and we don't want typeCall to duplicate
the typeCallInternal behavior (that's not any better than duplicating the
arg behavior), so we want typeCall to call into typeCallInternal.  But
typeCall receives varargs! which typeCallInternal doesn't support.  So typeCall
has to do some (simpler) arg handling to expand out the varargs.

In the end, it simplifies the code a little bit but causes a bunch of extra calls
in the varargs case, so it's less of a win than I thought, but at least it
fixes the bug.

We could make the typeGCHandler support these half-constructed classes,
but let's just turn off the GC for this area.

implement setting __name__ for functions

Update gcc-4.8.2 tarball url to generic gnu ftpmirror.

compvar: add int <op> float handling