fix rst format.

doc/extending/inplace.txt

@@ -203,8 +203,8 @@ Inplace optimization and DebugMode
 
 It is recommended that during the graph construction, all op are not inplace. 
 Then an optimization replace them with an inplace one. Currently DebugMode check
- all optimization that was tryed even if they got rejected. One reason an inplace
- optimization can get rejected is that their is another op that already do an
+all optimization that was tryed even if they got rejected. One reason an inplace
+optimization can get rejected is that their is another op that already do an
 inplace on the same input. A second reason to reject an inplace optimization is
 if it introduce cycle into the graph.
 

doc/install.txt

@@ -308,6 +308,7 @@ Windows V1(bigger install, but simpler instruction + try instruction for gpu)
   in python run:
 
   .. code-block:: bash
+
       import theano
       print theano.config.blas.ldflags
 
@@ -363,12 +364,14 @@ Windows V1(bigger install, but simpler instruction + try instruction for gpu)
   directory contain those caractere, you must add in your configuration file:
 
     .. code-block:: bash
+
       [global]
       base_compiledir=PATH_TO_A_DIRECTORY_WITHOUT_THOSE_CARACTERE
 
   You also need to add in the configuration file those line:
 
     .. code-block:: bash
+
       [cuda]
       nvccflags=-LC:\Python26\libs
 

doc/sandbox/ccodegen.txt

@@ -69,6 +69,7 @@ Failure
 Besides cleanup code, all code has access to the %(fail)s template. For three code blocks, the generated C code will pretty much look like this:
 
 .. code-block:: CPP
+
     int failure = 0;
     {
       <code1>
@@ -92,6 +93,7 @@ And %(fail)s in the nth code block will take the value "{failure = n; goto label
 When compiling an Op, we want to sync the outputs so we can get the results from Python. In case of failure, we will not necessarily want to sync. Because of that, typical code will look like this:
 
 .. code-block:: CPP
+
     int failure = 0;
     <declare input>
     <declare output>
@@ -144,6 +146,7 @@ Example Op
 The following ResultBase represents addition of two nonnegative doubles (we only care about the C part).
 
 .. code-block:: python
+
     class Add(Op):
       <snip>
       def c_var_names(self):
@@ -163,6 +166,7 @@ Generating a C function
 For the example Op, the generated C function will typically look like this:
 
 .. code-block:: python
+
     void add(PyObject* storage_x, PyObject* storage_y, PyObject* storage_z) {
       PyObject* py_x = PyList_GET_ITEM(storage_x, 0); Py_XINCREF(py_x); // automatic
       PyObject* py_y = PyList_GET_ITEM(storage_y, 0); Py_XINCREF(py_y); // automatic
@@ -215,6 +219,7 @@ To accelerate processing a tad, a struct can be generated instead of a function.
 Here is a sketch of the struct equivalent of the previous function:
 
 .. code-block:: CPP
+
     struct add {
       PyObject* storage_x;
       PyObject* storage_y;

doc/sandbox/elemwise_compiler.txt

@@ -34,6 +34,7 @@ Question: does it make sense to apply the order to the loop, or is this broadcas
 Here is the loop for {{{order == c}}}. Check for errors!
 
 .. code-block:: CPP
+
     <initialize iterators>
 
     i1 = -1