DOC: Removed obsolete docs.

docs/extensions.rst

@@ -1,93 +0,0 @@
-**********
-Extensions
-**********
-
-.. highlight:: cython
-
-Philosophy
-==========
-
-Use judgement when to use C extensions. Debugging them potentially
-has a time cost of t=infinity, they can segfault, and may not be
-debugabble by anyone else. Simply put 90% of the time its not worth it
-and construction of extensions be must informed by scientific profiling.
-Listen to your inner Knuth.
-
-Writing C Extensions
-====================
-
-Caveats aside, C Extensions can be in two forms:
-
-- C
-- Cython
-
-Cython is a superset of Python which compiles into C. The code it
-produces is generally not human readable.
-
-Reference: http://docs.cython.org/
-
-C is well, C. You manage your own memory and interface with Python.h .
-If you need raw performance or need to interface with other C libraries
-this is often the best approach. Of course this requires that you
-be very careful to tend to memory and and Python's internal garbage
-collection.
-
-Reference: http://docs.python.org/c-api/
-
-One can write C++ extensions, but please don't.
-
-One could also embed Assembly in C and thus in Python, but again please
-don't.
-
-Compilers
-=========
-
-Compatibility
-
-    - Do not use Clang
-    - Do not use GCC-LLVM
-
-Use standard GCC >= 4.6 from gnu.org, otherwise extensions will have
-undefined behavior and will not be portable.
-
-Also make sure to code against Python 2.7 and numpy 1.6.1 header
-files. If using Cython have it auto figure out the paths to ensurable
-portability.
-
-Pure C
-======
-
-.. highlight:: c
-
-::
-
-    #include "Python.h"
-
-Releasing the GIL
-=================
-
-::
-
-    from libc.stdio cimport printf
-
-    with nogil:
-        # in here you allowed to do whatever you like so long as
-        # you do not touch Python objects. This really should
-        # only be used to interface with other C libraries.
-
-        printf("hello, world\n");
-
-Debugging
-=========
-
-Compile with debug symbols and use gdb and valgrind. It sucks but its
-really the only way.
-
-Vim
-===
-
-.. highlight:: vim
-
-For syntax highlighting in Vim::
-
-    :set syntax=pyrex

docs/index.rst

@@ -54,9 +54,7 @@ Contents
    installation.rst
    quickstart.rst
    contributing.rst
-   overview.rst
    modules.rst
-   extensions.rst
 
 Indices and tables
 ==================

docs/overview.rst

@@ -1,77 +0,0 @@
-*******************************************
-Overview
-*******************************************
-
-Simulations
-===========
-
-:mod:`zipline` runs backtests using asynchronous components and zeromq messaging for
-communication and coordination. 
-
-:class:`.algorithm.TradingAlgorithm` is the heart of :mod:`zipline`, and the primary access point for creating,
-launching, and tracking simulations. You can find it in
-:py:class:`~zipline.algorithm.TradingAlgorithm`
-
-Simulator Sub-Components
-========================
-
-Each simulation contains numerous subcomponents, each operating asynchronously
-from all others, and communicating via zeromq.
-
-DataSources
---------------------
-
-A DataSource represents a historical event record, which will be played back
-during simulation. A simulation may have one or more DataSources, which will be
-combined in DataFeed. Generally, datasources read records from a persistent
-store (db, csv file, remote service), format the messages for downstream
-simulation components, and send them to a PUSH socket. See the base class for
-all datasources :py:class:`~zipline.messaging.DataSource` and the module
-holding all datasources :py:mod:`zipline.sources`
-
-DataFeed
---------------------
-
-All simulations start with a collection of
-:py:class:`~zipline.messaging.DataSource`, which need to be fed to an
-algorithm. Each :py:class:`~zipline.sources.DataSource`can contain events of
-differing content (trades, quotes, corporate event) and frequency (quarterly,
-intraday). To simplify the process of managing the data sources,
-:py:class:`~zipline.core.DataFeed` can receive events from multiple
-:py:class:`DataSources <zipline.sources.DataSource>` and combine them into a
-serial chronological stream. 
-
-Transforms
---------------------
-
-Often, an algorithm will require a running calculation on top of a
-:py:class:`~zipline.messaging.DataSource`, or on the consolidated feed. A
-simple example is a technical indicator or a moving average. Transforms can be
-described in :py:class:`~zipline.core.Simulator`'s configuration. Subclass
-:py:class:`~zipline.transforms.core.Transform` to add your own Transform.
-Transforms must hold their own state between events, and serialize their
-current values into messages.
-
-
-Data Alignment
---------------------
-
-Like Datasources, Transforms have differing frequencies and results. Simulator
-manages the results of parallel transforms and **aligns** transform results
-with the raw DataFeed. Client algorithms simply receive a map of data, which
-includes the current event and all the transformed values. 
-
-Time Compression
---------------------
-
-According to `this post
-<https://www.quantopian.com/posts/help-with-runtime-error>`_ on the Quantopian
-forums, time periods during which none of the selected SIDs were traded are
-skipped.
-
-
-Review the unit test coverage_.
-
-
-
-.. _coverage: cover/index.html