move images out of _static folder into _images

prevents sphinx from duplicating them into _static and _images

docs/source/interactive/qtconsole.txt

@@ -1,606 +1,606 b''
 .. _qtconsole:
 
 =========================
 A Qt Console for IPython
 =========================
 
 We now have a version of IPython, using the new two-process :ref:`ZeroMQ Kernel
 <ipythonzmq>`, running in a PyQt_ GUI.  This is a very lightweight widget that
 largely feels like a terminal, but provides a number of enhancements only
 possible in a GUI, such as inline figures, proper multiline editing with syntax
 highlighting, graphical calltips, and much more.
 
-.. figure:: ../_static/qtconsole.png
+.. figure:: ../../_images/qtconsole.png
     :width: 400px
     :alt: IPython Qt console with embedded plots
     :align: center
-    :target: ../_static/qtconsole.png
+    :target: ../_images/qtconsole.png
 
     The Qt console for IPython, using inline matplotlib plots.
 
 To get acquainted with the Qt console, type `%guiref` to see a quick
 introduction of its main features.
 
 The Qt frontend has hand-coded emacs-style bindings for text navigation. This
 is not yet configurable.
 
 .. tip::
 
    Since the Qt console tries hard to behave like a terminal, by default it
    immediately executes single lines of input that are complete.  If you want
    to force multiline input, hit :kbd:`Ctrl-Enter` at the end of the first line
    instead of :kbd:`Enter`, and it will open a new line for input.  At any
    point in a multiline block, you can force its execution (without having to
    go to the bottom) with :kbd:`Shift-Enter`.
 
 ``%load``
 =========
 
 The new ``%load`` magic (previously ``%loadpy``) takes any script, and pastes
 its contents as your next input, so you can edit it before executing. The
 script may be on your machine, but you can also specify an history range, or a
 url, and it will download the script from the web. This is particularly useful
 for playing with examples from documentation, such as matplotlib.
 
 .. sourcecode:: ipython
 
     In [6]: %load http://matplotlib.sourceforge.net/plot_directive/mpl_examples/mplot3d/contour3d_demo.py
 
     In [7]: from mpl_toolkits.mplot3d import axes3d
        ...: import matplotlib.pyplot as plt
        ...: 
        ...: fig = plt.figure()
        ...: ax = fig.add_subplot(111, projection='3d')
        ...: X, Y, Z = axes3d.get_test_data(0.05)
        ...: cset = ax.contour(X, Y, Z)
        ...: ax.clabel(cset, fontsize=9, inline=1)
        ...: 
        ...: plt.show()
 
 Pylab
 =====
 
 One of the most exciting features of the new console is embedded matplotlib
 figures. You can use any standard matplotlib GUI backend
 to draw the figures, and since there is now a two-process model, there is no
 longer a conflict between user input and the drawing eventloop.
 
 .. image:: figs/besselj.png
     :width: 519px
 
 .. display:
 
 :func:`display`
 ***************
 
 An additional function, :func:`display`, will be added to the global namespace
 if you specify the ``--pylab`` option at the command line. The IPython display
 system provides a mechanism for specifying PNG or SVG (and more)
 representations of objects for GUI frontends. By default, IPython registers
 convenient PNG and SVG renderers for matplotlib figures, so you can embed them
 in your document by calling :func:`display` on one or more of them. This is
 especially useful for saving_ your work.
 
 .. sourcecode:: ipython
 
     In [5]: plot(range(5)) # plots in the matplotlib window
     
     In [6]: display(gcf()) # embeds the current figure in the qtconsole
     
     In [7]: display(*getfigs()) # embeds all active figures in the qtconsole
 
 If you have a reference to a matplotlib figure object, you can always display
 that specific figure:
 
 .. sourcecode:: ipython
 
    In [1]: f = figure()
 
    In [2]: plot(rand(100))
    Out[2]: [<matplotlib.lines.Line2D at 0x7fc6ac03dd90>]
 
    In [3]: display(f)
 
    # Plot is shown here
 
    In [4]: title('A title')
    Out[4]: <matplotlib.text.Text at 0x7fc6ac023450>
 
    In [5]: display(f)
 
    # Updated plot with title is shown here.
 
 .. _inline:
 
 ``--pylab=inline``
 ******************
 
 If you want to have all of your figures embedded in your session, instead of
 calling :func:`display`, you can specify ``--pylab=inline`` when you start the
 console, and each time you make a plot, it will show up in your document, as if
 you had called :func:`display(fig)`.
 
 The inline backend can use either SVG or PNG figures (PNG being the default).
 To switch between them, set the ``InlineBackend.figure_format`` configurable
 in a config file, or via the ``%config`` magic:
 
 .. sourcecode:: ipython
 
     In [10]: %config InlineBackend.figure_format = 'svg'
 
 .. note::
 
     Changing the inline figure format also affects calls to :func:`display` above,
     even if you are not using the inline backend for all figures.
 
 By default, IPython closes all figures at the completion of each execution. This means you
 don't have to manually close figures, which is less convenient when figures aren't attached
 to windows with an obvious close button.  It also means that the first matplotlib call in
 each cell will always create a new figure:
 
 .. sourcecode:: ipython
 
     In [11]: plot(range(100))
     <single-line plot>
     
     In [12]: plot([1,3,2])
     <another single-line plot>
 
 
 However, it does prevent the list of active figures surviving from one input cell to the
 next, so if you want to continue working with a figure, you must hold on to a reference to
 it:
 
 .. sourcecode:: ipython
 
     In [11]: fig = gcf()
        ....: fig.plot(rand(100))
     <plot>
     In [12]: fig.title('Random Title')
     <redraw plot with title>
 
 This behavior is controlled by the :attr:`InlineBackend.close_figures` configurable, and
 if you set it to False, via %config or config file, then IPython will *not* close figures,
 and tools like :func:`gcf`, :func:`gca`, :func:`getfigs` will behave the same as they
 do with other backends.  You will, however, have to manually close figures:
 
 .. sourcecode:: ipython
 
     # close all active figures:
     In [13]: [ fig.close() for fig in getfigs() ]
 
 
 
 .. _saving:
 
 Saving and Printing
 ===================
 
 IPythonQt has the ability to save your current session, as either HTML or
 XHTML. If you have been using :func:`display` or inline_ pylab, your figures
 will be PNG in HTML, or inlined as SVG in XHTML. PNG images have the option to
 be either in an external folder, as in many browsers' "Webpage, Complete"
 option, or inlined as well, for a larger, but more portable file.
 
 .. note::
 
     Export to SVG+XHTML requires that you are using SVG figures, which is *not*
     the default.  To switch the inline figure format to use SVG during an active
     session, do:
     
     .. sourcecode:: ipython
     
         In [10]: %config InlineBackend.figure_format = 'svg'
     
     Or, you can add the same line (c.Inline... instead of %config Inline...) to
     your config files.
     
     This will only affect figures plotted after making this call
 
 
 The widget also exposes the ability to print directly, via the default print
 shortcut or context menu.
 
 
 .. Note:: 
 
     Saving is only available to richtext Qt widgets, which are used by default,
     but if you pass the ``--plain`` flag, saving will not be available to you.
 
 
 See these examples of :download:`png/html<figs/jn.html>` and
 :download:`svg/xhtml <figs/jn.xhtml>` output. Note that syntax highlighting
 does not survive export. This is a known issue, and is being investigated.
 
 
 Colors and Highlighting
 =======================
 
 Terminal IPython has always had some coloring, but never syntax
 highlighting. There are a few simple color choices, specified by the ``colors``
 flag or ``%colors`` magic:
 
 * LightBG for light backgrounds
 * Linux for dark backgrounds
 * NoColor for a simple colorless terminal
 
 The Qt widget has full support for the ``colors`` flag used in the terminal shell.
 
 The Qt widget, however, has full syntax highlighting as you type, handled by
 the `pygments`_ library. The ``style`` argument exposes access to any style by
 name that can be found by pygments, and there are several already
 installed. The ``colors`` argument, if unspecified, will be guessed based on
 the chosen style. Similarly, there are default styles associated with each
 ``colors`` option.
 
 
 Screenshot of ``ipython qtconsole --colors=linux``, which uses the 'monokai'
 theme by default:
 
 .. image:: figs/colors_dark.png
     :width: 627px
     
 .. Note::
 
     Calling ``ipython qtconsole -h`` will show all the style names that
     pygments can find on your system.
 
 You can also pass the filename of a custom CSS stylesheet, if you want to do
 your own coloring, via the ``stylesheet`` argument.  The default LightBG
 stylesheet:
 
 .. sourcecode:: css
 
     QPlainTextEdit, QTextEdit { background-color: white;
             color: black ;
             selection-background-color: #ccc}
     .error { color: red; }
     .in-prompt { color: navy; }
     .in-prompt-number { font-weight: bold; }
     .out-prompt { color: darkred; }
     .out-prompt-number { font-weight: bold; }
     /* .inverted is used to highlight selected completion */
     .inverted { background-color: black ; color: white; }
 
 Fonts
 =====
 
 The QtConsole has configurable via the ConsoleWidget. To change these, set the
 ``font_family`` or ``font_size`` traits of the ConsoleWidget. For instance, to
 use 9pt Anonymous Pro::
 
     $> ipython qtconsole --ConsoleWidget.font_family="Anonymous Pro" --ConsoleWidget.font_size=9
 
 Process Management
 ==================
 
 With the two-process ZMQ model, the frontend does not block input during
 execution. This means that actions can be taken by the frontend while the
 Kernel is executing, or even after it crashes. The most basic such command is
 via 'Ctrl-.', which restarts the kernel.  This can be done in the middle of a
 blocking execution. The frontend can also know, via a heartbeat mechanism, that
 the kernel has died. This means that the frontend can safely restart the
 kernel.
 
 .. _multiple_consoles:
 
 Multiple Consoles
 *****************
 
 Since the Kernel listens on the network, multiple frontends can connect to it.
 These do not have to all be qt frontends - any IPython frontend can connect and
 run code.  When you start ipython qtconsole, there will be an output line,
 like::
 
     [IPKernelApp] To connect another client to this kernel, use:
     [IPKernelApp] --existing kernel-12345.json
 
 Other frontends can connect to your kernel, and share in the execution. This is
 great for collaboration.  The ``--existing`` flag means connect to a kernel
 that already exists.  Starting other consoles
 with that flag will not try to start their own kernel, but rather connect to
 yours.  :file:`kernel-12345.json` is a small JSON file with the ip, port, and
 authentication information necessary to connect to your kernel. By default, this file
 will be in your default profile's security directory.  If it is somewhere else,
 the output line will print the full path of the connection file, rather than
 just its filename.
 
 If you need to find the connection info to send, and don't know where your connection file
 lives, there are a couple of ways to get it. If you are already running an IPython console
 connected to the kernel, you can use the ``%connect_info`` magic to display the information
 necessary to connect another frontend to the kernel.
 
 .. sourcecode:: ipython
 
     In [2]: %connect_info
     {
       "stdin_port":50255,
       "ip":"127.0.0.1",
       "hb_port":50256,
       "key":"70be6f0f-1564-4218-8cda-31be40a4d6aa",
       "shell_port":50253,
       "iopub_port":50254
     }
 
     Paste the above JSON into a file, and connect with:
         $> ipython <app> --existing <file>
     or, if you are local, you can connect with just:
         $> ipython <app> --existing kernel-12345.json
     or even just:
         $> ipython <app> --existing
     if this is the most recent IPython session you have started.
 
 Otherwise, you can find a connection file by name (and optionally profile) with
 :func:`IPython.lib.kernel.find_connection_file`:
 
 .. sourcecode:: bash
 
     $> python -c "from IPython.lib.kernel import find_connection_file;\
     print find_connection_file('kernel-12345.json')"
     /home/you/.ipython/profile_default/security/kernel-12345.json
 
 And if you are using a particular IPython profile:
 
 .. sourcecode:: bash
 
     $> python -c "from IPython.lib.kernel import find_connection_file;\
     print find_connection_file('kernel-12345.json', profile='foo')"
     /home/you/.ipython/profile_foo/security/kernel-12345.json
 
 You can even launch a standalone kernel, and connect and disconnect Qt Consoles
 from various machines.  This lets you keep the same running IPython session
 on your work machine (with matplotlib plots and everything), logging in from home,
 cafés, etc.::
 
     $> ipython kernel
     [IPKernelApp] To connect another client to this kernel, use:
     [IPKernelApp] --existing kernel-12345.json
 
 This is actually exactly the same as the subprocess launched by the qtconsole, so
 all the information about connecting to a standalone kernel is identical to that
 of connecting to the kernel attached to a running console.
 
 .. _kernel_security:
 
 Security
 --------
 
 .. warning::
 
     Since the ZMQ code currently has no encryption, listening on an
     external-facing IP is dangerous.  You are giving any computer that can see
     you on the network the ability to connect to your kernel, and view your traffic.
     Read the rest of this section before listening on external ports
     or running an IPython kernel on a shared machine.
 
 By default (for security reasons), the kernel only listens on localhost, so you
 can only connect multiple frontends to the kernel from your local machine. You
 can specify to listen on an external interface by specifying the ``ip``
 argument::
 
     $> ipython qtconsole --ip=192.168.1.123
 
 If you specify the ip as 0.0.0.0 or '*', that means all interfaces, so any
 computer that can see yours on the network can connect to the kernel.
 
 Messages are not encrypted, so users with access to the ports your kernel is using will be
 able to see any output of the kernel. They will **NOT** be able to issue shell commands as
 you due to message signatures, which are enabled by default as of IPython 0.12.
 
 .. warning::
 
     If you disable message signatures, then any user with access to the ports your
     kernel is listening on can issue arbitrary code as you. **DO NOT** disable message
     signatures unless you have a lot of trust in your environment.
 
 The one security feature IPython does provide is protection from unauthorized execution.
 IPython's messaging system will sign messages with HMAC digests using a shared-key. The key
 is never sent over the network, it is only used to generate a unique hash for each message,
 based on its content. When IPython receives a message, it will check that the digest
 matches, and discard the message. You can use any file that only you have access to to
 generate this key, but the default is just to generate a new UUID. You can generate a random
 private key with::
 
     # generate 1024b of random data, and store in a file only you can read:
     # (assumes IPYTHONDIR is defined, otherwise use your IPython directory)
     $> python -c "import os; print os.urandom(128).encode('base64')" > $IPYTHONDIR/sessionkey
     $> chmod 600 $IPYTHONDIR/sessionkey
 
 The *contents* of this file will be stored in the JSON connection file, so that file
 contains everything you need to connect to and use a kernel.
 
 To use this generated key, simply specify the ``Session.keyfile`` configurable
 in :file:`ipython_config.py` or at the command-line, as in::
 
     # instruct IPython to sign messages with that key, instead of a new UUID
     $> ipython qtconsole --Session.keyfile=$IPYTHONDIR/sessionkey
 
 .. _ssh_tunnels:
 
 SSH Tunnels
 -----------
 
 Sometimes you want to connect to machines across the internet, or just across
 a LAN that either doesn't permit open ports or you don't trust the other
 machines on the network.  To do this, you can use SSH tunnels.  SSH tunnels
 are a way to securely forward ports on your local machine to ports on another
 machine, to which you have SSH access.
 
 In simple cases, IPython's tools can forward ports over ssh by simply adding the
 ``--ssh=remote`` argument to the usual ``--existing...`` set of flags for connecting
 to a running kernel, after copying the JSON connection file (or its contents) to
 the second computer.
 
 .. warning::
 
     Using SSH tunnels does *not* increase localhost security.  In fact, when
     tunneling from one machine to another *both* machines have open
     ports on localhost available for connections to the kernel.
 
 There are two primary models for using SSH tunnels with IPython.  The first
 is to have the Kernel listen only on localhost, and connect to it from
 another machine on the same LAN.
 
 First, let's start a kernel on machine **worker**, listening only
 on loopback::
 
     user@worker $> ipython kernel
     [IPKernelApp] To connect another client to this kernel, use:
     [IPKernelApp] --existing kernel-12345.json
 
 In this case, the IP that you would connect
 to would still be 127.0.0.1, but you want to specify the additional ``--ssh`` argument
 with the hostname of the kernel (in this example, it's 'worker')::
 
     user@client $> ipython qtconsole  --ssh=worker --existing /path/to/kernel-12345.json
 
 Which will write a new connection file with the forwarded ports, so you can reuse them::
 
     [IPythonQtConsoleApp] To connect another client via this tunnel, use:
     [IPythonQtConsoleApp] --existing kernel-12345-ssh.json
 
 Note again that this opens ports on the *client* machine that point to your kernel.
 
 .. note::
 
     the ssh argument is simply passed to openssh, so it can be fully specified ``user@host:port``
     but it will also respect your aliases, etc. in :file:`.ssh/config` if you have any.
 
 The second pattern is for connecting to a machine behind a firewall across the internet
 (or otherwise wide network). This time, we have a machine **login** that you have ssh access
 to, which can see **kernel**, but **client** is on another network. The important difference
 now is that **client** can see **login**, but *not* **worker**. So we need to forward ports from
 client to worker *via* login. This means that the kernel must be started listening
 on external interfaces, so that its ports are visible to `login`::
 
     user@worker $> ipython kernel --ip=0.0.0.0
     [IPKernelApp] To connect another client to this kernel, use:
     [IPKernelApp] --existing kernel-12345.json
 
 Which we can connect to from the client with::
 
     user@client $> ipython qtconsole --ssh=login --ip=192.168.1.123 --existing /path/to/kernel-12345.json
 
 .. note::
 
     The IP here is the address of worker as seen from *login*, and need only be specified if
     the kernel used the ambiguous 0.0.0.0 (all interfaces) address. If it had used
     192.168.1.123 to start with, it would not be needed.
 
 
 Manual SSH tunnels
 ------------------
 
 It's possible that IPython's ssh helper functions won't work for you, for various
 reasons.  You can still connect to remote machines, as long as you set up the tunnels
 yourself.  The basic format of forwarding a local port to a remote one is::
 
     [client] $> ssh <server> <localport>:<remoteip>:<remoteport> -f -N
 
 This will forward local connections to **localport** on client to **remoteip:remoteport**
 *via* **server**. Note that remoteip is interpreted relative to *server*, not the client.
 So if you have direct ssh access to the machine to which you want to forward connections,
 then the server *is* the remote machine, and remoteip should be server's IP as seen from the
 server itself, i.e. 127.0.0.1.  Thus, to forward local port 12345 to remote port 54321 on
 a machine you can see, do::
 
     [client] $> ssh machine 12345:127.0.0.1:54321 -f -N
 
 But if your target is actually on a LAN at 192.168.1.123, behind another machine called **login**,
 then you would do::
 
     [client] $> ssh login 12345:192.168.1.16:54321 -f -N
 
 The ``-f -N`` on the end are flags that tell ssh to run in the background,
 and don't actually run any commands beyond creating the tunnel.
 
 .. seealso::
 
     A short discussion of ssh tunnels: http://www.revsys.com/writings/quicktips/ssh-tunnel.html
 
 
 
 Stopping Kernels and Consoles
 *****************************
 
 Since there can be many consoles per kernel, the shutdown mechanism and dialog
 are probably more complicated than you are used to. Since you don't always want
 to shutdown a kernel when you close a window, you are given the option to just
 close the console window or also close the Kernel and *all other windows*. Note
 that this only refers to all other *local* windows, as remote Consoles are not
 allowed to shutdown the kernel, and shutdowns do not close Remote consoles (to
 allow for saving, etc.).
 
 Rules:
 
     * Restarting the kernel automatically clears all *local* Consoles, and prompts remote
       Consoles about the reset.
     * Shutdown closes all *local* Consoles, and notifies remotes that
       the Kernel has been shutdown.
     * Remote Consoles may not restart or shutdown the kernel.
 
 Qt and the QtConsole
 ====================
 
 An important part of working with the QtConsole when you are writing your own
 Qt code is to remember that user code (in the kernel) is *not* in the same
 process as the frontend.  This means that there is not necessarily any Qt code
 running in the kernel, and under most normal circumstances there isn't. If,
 however, you specify ``--pylab=qt`` at the command-line, then there *will* be a
 :class:`QCoreApplication` instance running in the kernel process along with
 user-code. To get a reference to this application, do:
 
 .. sourcecode:: python
 
     from PyQt4 import QtCore
     app = QtCore.QCoreApplication.instance()
     # app will be None if there is no such instance
 
 A common problem listed in the PyQt4 Gotchas_ is the fact that Python's garbage
 collection will destroy Qt objects (Windows, etc.) once there is no longer a
 Python reference to them, so you have to hold on to them.  For instance, in:
 
 .. sourcecode:: python
 
     def make_window():
         win = QtGui.QMainWindow()
     
     def make_and_return_window():
         win = QtGui.QMainWindow()
         return win
 
 :func:`make_window` will never draw a window, because garbage collection will
 destroy it before it is drawn, whereas :func:`make_and_return_window` lets the
 caller decide when the window object should be destroyed.  If, as a developer,
 you know that you always want your objects to last as long as the process, you
 can attach them to the QApplication instance itself:
 
 .. sourcecode:: python
     
     # do this just once:
     app = QtCore.QCoreApplication.instance()
     app.references = set()
     # then when you create Windows, add them to the set
     def make_window():
         win = QtGui.QMainWindow()
         app.references.add(win)
 
 Now the QApplication itself holds a reference to ``win``, so it will never be
 garbage collected until the application itself is destroyed.
 
 .. _Gotchas: http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/gotchas.html#garbage-collection
 
 Regressions
 ===========
 
 There are some features, where the qt console lags behind the Terminal
 frontend:
 
 * !cmd input: Due to our use of pexpect, we cannot pass input to subprocesses
   launched using the '!' escape, so you should never call a command that
   requires interactive input.  For such cases, use the terminal IPython.  This
   will not be fixed, as abandoning pexpect would significantly degrade the
   console experience.
 
 .. _PyQt: http://www.riverbankcomputing.co.uk/software/pyqt/download
 .. _pygments: http://pygments.org/

docs/source/whatsnew/version0.11.txt

@@ -1,765 +1,765 b''
 =============
  0.11 Series
 =============
 
 Release 0.11
 ============
 
 IPython 0.11 is a *major* overhaul of IPython, two years in the making.  Most
 of the code base has been rewritten or at least reorganized, breaking backward
 compatibility with several APIs in previous versions.  It is the first major
 release in two years, and probably the most significant change to IPython since
 its inception.  We plan to have a relatively quick succession of releases, as
 people discover new bugs and regressions.  Once we iron out any significant
 bugs in this process and settle down the new APIs, this series will become
 IPython 1.0.  We encourage feedback now on the core APIs, which we hope to
 maintain stable during the 1.0 series.
 
 Since the internal APIs have changed so much, projects using IPython as a
 library (as opposed to end-users of the application) are the most likely to
 encounter regressions or changes that break their existing use patterns.  We
 will make every effort to provide updated versions of the APIs to facilitate
 the transition, and we encourage you to contact us on the `development mailing
 list`__ with questions and feedback.
 
 .. __: http://mail.scipy.org/mailman/listinfo/ipython-dev
 
 Chris Fonnesbeck recently wrote an `excellent post`__ that highlights some of
 our major new features, with examples and screenshots.  We encourage you to
 read it as it provides an illustrated, high-level overview complementing the
 detailed feature breakdown in this document.
 
 .. __: http://fonnesbeck.calepin.co/innovations-in-ipython.html
 
 A quick summary of the major changes (see below for details):
 
 * **Standalone Qt console**: a new rich console has been added to IPython,
   started with `ipython qtconsole`.  In this application we have tried to
   retain the feel of a terminal for fast and efficient workflows, while adding
   many features that a line-oriented terminal simply can not support, such as
   inline figures, full multiline editing with syntax highlighting, graphical
   tooltips for function calls and much more.  This development was sponsored by
   `Enthought Inc.`__. See :ref:`below <qtconsole_011>` for details.
 
 .. __: http://enthought.com
 
 * **High-level parallel computing with ZeroMQ**. Using the same architecture
   that our Qt console is based on, we have completely rewritten our high-level
   parallel computing machinery that in prior versions used the Twisted
   networking framework.  While this change will require users to update their
   codes, the improvements in performance, memory control and internal
   consistency across our codebase convinced us it was a price worth paying.  We
   have tried to explain how to best proceed with this update, and will be happy
   to answer questions that may arise.  A full tutorial describing these
   features `was presented at SciPy'11`__, more details :ref:`below
   <parallel_011>`.
 
 .. __: http://minrk.github.com/scipy-tutorial-2011
 
 * **New model for GUI/plotting support in the terminal**.  Now instead of the
   various `-Xthread` flags we had before, GUI support is provided without the
   use of any threads, by directly integrating GUI event loops with Python's
   `PyOS_InputHook` API.  A new command-line flag `--gui` controls GUI support,
   and it can also be enabled after IPython startup via the new `%gui` magic.
   This requires some changes if you want to execute GUI-using scripts inside
   IPython, see :ref:`the GUI support section <gui_support>` for more details.
 
 * **A two-process architecture.** The Qt console is the first use of a new
   model that splits IPython between a kernel process where code is executed and
   a client that handles user interaction.  We plan on also providing terminal
   and web-browser based clients using this infrastructure in future releases.
   This model allows multiple clients to interact with an IPython process
   through a :ref:`well-documented messaging protocol <messaging>` using the
   ZeroMQ networking library.
 
 * **Refactoring.** the entire codebase has been refactored, in order to make it
   more modular and easier to contribute to.  IPython has traditionally been a
   hard project to participate because the old codebase was very monolithic.  We
   hope this (ongoing) restructuring will make it easier for new developers to
   join us.
 
 * **Vim integration**. Vim can be configured to seamlessly control an IPython
   kernel, see the files in :file:`docs/examples/vim` for the full details.
   This work was done by Paul Ivanov, who prepared a nice `video
   demonstration`__ of the features it provides.
 
 .. __: http://pirsquared.org/blog/2011/07/28/vim-ipython/
   
 * **Integration into Microsoft Visual Studio**. Thanks to the work of the
   Microsoft `Python Tools for Visual Studio`__ team, this version of IPython
   has been integrated into Microsoft Visual Studio's Python tools open source
   plug-in.  `Details below`_
 
 .. __: http://pytools.codeplex.com
 .. _details below: ms_visual_studio_011_
 
 * **Improved unicode support**. We closed many bugs related to unicode input.
 
 * **Python 3**. IPython now runs on Python 3.x. See :ref:`python3_011` for
   details.
 
 * **New profile model**. Profiles are now directories that contain all relevant
   information for that session, and thus better isolate IPython use-cases.
 
 * **SQLite storage for history**. All history is now stored in a SQLite
   database, providing support for multiple simultaneous sessions that won't
   clobber each other as well as the ability to perform queries on all stored
   data.
 
 * **New configuration system**. All parts of IPython are now configured via a
   mechanism inspired by the Enthought Traits library.  Any configurable element
   can have its attributes set either via files that now use real Python syntax
   or from the command-line.
 
 * **Pasting of code with prompts**. IPython now intelligently strips out input
   prompts , be they plain Python ones (``>>>`` and ``...``) or IPython ones
   (``In [N]:`` and ``...:``).  More details :ref:`here <pasting_with_prompts>`.
   
 
 Authors and support
 -------------------
 
 Over 60 separate authors have contributed to this release, see :ref:`below
 <credits_011>` for a full list.  In particular, we want to highlight the
 extremely active participation of two new core team members: Evan Patterson
 implemented the Qt console, and Thomas Kluyver started with our Python 3 port
 and by now has made major contributions to just about every area of IPython.
 
 We are also grateful for the support we have received during this development
 cycle from several institutions:
 
 - `Enthought Inc`__ funded the development of our new Qt console, an effort that
   required developing major pieces of underlying infrastructure, which now
   power not only the Qt console but also our new parallel machinery.  We'd like
   to thank Eric Jones and Travis Oliphant for their support, as well as Ilan
   Schnell for his tireless work integrating and testing IPython in the
   `Enthought Python Distribution`_.
 
 .. __: http://enthought.com
 .. _Enthought Python Distribution: http://www.enthought.com/products/epd.php
 
 - Nipy/NIH: funding via the `NiPy project`__ (NIH grant 5R01MH081909-02) helped
   us jumpstart the development of this series by restructuring the entire
   codebase two years ago in a way that would make modular development and
   testing more approachable.  Without this initial groundwork, all the new
   features we have added would have been impossible to develop.
 
 .. __: http://nipy.org
 
 - Sage/NSF: funding via the grant `Sage: Unifying Mathematical Software for
   Scientists, Engineers, and Mathematicians`__ (NSF grant DMS-1015114)
   supported a meeting in spring 2011 of several of the core IPython developers
   where major progress was made integrating the last key pieces leading to this
   release.
 
 .. __: http://modular.math.washington.edu/grants/compmath09
 
 - Microsoft's team working on `Python Tools for Visual Studio`__ developed the 
   integraton of IPython into the Python plugin for Visual Studio 2010.
 
 .. __: http://pytools.codeplex.com
 
 - Google Summer of Code: in 2010, we had two students developing prototypes of
   the new machinery that is now maturing in this release: `Omar Zapata`_ and
   `Gerardo Gutiérrez`_.
 
 .. _Omar Zapata: http://ipythonzmq.blogspot.com/2010/08/ipython-zmq-status.html
 .. _Gerardo Gutiérrez: http://ipythonqt.blogspot.com/2010/04/ipython-qt-interface-gsoc-2010-proposal.html>
 
 
 Development summary: moving to Git and Github
 ---------------------------------------------
 
 In April 2010, after `one breakage too many with bzr`__, we decided to move our
 entire development process to Git and Github.com.  This has proven to be one of
 the best decisions in the project's history, as the combination of git and
 github have made us far, far more productive than we could be with our previous
 tools.  We first converted our bzr repo to a git one without losing history,
 and a few weeks later ported all open Launchpad bugs to github issues with
 their comments mostly intact (modulo some formatting changes).  This ensured a
 smooth transition where no development history or submitted bugs were lost.
 Feel free to use our little Launchpad to Github issues `porting script`_ if you
 need to make a similar transition.
 
 .. __: http://mail.scipy.org/pipermail/ipython-dev/2010-April/005944.html
 .. _porting script: https://gist.github.com/835577
 
 These simple statistics show how much work has been done on the new release, by
 comparing the current code to the last point it had in common with the 0.10
 series.  A huge diff and ~2200 commits make up this cycle::
 
     git diff $(git merge-base 0.10.2 HEAD)  | wc -l
     288019
 
     git log $(git merge-base 0.10.2 HEAD)..HEAD --oneline | wc -l
     2200
 
 Since our move to github, 511 issues were closed, 226 of which were pull
 requests and 285 regular issues (:ref:`a full list with links
 <issues_list_011>` is available for those interested in the details).  Github's
 pull requests are a fantastic mechanism for reviewing code and building a
 shared ownership of the project, and we are making enthusiastic use of it.
 
 .. Note::
 
    This undercounts the number of issues closed in this development cycle,
    since we only moved to github for issue tracking in May 2010, but we have no
    way of collecting statistics on the number of issues closed in the old
    Launchpad bug tracker prior to that.
 
    
 .. _qtconsole_011:
 
 Qt Console
 ----------
 
 IPython now ships with a Qt application that feels very much like a terminal,
 but is in fact a rich GUI that runs an IPython client but supports inline
 figures, saving sessions to PDF and HTML, multiline editing with syntax
 highlighting, graphical calltips and much more:
 
-.. figure:: ../_static/qtconsole.png
+.. figure:: ../_images/qtconsole.png
     :width: 400px
     :alt: IPython Qt console with embedded plots
     :align: center
-    :target: ../_static/qtconsole.png
+    :target: ../_images/qtconsole.png
 
     The Qt console for IPython, using inline matplotlib plots.
 
 We hope that many projects will embed this widget, which we've kept
 deliberately very lightweight, into their own environments.  In the future we
 may also offer a slightly more featureful application (with menus and other GUI
 elements), but we remain committed to always shipping this easy to embed
 widget.
 
 See the :ref:`Qt console section <qtconsole>` of the docs for a detailed
 description of the console's features and use.
 
 
 .. _parallel_011:
 
 High-level parallel computing with ZeroMQ
 -----------------------------------------
 
 We have completely rewritten the Twisted-based code for high-level parallel
 computing to work atop our new ZeroMQ architecture.  While we realize this will
 break compatibility for a number of users, we hope to make the transition as
 easy as possible with our docs, and we are convinced the change is worth it.
 ZeroMQ provides us with much tighter control over memory, higher performance,
 and its communications are impervious to the Python Global Interpreter Lock
 because they take place in a system-level C++ thread.  The impact of the GIL in
 our previous code was something we could simply not work around, given that
 Twisted is itself a Python library.  So while Twisted is a very capable
 framework, we think ZeroMQ fits our needs much better and we hope you will find
 the change to be a significant improvement in the long run.
 
 Our manual contains :ref:`a full description of how to use IPython for parallel
 computing <parallel_overview>`, and the `tutorial`__ presented by Min
 Ragan-Kelley at the SciPy 2011 conference provides a hands-on complement to the
 reference docs.
 
 .. __: http://minrk.github.com/scipy-tutorial-2011
 
 
 Refactoring
 -----------
 
 As of this release, a signifiant portion of IPython has been refactored.  This
 refactoring is founded on a number of new abstractions.  The main new classes
 that implement these abstractions are:
 
 * :class:`IPython.utils.traitlets.HasTraits`.
 * :class:`IPython.config.configurable.Configurable`.
 * :class:`IPython.config.application.Application`.
 * :class:`IPython.config.loader.ConfigLoader`.
 * :class:`IPython.config.loader.Config`
 
 We are still in the process of writing developer focused documentation about
 these classes, but for now our :ref:`configuration documentation
 <config_overview>` contains a high level overview of the concepts that these
 classes express.
 
 The biggest user-visible change is likely the move to using the config system
 to determine the command-line arguments for IPython applications. The benefit
 of this is that *all* configurable values in IPython are exposed on the
 command-line, but the syntax for specifying values has changed. The gist is
 that assigning values is pure Python assignment.  Simple flags exist for
 commonly used options, these are always prefixed with '--'.
 
 The IPython command-line help has the details of all the options (via
 ``ipythyon --help``), but a simple example should clarify things; the ``pylab``
 flag can be used to start in pylab mode with the qt4 backend::
 
   ipython --pylab=qt
 
 which is equivalent to using the fully qualified form::
 
   ipython --TerminalIPythonApp.pylab=qt
 
 The long-form options can be listed via ``ipython --help-all``.
 
 
 ZeroMQ architecture
 -------------------
 
 There is a new GUI framework for IPython, based on a client-server model in
 which multiple clients can communicate with one IPython kernel, using the
 ZeroMQ messaging framework. There is already a Qt console client, which can
 be started by calling ``ipython qtconsole``. The protocol is :ref:`documented
 <messaging>`.
 
 The parallel computing framework has also been rewritten using ZMQ. The
 protocol is described :ref:`here <parallel_messages>`, and the code is in the
 new :mod:`IPython.parallel` module.
 
 .. _python3_011:
 
 Python 3 support
 ----------------
 
 A Python 3 version of IPython has been prepared. For the time being, this is
 maintained separately and updated from the main codebase. Its code can be found
 `here <https://github.com/ipython/ipython-py3k>`_. The parallel computing
 components are not perfect on Python3, but most functionality appears to be
 working.  As this work is evolving quickly, the best place to find updated
 information about it is our `Python 3 wiki page`__.
 
 .. __: http://wiki.ipython.org/index.php?title=Python_3
 
 
 Unicode
 -------
 
 Entering non-ascii characters in unicode literals (``u"€ø"``) now works
 properly on all platforms. However, entering these in byte/string literals
 (``"€ø"``) will not work as expected on Windows (or any platform where the
 terminal encoding is not UTF-8, as it typically is for Linux & Mac OS X). You
 can use escape sequences (``"\xe9\x82"``) to get bytes above 128, or use
 unicode literals and encode them. This is a limitation of Python 2 which we
 cannot easily work around.
 
 .. _ms_visual_studio_011:
 
 Integration with Microsoft Visual Studio
 ----------------------------------------
 
 IPython can be used as the interactive shell in the `Python plugin for
 Microsoft Visual Studio`__, as seen here:
 
-.. figure:: ../_static/ms_visual_studio.png
+.. figure:: ../_images/ms_visual_studio.png
     :width: 500px
     :alt: IPython console embedded in Microsoft Visual Studio.
     :align: center
-    :target: ../_static/ms_visual_studio.png
+    :target: ../_images/ms_visual_studio.png
 
     IPython console embedded in Microsoft Visual Studio.
 
 The Microsoft team developing this currently has a release candidate out using
 IPython 0.11. We will continue to collaborate with them to ensure that as they
 approach their final release date, the integration with IPython remains smooth.
 We'd like to thank Dino Viehland and Shahrokh Mortazavi for the work they have
 done towards this feature, as well as Wenming Ye for his support of our WinHPC
 capabilities.
 
 .. __: http://pytools.codeplex.com
 
 
 Additional new features
 -----------------------
 
 * Added ``Bytes`` traitlet, removing ``Str``.  All 'string' traitlets should
   either be ``Unicode`` if a real string, or ``Bytes`` if a C-string. This
   removes ambiguity and helps the Python 3 transition.
 
 * New magic ``%loadpy`` loads a python file from disk or web URL into
   the current input buffer.
 
 * New magic ``%pastebin`` for sharing code via the 'Lodge it' pastebin.
 
 * New magic ``%precision`` for controlling float and numpy pretty printing.
 
 * IPython applications initiate logging, so any object can gain access to
   a the logger of the currently running Application with:
 
 .. sourcecode:: python
 
     from IPython.config.application import Application
     logger = Application.instance().log
 
 * You can now get help on an object halfway through typing a command. For
   instance, typing ``a = zip?`` shows the details of :func:`zip`. It also
   leaves the command at the next prompt so you can carry on with it.
 
 * The input history is now written to an SQLite database. The API for
   retrieving items from the history has also been redesigned.
 
 * The :mod:`IPython.extensions.pretty` extension has been moved out of
   quarantine and fully updated to the new extension API.
 
 * New magics for loading/unloading/reloading extensions have been added:
   ``%load_ext``, ``%unload_ext`` and ``%reload_ext``.
 
 * The configuration system and configuration files are brand new. See the
   configuration system :ref:`documentation <config_index>` for more details.
 
 * The :class:`~IPython.core.interactiveshell.InteractiveShell` class is now a
   :class:`~IPython.config.configurable.Configurable` subclass and has traitlets
   that determine the defaults and runtime environment. The ``__init__`` method
   has also been refactored so this class can be instantiated and run without
   the old :mod:`ipmaker` module.
 
 * The methods of :class:`~IPython.core.interactiveshell.InteractiveShell` have
   been organized into sections to make it easier to turn more sections
   of functionality into components.
 
 * The embedded shell has been refactored into a truly standalone subclass of
   :class:`InteractiveShell` called :class:`InteractiveShellEmbed`.  All
   embedding logic has been taken out of the base class and put into the 
   embedded subclass.
 
 * Added methods of :class:`~IPython.core.interactiveshell.InteractiveShell` to
   help it cleanup after itself. The :meth:`cleanup` method controls this. We
   couldn't do this in :meth:`__del__` because we have cycles in our object
   graph that prevent it from being called.
 
 * Created a new module :mod:`IPython.utils.importstring` for resolving
   strings like ``foo.bar.Bar`` to the actual class.
 
 * Completely refactored the :mod:`IPython.core.prefilter` module into
   :class:`~IPython.config.configurable.Configurable` subclasses. Added a new
   layer into the prefilter system, called "transformations" that all new
   prefilter logic should use (rather than the older "checker/handler"
   approach).
 
 * Aliases are now components (:mod:`IPython.core.alias`).
 
 * New top level :func:`~IPython.frontend.terminal.embed.embed` function that can
   be called to embed IPython at any place in user's code. On the first call it
   will create an :class:`~IPython.frontend.terminal.embed.InteractiveShellEmbed`
   instance and call it. In later calls, it just calls the previously created
   :class:`~IPython.frontend.terminal.embed.InteractiveShellEmbed`.
 
 * Created a configuration system (:mod:`IPython.config.configurable`) that is
   based on :mod:`IPython.utils.traitlets`. Configurables are arranged into a
   runtime containment tree (not inheritance) that i) automatically propagates
   configuration information and ii) allows singletons to discover each other in
   a loosely coupled manner. In the future all parts of IPython will be
   subclasses of :class:`~IPython.config.configurable.Configurable`. All IPython
   developers should become familiar with the config system.
 
 * Created a new :class:`~IPython.config.loader.Config` for holding
   configuration information. This is a dict like class with a few extras: i)
   it supports attribute style access, ii) it has a merge function that merges
   two :class:`~IPython.config.loader.Config` instances recursively and iii) it
   will automatically create sub-:class:`~IPython.config.loader.Config`
   instances for attributes that start with an uppercase character.
 
 * Created new configuration loaders in :mod:`IPython.config.loader`. These
   loaders provide a unified loading interface for all configuration
   information including command line arguments and configuration files. We
   have two default implementations based on :mod:`argparse` and plain python
   files.  These are used to implement the new configuration system.
 
 * Created a top-level :class:`Application` class in
   :mod:`IPython.core.application` that is designed to encapsulate the starting
   of any basic Python program. An application loads and merges all the
   configuration objects, constructs the main application, configures and
   initiates logging, and creates and configures any :class:`Configurable`
   instances and then starts the application running. An extended
   :class:`BaseIPythonApplication` class adds logic for handling the
   IPython directory as well as profiles, and all IPython entry points
   extend it.
 
 * The :class:`Type` and :class:`Instance` traitlets now handle classes given
   as strings, like ``foo.bar.Bar``. This is needed for forward declarations.
   But, this was implemented in a careful way so that string to class
   resolution is done at a single point, when the parent
   :class:`~IPython.utils.traitlets.HasTraitlets` is instantiated.
 
 * :mod:`IPython.utils.ipstruct` has been refactored to be a subclass of 
   dict.  It also now has full docstrings and doctests.
 
 * Created a Traits like implementation in :mod:`IPython.utils.traitlets`.  This
   is a pure Python, lightweight version of a library that is similar to
   Enthought's Traits project, but has no dependencies on Enthought's code.  We
   are using this for validation, defaults and notification in our new component
   system.  Although it is not 100% API compatible with Enthought's Traits, we
   plan on moving in this direction so that eventually our implementation could
   be replaced by a (yet to exist) pure Python version of Enthought Traits.
 
 * Added a new module :mod:`IPython.lib.inputhook` to manage the integration
   with GUI event loops using `PyOS_InputHook`.  See the docstrings in this
   module or the main IPython docs for details.
 
 * For users, GUI event loop integration is now handled through the new
   :command:`%gui` magic command.  Type ``%gui?`` at an IPython prompt for
   documentation.
 
 * For developers :mod:`IPython.lib.inputhook` provides a simple interface
   for managing the event loops in their interactive GUI applications.
   Examples can be found in our :file:`docs/examples/lib` directory.
 
 Backwards incompatible changes
 ------------------------------
 
 * The Twisted-based :mod:`IPython.kernel` has been removed, and completely
   rewritten as :mod:`IPython.parallel`, using ZeroMQ.
 
 * Profiles are now directories. Instead of a profile being a single config file,
   profiles are now self-contained directories. By default, profiles get their
   own IPython history, log files, and everything. To create a new profile, do
   ``ipython profile create <name>``.
 
 * All IPython applications have been rewritten to use
   :class:`~IPython.config.loader.KeyValueConfigLoader`. This means that
   command-line options have changed. Now, all configurable values are accessible
   from the command-line with the same syntax as in a configuration file.
 
 * The command line options ``-wthread``, ``-qthread`` and
   ``-gthread`` have been removed. Use ``--gui=wx``, ``--gui=qt``, ``--gui=gtk``
   instead.
 
 * The extension loading functions have been renamed to
   :func:`load_ipython_extension` and :func:`unload_ipython_extension`.
 
 * :class:`~IPython.core.interactiveshell.InteractiveShell` no longer takes an
   ``embedded`` argument. Instead just use the
   :class:`~IPython.core.interactiveshell.InteractiveShellEmbed` class.
 
 * ``__IPYTHON__`` is no longer injected into ``__builtin__``.
 
 * :meth:`Struct.__init__` no longer takes `None` as its first argument.  It
   must be a :class:`dict` or :class:`Struct`.
 
 * :meth:`~IPython.core.interactiveshell.InteractiveShell.ipmagic` has been
   renamed :meth:`~IPython.core.interactiveshell.InteractiveShell.magic.`
 
 * The functions :func:`ipmagic` and :func:`ipalias` have been removed from
   :mod:`__builtins__`.
 
 * The references to the global
   :class:`~IPython.core.interactivehell.InteractiveShell` instance (``_ip``, and
   ``__IP``) have been removed from the user's namespace. They are replaced by a
   new function called :func:`get_ipython` that returns the current
   :class:`~IPython.core.interactiveshell.InteractiveShell` instance. This
   function is injected into the user's namespace and is now the main way of
   accessing the running IPython.
 
 * Old style configuration files :file:`ipythonrc` and :file:`ipy_user_conf.py`
   are no longer supported. Users should migrate there configuration files to
   the new format described :ref:`here <config_overview>` and :ref:`here
   <configuring_ipython>`.
 
 * The old IPython extension API that relied on :func:`ipapi` has been
   completely removed. The new extension API is described :ref:`here
   <configuring_ipython>`.
 
 * Support for ``qt3`` has been dropped.  Users who need this should use
   previous versions of IPython.
 
 * Removed :mod:`shellglobals` as it was obsolete.
 
 * Removed all the threaded shells in :mod:`IPython.core.shell`. These are no
   longer needed because of the new capabilities in
   :mod:`IPython.lib.inputhook`.
 
 * New top-level sub-packages have been created: :mod:`IPython.core`, 
   :mod:`IPython.lib`, :mod:`IPython.utils`, :mod:`IPython.deathrow`,
   :mod:`IPython.quarantine`.  All existing top-level modules have been
   moved to appropriate sub-packages.  All internal import statements
   have been updated and tests have been added.  The build system (setup.py
   and friends) have been updated.  See :ref:`this section <module_reorg>` of the
   documentation for descriptions of these new sub-packages.
 
 * :mod:`IPython.ipapi` has been moved to :mod:`IPython.core.ipapi`.
   :mod:`IPython.Shell` and :mod:`IPython.iplib` have been split and removed as
   part of the refactor.
 
 * :mod:`Extensions` has been moved to :mod:`extensions` and all existing
   extensions have been moved to either :mod:`IPython.quarantine` or
   :mod:`IPython.deathrow`. :mod:`IPython.quarantine` contains modules that we
   plan on keeping but that need to be updated. :mod:`IPython.deathrow` contains
   modules that are either dead or that should be maintained as third party
   libraries. More details about this can be found :ref:`here <module_reorg>`.
 
 * Previous IPython GUIs in :mod:`IPython.frontend` and :mod:`IPython.gui` are
   likely broken, and have been removed to :mod:`IPython.deathrow` because of the
   refactoring in the core. With proper updates, these should still work.
 
 
 Known Regressions
 -----------------
 
 We do our best to improve IPython, but there are some known regressions in 0.11
 relative to 0.10.2.  First of all, there are features that have yet to be
 ported to the new APIs, and in order to ensure that all of the installed code
 runs for our users, we have moved them to two separate directories in the
 source distribution, `quarantine` and `deathrow`.  Finally, we have some other
 miscellaneous regressions that we hope to fix as soon as possible.  We now
 describe all of these in more detail.
 
 Quarantine
 ~~~~~~~~~~
 
 These are tools and extensions that we consider relatively easy to update to
 the new classes and APIs, but that we simply haven't had time for.  Any user
 who is interested in one of these is encouraged to help us by porting it and
 submitting a pull request on our `development site`_.
 
 .. _development site: http://github.com/ipython/ipython
 
 Currently, the quarantine directory contains::
 
     clearcmd.py            ipy_fsops.py            ipy_signals.py
     envpersist.py          ipy_gnuglobal.py        ipy_synchronize_with.py
     ext_rescapture.py      ipy_greedycompleter.py  ipy_system_conf.py
     InterpreterExec.py     ipy_jot.py              ipy_which.py
     ipy_app_completers.py  ipy_lookfor.py          ipy_winpdb.py
     ipy_autoreload.py      ipy_profile_doctest.py  ipy_workdir.py
     ipy_completers.py      ipy_pydb.py             jobctrl.py
     ipy_editors.py         ipy_rehashdir.py        ledit.py
     ipy_exportdb.py        ipy_render.py           pspersistence.py
     ipy_extutil.py         ipy_server.py           win32clip.py
 
 Deathrow
 ~~~~~~~~
 
 These packages may be harder to update or make most sense as third-party
 libraries.  Some of them are completely obsolete and have been already replaced
 by better functionality (we simply haven't had the time to carefully weed them
 out so they are kept here for now). Others simply require fixes to code that
 the current core team may not be familiar with.  If a tool you were used to is
 included here, we encourage you to contact the dev list and we can discuss
 whether it makes sense to keep it in IPython (if it can be maintained).
 
 Currently, the deathrow directory contains::
 
     astyle.py              ipy_defaults.py          ipy_vimserver.py
     dtutils.py             ipy_kitcfg.py            numeric_formats.py
     Gnuplot2.py            ipy_legacy.py            numutils.py
     GnuplotInteractive.py  ipy_p4.py                outputtrap.py
     GnuplotRuntime.py      ipy_profile_none.py      PhysicalQInput.py
     ibrowse.py             ipy_profile_numpy.py     PhysicalQInteractive.py
     igrid.py               ipy_profile_scipy.py     quitter.py*
     ipipe.py               ipy_profile_sh.py        scitedirector.py
     iplib.py               ipy_profile_zope.py      Shell.py
     ipy_constants.py       ipy_traits_completer.py  twshell.py
 
 
 Other regressions
 ~~~~~~~~~~~~~~~~~
 
 * The machinery that adds functionality to the 'sh' profile for using IPython
   as your system shell has not been updated to use the new APIs.  As a result,
   only the aesthetic (prompt) changes are still implemented. We intend to fix
   this by 0.12.  Tracked as issue 547_.
 
 .. _547: https://github.com/ipython/ipython/issues/547
 
 * The installation of scripts on Windows was broken without setuptools, so we
   now depend on setuptools on Windows.  We hope to fix setuptools-less
   installation, and then remove the setuptools dependency.  Issue 539_.
 
 .. _539: https://github.com/ipython/ipython/issues/539
 
 * The directory history `_dh` is not saved between sessions.  Issue 634_.
 
 .. _634: https://github.com/ipython/ipython/issues/634
 
 
 Removed Features
 ----------------
 
 As part of the updating of IPython, we have removed a few features for the
 purposes of cleaning up the codebase and interfaces.  These removals are
 permanent, but for any item listed below, equivalent functionality is
 available.
 
 * The magics Exit and Quit have been dropped as ways to exit IPython. Instead,
   the lowercase forms of both work either as a bare name (``exit``) or a
   function call (``exit()``).  You can assign these to other names using
   exec_lines in the config file.
 
 
 .. _credits_011:
 
 Credits
 -------
 
 Many users and developers contributed code, features, bug reports and ideas to
 this release.  Please do not hesitate in contacting us if we've failed to
 acknowledge your contribution here.  In particular, for this release we have
 contribution from the following people, a mix of new and regular names (in
 alphabetical order by first name):
 
 * Aenugu Sai Kiran Reddy <saikrn08-at-gmail.com>
 * andy wilson <wilson.andrew.j+github-at-gmail.com>
 * Antonio Cuni <antocuni>
 * Barry Wark <barrywark-at-gmail.com>
 * Beetoju Anuradha <anu.beethoju-at-gmail.com>
 * Benjamin Ragan-Kelley <minrk-at-Mercury.local>
 * Brad Reisfeld
 * Brian E. Granger <ellisonbg-at-gmail.com>
 * Christoph Gohlke <cgohlke-at-uci.edu>
 * Cody Precord
 * dan.milstein
 * Darren Dale <dsdale24-at-gmail.com>
 * Dav Clark <davclark-at-berkeley.edu>
 * David Warde-Farley <wardefar-at-iro.umontreal.ca>
 * epatters <ejpatters-at-gmail.com>
 * epatters <epatters-at-caltech.edu>
 * epatters <epatters-at-enthought.com>
 * Eric Firing <efiring-at-hawaii.edu>
 * Erik Tollerud <erik.tollerud-at-gmail.com>
 * Evan Patterson <epatters-at-enthought.com>
 * Fernando Perez <Fernando.Perez-at-berkeley.edu>
 * Gael Varoquaux <gael.varoquaux-at-normalesup.org>
 * Gerardo <muzgash-at-Muzpelheim>
 * Jason Grout <jason.grout-at-drake.edu>
 * John Hunter <jdh2358-at-gmail.com>
 * Jens Hedegaard Nielsen <jenshnielsen-at-gmail.com>
 * Johann Cohen-Tanugi <johann.cohentanugi-at-gmail.com>
 * Jörgen Stenarson <jorgen.stenarson-at-bostream.nu>
 * Justin Riley <justin.t.riley-at-gmail.com>
 * Kiorky
 * Laurent Dufrechou <laurent.dufrechou-at-gmail.com>
 * Luis Pedro Coelho <lpc-at-cmu.edu>
 * Mani chandra <mchandra-at-iitk.ac.in>
 * Mark E. Smith
 * Mark Voorhies <mark.voorhies-at-ucsf.edu>
 * Martin Spacek <git-at-mspacek.mm.st>
 * Michael Droettboom <mdroe-at-stsci.edu>
 * MinRK <benjaminrk-at-gmail.com>
 * muzuiget <muzuiget-at-gmail.com>
 * Nick Tarleton <nick-at-quixey.com>
 * Nicolas Rougier <Nicolas.rougier-at-inria.fr>
 * Omar Andres Zapata Mesa <andresete.chaos-at-gmail.com>
 * Paul Ivanov <pivanov314-at-gmail.com>
 * Pauli Virtanen <pauli.virtanen-at-iki.fi>
 * Prabhu Ramachandran
 * Ramana <sramana9-at-gmail.com>
 * Robert Kern <robert.kern-at-gmail.com>
 * Sathesh Chandra <satheshchandra88-at-gmail.com>
 * Satrajit Ghosh <satra-at-mit.edu>
 * Sebastian Busch
 * Skipper Seabold <jsseabold-at-gmail.com>
 * Stefan van der Walt <bzr-at-mentat.za.net>
 * Stephan Peijnik <debian-at-sp.or.at>
 * Steven Bethard
 * Thomas Kluyver <takowl-at-gmail.com>
 * Thomas Spura <tomspur-at-fedoraproject.org>
 * Tom Fetherston <tfetherston-at-aol.com>
 * Tom MacWright
 * tzanko
 * vankayala sowjanya <hai.sowjanya-at-gmail.com>
 * Vivian De Smedt <vds2212-at-VIVIAN>
 * Ville M. Vainio <vivainio-at-gmail.com>
 * Vishal Vatsa <vishal.vatsa-at-gmail.com>
 * Vishnu S G <sgvishnu777-at-gmail.com>
 * Walter Doerwald <walter-at-livinglogic.de>
 
 .. note::
 
     This list was generated with the output of
     ``git log dev-0.11 HEAD --format='* %aN <%aE>' | sed 's/@/\-at\-/' | sed 's/<>//' | sort -u``
     after some cleanup.  If you should be on this list, please add yourself.

