We always want to crawl the entire stack, and it's
possible to determine the extents of the stack, so just
do a scan over the entire memory range.

Also, change the way the interpreter keeps track of its roots;
we don't really need to associate the roots with a specific
interpreter frame.

This should hopefully clear up the weirdness about libunwind
trying to unwind through the pthreads assembly code, and potentially
also make stack crawling faster.

I think threading now "works" ie doesn't crash Pyston,
though we don't release the GIL until the thread exits.

Don't worry, a non-gil version is coming.
Use a gil for now so we can start working on the other threading
requirements, such as GC.

Well, the thread-creating should work, but nothing is threadsafe.

Remove read from freed memory

Update chr to be compatible with CPython

Not all exposed to python code yet

This commit is pretty large because it contains two separate but interrelated changes:
- Rewrite the function argument handling code (callCompiledFunction and resolveCLFunc)
  into a single callFunc that does its own rewriting, and support the new features.
-- this required a change of data representations, so instead of having each function
   consist of variants with unrelated signatures, we can only have a single signature,
   but multiple type specializations of that signature
- To do that, had to rewrite all of the stdlib functions that used signature-variation
  (ex range1 + range2 + range3) to be a single function that took default arguments, and
  then took action appropriately.

Can emit add/sub/etc instructions with 32-bit operands in addition to 8-bit now
Can get the RSP and RBP in rewriter1, for accessing scratch space
Change some debugging output

Fix a gc bug: if an object gets new'd, and takes a parameter that gets new'd, the sequence is
1) object space gets allocated
2) parameter space gets allocated
3) parameter gets constructed
4) object gets constructed
The bug is that the object construction is what initializes the GC header,
so if step #3 causes a collection, it can see that the allocation from step #1
has an invalid header.
As a workaround, always zero out the header in allocation, and skip blocks with
zeroed headers.
The real solution is probably to have the GC manage the header itself rather than
expecting the user to; this would mean that gc_alloc would take the allocation kind,
put that into the header, and then return a pointer to the post-header data section
of the allocation.

Experimenting with vim+make integration
Changed installation instructions slightly
Added rlwrap support for repl

Currently many places in the codebase create AST_Jump objects but do not initalice the line ,col numbers. Set them to -1, in order to not call SetCurrentDebugLocation with random locations.

Fix crash: register string iterator class

Tried up to 210379 with the same segfaults.

Replace a simple "num_args" argument with a packed struct that takes
num_args and adds num_keywords, has_varargs, and has_kwargs.  Tried
to add asserts in all the places that don't allow
keywords/varargs/starargs

Started refactoring things; got to the point of attempting
argument->parameter shuffling, but it's tricky if we allow every
compilation to have a different signature (used by builtins).
Really they all have the same signatures but different
specializations; to get to that point, need to add defaults.

- Support parsing (but not running) **kw in function definitions
- more consistent assertion of what parts handle non-simple arguments or not

Added implementation of 'dir'

Implementation of __iter__ for tuple, added tests

Signed-off-by: Vinzenz Feenstra <evilissimo@gmail.com>

Signed-off-by: Vinzenz Feenstra <evilissimo@gmail.com>

- Added dir0 which would in theory return the local scope, but
  for just returns the content of the builtins module
- Added a unit test file for dir which won't print anything as the
  list sorting does not work as expected at the moment
  (missing full implementation) and the attributes are different
  as well (pyston has some CPython 2.7.5 does not have and vice versa)
- dir1 implements the lookup on a passed object
  - If the object has a __dir__ method, it will call it and return the result
    returned by this method
  - Otherwise all class and instance attributes and methods are returned
  - If the object has a __dict__ attribute, additional to the previous one
    it will return the keys from that one as well
Signed-off-by: Vinzenz Feenstra <evilissimo@gmail.com>

Signed-off-by: Vinzenz Feenstra <evilissimo@gmail.com>

Signed-off-by: Vinzenz Feenstra <evilissimo@gmail.com>