Get rid of references to the old 'THEANO_*' environment variables in the documentation.

doc/extending/pipeline.txt

@@ -101,14 +101,13 @@ case if ``borrow`` was True, the thunk would be allowed to reuse (or
     Compiled libraries are stored within a specific compilation directory,
     which by default is set to ``$HOME/.theano/compiledir_xxx``, where
     ``xxx`` identifies the platform. It may be manually set to a different
-    location either by setting the ``THEANO_COMPILEDIR`` environment variable,
-    the ``THEANO_BASE_COMPILEDIR`` environment variable
-    or by calling ``theano.gof.compiledir.set_compiledir(..)`` within your
-    Python script.
+    location either by setting :attr:`config.compiledir` or
+    :attr:`config.base_compiledir`, either within your Python script or by
+    using one of the configuration mechanisms described in :mod:`config`.
 
     The compile cache is based upon the C++ code of the graph to be compiled.
-    So, if you change compilation environment variables, such as
-    ``THEANO_BLAS_LDFLAGS``, you will need to manually remove your compile cache,
+    So, if you change compilation configuration variables, such as
+    :attr:`config.blas.ldflags`, you will need to manually remove your compile cache,
     using ``Theano/bin/theano-compiledir clear``
 
     Theano also implements a lock mechanism that prevents

doc/extending/unittest.txt

@@ -260,21 +260,22 @@ Example:
 >>> m = theano.Module()
 >>> minstance = m.make(mode='DEBUG_MODE')
 
-Whenever possible, unit tests should omit this parameter. Leaving-out
-the mode will ensure that unit tests use the default mode (defined in
-compile.mode.default_mode). This default_mode is set to the
-THEANO_DEFAULT_MODE environment variable, if it is present. If not, it
-defaults to 'FAST_RUN'.
-
-This allows the user to easily switch the mode in which unittests are
+Whenever possible, unit tests should omit this parameter. Leaving
+out the mode will ensure that unit tests use the default mode
+(defined in compile.mode.default_mode). This default_mode is set to
+the configuration variable :attr:`config.mode`, which defaults to
+'FAST_RUN', and can be set by various mechanisms (see :mod:`config`).
+
+In particular, the enviromnment variable :envvar:`THEANO_FLAGS`
+allows the user to easily switch the mode in which unittests are
 run. For example to run all tests in all modes from a BASH script,
 type this:
 
 .. code-block:: bash
 
-    THEANO_DEFAULT_MODE=FAST_COMPILE nosetests
-    THEANO_DEFAULT_MODE=FAST_RUN nosetests
-    THEANO_DEFAULT_MODE=DEBUG_MODE nosetests
+    THEANO_FLAGS='mode=FAST_COMPILE' nosetests
+    THEANO_FLAGS='mode=FAST_RUN' nosetests
+    THEANO_FLAGS='mode=DEBUG_MODE' nosetests
 
 Using Random Values in Test Cases
 ---------------------------------
@@ -299,14 +300,12 @@ do the following:
 
 The behaviour of seed_rng is as follows:
 
-* If an explicit seed is given, it will be used for seending numpy's rng.
-
-* If not, it will try to get a seed from the THEANO_UNITTEST_SEED variable.
+* If an explicit seed is given, it will be used for seeding numpy's rng.
 
-* If THEANO_UNITTEST_SEED is set to "random", it will seed the
-  rng. with None, which is equivalent to seeding with a random seed.
+* If not, it will use ``config.unittest.rseed`` (its default value is 666).
 
-* If THEANO_UNITTEST_SEED is not defined, it will use a default seed of 666.
+* If config.unittest.rseed is set to "random", it will seed the rng with
+  None, which is equivalent to seeding with a random seed.
 
 
 The main advantage of using unittest_tools.seed_rng is that it allows
@@ -317,7 +316,8 @@ a higher confidence that the variables are correct), while still
 making sure unittests are deterministic.
 
 Users who prefer their unittests to be random (when run on their local
-machine) can simply set THEANO_UNITTEST_SEED to 'random'.
+machine) can simply set ``config.unittest.rseed`` to 'random' (see
+:mod:`config`).
 
 Similarly, to provide a seed to numpy.random.RandomState, simply use:
 

doc/internal/lisa_labo.txt

@@ -8,8 +8,12 @@ LISA Labo specific instructions
 Tips for running at LISA
 ------------------------
 
-Use the fast BLAS library that Fred installed, by setting
-`THEANO_BLAS_LDFLAGS=-lgoto`.
+Shell configuration files ``/opt/lisa/os/.local.{bash,csh}rc`` should define
+:envvar:`THEANORC` to include ``/opt/lisa/os/.local.theanorc`` as a
+configuration file.
+
+``/opt/lisa/os/.local.theanorc`` should include the right default values for
+the lab, in particular, ``blas.ldflags`` should contain '-lgoto'.
 
 Tips for running on a cluster
 -----------------------------

doc/internal/mammouth.txt

@@ -14,7 +14,8 @@ To run Theano on the Mammouth cluster, follow these simple steps:
 
       Perhaps even put this in your ``.bashrc``
 