docs/source/whatsnew/version0.12.txt

@@ -1,370 +1,370 b''
 =============
  0.12 Series
 =============
 
 Release 0.12.1
 ==============
 
 IPython 0.12.1 is a bugfix release of 0.12, pulling only bugfixes and minor
 cleanup from 0.13, timed for the Ubuntu 12.04 LTS release.
 
 See the :ref:`list of fixed issues <issues_list_012>` for specific backported issues.
 
 
 Release 0.12
 ============
 
 IPython 0.12 contains several major new features, as well as a large amount of
 bug and regression fixes.  The 0.11 release brought with it a lot of new
 functionality and major refactorings of the codebase; by and large this has
 proven to be a success as the number of contributions to the project has
 increased dramatically, proving that the code is now much more approachable.
 But in the refactoring inevitably some bugs were introduced, and we have also
 squashed many of those as well as recovered some functionality that had been
 temporarily disabled due to the API changes.
 
 The following major new features appear in this version.
 
 
 An interactive browser-based Notebook with rich media support
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 A powerful new interface puts IPython in your browser. You can start it with
 the command ``ipython notebook``:
 
-.. figure:: ../_static/notebook_specgram.png
+.. figure:: ../_images/notebook_specgram.png
     :width: 400px
     :alt: The IPython notebook with embedded text, code, math and figures.
     :align: center
