fixing links in debugmode docs

doc/advanced/debug_faq.txt

@@ -38,12 +38,12 @@ Theano provides a 'Print' Op to do this.
 Since Theano runs your program in a topological order, you won't have precise
 control over the order in which multiple Print() Ops are evaluted.  For a more
 precise inspection of what's being computed where, when, and how, see the
-:ref:`wraplinker_faq`.
+:ref:`faq_wraplinker`.
 
 
 
 
-.. _wraplinker_faq:
+.. _faq_wraplinker:
 
 How do I step through a compiled function with the WrapLinker?
 --------------------------------------------------------------
@@ -81,7 +81,7 @@ The function I compiled is too slow, what's up?
 First, make sure you're running in FAST_RUN mode, by passing ``mode='FAST_RUN'``
 to ``theano.function`` or ``theano.make``.
 
-Second, try the theano :ref:`profiler`.  This will tell you which Apply nodes,
+Second, try the theano :ref:`profilemode`.  This will tell you which Apply nodes,
 and which Ops are eating up your CPU cycles.
 
 

doc/advanced/debugmode.txt

@@ -70,14 +70,14 @@ For detailed documentation see :api:`BadOptimization`.
 BadDestroyMap
 -------------
 
-This happens when an Op's perform() or c_code() modifies an input that it wasn't
+This happens when an Op's ``perform()`` or ``c_code()`` modifies an input that it wasn't
 supposed to.  If either the ``perform`` or ``c_code`` implementation of an Op
 might modify any input, it has to advertise that fact via the ``destroy_map``
 attribute.
 
-For detailed documentation on the Exception see :api:`BadDestroyMap`.
+For detailed documentation on the Exception, see :api:`BadDestroyMap`.
 
-For detailed documentation on the ``destroy_map`` attribute :ref:`destroymap`.
+For detailed documentation on the ``destroy_map`` attribute, see :ref:`_inplace`.
 
 
 BadViewMap
@@ -87,9 +87,9 @@ This happens when an Op's perform() or c_code() creates an alias or alias-like
 dependency between an input and an output... and it didn't warn the
 optimization system via the ``view_map`` attribute.
 
-For detailed documentation on the Exception see :api:`BadViewMap`.
+For detailed documentation on the Exception, see :api:`BadViewMap`.
 
-For detailed documentation on the ``view_map`` attribute :ref:`destroymap`.
+For detailed documentation on the ``view_map`` attribute, see :ref:`_views`.
 
 
 StochasticOrder

doc/advanced/profilemode.txt

 
+.. _profilemode:
+
 =========================================
 ProfileMode
 =========================================

doc/advanced_tutorial/inplace.txt

 
+.. _views_and_inplace:
 
 ============================
 Views and inplace operations
@@ -19,6 +20,7 @@ floats are immutable). Therefore, we can't make examples of these
 concepts out of what we've just built. Nonetheless, we will present
 the concepts:
 
+.. _views:
 
 Views
 =====
@@ -77,6 +79,8 @@ unsupported. Here are more examples:
    myop.view_map = {0: [0, 1]} # THIS IS NOT SUPPORTED! Only put a single input number in the list!
 
 
+.. _inplace:
+
 
 Inplace operations
 ==================
@@ -186,6 +190,9 @@ input(s)'s memory). From there, go to the previous section.
    the addition, the original x that we wanted to take the logarithm
    of is gone). If Theano does not know that ``add_inplace`` changes
    the value of ``x`` it might invert the order and that will
-   certainly lead to erroneous computations and be a headache to
-   debug.
+   certainly lead to erroneous computations.
+
+   You can often identify an incorrect view_map or destroy_map by using
+   :ref:`DebugMode`.  *Be sure to use DebugMode when developing a new Op that
+   uses view_map and/or destroy_map.*
 

theano/compile/debugmode.py

@@ -31,7 +31,7 @@ class DebugModeError(Exception):
     """Generic Exception raised to indicate an internal theano problem"""
     pass
 
-class BadClinkerOutput(DebugModeError):
+class BadCLinkerOutput(DebugModeError):
     """Exception: an Op's c_code and perform implementations don't agree."""
 
     r = None
@@ -45,7 +45,7 @@ class BadClinkerOutput(DebugModeError):
 
     def __init__(self, r, val_py, val_c):
         """Initialize members"""
-        super(BadClinkerOutput, self).__init__()
+        super(BadCLinkerOutput, self).__init__()
         self.r = r
         self.val_py = val_py
         self.val_c = val_c
@@ -861,7 +861,7 @@ class _Linker(gof.link.LocalLinker):
                             # compares the version from thunk_py (in r_vals)
                             # to the version produced by thunk_c (in storage_map)
                             if not r.type.values_eq_approx(r_vals[r], storage_map[r][0]):
-                                raise BadClinkerOutput(r, val_py=r_vals[r], val_c=storage_map[r][0])
+                                raise BadCLinkerOutput(r, val_py=r_vals[r], val_c=storage_map[r][0])
                         else:
                             #retrieve each output from the storage_map
                             r_vals[r] = storage_map[r][0]
@@ -1128,7 +1128,7 @@ class DebugMode(Mode):
 
     This mode catches several kinds of internal error:
 
-    - inconsistent c_code and perform implementations (see `BadClinkerOutput`)
+    - inconsistent c_code and perform implementations (see `BadCLinkerOutput`)
 
     - a variable replacing another when their runtime values don't match.  This is a symptom of
       an incorrect optimization step, or faulty Op implementation (raises `BadOptimization`)

theano/compile/tests/test_debugmode.py

@@ -268,7 +268,7 @@ def test_badclinkeroutput():
                 [0,1,2,3],
                 3,
                 numpy.asarray([[0.,1.,2.],[3.,4.,5.],[6.,7.,8.]]))
-    except debugmode.BadClinkerOutput, e:
+    except debugmode.BadCLinkerOutput, e:
         print repr(e)
         assert e.r.owner.op is inconsistent
         return #TEST PASS