-    * ``set THEANO_BLAS_LDFLAGS='-lmkl -lguide -fopenmp'``
+    * set ``config.blas.ldflags`` to ``'-lmkl -lguide -fopenmp'``
+      (see :mod:`config` to know how)
 
       Note: the -lguide flag works, however the fix should probably be considered temporary.
       Intel has deprecated libguide.so in favor of the newer library libiomp5.so. However, 

doc/internal/metadocumentation.txt

@@ -145,7 +145,7 @@ Then it executes something like
 
 .. code-block:: bash
 
-    THEANO_UNITTEST_SEED=<SEED> THEANO_DEFAULT_MODE=DEBUG_MODE /usr/bin/nosetests --with-coverage --cover-package=theano --cover-package=pylearn
+    THEANO_FLAGS='unittests.rseed=<SEED>,mode=DEBUG_MODE' /usr/bin/nosetests --with-coverage --cover-package=theano --cover-package=pylearn
 
 in the updated ``theano`` directory.
 The output is emailed automatically to one of the developers.

doc/library/compile/debugmode.txt

@@ -35,7 +35,7 @@ DebugMode can be used as follows:
     f(0) 
     f(7) 
 
-It can also be used by setting an environment variable ``THEANO_DEFAULT_MODE=DEBUG_MODE``.
+It can also be used by setting the configuration variable :attr:`config.mode`.
 It can also be used by passing a DebugMode instance as the mode, as in 
 
 >>> f = theano.function([x], 10*x, mode=DebugMode(check_c_code=False))
@@ -82,12 +82,12 @@ Reference
 
     If there are internal errors, this mode will raise an `DebugModeError` exception.
 
-    .. attribute:: stability_patience = config.THEANO_DEBUGMODE_PATIENCE
+    .. attribute:: stability_patience = config.DebugMode.patience
 
         When checking for the stability of optimization, recompile the graph this many times.
         Default 10.
 
-    .. attribute:: check_c_code = config.THEANO_DEBUGMODE_CHECK_C
+    .. attribute:: check_c_code = config.DebugMode.check_c
 
         Should we evaluate (and check) the `c_code` implementations?
 
@@ -95,7 +95,7 @@ Reference
 
         Default yes.
 
-    .. attribute:: check_py_code = config.THEANO_DEBUGMODE_CHECK_PY
+    .. attribute:: check_py_code = config.DebugMode.check_py
 
     Should we evaluate (and check) the `perform` implementations?
 
@@ -103,7 +103,7 @@ Reference
 
         Default yes.
 
-    .. attribute:: check_isfinite = config.THEANO_DEBUGMODE_CHECK_FINITE
+    .. attribute:: check_isfinite = config.DebugMode.check_finite
 
         Should we check for (and complain about) ``NaN``/``Inf`` ndarray elements?
 
@@ -111,7 +111,7 @@ Reference
 
         Default yes.
 
-    .. attribute:: require_matching_strides = config.THEANO_DEBUGMODE_CHECK_STRIDES
+    .. attribute:: require_matching_strides = config.DebugMode.check_strides
 
         Check for (and complain about) Ops whose python and C
         outputs are ndarrays with different strides. (This can catch bugs, but

doc/library/compile/function.txt

@@ -134,7 +134,7 @@ Reference
     about how output variables should be returned.
 
     The default is typically 'FAST_RUN' but this can be changed in
-    :doc:`theano.config <../config>` or via :envvar:`THEANO_DEFAULT_MODE`.  The mode
+    :doc:`theano.config <../config>`.  The mode
     argument controls the sort of optimizations that will be applied to the
     graph, and the way the optimized graph will be evaluated.
 

doc/library/compile/mode.txt

@@ -10,21 +10,21 @@
 Guide
 =====
 
-The ``mode`` parameter to :func:`theano.function`` controls how the
+The ``mode`` parameter to :func:`theano.function` controls how the
 inputs-to-outputs graph is transformed into a callable object.
 
 Theano defines the following modes by name:
 
-- ``FAST_COMPILE``: Apply just a few optimizations, but use C op implementations where possible.
-- ``FAST_RUN``: Apply all optimizations, and use C op implementations where possible.
-- ``DEBUG_MODE``: Verify the correctness of all optimizations, and compare C and python 
+- ``'FAST_COMPILE'``: Apply just a few graph optimizations, but use C implementations where possible.
+- ``'FAST_RUN'``: Apply all optimizations, and use C implementations where possible.
+- ``'DEBUG_MODE'``: Verify the correctness of all optimizations, and compare C and python 
     implementations. This mode can take much longer than the other modes, 
     but can identify many kinds of problems.
 
-The default mode is typically 'FAST_RUN', but it can be controlled via the
-environment variable 'THEANO_DEFAULT_MODE', which can in turn be overridden by
+The default mode is typically ``FAST_RUN``, but it can be controlled via the
+configuration variable :attr:`config.mode`, which can in turn be overridden by
 setting ``theano.compile.mode.default_mode`` directly, which can in turn be
-overridden by passing the keyword argument to ``theano.function``.
+overridden by passing the keyword argument to :func:`theano.function`.
 
 .. TODO::