-    :target: ../_static/notebook_specgram.png
+    :target: ../_images/notebook_specgram.png
 
     The new IPython notebook showing text, mathematical expressions in LaTeX,
     code, results and embedded figures created with Matplotlib.
 
 This new interface maintains all the features of IPython you are used to, as it
 is a new client that communicates with the same IPython kernels used by the
 terminal and Qt console.  But the web notebook provides for a different
 workflow where you can integrate, along with code execution, also text,
 mathematical expressions, graphics, video, and virtually any content that a
 modern browser is capable of displaying.
 
 You can save your work sessions as documents that retain all these elements and
 which can be version controlled, emailed to colleagues or saved as HTML or PDF
 files for printing or publishing statically on the web.  The internal storage
 format is a JSON file that can be easily manipulated for manual exporting to
 other formats.
 
 This Notebook is a major milestone for IPython, as for years we have tried to
 build this kind of system.  We were inspired originally by the excellent
 implementation in Mathematica, we made a number of attempts using older
 technologies in earlier Summer of Code projects in 2005 (both students and
 Robert Kern developed early prototypes), and in recent years we have seen the
 excellent implementation offered by the `Sage <http://sagemath.org>` system.
 But we continued to work on something that would be consistent with the rest of
 IPython's design, and it is clear now that the effort was worth it: based on
 the ZeroMQ communications architecture introduced in version 0.11, the notebook
 can now retain 100% of the features of the real IPython.  But it can also
 provide the rich media support and high quality Javascript libraries that were
 not available in browsers even one or two years ago (such as high-quality
 mathematical rendering or built-in video).
 
 The notebook has too many useful and important features to describe in these
 release notes; our documentation now contains a directory called
 ``examples/notebooks`` with several notebooks that illustrate various aspects
 of the system.  You should start by reading those named
 ``00_notebook_tour.ipynb`` and ``01_notebook_introduction.ipynb`` first, and
 then can proceed to read the others in any order you want.
 
 To start the notebook server, go to a directory containing the notebooks you
 want to open (or where you want to create new ones) and type::
 
   ipython notebook
 
 You can see all the relevant options with::
 
   ipython notebook --help
   ipython notebook --help-all  # even more
 
 and just like the Qt console, you can start the notebook server with pylab
 support by using::
   
   ipython notebook --pylab
 
 for floating matplotlib windows or::
   
   ipython notebook --pylab inline
 
 for plotting support with automatically inlined figures.  Note that it is now
 possible also to activate pylab support at runtime via ``%pylab``, so you do
 not need to make this decision when starting the server.
   
 See :ref:`the Notebook docs <htmlnotebook>` for technical details.
 
 .. _two_process_console:
 
 Two-process terminal console
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Based on the same architecture as the notebook and the Qt console, we also have
 now a terminal-based console that can connect to an external IPython kernel
 (the same kernels used by the Qt console or the notebook, in fact).  While this
 client behaves almost identically to the usual IPython terminal application,
 this capability can be very useful to attach an interactive console to an
 existing kernel that was started externally.  It lets you use the interactive
 ``%debug`` facilities in a notebook, for example (the web browser can't
 interact directly with the debugger) or debug a third-party code where you may
 have embedded an IPython kernel.
 
 This is also something that we have wanted for a long time, and which is a
 culmination (as a team effort) of the work started last year during the 2010
 Google Summer of Code project.
   
 Tabbed QtConsole
 ~~~~~~~~~~~~~~~~
 
 The QtConsole now supports starting multiple kernels in tabs, and has a
 menubar, so it looks and behaves more like a real application.  Keyboard
 enthusiasts can disable the menubar with ctrl-shift-M (:ghpull:`887`).
 
-.. figure:: ../_static/qtconsole_tabbed.png
+.. figure:: ../_images/qtconsole_tabbed.png
     :width: 400px
     :alt: Tabbed IPython Qt console with embedded plots and menus.
     :align: center
-    :target: ../_static/qtconsole_tabbed.png
+    :target: ../_images/qtconsole_tabbed.png
 
     The improved Qt console for IPython, now with tabs to control multiple
     kernels and full menu support.
 
 
 Full Python 3 compatibility
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 IPython can now be installed from a single codebase on Python 2 and
 Python 3. The installation process for Python 3 automatically runs 2to3. The
 same 'default' profile is now used for Python 2 and 3 (the previous version had
 a separate 'python3' profile).
 
 Standalone Kernel
 ~~~~~~~~~~~~~~~~~
 
 The ``ipython kernel`` subcommand has been added, to allow starting a
 standalone kernel, that can be used with various frontends.  You can then later
 connect a Qt console or a terminal console to this kernel by typing e.g.::
 
   ipython qtconsole --existing
 
 if it's the only one running, or by passing explicitly the connection
 parameters (printed by the kernel at startup).
 
 
 PyPy support
 ~~~~~~~~~~~~
 
 The terminal interface to IPython now runs under `PyPy <http://pypy.org/>`_.
 We will continue to monitor PyPy's progress, and hopefully before long at least
 we'll be able to also run the notebook.  The Qt console may take longer, as Qt
 is a very complex set of bindings to a huge C++ library, and that is currently
 the area where PyPy still lags most behind.  But for everyday interactive use
 at the terminal, with this release and PyPy 1.7, things seem to work quite well
 from our admittedly limited testing.
 
   
 Other important new features
 ----------------------------
 
 * **SSH Tunnels**: In 0.11, the :mod:`IPython.parallel` Client could tunnel its
   connections to the Controller via ssh. Now, the QtConsole :ref:`supports
   <ssh_tunnels>` ssh tunneling, as do parallel engines.
 
 * **relaxed command-line parsing**: 0.11 was released with overly-strict
   command-line parsing, preventing the ability to specify arguments with spaces,
   e.g. ``ipython --pylab qt`` or ``ipython -c "print 'hi'"``. This has
   been fixed, by using argparse. The new parsing is a strict superset of 0.11, so
   any commands in 0.11 should still work in 0.12.
 
 * **HistoryAccessor**: The :class:`~IPython.core.history.HistoryManager` class
   for interacting with your IPython SQLite history database has been split,
   adding a parent :class:`~IPython.core.history.HistoryAccessor` class, so that
   users can write code to access and search their IPython history without being
   in an IPython session (:ghpull:`824`).
 
 * **kernel %gui and %pylab**: The ``%gui`` and ``%pylab`` magics have been
   restored to the IPython kernel (e.g. in the qtconsole or notebook). This
   allows activation of pylab-mode, or eventloop integration after starting the
   kernel, which was unavailable in 0.11.  Unlike in the terminal, this can be
   set only once, and cannot be changed.
 
 * **%config**: A new ``%config`` magic has been added, giving easy access to the
   IPython configuration system at runtime (:ghpull:`923`).
 
 * **Multiline History**: Multiline readline history has been restored to the
   Terminal frontend by default (:ghpull:`838`).
 
 * **%store**: The ``%store`` magic from earlier versions has been updated and
   re-enabled (:ref:`extensions_storemagic`; :ghpull:`1029`). To autorestore
   stored variables on startup, specify ``c.StoreMagic.autorestore = True`` in
   :file:`ipython_config.py`.
 
 
 Major Bugs fixed
 ----------------
 
 In this cycle, we have :ref:`closed over 500 issues <issues_list_012>`, but a
 few major ones merit special mention:
 
 * Simple configuration errors should no longer crash IPython. In 0.11, errors
   in config files, as well as invalid trait values, could crash IPython. Now,
   such errors are reported, and help is displayed.
 
 * Certain SyntaxErrors no longer crash IPython (e.g. just typing keywords, such
   as ``return``, ``break``, etc.). See :ghissue:`704`.
 
 * IPython path utils, such as :func:`~IPython.utils.path.get_ipython_dir` now
   check for write permissions, so IPython should function on systems where the
   default path resolution might point to a read-only location, such as
   ``HOMESHARE`` on Windows (:ghissue:`669`).
 
 * :func:`raw_input` now works in the kernel when multiple frontends are in
   use. The request will be sent to the frontend that made the request, and an
   exception is raised if that frontend does not support stdin requests
   (e.g. the notebook) (:ghissue:`673`).
 
 * :mod:`zmq` version detection no longer uses simple lexicographical comparison
   to check minimum version, which prevents 0.11 from working with pyzmq-2.1.10
   (:ghpull:`758`).
 
 * A bug in PySide < 1.0.7 caused crashes on OSX when tooltips were shown
   (:ghissue:`711`). these tooltips are now disabled on old PySide
   (:ghpull:`963`).
 
 * IPython no longer crashes when started on recent versions of Python 3 in
   Windows (:ghissue:`737`).
 
 * Instances of classes defined interactively can now be pickled (:ghissue:`29`;
   :ghpull:`648`). Note that pickling saves a reference to the class definition,
   so unpickling the instances will only work where the class has been defined.
 
 
 Backwards incompatible changes
 ------------------------------
 
 * IPython connection information is no longer specified via ip/port directly,
   rather via json connection files.  These files are stored in the security
   directory, and enable us to turn on HMAC message authentication by default,
   significantly improving the security of kernels.  Various utility functions
   have been added to :mod:`IPython.lib.kernel`, for easier connecting to existing
   kernels.
 
 * :class:`~IPython.zmq.kernelmanager.KernelManager` now has one ip, and several
   port traits, rather than several ip/port pair ``_addr`` traits. This better
   matches the rest of the code, where the ip cannot not be set separately for
   each channel.
 
 * Custom prompts are now configured using a new class,
   :class:`~IPython.core.prompts.PromptManager`, which has traits for
   :attr:`in_template`, :attr:`in2_template` (the ``...:`` continuation prompt),
   :attr:`out_template` and :attr:`rewrite_template`. This uses Python's string
   formatting system, so you can use ``{time}`` and ``{cwd}``, although we have
   preserved the abbreviations from previous versions, e.g. ``\#`` (prompt number)
   and ``\w`` (working directory). For the list of available fields, refer to the
   source of :file:`IPython/core/prompts.py`.
 
 * The class inheritance of the Launchers in
   :mod:`IPython.parallel.apps.launcher` used by ipcluster has changed, so that
   trait names are more consistent across batch systems. This may require a few
   renames in your config files, if you customized the command-line args for
   launching controllers and engines. The configurable names have also been
   changed to be clearer that they point to class names, and can now be
   specified by name only, rather than requiring the full import path of each
   class, e.g.::
 
     IPClusterEngines.engine_launcher = 'IPython.parallel.apps.launcher.MPIExecEngineSetLauncher'
     IPClusterStart.controller_launcher = 'IPython.parallel.apps.launcher.SSHControllerLauncher'
 
   would now be specified as::
 
     IPClusterEngines.engine_launcher_class = 'MPI'
     IPClusterStart.controller_launcher_class = 'SSH'
 
   The full path will still work, and is necessary for using custom launchers
   not in IPython's launcher module.
   
   Further, MPIExec launcher names are now prefixed with just MPI, to better match
   other batch launchers, and be generally more intuitive.  The MPIExec names are
   deprecated, but continue to work.
 
 * For embedding a shell, note that the parameters ``user_global_ns`` and
   ``global_ns`` have been deprectated in favour of ``user_module`` and
   ``module`` respsectively.  The new parameters expect a module-like object,
   rather than a namespace dict.  The old parameters remain for backwards
   compatibility, although ``user_global_ns`` is now ignored. The ``user_ns``
   parameter works the same way as before, and calling
   :func:`~IPython.frontend.terminal.embed.embed` with no arguments still works
   as before.
 
 
 Development summary and credits
 -------------------------------
 
 The previous version (IPython 0.11) was released on July 31 2011, so this
 release cycle was roughly 4 1/2 months long, we closed a total of 515 issues,
 257 pull requests and 258 regular issues (a :ref:`detailed list
 <issues_list_012>` is available).
 
 Many users and developers contributed code, features, bug reports and ideas to
 this release.  Please do not hesitate in contacting us if we've failed to
 acknowledge your contribution here.  In particular, for this release we have
 had commits from the following 45 contributors, a mix of new and regular names
 (in alphabetical order by first name):
 
 * Alcides <alcides-at-do-not-span-me.com>
 * Ben Edwards <bedwards-at-cs.unm.edu>
 * Benjamin Ragan-Kelley <benjaminrk-at-gmail.com>
 * Benjamin Thyreau <benjamin.thyreau-at-gmail.com>
 * Bernardo B. Marques <bernardo.fire-at-gmail.com>
 * Bernard Paulus <bprecyclebin-at-gmail.com>
 * Bradley M. Froehle <brad.froehle-at-gmail.com>
 * Brian E. Granger <ellisonbg-at-gmail.com>
 * Christian Boos <cboos-at-bct-technology.com>
 * Daniel Velkov <danielv-at-mylife.com>
 * Erik Tollerud <erik.tollerud-at-gmail.com>
 * Evan Patterson <epatters-at-enthought.com>
 * Felix Werner <Felix.Werner-at-kit.edu>
 * Fernando Perez <Fernando.Perez-at-berkeley.edu>
 * Gabriel <g2p.code-at-gmail.com>
 * Grahame Bowland <grahame-at-angrygoats.net>
 * Hannes Schulz <schulz-at-ais.uni-bonn.de>
 * Jens Hedegaard Nielsen <jenshnielsen-at-gmail.com>
 * Jonathan March <jmarch-at-enthought.com>
 * Jörgen Stenarson <jorgen.stenarson-at-bostream.nu>
 * Julian Taylor <jtaylor.debian-at-googlemail.com>
 * Kefu Chai <tchaikov-at-gmail.com>
 * macgyver <neil.rabinowitz-at-merton.ox.ac.uk>
 * Matt Cottingham <matt.cottingham-at-gmail.com>
 * Matthew Brett <matthew.brett-at-gmail.com>
 * Matthias BUSSONNIER <bussonniermatthias-at-gmail.com>
 * Michael Droettboom <mdboom-at-gmail.com>
 * Nicolas Rougier <Nicolas.Rougier-at-inria.fr>
 * Olivier Verdier <olivier.verdier-at-gmail.com>
 * Omar Andres Zapata Mesa <andresete.chaos-at-gmail.com>
 * Pablo Winant <pablo.winant-at-gmail.com>
 * Paul Ivanov <pivanov314-at-gmail.com>
 * Pauli Virtanen <pav-at-iki.fi>
 * Pete Aykroyd <aykroyd-at-gmail.com>
 * Prabhu Ramachandran <prabhu-at-enthought.com>
 * Puneeth Chaganti <punchagan-at-gmail.com>
 * Robert Kern <robert.kern-at-gmail.com>
 * Satrajit Ghosh <satra-at-mit.edu>
 * Stefan van der Walt <stefan-at-sun.ac.za>
 * Szabolcs Horvát <szhorvat-at-gmail.com>
 * Thomas Kluyver <takowl-at-gmail.com>
 * Thomas Spura <thomas.spura-at-gmail.com>
 * Timo Paulssen <timonator-at-perpetuum-immobile.de>
 * Valentin Haenel <valentin.haenel-at-gmx.de>
 * Yaroslav Halchenko <debian-at-onerussian.com>
    
 .. note::
 
     This list was generated with the output of
     ``git log rel-0.11..HEAD --format='* %aN <%aE>' | sed 's/@/\-at\-/' | sed 's/<>//' | sort -u``
     after some cleanup.  If you should be on this list, please add yourself.

docs/source/whatsnew/version0.13.txt

@@ -1,673 +1,673 b''
 =============
  0.13 Series
 =============
 
 Release 0.13
 ============
 
 IPython 0.13 contains several major new features, as well as a large amount of
 bug and regression fixes.  The previous version (0.12) was released on December
 19 2011, and in this development cycle we had:
 
 - ~6 months of work.
 - 373 pull requests merged.
 - 742 issues closed (non-pull requests).
 - contributions from 62 authors.
 - 1760 commits.
 - a diff of 114226 lines.
 
 The amount of work included in this release is so large, that we can only cover
 here the main highlights; please see our :ref:`detailed release statistics
 <issues_list_013>` for links to every issue and pull request closed on GitHub
 as well as a full list of individual contributors.
 
 
 Major Notebook improvements: new user interface and more
 --------------------------------------------------------
 
 The IPython Notebook, which has proven since its release to be wildly popular,
 has seen a massive amount of work in this release cycle, leading to a
 significantly improved user experience as well as many new features.
 
 The first user-visible change is a reorganization of the user interface; the
 left panel has been removed and was replaced by a real menu system and a
 toolbar with icons.  Both the toolbar and the header above the menu can be
 collapsed to leave an unobstructed working area:
 
-.. image:: ../_static/ipy_013_notebook_spectrogram.png
+.. image:: ../_images/ipy_013_notebook_spectrogram.png
     :width: 460px
     :alt: New user interface for Notebook
     :align: center
-    :target: ../_static/ipy_013_notebook_spectrogram.png
+    :target: ../_images/ipy_013_notebook_spectrogram.png
 
 The notebook handles very long outputs much better than before (this was a
 serious usability issue when running processes that generated massive amounts
 of output).  Now, in the presence of outputs longer than ~100 lines, the
 notebook will automatically collapse to a scrollable area and the entire left
 part of this area controls the display: one click in this area will expand the
 output region completely, and a double-click will hide it completely.  This
 figure shows both the scrolled and hidden modes:
 
-.. image:: ../_static/ipy_013_notebook_long_out.png
+.. image:: ../_images/ipy_013_notebook_long_out.png
     :width: 460px
     :alt: Scrolling and hiding of long output in the notebook.
     :align: center
-    :target: ../_static/ipy_013_notebook_long_out.png
+    :target: ../_images/ipy_013_notebook_long_out.png
 
 .. note::
 
    The auto-folding of long outputs is disabled in Firefox due to bugs in its
    scrolling behavior.  See :ghpull:`2047` for details.
 
 Uploading notebooks to the dashboard is now easier: in addition to drag and
 drop (which can be finicky sometimes), you can now click on the upload text and
 use a regular file dialog box to select notebooks to upload. Furthermore, the
 notebook dashboard now auto-refreshes its contents and offers buttons to shut
 down any running kernels (:ghpull:`1739`):
 
-.. image:: ../_static/ipy_013_dashboard.png
+.. image:: ../_images/ipy_013_dashboard.png
     :width: 460px
     :alt: Improved dashboard
     :align: center
-    :target: ../_static/ipy_013_dashboard.png
+    :target: ../_images/ipy_013_dashboard.png
 
 
 Cluster management
 ~~~~~~~~~~~~~~~~~~
 
 The notebook dashboard can now also start and stop clusters, thansk to a new
 tab in the dashboard user interface:
 
-.. image:: ../_static/ipy_013_dashboard_cluster.png
+.. image:: ../_images/ipy_013_dashboard_cluster.png
     :width: 460px
     :alt: Cluster management from the notebook dashboard
     :align: center
-    :target: ../_static/ipy_013_dashboard_cluster.png
+    :target: ../_images/ipy_013_dashboard_cluster.png
 
 This interface allows, for each profile you have configured, to start and stop
 a cluster (and optionally override the default number of engines corresponding
 to that configuration).  While this hides all error reporting, once you have a
 configuration that you know works smoothly, it is a very convenient interface
 for controlling your parallel resources.
 
 
 New notebook format
 ~~~~~~~~~~~~~~~~~~~
 
 The notebooks saved now use version 3 of our format, which supports heading
 levels as well as the concept of 'raw' text cells that are not rendered as
 Markdown.  These will be useful with converters_ we are developing, to pass raw
 markup (say LaTeX).  That conversion code is still under heavy development and
 not quite ready for prime time, but we welcome help on this front so that we
 can merge it for full production use as soon as possible.
 
 .. _converters: https://github.com/ipython/nbconvert
 
 .. note::
 
    v3 notebooks can *not* be read by older versions of IPython, but we provide
    a `simple script`_ that you can use in case you need to export a v3
    notebook to share with a v2 user.
 
 .. _simple script: https://gist.github.com/1935808
 
 
 JavaScript refactoring
 ~~~~~~~~~~~~~~~~~~~~~~
   
 All the client-side JavaScript has been decoupled to ease reuse of parts of the
 machinery without having to build a full-blown notebook. This will make it much
 easier to communicate with an IPython kernel from existing web pages and to
 integrate single cells into other sites, without loading the full notebook
 document-like UI. :ghpull:`1711`.
     
 This refactoring also enables the possibility of writing dynamic javascript
 widgets that are returned from Python code and that present an interactive view
 to the user, with callbacks in Javascript executing calls to the Kernel.  This
 will enable many interactive elements to be added by users in notebooks.
 
 An example of this capability has been provided as a proof of concept in
 :file:`docs/examples/widgets` that lets you directly communicate with one or more
 parallel engines, acting as a mini-console for parallel debugging and
 introspection.
 
     
 Improved tooltips
 ~~~~~~~~~~~~~~~~~
 
 The object tooltips have gained some new functionality. By pressing tab several
 times, you can expand them to see more of a docstring, keep them visible as you
 fill in a function's parameters, or transfer the information to the pager at the
 bottom of the screen. For the details, look at the example notebook
 :file:`01_notebook_introduction.ipynb`.
 
-.. figure:: ../_static/ipy_013_notebook_tooltip.png
+.. figure:: ../_images/ipy_013_notebook_tooltip.png
     :width: 460px
     :alt: Improved tooltips in the notebook.
     :align: center
-    :target: ../_static/ipy_013_notebook_tooltip.png
+    :target: ../_images/ipy_013_notebook_tooltip.png
 
     The new notebook tooltips.
 
 Other improvements to the Notebook
 ----------------------------------
 
 These are some other notable small improvements to the notebook, in addition to
 many bug fixes and minor changes to add polish and robustness throughout:
 
 * The notebook pager (the area at the bottom) is now resizeable by dragging its
   divider handle, a feature that had been requested many times by just about
   anyone who had used the notebook system.  :ghpull:`1705`.
 
 * It is now possible to open notebooks directly from the command line; for
   example: ``ipython notebook path/`` will automatically set ``path/`` as the
   notebook directory, and ``ipython notebook path/foo.ipynb`` will further
   start with the ``foo.ipynb`` notebook opened.  :ghpull:`1686`.
   
 * If a notebook directory is specified with ``--notebook-dir`` (or with the
   corresponding configuration flag ``NotebookManager.notebook_dir``), all
   kernels start in this directory.
 
 * Fix codemirror clearing of cells with ``Ctrl-Z``; :ghpull:`1965`.
   
 * Text (markdown) cells now line wrap correctly in the notebook, making them
   much easier to edit :ghpull:`1330`.
   
 * PNG and JPEG figures returned from plots can be interactively resized in the
   notebook, by dragging them from their lower left corner. :ghpull:`1832`.
 
 * Clear ``In []`` prompt numbers on "Clear All Output".  For more
   version-control-friendly ``.ipynb`` files, we now strip all prompt numbers
   when doing a "Clear all output".  This reduces the amount of noise in
   commit-to-commit diffs that would otherwise show the (highly variable) prompt
   number changes. :ghpull:`1621`.
 
 * The notebook server now requires *two* consecutive ``Ctrl-C`` within 5
   seconds (or an interactive confirmation) to terminate operation.  This makes
   it less likely that you will accidentally kill a long-running server by
   typing ``Ctrl-C`` in the wrong terminal.  :ghpull:`1609`.
 
 * Using ``Ctrl-S`` (or ``Cmd-S`` on a Mac) actually saves the notebook rather
   than providing the fairly useless browser html save dialog.  :ghpull:`1334`.
   
 * Allow accessing local files from the notebook (in urls), by serving any local
   file as the url ``files/<relativepath>``.  This makes it possible to, for
   example, embed local images in a notebook.  :ghpull:`1211`.
 
       
 Cell magics
 -----------
 
 We have completely refactored the magic system, finally moving the magic
 objects to standalone, independent objects instead of being the mixin class
 we'd had since the beginning of IPython (:ghpull:`1732`).  Now, a separate base
 class is provided in :class:`IPython.core.magic.Magics` that users can subclass
 to create their own magics.  Decorators are also provided to create magics from
 simple functions without the need for object orientation.  Please see the
 :ref:`magic` docs for further details.
 
 All builtin magics now exist in a few subclasses that group together related
 functionality, and the new :mod:`IPython.core.magics` package has been created
 to organize this into smaller files.
     
 This cleanup was the last major piece of deep refactoring needed from the
 original 2001 codebase.
     
 We have also introduced a new type of magic function, prefixed with `%%`
 instead of `%`, which operates at the whole-cell level.  A cell magic receives
 two arguments: the line it is called on (like a line magic) and the body of the
 cell below it.
     
 Cell magics are most natural in the notebook, but they also work in the
 terminal and qt console, with the usual approach of using a blank line to
 signal cell termination.
     
 For example, to time the execution of several statements::
 
     %%timeit x = 0   # setup
     for i in range(100000):
         x += i**2
 
 This is particularly useful to integrate code in another language, and cell
 magics already exist for shell scripts, Cython, R and Octave. Using ``%%script
 /usr/bin/foo``, you can run a cell in any interpreter that accepts code via
 stdin.
 
 Another handy cell magic makes it easy to write short text files: ``%%file
 ~/save/to/here.txt``.
 
 The following cell magics are now included by default; all those that use
 special interpreters (Perl, Ruby, bash, etc.) assume you have the requisite
 interpreter installed:
 
 * ``%%!``: run cell body with the underlying OS shell; this is similar to
   prefixing every line in the cell with ``!``.
   
 * ``%%bash``: run cell body under bash.
   
 * ``%%capture``: capture the output of the code in the cell (and stderr as
   well).  Useful to run codes that produce too much output that you don't even
   want scrolled.
   
 * ``%%file``: save cell body as a file.
   
 * ``%%perl``: run cell body using Perl.
   
 * ``%%prun``: run cell body with profiler (cell extension of ``%prun``).
   
 * ``%%python3``: run cell body using Python 3.
   
 * ``%%ruby``: run cell body using Ruby.
   
 * ``%%script``: run cell body with the script specified in the first line.
   
 * ``%%sh``: run cell body using sh.
   
 * ``%%sx``: run cell with system shell and capture process output (cell
   extension of ``%sx``).
   
 * ``%%system``: run cell with system shell (``%%!`` is an alias to this).
   
 * ``%%timeit``: time the execution of the cell (extension of ``%timeit``).
 
 This is what some of the script-related magics look like in action:
 
-.. image:: ../_static/ipy_013_notebook_script_cells.png
+.. image:: ../_images/ipy_013_notebook_script_cells.png
     :width: 460px
     :alt: Cluster management from the notebook dashboard
     :align: center
-    :target: ../_static/ipy_013_notebook_script_cells.png
+    :target: ../_images/ipy_013_notebook_script_cells.png
   
 In addition, we have also a number of :ref:`extensions <extensions_overview>`
 that provide specialized magics.  These typically require additional software
 to run and must be manually loaded via ``%load_ext <extension name>``, but are
 extremely useful.  The following extensions are provided:
 
 **Cython magics** (extension :ref:`cythonmagic <extensions_cythonmagic>`)
     This extension provides magics to automatically build and compile Python
     extension modules using the Cython_ language. You must install Cython
     separately, as well as a C compiler, for this to work.  The examples
     directory in the source distribution ships with a full notebook
     demonstrating these capabilities:
 
-.. image:: ../_static/ipy_013_notebook_cythonmagic.png
+.. image:: ../_images/ipy_013_notebook_cythonmagic.png
     :width: 460px
     :alt: Cython magic
     :align: center
-    :target: ../_static/ipy_013_notebook_cythonmagic.png
+    :target: ../_images/ipy_013_notebook_cythonmagic.png
 
 .. _cython: http://cython.org
 
 **Octave magics** (extension :ref:`octavemagic <extensions_octavemagic>`)
     This extension provides several magics that support calling code written in
     the Octave_ language for numerical computing.  You can execute single-lines
     or whole blocks of Octave code, capture both output and figures inline
     (just like matplotlib plots), and have variables automatically converted
     between the two languages.  To use this extension, you must have Octave
     installed as well as the oct2py_ package.  The examples
     directory in the source distribution ships with a full notebook
     demonstrating these capabilities:
 
-.. image:: ../_static/ipy_013_notebook_octavemagic.png
+.. image:: ../_images/ipy_013_notebook_octavemagic.png
     :width: 460px
     :alt: Octave magic
     :align: center
-    :target: ../_static/ipy_013_notebook_octavemagic.png
+    :target: ../_images/ipy_013_notebook_octavemagic.png
 
 .. _octave: http://www.gnu.org/software/octave
 .. _oct2py: http://pypi.python.org/pypi/oct2py
 
 **R magics** (extension :ref:`rmagic <extensions_rmagic>`)
     This extension provides several magics that support calling code written in
     the R_ language for statistical data analysis.  You can execute
     single-lines or whole blocks of R code, capture both output and figures
     inline (just like matplotlib plots), and have variables automatically
     converted between the two languages.  To use this extension, you must have
     R installed as well as the rpy2_ package that bridges Python and R.  The
     examples directory in the source distribution ships with a full notebook
     demonstrating these capabilities:
 
-.. image:: ../_static/ipy_013_notebook_rmagic.png
+.. image:: ../_images/ipy_013_notebook_rmagic.png
     :width: 460px
     :alt: R magic
     :align: center
-    :target: ../_static/ipy_013_notebook_rmagic.png
+    :target: ../_images/ipy_013_notebook_rmagic.png
 
 .. _R: http://www.r-project.org
 .. _rpy2: http://rpy.sourceforge.net/rpy2.html
 
 
 Tab completer improvements
 --------------------------
 
 Useful tab-completion based on live inspection of objects is one of the most
 popular features of IPython. To make this process even more user-friendly, the
 completers of both the Qt console and the Notebook have been reworked.
 
 The Qt console comes with a new ncurses-like tab completer, activated by
 default, which lets you cycle through the available completions by pressing tab,
 or select a completion with the arrow keys (:ghpull:`1851`).
 
-.. figure:: ../_static/ipy_013_qtconsole_completer.png
+.. figure:: ../_images/ipy_013_qtconsole_completer.png
     :width: 460px
     :alt: ncurses-like completer, with highlighted selection.
     :align: center
-    :target: ../_static/ipy_013_qtconsole_completer.png
+    :target: ../_images/ipy_013_qtconsole_completer.png
 
     The new improved Qt console's ncurses-like completer allows to easily
     navigate thought long list of completions.
 
 In the notebook, completions are now sourced both from object introspection and
 analysis of surrounding code, so limited completions can be offered for
 variables defined in the current cell, or while the kernel is busy 
 (:ghpull:`1711`).
 
 
 We have implemented a new configurable flag to control tab completion on
 modules that provide the ``__all__`` attribute::
 
   IPCompleter.limit_to__all__= Boolean
 
 This instructs the completer to honor ``__all__`` for the completion.
 Specifically, when completing on ``object.<tab>``, if True: only those names
 in ``obj.__all__`` will be included.  When False [default]: the ``__all__``
 attribute is ignored. :ghpull:`1529`.
 
 
 Improvements to the Qt console
 ------------------------------
 
 The Qt console continues to receive improvements and refinements, despite the
 fact that it is by now a fairly mature and robust component.  Lots of small
 polish has gone into it, here are a few highlights:
 
 * A number of changes were made to the underlying code for easier integration
   into other projects such as Spyder_ (:ghpull:`2007`, :ghpull:`2024`).
 
 * Improved menus with a new Magic menu that is organized by magic groups (this
   was made possible by the reorganization of the magic system
   internals). :ghpull:`1782`.
 
 * Allow for restarting kernels without clearing the qtconsole, while leaving a
   visible indication that the kernel has restarted. :ghpull:`1681`.
   
 * Allow the native display of jpeg images in the qtconsole. :ghpull:`1643`.
 
 .. _spyder: https://code.google.com/p/spyderlib
 
 
   
 Parallel
 --------
 
 The parallel tools have been improved and fine-tuned on multiple fronts.  Now,
 the creation of an :class:`IPython.parallel.Client` object automatically
 activates a line and cell magic function ``px`` that sends its code to all the
 engines. Further magics can be easily created with the :meth:`.Client.activate`
 method, to conveniently execute code on any subset of engines. :ghpull:`1893`.
 
 The ``%%px`` cell magic can also be given an optional targets argument, as well
 as a ``--out`` argument for storing its output.
 
 A new magic has also been added, ``%pxconfig``, that lets you configure various
 defaults of the parallel magics.  As usual, type  ``%pxconfig?`` for details.
 
 The exception reporting in parallel contexts has been improved to be easier to
 read.  Now, IPython directly reports the remote exceptions without showing any
 of the internal execution parts:
 
-.. image::  ../_static/ipy_013_par_tb.png
+.. image::  ../_images/ipy_013_par_tb.png
     :width: 460px
     :alt: Improved parallel exceptions.
     :align: center
-    :target: ../_static/ipy_013_par_tb.png
+    :target: ../_images/ipy_013_par_tb.png
 
 The parallel tools now default to using ``NoDB`` as the storage backend for
 intermediate results.  This means that the default usage case will have a
 significantly reduced memory footprint, though certain advanced features are
 not available with this backend.  For more details, see :ref:`parallel_db`.
 
 The parallel magics now display all output, so you can do parallel plotting or
 other actions with complex display.  The ``px`` magic has now both line and cell
 modes, and in cell mode finer control has been added about how to collate
 output from multiple engines. :ghpull:`1768`.
 
 There have also been incremental improvements to the SSH launchers:
     
 * add to_send/fetch steps for moving connection files around.
   
 * add SSHProxyEngineSetLauncher, for invoking to `ipcluster engines` on a
   remote host. This can be used to start a set of engines via PBS/SGE/MPI
   *remotely*.
     
 This makes the SSHLauncher usable on machines without shared filesystems.
 
 A number of 'sugar' methods/properties were added to AsyncResult that are
 quite useful (:ghpull:`1548`) for everday work:
     
     * ``ar.wall_time`` = received - submitted
     * ``ar.serial_time`` = sum of serial computation time
     * ``ar.elapsed`` = time since submission (wall_time if done)
     * ``ar.progress`` = (int) number of sub-tasks that have completed
     * ``len(ar)`` = # of tasks
     * ``ar.wait_interactive()``: prints progress
     
 Added :meth:`.Client.spin_thread` / :meth:`~.Client.stop_spin_thread` for
 running spin in a background thread, to keep zmq queue clear.  This can be used
 to ensure that timing information is as accurate as possible (at the cost of
 having a background thread active).
 
 Set TaskScheduler.hwm default to 1 instead of 0.  1 has more
 predictable/intuitive behavior, if often slower, and thus a more logical
 default.  Users whose workloads require maximum throughput and are largely
 homogeneous in time per task can make the optimization themselves, but now the
 behavior will be less surprising to new users. :ghpull:`1294`.
 
 
 Kernel/Engine unification
 -------------------------
 
 This is mostly work 'under the hood', but it is actually a *major* achievement
 for the project that has deep implications in the long term: at last, we have
 unified the main object that executes as the user's interactive shell (which we
 refer to as the *IPython kernel*) with the objects that run in all the worker
 nodes of the parallel computing facilities (the *IPython engines*).  Ever since
 the first implementation of IPython's parallel code back in 2006, we had wanted
 to have these two roles be played by the same machinery, but a number of
 technical reasons had prevented that from being true.
 
 In this release we have now merged them, and this has a number of important
 consequences:
 
 * It is now possible to connect any of our clients (qtconsole or terminal
   console) to any individual parallel engine, with the *exact* behavior of
   working at a 'regular' IPython console/qtconsole.  This makes debugging,
   plotting, etc. in parallel scenarios vastly easier.
 
 * Parallel engines can always execute arbitrary 'IPython code', that is, code
   that has magics, shell extensions, etc.  In combination with the ``%%px``
   magics, it is thus extremely natural for example to send to all engines a
   block of Cython or R code to be executed via the new Cython and R magics. For
   example, this snippet would send the R block to all active engines in a
   cluster::
 
     %%px
     %%R
     ... R code goes here
   
 * It is possible to embed not only an interactive shell with the
   :func:`IPython.embed` call as always, but now you can also embed a *kernel*
   with :func:`IPython.embed_kernel()`.  Embedding an IPython kernel in an
   application is useful when you want to use :func:`IPython.embed` but don't
   have a terminal attached on stdin and stdout.
 
 * The new :func:`IPython.parallel.bind_kernel` allows you to promote Engines to
   listening Kernels, and connect QtConsoles to an Engine and debug it
   directly.
 
 In addition, having a single core object through our entire architecture also
 makes the project conceptually cleaner, easier to maintain and more robust.
 This took a lot of work to get in place, but we are thrilled to have this major
 piece of architecture finally where we'd always wanted it to be.
   
 
 Official Public API
 -------------------
 
 We have begun organizing our API for easier public use, with an eye towards an
 official IPython 1.0 release which will firmly maintain this API compatible for
 its entire lifecycle.  There is now an :mod:`IPython.display` module that
 aggregates all display routines, and the :mod:`IPython.config` namespace has
 all public configuration tools.  We will continue improving our public API
 layout so that users only need to import names one level deeper than the main
 ``IPython`` package to access all public namespaces.
 
 
 IPython notebook file icons
 ---------------------------
 
 The directory ``docs/resources`` in the source distribution contains SVG and
 PNG versions of our file icons, as well as an ``Info.plist.example`` file with
 instructions to install them on Mac OSX.  This is a first draft of our icons,
 and we encourage contributions from users with graphic talent to improve them
 in the future:
 
 .. image:: ../../resources/ipynb_icon_128x128.png
    :alt:  IPython notebook file icon.
 
 	  
 New top-level `locate` command
 ------------------------------
 
 Add `locate` entry points; these would be useful for quickly locating IPython
 directories and profiles from other (non-Python) applications. :ghpull:`1762`.
     
 Examples::
     
     $> ipython locate
     /Users/me/.ipython
   
     $> ipython locate profile foo
     /Users/me/.ipython/profile_foo
   
     $> ipython locate profile
     /Users/me/.ipython/profile_default
   
     $> ipython locate profile dne
     [ProfileLocate] Profile u'dne' not found.
 
 	
 Other new features and improvements
 -----------------------------------
 
 * **%install_ext**: A new magic function to install an IPython extension from
   a URL. E.g. ``%install_ext
   https://bitbucket.org/birkenfeld/ipython-physics/raw/default/physics.py``.
 
 * The ``%loadpy`` magic is no longer restricted to Python files, and has been
   renamed ``%load``. The old name remains as an alias.
 
 * New command line arguments will help external programs find IPython folders:
   ``ipython locate`` finds the user's IPython directory, and ``ipython locate
   profile foo`` finds the folder for the 'foo' profile (if it exists).
 
 * The :envvar:`IPYTHON_DIR` environment variable, introduced in the Great
   Reorganization of 0.11 and existing only in versions 0.11-0.13, has been
   deprecated. As described in :ghpull:`1167`, the complexity and confusion of
   migrating to this variable is not worth the aesthetic improvement. Please use
   the historical :envvar:`IPYTHONDIR` environment variable instead.
 
 * The default value of *interactivity* passed from
   :meth:`~IPython.core.interactiveshell.InteractiveShell.run_cell` to
   :meth:`~IPython.core.interactiveshell.InteractiveShell.run_ast_nodes`
   is now configurable.
 
 * New ``%alias_magic`` function to conveniently create aliases of existing
   magics, if you prefer to have shorter names for personal use.
 
 * We ship unminified versions of the JavaScript libraries we use, to better
   comply with Debian's packaging policies.
 
 * Simplify the information presented by ``obj?/obj??`` to eliminate a few
   redundant fields when possible.  :ghpull:`2038`.
 
 * Improved continuous integration for IPython.  We now have automated test runs
   on `Shining Panda <https://jenkins.shiningpanda.com/ipython>`_ and `Travis-CI
   <http://travis-ci.org/#!/ipython/ipython>`_, as well as `Tox support
   <http://tox.testrun.org>`_.
 
 * The `vim-ipython`_ functionality (externally developed) has been updated to
   the latest version.
 
 .. _vim-ipython: https://github.com/ivanov/vim-ipython
 
 * The ``%save`` magic now has a ``-f`` flag to force overwriting, which makes
   it much more usable in the notebook where it is not possible to reply to
   interactive questions from the kernel. :ghpull:`1937`.
 
 * Use dvipng to format sympy.Matrix, enabling display of matrices in the Qt
   console with the sympy printing extension. :ghpull:`1861`.
 
 * Our messaging protocol now has a reasonable test suite, helping ensure that
   we don't accidentally deviate from the spec and possibly break third-party
   applications that may have been using it.  We encourage users to contribute
   more stringent tests to this part of the test suite.  :ghpull:`1627`.
 
 * Use LaTeX to display, on output, various built-in types with the SymPy
   printing extension. :ghpull:`1399`.
 
 * Add Gtk3 event loop integration and example. :ghpull:`1588`.
 
 * ``clear_output`` improvements, which allow things like progress bars and other
   simple animations to work well in the notebook (:ghpull:`1563`):
     
     * `clear_output()` clears the line, even in terminal IPython, the QtConsole
       and plain Python as well, by printing `\r` to streams.
     
     * `clear_output()` avoids the flicker in the notebook by adding a delay,
       and firing immediately upon the next actual display message.
     
     * `display_javascript` hides its `output_area` element, so using display to
       run a bunch of javascript doesn't result in ever-growing vertical space.
 
 * Add simple support for running inside a virtualenv.  While this doesn't
   supplant proper installation (as users should do), it helps ad-hoc calling of
   IPython from inside a virtualenv. :ghpull:`1388`.
 
   
 Major Bugs fixed
 ----------------
 
 In this cycle, we have :ref:`closed over 740 issues <issues_list_013>`, but a
 few major ones merit special mention:
 
 * The ``%pastebin`` magic has been updated to point to gist.github.com, since
   unfortunately http://paste.pocoo.org has closed down. We also added a -d flag
   for the user to provide a gist description string. :ghpull:`1670`.
 
 * Fix ``%paste`` that would reject certain valid inputs. :ghpull:`1258`.
 
 * Fix sending and receiving of Numpy structured arrays (those with composite
   dtypes, often used as recarrays). :ghpull:`2034`.
 
 * Reconnect when the websocket connection closes unexpectedly. :ghpull:`1577`.
 
 * Fix truncated representation of objects in the debugger by showing at least
   80 characters' worth of information.  :ghpull:`1793`.
 
 * Fix logger to be Unicode-aware: logging could crash ipython if there was
   unicode in the input. :ghpull:`1792`.
 
 * Fix images missing from XML/SVG export in the Qt console. :ghpull:`1449`.
 
 * Fix deepreload on Python 3. :ghpull:`1625`, as well as having a much cleaner
   and more robust implementation of deepreload in general. :ghpull:`1457`.
 
 
 Backwards incompatible changes
 ------------------------------
 
 * The exception :exc:`IPython.core.error.TryNext` previously accepted
   arguments and keyword arguments to be passed to the next implementation
   of the hook. This feature was removed as it made error message propagation
   difficult and violated the principle of loose coupling.