Update the developer start guide

.github/PULL_REQUEST_TEMPLATE.md

@@ -6,7 +6,7 @@ Here are a few important guidelines and requirements to check before your PR can
 + [ ] The description and/or commit message(s) references the relevant GitHub issue(s).
 + [ ] [`pre-commit`](https://pre-commit.com/#installation) is installed and [set up](https://pre-commit.com/#3-install-the-git-hook-scripts).
 + [ ] The commit messages follow [these guidelines](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
-+ [ ] The commits correspond to [_relevant logical changes_](https://wiki.openstack.org/wiki/GitCommitMessages#Structural_split_of_changes), and there are **no commits that fix changes introduced by other commits in the same branch/BR**.  If your commit description starts with "Fix...", then you're probably making this mistake.
++ [ ] The commits correspond to [_relevant logical changes_](https://wiki.openstack.org/wiki/GitCommitMessages#Structural_split_of_changes), and there are **no commits that fix changes introduced by other commits in the same branch/BR**.
 + [ ] There are tests covering the changes introduced in the PR.
 
 Don't worry, your PR doesn't need to be in perfect order to submit it.  As development progresses and/or reviewers request changes, you can always [rewrite the history](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_rewriting_history) of your feature/PR branches.

aesara/misc/doubleop.py

-# This is the example in the Aesara/doc/tutorial/extending_aesara.txt
-import aesara
-from aesara.graph.basic import Apply
-from aesara.graph.op import Op
-
-
-class DoubleOp(Op):
-    """
-    Double each element of a tensor.
-
-    Parameters
-    ----------
-    x : tensor
-        Input tensor
-
-    Returns
-    -------
-    tensor
-        a tensor of the same shape and dtype as the input with all
-        values doubled.
-
-    Notes
-    -----
-    this is a test note
-
-    See Also
-    --------
-    :class:`~aesara.tensor.elemwise.Elemwise` : You can use this to replace
-    this example.  Just execute `x * 2` with x being an Aesara variable.
-
-
-    .. versionadded:: 0.6
-    """
-
-    def __eq__(self, other):
-        return type(self) == type(other)
-
-    def __hash__(self):
-        return hash(type(self))
-
-    def __str__(self):
-        return self.__class__.__name__
-
-    def make_node(self, x):
-        x = aesara.tensor.as_tensor_variable(x)
-        return Apply(self, [x], [x.type()])
-
-    def perform(self, node, inputs, output_storage):
-        x = inputs[0]
-        z = output_storage[0]
-        z[0] = x * 2
-
-    def infer_shape(self, fgraph, node, i0_shapes):
-        return i0_shapes
-
-    def grad(self, inputs, output_grads):
-        return [output_grads[0] * 2]
-
-    def R_op(self, inputs, eval_points):
-        # R_op can receive None as eval_points.
-        # That means there is no differentiable path through that input.
-        # If this implies that you cannot compute some outputs,
-        # return None for those.
-        if eval_points[0] is None:
-            return eval_points
-        return self.grad(inputs, eval_points)

doc/dev_start_guide.rst

@@ -31,215 +31,44 @@ The Theano Google group is also relevant to (early) Aesara versions:
 .. _theano-dev: https://groups.google.com/group/theano-dev
 
 
-To get up to speed, you'll need to
-
-- Learn some non-basic Python to understand what's going on in some of the
-  trickier files (like tensor.py).
-- Go through the `NumPy documentation`_.
-- Learn to write reStructuredText_ for Sphinx_.
-- Learn about how unittest_ and pytest_ work
-
-.. _Sphinx: http://sphinx.pocoo.org/
-.. _reStructuredText: http://docutils.sourceforge.net/rst.html
-.. _NumPy documentation: http://docs.scipy.org/numpy/
-.. _unittest: http://docs.python.org/library/unittest.html
-.. _pytest: http://docs.pytest.org/en/latest/
-
-
 .. _quality_contributions:
 
 Requirements for Quality Contributions
 ======================================
 
-* All code should be accompanied by quality unit tests.
-
-* The code should be compatible with Python 3.6 and above.
-
-* All the code should respect the
-  `PEP8 Code Style Guide <http://www.python.org/dev/peps/pep-0008>`_.
-
-* The docstrings of all the classes and functions should respect the
-  `PEP257 <https://www.python.org/dev/peps/pep-0257/>`_ rules and follow the
-  `Numpy docstring standard
-  <https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt>`_.
-
-Each point will be referred to more in detail in the following.
-
-Unit tests
-----------
-
-When you submit a pull request, your changes will automatically be
-tested via our continuous integration (CI).
-
-Just because the tests run automatically does not mean you shouldn't
-run them yourself to make sure everything is all right.  You can run
-only the portion you are modifying to go faster and have CI
-make sure there are no broader problems.
-
-To run the test suite with the default options, see
-:ref:`test_aesara`.
-
-
-Setting up your Editor for PEP8
--------------------------------
-
-Here are instructions for :ref:`Vim <vim_pep8>` and :ref:`Emacs
-<emacs_pep8>`. If you have similar instructions for other text editors
-or IDE, please let us know and we will update this documentation.
-
-.. _vim_pep8:
-
-Vim
-~~~
-
-Detection of warnings and errors is done by the `pep8`_ script
-(or `flake8`_, that also checks for other things, like syntax
-errors). Syntax highlighting and general integration into Vim is done by
-the `Syntastic`_ plugin for Vim.
-
-To setup VIM:
-
-#. Install flake8 (if not already installed) with::
-
-    pip install flake8
-
-   .. warning:: Starting version 3.0.0, flake8 changed its dependencies and
-      moved its Python API to a legacy module, breaking Aesara's flake8 tests.
-      We recommend using a version prior to 3.
-
-   .. note:: You can use ``easy_install`` instead of ``pip``, and ``pep8``
-      instead of ``flake8`` if you prefer. The important thing is that the
-      ``flake8`` or ``pep8`` executable ends up in your ``$PATH``.
-
-#. Install vundle with::
-
-    git clone https://github.com/VundleVim/Vundle.vim.git ~/.vim/bundle/Vundle.vim
-
-#. Edit ``~/.vimrc`` and add the lines:
-
-    .. code-block:: python
-
-        set nocompatible              " be iMproved, required
-        filetype off                  " required
-        " set the runtime path to include Vundle and initialize
-        set rtp+=~/.vim/bundle/Vundle.vim
-        call vundle#begin()
-
-        Plugin 'gmarik/Vundle.vim' " let Vundle manage Vundle (required!)
-        Plugin 'scrooloose/syntastic'
-        Plugin 'jimf/vim-pep8-text-width'
-
-        call vundle#end()
-
-        " Syntastic settings
-        " You can run checkers explicitly by calling :SyntasticCheck <checker
-        let g:syntastic_python_checkers = ['flake8'] "use one of the following checkers:
-                                                     " flake8, pyflakes, pylint, python (native checker)
-        let g:syntastic_enable_highlighting = 1  "highlight errors and warnings
-        let g:syntastic_style_error_symbol = ">>" "error symbol
-        let g:syntastic_warning_symbol = ">>" "warning symbol
-        let g:syntastic_check_on_open = 1
-        let g:syntastic_auto_jump = 0  "do not jump to errors when detected
+The following are requirements for a quality pull request (PR)/contribution:
 
-#. Open a new vim and run ``:PluginInstall`` to automatically install the
-   plugins. When the installation is done, close the installation "window"
-   with ``:q``.
-   From now on Vim will check for PEP8 errors and highlight them whenever a
-   file is saved.
+* All code should be accompanied by quality unit tests  that provide complete
+  coverage of the features added.
+* There is an informative high-level description of the changes, or a reference to an issue describing the changes.
+* The description and/or commit messages reference any relevant GitHub issues.
+* `pre-commit <https://pre-commit.com/#installation>`_ is installed and `set up <https://pre-commit.com/#3-install-the-git-hook-scripts>`_.
+* The commit messages follow `these guidelines <https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html>`_.
+* The commits correspond to `relevant logical changes <https://wiki.openstack.org/wiki/GitCommitMessages#Structural_split_of_changes>`_, and there are **no commits that fix changes introduced by other commits in the same branch/BR**.
+* There are tests, implemented within the pytest_ framework, covering the changes introduced by the PR.
+* `Type hints <https://www.python.org/dev/peps/pep-0484/>`_ are added where appropriate.
 
-A few useful commands
-"""""""""""""""""""""
+Don't worry, your PR doesn't need to be in perfect order to submit it.  As development progresses and/or reviewers request changes, you can always `rewrite the history <https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_rewriting_history>`_ of your feature/PR branches.
 
-* Open the list of errors: ``:lopen``, that can be abbreviated in ``:lop``
-  (denoted ``:lop[en]``).
-* Close that list: ``:lcl[ose]``.
-* Next error: ``:lne[xt]``.
-* Previous error: ``:lp[revious]``.
+If your PR is an ongoing effort and you would like to involve us in the process,
+simply make it a `draft PR <https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/about-pull-requests#draft-pull-requests>`_.
 
-Once you fix errors, messages and highlighting will still appear in the
-fixed file until you save it again.
+When you submit a PR, your changes will automatically be tested via our
+continuous integration (CI). Just because the tests run automatically does not
+mean you shouldn't run them yourself to make sure everything is all right.  You
+can run only the portion you are modifying to go faster and have CI make sure
+there are no broader problems.
 
-We can also configure the ``~/.vimrc`` to make it easier to work with Syntastic.
-For instance, to add a summary in the status bar, you can add::
+To run the test suite with the default options, see :ref:`test_aesara`.
 
-    set statusline+=%{SyntasticStatuslineFlag()}
-
-To bind F2 and F3 to navigate to previous and next error, you can add::
-
-    map <F2> :lprevious<CR>
-    map <F3> :lnext<CR>
-
-You can prefix those by ``autocmd FileType python`` if you want these
-bindings to work only on Python files.
-
-.. _pep8: http://pypi.python.org/pypi/pep8
-.. _flake8: http://pypi.python.org/pypi/flake8
-.. _Syntastic: https://github.com/scrooloose/syntastic/
-.. _pathogen.vim: https://github.com/tpope/vim-pathogen
-.. _quickfix: http://vimdoc.sourceforge.net/htmldoc/quickfix.html#quickfix
-
-.. _emacs_pep8:
-
-Emacs
-~~~~~
-
-There is an **excellent** system to configure emacs for Python:
-`emacs-for-python
-<https://github.com/gabrielelanaro/emacs-for-python>`_. It gathers many
-emacs config into one, and modifies them to behave together nicely. You
-can use it to check for pep8 compliance and for Python syntax errors.
-
-To install it on Linux, you can do like this:
-
-.. code-block:: bash
-
-   cd
-   git clone https://github.com/gabrielelanaro/emacs-for-python.git ~/.emacs.d/emacs-for-python
-
-
-Then in your ``~/.emacs`` file, add this:
-
-.. code-block:: common-lisp
-
-   ;; Mandatory
-   (load-file "~/.emacs.d/emacs-for-python/epy-init.el")
-   (add-to-list 'load-path "~/.emacs.d/emacs-for-python/") ;; tell where to load the various files
-
-   ;; Each of them enables different parts of the system.
-   ;; Only the first two are needed for pep8, syntax check.
-   (require 'epy-setup) ;; It will setup other loads, it is required!
-   (require 'epy-python) ;; If you want the python facilities [optional]
-   (require 'epy-completion) ;; If you want the autocompletion settings [optional]
-   (require 'epy-editing) ;; For configurations related to editing [optional]
-   ;; [newer version of emacs-for-python]
-
-   ;; Define f10 to previous error
-   ;; Define f11 to next error
-   (require 'epy-bindings) ;; For my suggested keybindings [optional]
-
-   ;; Some shortcut that do not collide with gnome-terminal,
-   ;; otherwise, "epy-bindings" define f10 and f11 for them.
-   (global-set-key [f2] 'flymake-goto-prev-error)
-   (global-set-key [f3] 'flymake-goto-next-error)
-
-   ;; Next two lines are the checks to do. You can add more if you wish.
-   (epy-setup-checker "pyflakes %f") ;; For python syntax check
-   (epy-setup-checker "pep8 -r %f") ;; For pep8 check
-
-.. note::
-
-   The script highlights problematic lines. This can make part of the
-   line not readable depending on the background. To replace the line
-   highlight by an underline, add this to your emacs configuration
-   file:
+.. _Sphinx: http://sphinx.pocoo.org/
+.. _reStructuredText: http://docutils.sourceforge.net/rst.html
+.. _pytest: http://docs.pytest.org/en/latest/
 
-   ;; Make lines readable when there is an warning [optional]
-   (custom-set-faces
-   '(flymake-errline ((((class color)) (:underline "red"))))
-   '(flymake-warnline ((((class color)) (:underline "yellow")))))
 
 Documentation and docstrings
 ----------------------------
+
 * The documentation and the API documentation are generated using `Sphinx`_.
 
 * The documentation should be written in `reStructuredText`_ and the
@@ -264,24 +93,12 @@ Here is an example on how to add a docstring to a class.
 
 .. testcode:: python
 
-    import aesara
+    from aesara.graph.basic import Variable
     from aesara.graph.op import Op
 
 
     class DoubleOp(Op):
-        """
-        Double each element of a tensor.
-
-        Parameters
-        ----------
-        x : tensor
-            Input tensor
-
-        Returns
-        -------
-        tensor
-            a tensor of the same shape and dtype as the input with all
-            values doubled.
+        """Double each element of a tensor.
 
         Notes
         -----
@@ -289,29 +106,31 @@ Here is an example on how to add a docstring to a class.
 
         See Also
         --------
-        :class:`~aesara.tensor.elemwise.Elemwise` : You can use this to replace
-        this example.  Just execute `x * 2` with x being an Aesara variable.
+        `Elemwise`: This functionality is already available; just execute
+        ``x * 2`` with ``x`` being an Aesara variable.
+        """
 
+        def make_node(self, x: Variable):
+            """Construct an `Apply` node for this `Op`.
 
-        .. versionadded:: 0.6
-        """
+            Parameters
+            ----------
+            x
+                Input tensor
 
-This is how it will show up for files that we auto-list in the library
-documentation:
+            """
+            ...
 
-.. automodule:: aesara.misc.doubleop
-    :members:
 
 Installation and configuration
 ==============================
 
-To obtain developer access: register with `GitHub
-<http://www.github.com/>`_ and create a fork of `Aesara
-<http://www.github.com/aesara-devs/aesara>`_.
+To submit PRs, create an account on `GitHub <http://www.github.com/>`_ and fork
+`Aesara <http://www.github.com/aesara-devs/aesara>`_.
 
-This will create your own Aesara project on GitHub, referred later
-as "YourProfile/Aesara", or "origin", from which you will be able to
-contribute to the original Aesara/Aesara, also called "central".
+This will create your own clone of the Aesara project on GitHub. It is customary
+to assign this Git remote the name "origin", and the official Aesara repository
+the name "upstream".
 
 
 Create a local copy
@@ -323,254 +142,68 @@ Clone your fork locally with
 
     git clone git@github.com:YOUR_GITHUB_LOGIN/Aesara.git
 
-For this URL to work, you must set your public ssh keys inside your
-`github account setting <https://github.com/settings/ssh>`_.
+For this URL to work, you must set your public SSH keys inside your
+`GitHub account setting <https://github.com/settings/ssh>`_.
 
-From your local repository, your own fork on GitHub will be called "origin".
+From your local repository, your fork on GitHub will be called "origin" by default.
 
-Then, add a reference to the original ("central") Aesara repository with
+Next, add a reference to the original ("upstream") Aesara repository with
 
 .. code-block:: bash
 
-    git remote add central git://github.com/aesara-devs/aesara.git
+    git remote add upstream git://github.com/aesara-devs/aesara.git
 
-You can choose another name than "central" to reference Aesara/Aesara
-(for instance, NumPy uses "upstream"), but this documentation will stick
-to "central."
+You can choose a name other than "upstream" to reference the official Aesara
+repository, but this documentation will stick to "upstream."
 
-You can then test your installation of Aesara by following the steps of
-:ref:`test_aesara`.
+You can then test your installation of Aesara by following the steps of :ref:`test_aesara`.
 
 
-Using your local copy
----------------------
+Setting up the your local development environment
+-------------------------------------------------
 
-To update your library to the latest revision, you should have a local branch
-that tracks ``origin/main``. You can add one (named "trunk" here) with:
+You will need to create a virtual environment and install the project requirements within it.
 
-.. code-block:: bash
-
-    git fetch origin
-    git branch trunk origin/main
-
-Once you have such a branch, in order to update it, do:
+The recommended approach is to install `conda <https://conda.io/projects/conda/en/latest/user-guide/install/index.html>`_ and
+create a virtual environment in the project directory with the following:
 
 .. code-block:: bash
 
-    git checkout trunk
-    git pull
-
-Keep in mind that this branch should be "read-only": if you want to
-patch Aesara, you should work in another branch, like described in the
-:ref:`dev_workflow` section below.
-
+    conda env create -n aesara-dev -f environment.yaml
+    conda activate aesara-dev
 
-Configure Git
--------------
-
-On your local machine, you need to configure git with basic information:
+Afterward, you can install the development dependencies with the following:
 
 .. code-block:: bash
 
-   git config --global user.email you@yourdomain.example.com
-   git config --global user.name "Your Name Comes Here"
-
-
-You can also instruct git to use color in diff. For this, you need to
-add those lines in the file ~/.gitconfig
-
-.. code-block:: cfg
-
-    [color]
-       branch = auto
-       diff = auto
-       interactive = auto
-       status = auto
+    pip install -r requirements.txt
 
-
-.. _dev_workflow:
-
-Development Workflow
-====================
-
-Start a new local branch
-------------------------
-
-When working on a new feature in your own fork, start from an up-to-date copy
-of the `main` branch (the principal one) of the central repository
-(Aesara/Aesara on GitHub):
+Next, ``pre-commit`` needs to be configured so that the linting and code quality
+checks are performed before each commit:
 
 .. code-block:: bash
 
-    git fetch origin
-    git checkout -b my_shiny_feature origin/main
-
-.. note::
-
-    This last line is a shortcut for:
-
-    .. code-block:: bash
-
-        git branch my_shiny_feature origin/main
-        git checkout my_shiny_feature
-
+    pre-commit install
 
-Submit your changes to the central repository
----------------------------------------------
-
-Once your code is ready for others to review, you need to commit all the changes and then push your
-branch to your GitHub fork first:
-
-.. code-block:: bash
-
-    git commit -a -m "Your message here"
-
-.. code-block:: bash
-
-    git push -u origin my_shiny_feature
-
-Then, go to your fork's GitHub page on the GitHub website, select your
-feature branch and hit the "Pull Request" button in the top right
-corner.  This will signal the maintainers that you wish to submit your
-changes for inclusion in ``origin/main``.
-
-
-Address reviewer comments
--------------------------
-
-Your pull request will be reviewed by members of the core development
-team. If your branch is not directly accepted, the reviewers will use
-GitHub's system to add "notes", either general (on the entire commit),
-or "line notes", relative to a particular line of code.
-In order to have the pull request accepted, you may have to answer
-the reviewer's questions, you can do that on GitHub.
-
-You may also have to edit your code to address their concerns. Some
-of the usual requests include fixing typos in comments, adding or
-correcting comments, adding unit tests in the test suite.  In order to
-do that, you should continue your edits in the same branch you used (in
-this example, "my_shiny_feature").  For instance, if you changed your
-working branch, you should first:
-
-.. code-block:: bash
-
-    git checkout my_shiny_feature
-
-Then, edit your code, and test it appropriately (see
-:ref:`quality_contributions` below), and push it again to your GitHub
-fork, like the first time (except the ``-u`` option is only needed the
-first time):
-
-.. code-block:: bash
 
-    git push origin my_shiny_feature
+The virtual environment will need to be activated in any environment
+(e.g. shells, IDEs, etc.) that plans to run the Aesara tests or add commits to the
+project repository.
 
-The pull request to the central repository will then be automatically
-updated by GitHub. However, the reviewers will not be automatically
-notified of your revision, so it is advised to reply to the comments on
-GitHub, to let them know that you have submitted a fix.
-
-
-More Advanced Git Usage
-=======================
-
-You can find information and tips in the `numpy development
-<http://docs.scipy.org/doc/numpy/dev/gitwash/development_workflow.html>`_
-page. Here are a few.
-
-
-Cleaning up branches
---------------------
-
-When your pull request has been merged, you can delete the branch from
-your GitHub fork's list of branches. This is useful to avoid having too
-many branches staying there. Deleting this remote branch is achieved
-with:
-
-.. code-block:: bash
-
-   git push origin :my_shiny_feature
-
-This lines pushes to the "origin" repository (your fork of Aesara on
-GitHub), into the branch "my_shiny_feature", an empty content (that's
-why there is nothing before the colon), effectively removing it.
-
-The branch will still be present in your local clone of the repository.
-If you want to delete it from there, too, you can run:
-
-.. code-block:: bash
-
-   git branch -d my_shiny_feature
-
-
-Amending a submitted pull request
----------------------------------
-
-If you want to fix a commit already submitted within a pull request
-(e.g. to fix a small typo), before the pull request is accepted, you can
-do it like this to keep history clean:
-
-.. code-block:: bash
-
-   git checkout my_shiny_feature
-   git commit --amend
-   git push origin my_shiny_feature:my_shiny_feature
-
-Do not abuse that command, and please use it only when there are only
-small issues to be taken care of. Otherwise, it becomes difficult to
-match the comments made by reviewers with the new modifications.
-In the general case, you should stick with the approach described above.
-
-
-Cleaning up history
--------------------
-
-Sometimes you may have commits in your feature branch that
-are not needed in the final pull request. There is a `page
-<http://sandofsky.com/blog/git-workflow.html>`_ that talks about
-this. In summary:
-
-* Commits to the trunk should be a lot cleaner than commits to your
-  feature branch; not just for ease of reviewing but also
-  because intermediate commits can break blame (the bisecting tool).
-* `git merge --squash` will put all of the commits from your feature branch into one commit.
-* There are other tools that are useful if your branch is too big for one squash.
-
-
-Add another distant repository
-------------------------------
-
-To collaborate with another user on some feature he is developing, and
-that is not ready for inclusion in central, the easiest way is to use a
-branch of their Aesara fork (usually on GitHub).
-
-Just like we added Aesara/Aesara as a remote repository, named
-"central", you can add (on your local machine) a reference to their fork
-as a new remote repository. REPO_NAME is the name you choose to name
-this fork, and GIT_REPO_PATH is the URL of the fork in question.
-
-.. code-block:: bash
-
-    git remote add REPO_NAME GIT_REPO_PATH
-
-Then, you can create a new local branch (LOCAL_BRANCH_NAME) based on
-a specific branch (REMOTE_BRANCH_NAME) from the remote repository
-(REPO_NAME):
-
-.. code-block:: bash
 
-   git checkout -b LOCAL_BRANCH_NAME REPO_NAME/REMOTE_BRANCH_NAME
+For a general guide on how to provide open source contributions see `here
+<https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution>`_.
+For a good overview of the development workflow (e.g. relevant ``git`` commands)
+see the `NumPy development guide <https://numpy.org/doc/stable/dev/>`_.
 
 
-Other tools that can help you
-=============================
+Other tools that might help
+===========================
 
- * `cProfile <http://docs.python.org/library/profile.html>`_: time profiler that work at function level.
- * `Yep <http://pypi.python.org/pypi/yep>`_: A module for profiling compiled extensions.
- * `autopep8 <http://pypi.python.org/pypi/autopep8/>`_: A tool that automatically formats Python code to conform to the PEP 8 style guide.
- * `line_profiler <http://pypi.python.org/pypi/line_profiler/>`_: Line-by-line profiler.
- * `memory_profiler <http://fseoane.net/blog/2012/line-by-line-report-of-memory-usage/>`_: memory profiler
- * `runsnake <http://www.vrplumber.com/programming/runsnakerun/>`_: Gui for cProfile(time profiler) and Meliae(memory profiler)
- * `Guppy <https://pypi.python.org/pypi/guppy/>`_: Supports object and heap memory sizing, profiling and debugging.
- * `hub <https://github.com/defunkt/hub>`_: A tool that adds github commands to the git command line.
- * `git pull-requests <http://www.splitbrain.org/blog/2011-06/19-automate_github_pull_requests>`_: Another tool for git/github command line.
+ * `cProfile <http://docs.python.org/library/profile.html>`_: Time profiler that work at function level
+ * `line_profiler <http://pypi.python.org/pypi/line_profiler/>`_: Line-by-line profiler
+ * `memory_profiler <http://fseoane.net/blog/2012/line-by-line-report-of-memory-usage/>`_: A memory profiler
+ * `runsnake <http://www.vrplumber.com/programming/runsnakerun/>`_: GUI for cProfile (time profiler) and Meliae (memory profiler)
+ * `Guppy <https://pypi.python.org/pypi/guppy/>`_: Supports object and heap memory sizing, profiling, and debugging
+ * `hub <https://github.com/defunkt/hub>`_: A tool that adds GitHub commands to the git command line
+ * `git pull-requests <http://www.splitbrain.org/blog/2011-06/19-automate_github_pull_requests>`_: Another command line tool for ``git``/GitHub

doc/extending/extending_aesara.rst

@@ -853,7 +853,6 @@ The section :ref:`Other Ops <other_ops>` includes more instructions for
 the following specific cases:
 
  - :ref:`scalar_ops`
- - :ref:`scipy_ops`
  - :ref:`sparse_ops`
  - :ref:`Random ops <random_ops>`
  - :ref:`openmp_ops`

doc/extending/scan.rst

@@ -143,16 +143,16 @@ through time for these variables.
 
 To synthesize :
 
-===========================================================  =====================================================  ==========================================================  ===========================================================  =========================================================  ======================================================
+===========================================================  =======================================================  ============================================================  =============================================================  =========================================================  ======================================================
 Type of `Scan` variables                                     Corresponding outer input                                Corresponding inner input at timestep ``t`` (indexed from 0)  Corresponding inner output at timestep ``t`` (indexed from 0)  Corresponding outer output ``t``                           Corresponding argument of the `aesara.scan` function
-===========================================================  =====================================================  ==========================================================  ===========================================================  =========================================================  ======================================================
+===========================================================  =======================================================  ============================================================  =============================================================  =========================================================  ======================================================
 Sequence                                                     Sequence of elements ``X``                               Individual sequence element ``X[t]``                          *No corresponding inner output*                                *No corresponding outer output*                            `sequences`
 Non-Sequence                                                 Any variable ``X``                                       Variable identical to ``X``                                   *No corresponding inner output*                                *No corresponding outer output*                            `non_sequences`
 Non-recurring output (NITSOT)                                *No corresponding outer input*                           *No corresponding inner input*                                Output value at timestep ``t``                                 Concatenation of the values of the output at all timestep  `outputs_info`
 Singly-recurrent output (SITSOT)                             Initial value (value at timestep ``-1``)                 Output value at previous timestep (``t-1``)                   Output value at timestep ``t``                                 Concatenation of the values of the output at all timestep  `outputs_info`
 Multiply-recurrent output (MITSOT)                           Initial values for the required timesteps where ``t<0``  Output value at previous required timesteps                   Output value at timestep ``t``                                 Concatenation of the values of the output at all timestep  `outputs_info`
 Multiply-recurrent multiple outputs (MITMOT)                 Initial values for the required timesteps where ``t<0``  Output value at previous required timesteps                   Output values for current and multiple future timesteps        Concatenation of the values of the output at all timestep  *No corresponding argument*
-===========================================================  =====================================================  ==========================================================  ===========================================================  =========================================================  ======================================================
+===========================================================  =======================================================  ============================================================  =============================================================  =========================================================  ======================================================
 
 
 .. _scan_internals_optimizations: