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))
@@ -78,47 +78,47 @@ Reference
     Each of these exceptions inherits from the more generic `DebugModeError`.
 
     If there are no internal errors, this mode behaves like FAST_RUN or FAST_COMPILE, but takes
-    a little longer and uses more memory.  
+    a little longer and uses more memory.
 
     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?
 
         ``True`` -> yes, ``False`` -> no.
-        
+
         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?
 
         ``True`` -> yes, ``False`` -> no.
-        
+
         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?
 
         ``True`` -> yes, ``False`` -> no.
-        
+
         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
-        is generally overly strict.) 
-        
+        is generally overly strict.)
+
         0 -> no check, 1 -> warn, 2 -> err.
-        
+
         Default warn.
 
     .. method:: __init__(self, optimizer='fast_run', stability_patience=None, check_c_code=None, check_py_code=None, check_isfinite=None, require_matching_strides=None, linker=None)
@@ -128,7 +128,7 @@ Reference
         If any of these arguments (except optimizer) is not None, it overrides the class default.
         The linker arguments is not used. It is set their to allow Mode.requiring() and some other fct to work with DebugMode too.
 
-    
+
 
 The keyword version of DebugMode (which you get by using ``mode='DEBUG_MODE``)
 is quite strict, and can raise several different Exception types.

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::