cs: klister: use anonymous links

Author: doyougnu

src/Case_Studies/klister.rst

@@ -12,17 +12,17 @@ This chapter is a case study on a first pass of performance engineering for the
 |klister| programming language interpreter. This case study should be exemplary
 of any system which is shortlived, has distinct phases of input and output, and
 maintains state. To diagnose the performance issues this case study uses
-:ref:`Heap Profiling <Heap Profiling Chapter>` with :ref:`Eventlog <EventLog
+:ref:`Heap Profiling <Haskell GHC Flags>` with :ref:`Eventlog <EventLog
 Chapter>`, :ref:`Info Table Profiling <IPE Chapter>`, :ref:`TickyTicky <Ticky
 Chapter>` profiling. The optimizations are trivial: choosing better data
 structures and closing memory leaks; any intermediate level Haskeller should be
 able to follow along. After reading this chapter, a reader should be able to
 spot inefficient data structure use by reading code, and GHC's profiling tools
 to diagnose memory performance issues and identify hot code. To read through the
 code, `this commit
-<https://github.com/gelisam/klister/commit/33501b2233ce865407a8a3ca7c090457f3375442>`_
+<https://github.com/gelisam/klister/commit/33501b2233ce865407a8a3ca7c090457f3375442>`__
 is the result of the case study, and `this commit
-<https://github.com/gelisam/klister/tree/5aea4d2b9df8f6e9db276078570c1e1bd1306cd3>`_
+<https://github.com/gelisam/klister/tree/5aea4d2b9df8f6e9db276078570c1e1bd1306cd3>`__
 was the state of the klister code base that the tutorial starts with.
 
 The rest of the chapter is structured as follows. We introduce the |klister|
@@ -1464,7 +1464,7 @@ Then we employed a number of methods to find performance problems. We used:
 
 * :ref:`Ticky Profiling <Ticky Chapter>`: To determine hot loops and highly
   allocating functions
-* :ref:`Biographical/Retainer Profiling <Heap Profiling Chapter>`: To determine
+* :ref:`Biographical/Retainer Profiling <Haskell GHC Flags>`: To determine
   the source of memory leaks in the expander state. This technique led our
   analysis to the lazy return in ``currentEnv``.
 * :ref:`Info-Table Profiling <IPE Chapter>`: To determine the line of code

src/Measurement_Observation/Haskell_Profiling/ghc_flags.rst

@@ -1,4 +1,4 @@
-.. _Heap Profiling Chapter:
+.. _Haskell GHC Flags:
 
 :lightgrey:`GHC Flags`
 ======================

src/Preliminaries/how_to_debug.rst

@@ -230,8 +230,8 @@ properties:
    invalidated. For example, the hypothesis "The total runtime of the system is
    dominated by garbage collection induced by storing thunks in the cache" is
    testable; we can directly measure how much garbage collection the runtime
-   system does and the kinds of objects it is storing (see :doc:`GHC Flags
-   <./Heap_Ghc/ghc_flags>`). This hypothesis is also specific; from reading it
+   system does and the kinds of objects it is storing (see :ref:`GHC Flags
+   <Haskell GHC Flags>`). This hypothesis is also specific; from reading it
    we know which sub-systems to inspect: the garbage collector, the cache, and
    the heap. But in addition to that, this hypothesis also adds information
    *even if* it is shown to be wrong. It could be the case that the runtime *is

src/Preliminaries/how_to_use.rst

@@ -32,13 +32,13 @@ picking your favorite Haskell library and attempting to optimize that!
 
 The book assumes you are using GHC |ghcVersion| and a Linux distribution (kernel
 version ``5.8`` and higher). Should you be using an older compiler than some
-sections, such as :doc:`Using EventLog
-</src/Measurement_Observation/Heap_Ghc/eventlog>`; which arrived in ``GHC 8.8``
-may still be useful, while others such as :doc:`Using Cachegrind
-</src/Measurement_Observation/Heap_Third/cachegrind>`; which relies on
+sections, such as :ref:`Using EventLog
+<EventLog Chapter>`; which arrived in ``GHC 8.8``
+may still be useful, while others such as :ref:`Using Cachegrind
+<Cachegrind Chapter>`; which relies on
 :term:`DWARF` symbols (added in ``GHC 8.10.x``) may not be applicable.
-Similarly, some chapters, such as :doc:`Using perf
-</src/Measurement_Observation/Measurement_Third/linux_perf>` will only be
+Similarly, some chapters, such as :ref:`Using perf
+<Perf Chapter>` will only be
 applicable for Linux and Linux based operating systems.
 
 Notation