update CompositeError docs with recent changes

docs/source/parallel/parallel_details.txt

@@ -1,658 +1,652 b''
 .. _parallel_details:
 
 ==========================================
 Details of Parallel Computing with IPython
 ==========================================
 
 .. note::
 
     There are still many sections to fill out in this doc
 
 
 Caveats
 =======
 
 First, some caveats about the detailed workings of parallel computing with 0MQ and IPython.
 
 Non-copying sends and numpy arrays
 ----------------------------------
 
 When numpy arrays are passed as arguments to apply or via data-movement methods, they are not
 copied. This means that you must be careful if you are sending an array that you intend to work
 on. PyZMQ does allow you to track when a message has been sent so you can know when it is safe
 to edit the buffer, but IPython only allows for this.
 
 It is also important to note that the non-copying receive of a message is *read-only*. That
 means that if you intend to work in-place on an array that you have sent or received, you must
 copy it. This is true for both numpy arrays sent to engines and numpy arrays retrieved as
 results.
 
 The following will fail:
 
 .. sourcecode:: ipython
 
     In [3]: A = numpy.zeros(2)
     
     In [4]: def setter(a):
-       ...: a[0]=1
-       ...: return a
+       ...:   a[0]=1
+       ...:   return a
 
     In [5]: rc[0].apply_sync(setter, A)
     ---------------------------------------------------------------------------
-    RemoteError                               Traceback (most recent call last)
-    ...
-    RemoteError: RuntimeError(array is not writeable)
-    Traceback (most recent call last):
-      File "/path/to/site-packages/IPython/parallel/streamkernel.py", line 329, in apply_request
-        exec code in working, working
-      File "<string>", line 1, in <module>
-      File "<ipython-input-14-736187483856>", line 2, in setter
+    RuntimeError                              Traceback (most recent call last)<string> in <module>()
+    <ipython-input-12-c3e7afeb3075> in setter(a)
     RuntimeError: array is not writeable
 
 If you do need to edit the array in-place, just remember to copy the array if it's read-only.
 The :attr:`ndarray.flags.writeable` flag will tell you if you can write to an array.
 
 .. sourcecode:: ipython
 
     In [3]: A = numpy.zeros(2)
     
     In [4]: def setter(a):
        ...:     """only copy read-only arrays"""
        ...:     if not a.flags.writeable:
        ...:         a=a.copy()
        ...:     a[0]=1
        ...:     return a
 
     In [5]: rc[0].apply_sync(setter, A)
     Out[5]: array([ 1.,  0.])
     
     # note that results will also be read-only:
     In [6]: _.flags.writeable
     Out[6]: False
 
 If you want to safely edit an array in-place after *sending* it, you must use the `track=True`
 flag. IPython always performs non-copying sends of arrays, which return immediately. You must
 instruct IPython track those messages *at send time* in order to know for sure that the send has
 completed. AsyncResults have a :attr:`sent` property, and :meth:`wait_on_send` method for
 checking and waiting for 0MQ to finish with a buffer.
 
 .. sourcecode:: ipython
 
     In [5]: A = numpy.random.random((1024,1024))
     
     In [6]: view.track=True
     
     In [7]: ar = view.apply_async(lambda x: 2*x, A)
     
     In [8]: ar.sent
     Out[8]: False
     
     In [9]: ar.wait_on_send() # blocks until sent is True
 
 
 What is sendable?
 -----------------
 
 If IPython doesn't know what to do with an object, it will pickle it. There is a short list of
 objects that are not pickled: ``buffers``, ``str/bytes`` objects, and ``numpy``
 arrays. These are handled specially by IPython in order to prevent the copying of data. Sending
 bytes or numpy arrays will result in exactly zero in-memory copies of your data (unless the data
 is very small).
 
 If you have an object that provides a Python buffer interface, then you can always send that
 buffer without copying - and reconstruct the object on the other side in your own code. It is
 possible that the object reconstruction will become extensible, so you can add your own
 non-copying types, but this does not yet exist.
 
 Closures
 ********
 
 Just about anything in Python is pickleable. The one notable exception is objects (generally
 functions) with *closures*. Closures can be a complicated topic, but the basic principal is that
 functions that refer to variables in their parent scope have closures.
 
 An example of a function that uses a closure:
 
 .. sourcecode:: python
 
     def f(a):
         def inner():
             # inner will have a closure
             return a
         return echo
     
     f1 = f(1)
     f2 = f(2)
     f1() # returns 1
     f2() # returns 2
 
 ``f1`` and ``f2`` will have closures referring to the scope in which `inner` was defined,
 because they use the variable 'a'. As a result, you would not be able to send ``f1`` or ``f2``
 with IPython. Note that you *would* be able to send `f`. This is only true for interactively
 defined functions (as are often used in decorators), and only when there are variables used
 inside the inner function, that are defined in the outer function. If the names are *not* in the
 outer function, then there will not be a closure, and the generated function will look in
 ``globals()`` for the name:
 
 .. sourcecode:: python
 
     def g(b):
         # note that `b` is not referenced in inner's scope
         def inner():
             # this inner will *not* have a closure
             return a
         return echo
     g1 = g(1)
     g2 = g(2)
     g1() # raises NameError on 'a'
     a=5
     g2() # returns 5
 
 `g1` and `g2` *will* be sendable with IPython, and will treat the engine's namespace as
 globals().  The :meth:`pull` method is implemented based on this principal.  If we did not
 provide pull, you could implement it yourself with `apply`, by simply returning objects out
 of the global namespace:
 
 .. sourcecode:: ipython
 
     In [10]: view.apply(lambda : a)
     
     # is equivalent to
     In [11]: view.pull('a')
 
 Running Code
 ============
 
 There are two principal units of execution in Python: strings of Python code (e.g. 'a=5'),
 and Python functions.  IPython is designed around the use of functions via the core
 Client method, called `apply`.
 
 Apply
 -----
 
 The principal method of remote execution is :meth:`apply`, of
 :class:`~IPython.parallel.client.view.View` objects. The Client provides the full execution and
 communication API for engines via its low-level :meth:`send_apply_message` method, which is used
 by all higher level methods of its Views.
 
 f : function
     The fuction to be called remotely
 args : tuple/list
     The positional arguments passed to `f`
 kwargs : dict
     The keyword arguments passed to `f`
 
 flags for all views:
 
 block : bool (default: view.block)
     Whether to wait for the result, or return immediately.
     False:
         returns AsyncResult
     True:
         returns actual result(s) of f(*args, **kwargs)
         if multiple targets:
             list of results, matching `targets`
 track : bool [default view.track]
     whether to track non-copying sends.
 
 targets : int,list of ints, 'all', None [default view.targets]
     Specify the destination of the job.
     if 'all' or None:
         Run on all active engines
     if list:
         Run on each specified engine
     if int:
         Run on single engine
 
 Note that LoadBalancedView uses targets to restrict possible destinations.  LoadBalanced calls
 will always execute in just one location.
 
 flags only in LoadBalancedViews:
 
 after : Dependency or collection of msg_ids
     Only for load-balanced execution (targets=None)
     Specify a list of msg_ids as a time-based dependency.
     This job will only be run *after* the dependencies
     have been met.
     
 follow : Dependency or collection of msg_ids
     Only for load-balanced execution (targets=None)
     Specify a list of msg_ids as a location-based dependency.
     This job will only be run on an engine where this dependency
     is met.
 
 timeout : float/int or None
     Only for load-balanced execution (targets=None)
     Specify an amount of time (in seconds) for the scheduler to
     wait for dependencies to be met before failing with a
     DependencyTimeout.
 
 execute and run
 ---------------
 
 For executing strings of Python code, :class:`DirectView` 's also provide an :meth:`execute` and
 a :meth:`run` method, which rather than take functions and arguments, take simple strings.
 `execute` simply takes a string of Python code to execute, and sends it to the Engine(s). `run`
 is the same as `execute`, but for a *file*, rather than a string. It is simply a wrapper that
 does something very similar to ``execute(open(f).read())``.
 
 .. note::
 
     TODO: Examples for execute and run
 
 Views
 =====
 
 The principal extension of the :class:`~parallel.Client` is the :class:`~parallel.View`
 class. The client is typically a singleton for connecting to a cluster, and presents a
 low-level interface to the Hub and Engines. Most real usage will involve creating one or more
 :class:`~parallel.View` objects for working with engines in various ways.
 
 
 DirectView
 ----------
 
 The :class:`.DirectView` is the class for the IPython :ref:`Multiplexing Interface
 <parallel_multiengine>`.
 
 Creating a DirectView
 *********************
 
 DirectViews can be created in two ways, by index access to a client, or by a client's
 :meth:`view` method.  Index access to a Client works in a few ways.  First, you can create
 DirectViews to single engines simply by accessing the client by engine id:
 
 .. sourcecode:: ipython
 
     In [2]: rc[0]
     Out[2]: <DirectView 0>
 
 You can also create a DirectView with a list of engines:
 
 .. sourcecode:: ipython
 
     In [2]: rc[0,1,2]
     Out[2]: <DirectView [0,1,2]>
 
 Other methods for accessing elements, such as slicing and negative indexing, work by passing
 the index directly to the client's :attr:`ids` list, so:
 
 .. sourcecode:: ipython
 
     # negative index
     In [2]: rc[-1]
     Out[2]: <DirectView 3>
     
     # or slicing:
     In [3]: rc[::2]
     Out[3]: <DirectView [0,2]>
 
 are always the same as:
 
 .. sourcecode:: ipython
 
     In [2]: rc[rc.ids[-1]]
     Out[2]: <DirectView 3>
     
     In [3]: rc[rc.ids[::2]]
     Out[3]: <DirectView [0,2]>
 
 Also note that the slice is evaluated at the time of construction of the DirectView, so the 
 targets will not change over time if engines are added/removed from the cluster.
 
 Execution via DirectView
 ************************
 
 The DirectView is the simplest way to work with one or more engines directly (hence the name).
 
 For instance, to get the process ID of all your engines:
 
 .. sourcecode:: ipython
 
     In [5]: import os
     
     In [6]: dview.apply_sync(os.getpid)
     Out[6]: [1354, 1356, 1358, 1360]
 
 Or to see the hostname of the machine they are on:
 
 .. sourcecode:: ipython
 
     In [5]: import socket
     
     In [6]: dview.apply_sync(socket.gethostname)
     Out[6]: ['tesla', 'tesla', 'edison', 'edison', 'edison']
 
 .. note::
 
     TODO: expand on direct execution
 
 Data movement via DirectView
 ****************************
 
 Since a Python namespace is just a :class:`dict`, :class:`DirectView` objects provide
 dictionary-style access by key and methods such as :meth:`get` and
 :meth:`update` for convenience. This make the remote namespaces of the engines
 appear as a local dictionary. Underneath, these methods call :meth:`apply`:
 
 .. sourcecode:: ipython
 
     In [51]: dview['a']=['foo','bar']
 
     In [52]: dview['a']
     Out[52]: [ ['foo', 'bar'], ['foo', 'bar'], ['foo', 'bar'], ['foo', 'bar'] ]
 
 Scatter and gather
 ------------------
 
 Sometimes it is useful to partition a sequence and push the partitions to
 different engines. In MPI language, this is know as scatter/gather and we
 follow that terminology. However, it is important to remember that in
 IPython's :class:`Client` class, :meth:`scatter` is from the
 interactive IPython session to the engines and :meth:`gather` is from the
 engines back to the interactive IPython session. For scatter/gather operations
 between engines, MPI should be used:
 
 .. sourcecode:: ipython
 
     In [58]: dview.scatter('a',range(16))
     Out[58]: [None,None,None,None]
 
     In [59]: dview['a']
     Out[59]: [ [0, 1, 2, 3], [4, 5, 6, 7], [8, 9, 10, 11], [12, 13, 14, 15] ]
 
     In [60]: dview.gather('a')
     Out[60]: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]
 
 Push and pull
 -------------
 
 :meth:`~IPython.parallel.client.view.DirectView.push`
 
 :meth:`~IPython.parallel.client.view.DirectView.pull`
 
 .. note::
 
     TODO: write this section
 
 
 LoadBalancedView
 ----------------
 
 The :class:`~.LoadBalancedView` is the class for load-balanced execution via the task scheduler.
 These views always run tasks on exactly one engine, but let the scheduler determine where that
 should be, allowing load-balancing of tasks. The LoadBalancedView does allow you to specify
 restrictions on where and when tasks can execute, for more complicated load-balanced workflows.
 
 Data Movement
 =============
 
 Since the :class:`~.LoadBalancedView` does not know where execution will take place, explicit
 data movement methods like push/pull and scatter/gather do not make sense, and are not provided.
 
 Results
 =======
 
 AsyncResults
 ------------
 
 Our primary representation of the results of remote execution is the :class:`~.AsyncResult`
 object, based on the object of the same name in the built-in :mod:`multiprocessing.pool`
 module. Our version provides a superset of that interface.
 
 The basic principle of the AsyncResult is the encapsulation of one or more results not yet completed.  Execution methods (including data movement, such as push/pull) will all return
 AsyncResults when `block=False`.
 
 The mp.pool.AsyncResult interface
 ---------------------------------
 
 The basic interface of the AsyncResult is exactly that of the AsyncResult in :mod:`multiprocessing.pool`, and consists of four methods:
 
 .. AsyncResult spec directly from docs.python.org
 
 .. class:: AsyncResult
 
    The stdlib AsyncResult spec
    
    .. method:: wait([timeout])
 
       Wait until the result is available or until *timeout* seconds pass. This
       method always returns ``None``.
 
    .. method:: ready()
 
       Return whether the call has completed.
 
    .. method:: successful()
 
       Return whether the call completed without raising an exception.  Will
       raise :exc:`AssertionError` if the result is not ready.
 
    .. method:: get([timeout])
 
       Return the result when it arrives.  If *timeout* is not ``None`` and the
       result does not arrive within *timeout* seconds then
       :exc:`TimeoutError` is raised.  If the remote call raised
       an exception then that exception will be reraised as a :exc:`RemoteError`
       by :meth:`get`.
 
 
 While an AsyncResult is not done, you can check on it with its :meth:`ready` method, which will
 return whether the AR is done. You can also wait on an AsyncResult with its :meth:`wait` method.
 This method blocks until the result arrives. If you don't want to wait forever, you can pass a
 timeout (in seconds) as an argument to :meth:`wait`. :meth:`wait` will *always return None*, and
 should never raise an error.
 
 :meth:`ready` and :meth:`wait` are insensitive to the success or failure of the call. After a
 result is done, :meth:`successful` will tell you whether the call completed without raising an
 exception.
 
 If you actually want the result of the call, you can use :meth:`get`. Initially, :meth:`get`
 behaves just like :meth:`wait`, in that it will block until the result is ready, or until a
 timeout is met. However, unlike :meth:`wait`, :meth:`get` will raise a :exc:`TimeoutError` if
 the timeout is reached and the result is still not ready. If the result arrives before the
 timeout is reached, then :meth:`get` will return the result itself if no exception was raised,
 and will raise an exception if there was.
 
 Here is where we start to expand on the multiprocessing interface. Rather than raising the
 original exception, a RemoteError will be raised, encapsulating the remote exception with some
 metadata. If the AsyncResult represents multiple calls (e.g. any time `targets` is plural), then
 a CompositeError, a subclass of RemoteError, will be raised.
 
 .. seealso::
 
     For more information on remote exceptions, see :ref:`the section in the Direct Interface
     <parallel_exceptions>`.
 
 Extended interface
 ******************
 
 
 Other extensions of the AsyncResult interface include convenience wrappers for :meth:`get`.
 AsyncResults have a property, :attr:`result`, with the short alias :attr:`r`, which simply call
 :meth:`get`. Since our object is designed for representing *parallel* results, it is expected
 that many calls (any of those submitted via DirectView) will map results to engine IDs. We
 provide a :meth:`get_dict`, which is also a wrapper on :meth:`get`, which returns a dictionary
 of the individual results, keyed by engine ID.
 
 You can also prevent a submitted job from actually executing, via the AsyncResult's
 :meth:`abort` method. This will instruct engines to not execute the job when it arrives.
 
 The larger extension of the AsyncResult API is the :attr:`metadata` attribute.  The metadata
 is a dictionary (with attribute access) that contains, logically enough, metadata about the
 execution.
 
 Metadata keys:
 
 timestamps
 
 submitted
     When the task left the Client
 started
     When the task started execution on the engine
 completed
     When execution finished on the engine
 received
     When the result arrived on the Client
     
     note that it is not known when the result arrived in 0MQ on the client, only when it
     arrived in Python via :meth:`Client.spin`, so in interactive use, this may not be
     strictly informative.
 
 Information about the engine
 
 engine_id
     The integer id
 engine_uuid
     The UUID of the engine
 
 output of the call
 
 pyerr
     Python exception, if there was one
 pyout
     Python output
 stderr
     stderr stream
 stdout
     stdout (e.g. print) stream
 
 And some extended information
 
 status
     either 'ok' or 'error'
 msg_id
     The UUID of the message
 after
     For tasks: the time-based msg_id dependencies
 follow
     For tasks: the location-based msg_id dependencies
 
 While in most cases, the Clients that submitted a request will be the ones using the results,
 other Clients can also request results directly from the Hub. This is done via the Client's
 :meth:`get_result` method. This method will *always* return an AsyncResult object. If the call
 was not submitted by the client, then it will be a subclass, called :class:`AsyncHubResult`.
 These behave in the same way as an AsyncResult, but if the result is not ready, waiting on an
 AsyncHubResult polls the Hub, which is much more expensive than the passive polling used
 in regular AsyncResults.
 
 
 The Client keeps track of all results
 history, results, metadata
 
 Querying the Hub
 ================
 
 The Hub sees all traffic that may pass through the schedulers between engines and clients.
 It does this so that it can track state, allowing multiple clients to retrieve results of
 computations submitted by their peers, as well as persisting the state to a database.
 
 queue_status
 
     You can check the status of the queues of the engines with this command.
 
 result_status
 
     check on results
 
 purge_results
 
     forget results (conserve resources)
 
 Controlling the Engines
 =======================
 
 There are a few actions you can do with Engines that do not involve execution.  These
 messages are sent via the Control socket, and bypass any long queues of waiting execution
 jobs
 
 abort
 
     Sometimes you may want to prevent a job you have submitted from actually running. The method
     for this is :meth:`abort`. It takes a container of msg_ids, and instructs the Engines to not
     run the jobs if they arrive. The jobs will then fail with an AbortedTask error.
 
 clear
 
     You may want to purge the Engine(s) namespace of any data you have left in it.  After
     running `clear`, there will be no names in the Engine's namespace
 
 shutdown
 
     You can also instruct engines (and the Controller) to terminate from a Client.  This 
     can be useful when a job is finished, since you can shutdown all the processes with a
     single command.
 
 Synchronization
 ===============
 
 Since the Client is a synchronous object, events do not automatically trigger in your
 interactive session - you must poll the 0MQ sockets for incoming messages.  Note that 
 this polling *does not* actually make any network requests.  It simply performs a `select`
 operation, to check if messages are already in local memory, waiting to be handled.
 
 The method that handles incoming messages is :meth:`spin`. This method flushes any waiting
 messages on the various incoming sockets, and updates the state of the Client.
 
 If you need to wait for particular results to finish, you can use the :meth:`wait` method,
 which will call :meth:`spin` until the messages are no longer outstanding. Anything that
 represents a collection of messages, such as a list of msg_ids or one or more AsyncResult
 objects, can be passed as argument to wait. A timeout can be specified, which will prevent
 the call from blocking for more than a specified time, but the default behavior is to wait
 forever.
 
 The client also has an ``outstanding`` attribute - a ``set`` of msg_ids that are awaiting
 replies. This is the default if wait is called with no arguments - i.e. wait on *all*
 outstanding messages.
 
 
 .. note::
 
     TODO wait example
 
 Map
 ===
 
 Many parallel computing problems can be expressed as a ``map``, or running a single program with
 a variety of different inputs. Python has a built-in :py:func:`map`, which does exactly this,
 and many parallel execution tools in Python, such as the built-in
 :py:class:`multiprocessing.Pool` object provide implementations of `map`. All View objects
 provide a :meth:`map` method as well, but the load-balanced and direct implementations differ.
 
 Views' map methods can be called on any number of sequences, but they can also take the `block`
 and `bound` keyword arguments, just like :meth:`~client.apply`, but *only as keywords*.
 
 .. sourcecode:: python
 
     dview.map(*sequences, block=None)
 
 
 * iter, map_async, reduce
 
 Decorators and RemoteFunctions
 ==============================
 
 .. note::
 
     TODO: write this section
 
 :func:`~IPython.parallel.client.remotefunction.@parallel`
 
 :func:`~IPython.parallel.client.remotefunction.@remote`
 
 :class:`~IPython.parallel.client.remotefunction.RemoteFunction`
 
 :class:`~IPython.parallel.client.remotefunction.ParallelFunction`
 
 Dependencies
 ============
 
 .. note::
 
     TODO: write this section
 
 :func:`~IPython.parallel.controller.dependency.@depend`
 
 :func:`~IPython.parallel.controller.dependency.@require`
 
 :class:`~IPython.parallel.controller.dependency.Dependency`

docs/source/parallel/parallel_multiengine.txt

@@ -1,1002 +1,907 b''
 .. _parallel_multiengine:
 
 ==========================
 IPython's Direct interface
 ==========================
 
 The direct, or multiengine, interface represents one possible way of working with a set of
 IPython engines. The basic idea behind the multiengine interface is that the
 capabilities of each engine are directly and explicitly exposed to the user.
 Thus, in the multiengine interface, each engine is given an id that is used to
 identify the engine and give it work to do. This interface is very intuitive
 and is designed with interactive usage in mind, and is the best place for
 new users of IPython to begin.
 
 Starting the IPython controller and engines
 ===========================================
 
 To follow along with this tutorial, you will need to start the IPython
 controller and four IPython engines. The simplest way of doing this is to use
 the :command:`ipcluster` command::
 
     $ ipcluster start -n 4
     
 For more detailed information about starting the controller and engines, see
 our :ref:`introduction <parallel_overview>` to using IPython for parallel computing.
 
 Creating a ``DirectView`` instance
 ==================================
 
 The first step is to import the IPython :mod:`IPython.parallel`
 module and then create a :class:`.Client` instance:
 
 .. sourcecode:: ipython
 
     In [1]: from IPython.parallel import Client
     
     In [2]: rc = Client()
 
 This form assumes that the default connection information (stored in
 :file:`ipcontroller-client.json` found in :file:`IPYTHONDIR/profile_default/security`) is
 accurate. If the controller was started on a remote machine, you must copy that connection
 file to the client machine, or enter its contents as arguments to the Client constructor:
 
 .. sourcecode:: ipython
 
     # If you have copied the json connector file from the controller:
     In [2]: rc = Client('/path/to/ipcontroller-client.json')
     # or to connect with a specific profile you have set up:
     In [3]: rc = Client(profile='mpi')
     
 
 To make sure there are engines connected to the controller, users can get a list
 of engine ids:
 
 .. sourcecode:: ipython
 
     In [3]: rc.ids
     Out[3]: [0, 1, 2, 3]
 
 Here we see that there are four engines ready to do work for us.
 
 For direct execution, we will make use of a :class:`DirectView` object, which can be
 constructed via list-access to the client:
 
 .. sourcecode:: ipython
 
     In [4]: dview = rc[:] # use all engines
 
 .. seealso::
 
     For more information, see the in-depth explanation of :ref:`Views <parallel_details>`.
 
 
 Quick and easy parallelism
 ==========================
 
 In many cases, you simply want to apply a Python function to a sequence of
 objects, but *in parallel*. The client interface provides a simple way
 of accomplishing this: using the DirectView's :meth:`~DirectView.map` method.
 
 Parallel map
 ------------
 
 Python's builtin :func:`map` functions allows a function to be applied to a
 sequence element-by-element. This type of code is typically trivial to
 parallelize. In fact, since IPython's interface is all about functions anyway,
 you can just use the builtin :func:`map` with a :class:`RemoteFunction`, or a 
 DirectView's :meth:`map` method:
 
 .. sourcecode:: ipython
 
     In [62]: serial_result = map(lambda x:x**10, range(32))
     
     In [63]: parallel_result = dview.map_sync(lambda x: x**10, range(32))
 
     In [67]: serial_result==parallel_result
     Out[67]: True
 
 
 .. note::
 
     The :class:`DirectView`'s version of :meth:`map` does
     not do dynamic load balancing. For a load balanced version, use a
     :class:`LoadBalancedView`.
 
 .. seealso::
     
     :meth:`map` is implemented via :class:`ParallelFunction`.
 
 Remote function decorators
 --------------------------
 
 Remote functions are just like normal functions, but when they are called,
 they execute on one or more engines, rather than locally. IPython provides
 two decorators:
 
 .. sourcecode:: ipython
 
     In [10]: @dview.remote(block=True)
        ....: def getpid():
        ....:     import os
        ....:     return os.getpid()
        ....: 
 
     In [11]: getpid()
     Out[11]: [12345, 12346, 12347, 12348]
 
 The ``@parallel`` decorator creates parallel functions, that break up an element-wise
 operations and distribute them, reconstructing the result.
 
 .. sourcecode:: ipython
 
     In [12]: import numpy as np
     
     In [13]: A = np.random.random((64,48))
     
     In [14]: @dview.parallel(block=True)
        ....: def pmul(A,B):
        ....:     return A*B
     
     In [15]: C_local = A*A
     
     In [16]: C_remote = pmul(A,A)
     
     In [17]: (C_local == C_remote).all()
     Out[17]: True
 
 Calling a ``@parallel`` function *does not* correspond to map. It is used for splitting
 element-wise operations that operate on a sequence or array.  For ``map`` behavior,
 parallel functions do have a map method.
 
 ====================    ============================    =============================
 call                    pfunc(seq)                      pfunc.map(seq)
 ====================    ============================    =============================
 # of tasks              # of engines (1 per engine)     # of engines (1 per engine)
 # of remote calls       # of engines (1 per engine)     ``len(seq)``
 argument to remote      ``seq[i:j]`` (sub-sequence)     ``seq[i]`` (single element)
 ====================    ============================    =============================
 
 A quick example to illustrate the difference in arguments for the two modes:
 
 .. sourcecode:: ipython
 
     In [16]: @dview.parallel(block=True)
        ....: def echo(x):
        ....:     return str(x)
        ....: 
 
     In [17]: echo(range(5))
     Out[17]: ['[0, 1]', '[2]', '[3]', '[4]']
 
     In [18]: echo.map(range(5))
     Out[18]: ['0', '1', '2', '3', '4']
 
 
 .. seealso::
 
     See the :func:`~.remotefunction.parallel` and :func:`~.remotefunction.remote`
     decorators for options.
 
 Calling Python functions
 ========================
 
 The most basic type of operation that can be performed on the engines is to
 execute Python code or call Python functions. Executing Python code can be
 done in blocking or non-blocking mode (non-blocking is default) using the
 :meth:`.View.execute` method, and calling functions can be done via the
 :meth:`.View.apply` method.
 
 apply
 -----
 
 The main method for doing remote execution (in fact, all methods that
 communicate with the engines are built on top of it), is :meth:`View.apply`.
 
 We strive to provide the cleanest interface we can, so `apply` has the following
 signature:
 
 .. sourcecode:: python
 
     view.apply(f, *args, **kwargs)
 
 There are various ways to call functions with IPython, and these flags are set as
 attributes of the View.  The ``DirectView`` has just two of these flags:
 
 dv.block : bool
     whether to wait for the result, or return an :class:`AsyncResult` object
     immediately
 dv.track : bool
     whether to instruct pyzmq to track when zeromq is done sending the message.
     This is primarily useful for non-copying sends of numpy arrays that you plan to
     edit in-place.  You need to know when it becomes safe to edit the buffer
     without corrupting the message.
 dv.targets : int, list of ints
     which targets this view is associated with.
 
 
 Creating a view is simple: index-access on a client creates a :class:`.DirectView`.
 
 .. sourcecode:: ipython
 
     In [4]: view = rc[1:3]
     Out[4]: <DirectView [1, 2]>
 
     In [5]: view.apply<tab>
     view.apply  view.apply_async  view.apply_sync
 
 For convenience, you can set block temporarily for a single call with the extra sync/async methods.
 
 Blocking execution
 ------------------
 
 In blocking mode, the :class:`.DirectView` object (called ``dview`` in
 these examples) submits the command to the controller, which places the
 command in the engines' queues for execution. The :meth:`apply` call then
 blocks until the engines are done executing the command:
 
 .. sourcecode:: ipython
 
     In [2]: dview = rc[:] # A DirectView of all engines
     In [3]: dview.block=True
     In [4]: dview['a'] = 5
 
     In [5]: dview['b'] = 10
 
     In [6]: dview.apply(lambda x: a+b+x, 27)
     Out[6]: [42, 42, 42, 42]
 
 You can also select blocking execution on a call-by-call basis with the :meth:`apply_sync`
 method:
 
 .. sourcecode:: ipython
 
     In [7]: dview.block=False
 
     In [8]: dview.apply_sync(lambda x: a+b+x, 27)
     Out[8]: [42, 42, 42, 42]
 
 Python commands can be executed as strings on specific engines by using a View's ``execute``
 method:
 
 .. sourcecode:: ipython
 
     In [6]: rc[::2].execute('c=a+b')
 
     In [7]: rc[1::2].execute('c=a-b')
 
     In [8]: dview['c'] # shorthand for dview.pull('c', block=True)
     Out[8]: [15, -5, 15, -5]
 
 
 Non-blocking execution
 ----------------------
 
 In non-blocking mode, :meth:`apply` submits the command to be executed and
 then returns a :class:`AsyncResult` object immediately. The
 :class:`AsyncResult` object gives you a way of getting a result at a later
 time through its :meth:`get` method.
 
 .. seealso::
 
     Docs on the :ref:`AsyncResult <parallel_asyncresult>` object.
 
 This allows you to quickly submit long running commands without blocking your
 local Python/IPython session:
 
 .. sourcecode:: ipython
     
     # define our function
     In [6]: def wait(t):
       ....:     import time
       ....:     tic = time.time()
       ....:     time.sleep(t)
       ....:     return time.time()-tic
     
     # In non-blocking mode
     In [7]: ar = dview.apply_async(wait, 2)
 
     # Now block for the result
     In [8]: ar.get()
     Out[8]: [2.0006198883056641, 1.9997570514678955, 1.9996809959411621, 2.0003249645233154]
 
     # Again in non-blocking mode
     In [9]: ar = dview.apply_async(wait, 10)
 
     # Poll to see if the result is ready
     In [10]: ar.ready()
     Out[10]: False
     
     # ask for the result, but wait a maximum of 1 second:
     In [45]: ar.get(1)
     ---------------------------------------------------------------------------
     TimeoutError                              Traceback (most recent call last)
     /home/you/<ipython-input-45-7cd858bbb8e0> in <module>()
     ----> 1 ar.get(1)
 
     /path/to/site-packages/IPython/parallel/asyncresult.pyc in get(self, timeout)
          62                 raise self._exception
          63         else:
     ---> 64             raise error.TimeoutError("Result not ready.")
          65 
          66     def ready(self):
 
     TimeoutError: Result not ready.
 
 .. Note::
 
     Note the import inside the function. This is a common model, to ensure
     that the appropriate modules are imported where the task is run. You can
     also manually import modules into the engine(s) namespace(s) via 
     :meth:`view.execute('import numpy')`.
 
 Often, it is desirable to wait until a set of :class:`AsyncResult` objects
 are done. For this, there is a the method :meth:`wait`. This method takes a
 tuple of :class:`AsyncResult` objects (or `msg_ids` or indices to the client's History),
 and blocks until all of the associated results are ready:
 
 .. sourcecode:: ipython
 
     In [72]: dview.block=False
 
     # A trivial list of AsyncResults objects
     In [73]: pr_list = [dview.apply_async(wait, 3) for i in range(10)]
 
     # Wait until all of them are done
     In [74]: dview.wait(pr_list)
 
     # Then, their results are ready using get() or the `.r` attribute
     In [75]: pr_list[0].get()
     Out[75]: [2.9982571601867676, 2.9982588291168213, 2.9987530708312988, 2.9990990161895752]
 
 
 
 The ``block`` and ``targets`` keyword arguments and attributes
 --------------------------------------------------------------
 
 Most DirectView methods (excluding :meth:`apply`) accept ``block`` and
 ``targets`` as keyword arguments. As we have seen above, these keyword arguments control the
 blocking mode and which engines the command is applied to. The :class:`View` class also has
 :attr:`block` and :attr:`targets` attributes that control the default behavior when the keyword
 arguments are not provided. Thus the following logic is used for :attr:`block` and :attr:`targets`:
 
 * If no keyword argument is provided, the instance attributes are used.
 * The Keyword arguments, if provided overrides the instance attributes for
   the duration of a single call.
   
 The following examples demonstrate how to use the instance attributes:
 
 .. sourcecode:: ipython
 
     In [16]: dview.targets = [0,2]
     
     In [17]: dview.block = False
 
     In [18]: ar = dview.apply(lambda : 10)
 
     In [19]: ar.get()
     Out[19]: [10, 10]
 
     In [20]: dview.targets = v.client.ids # all engines (4)
     
     In [21]: dview.block = True
 
     In [22]: dview.apply(lambda : 42)
     Out[22]: [42, 42, 42, 42]
 
 The :attr:`block` and :attr:`targets` instance attributes of the
 :class:`.DirectView` also determine the behavior of the parallel magic commands.
 
 Parallel magic commands
 -----------------------
 
 We provide a few IPython magic commands (``%px``, ``%autopx`` and ``%result``)
 that make it a bit more pleasant to execute Python commands on the engines interactively.
 These are simply shortcuts to :meth:`.DirectView.execute`
 and :meth:`.AsyncResult.display_outputs` methods repsectively.
 The ``%px`` magic executes a single Python command on the engines
 specified by the :attr:`targets` attribute of the :class:`DirectView` instance:
 
 .. sourcecode:: ipython
 
     # Create a DirectView for all targets
     In [22]: dv = rc[:]
     
     # Make this DirectView active for parallel magic commands
     In [23]: dv.activate()
 
     In [24]: dv.block=True
 
     # import numpy here and everywhere
     In [25]: with dv.sync_imports():
        ....:    import numpy
     importing numpy on engine(s)
 
     In [27]: %px a = numpy.random.rand(2,2)
     Parallel execution on engines: [0, 1, 2, 3]
 
     In [28]: %px numpy.linalg.eigvals(a)
     Parallel execution on engines: [0, 1, 2, 3]
     [0] Out[68]: array([ 0.77120707, -0.19448286])
     [1] Out[68]: array([ 1.10815921,  0.05110369])
     [2] Out[68]: array([ 0.74625527, -0.37475081])
     [3] Out[68]: array([ 0.72931905,  0.07159743])
     
     In [29]: %px print 'hi'
     Parallel execution on engine(s): [0, 1, 2, 3]
     [stdout:0] hi
     [stdout:1] hi
     [stdout:2] hi
     [stdout:3] hi
 
 
 Since engines are IPython as well, you can even run magics remotely:
 
 .. sourcecode:: ipython
 
     In [28]: %px %pylab inline
     Parallel execution on engine(s): [0, 1, 2, 3]
     [stdout:0] 
     Welcome to pylab, a matplotlib-based Python environment...
     For more information, type 'help(pylab)'.
     [stdout:1] 
     Welcome to pylab, a matplotlib-based Python environment...
     For more information, type 'help(pylab)'.
     [stdout:2] 
     Welcome to pylab, a matplotlib-based Python environment...
     For more information, type 'help(pylab)'.
     [stdout:3] 
     Welcome to pylab, a matplotlib-based Python environment...
     For more information, type 'help(pylab)'.
 
 And once in pylab mode with the inline backend,
 you can make plots and they will be displayed in your frontend
 if it suports the inline figures (e.g. notebook or qtconsole):
 
 .. sourcecode:: ipython
 
     In [40]: %px plot(rand(100))
     Parallel execution on engine(s): [0, 1, 2, 3]
     <plot0>
     <plot1>
     <plot2>
     <plot3>
     [0] Out[79]: [<matplotlib.lines.Line2D at 0x10a6286d0>]
     [1] Out[79]: [<matplotlib.lines.Line2D at 0x10b9476d0>]
     [2] Out[79]: [<matplotlib.lines.Line2D at 0x110652750>]
     [3] Out[79]: [<matplotlib.lines.Line2D at 0x10c6566d0>]
 
 
 ``%%px`` Cell Magic
 *******************
 
 `%%px` can also be used as a Cell Magic, which accepts ``--[no]block`` flags,
 and a ``--group-outputs`` argument, which adjust how the outputs of multiple
 engines are presented.
 
 .. seealso::
 
     :meth:`.AsyncResult.display_outputs` for the grouping options.
 
 .. sourcecode:: ipython
 
     In [50]: %%px --block --group-outputs=engine
        ....: import numpy as np
        ....: A = np.random.random((2,2))
        ....: ev = numpy.linalg.eigvals(A)
        ....: print ev
        ....: ev.max()
        ....:
     Parallel execution on engine(s): [0, 1, 2, 3]
     [stdout:0] [ 0.60640442  0.95919621]
     [0] Out[73]: 0.9591962130899806
     [stdout:1] [ 0.38501813  1.29430871]
     [1] Out[73]: 1.2943087091452372
     [stdout:2] [-0.85925141  0.9387692 ]
     [2] Out[73]: 0.93876920456230284
     [stdout:3] [ 0.37998269  1.24218246]
     [3] Out[73]: 1.2421824618493817
 
 ``%result`` Magic
 *****************
 
 If you are using ``%px`` in non-blocking mode, you won't get output.
 You can use ``%result`` to display the outputs of the latest command,
 just as is done when ``%px`` is blocking:
 
 .. sourcecode:: ipython
 
     In [39]: dv.block = False
     
     In [40]: %px print 'hi'
     Async parallel execution on engine(s): [0, 1, 2, 3]
     
     In [41]: %result
     [stdout:0] hi
     [stdout:1] hi
     [stdout:2] hi
     [stdout:3] hi
 
 ``%result`` simply calls :meth:`.AsyncResult.display_outputs` on the most recent request.
 You can pass integers as indices if you want a result other than the latest,
 e.g. ``%result -2``, or ``%result 0`` for the first.
 
 
 ``%autopx``
 ***********
 
 The ``%autopx`` magic switches to a mode where everything you type is executed
 on the engines until you do ``%autopx`` again.
 
 .. sourcecode:: ipython
 
     In [30]: dv.block=True
 
     In [31]: %autopx
     %autopx enabled
 
     In [32]: max_evals = []
 
     In [33]: for i in range(100):
        ....:     a = numpy.random.rand(10,10)
        ....:     a = a+a.transpose()
        ....:     evals = numpy.linalg.eigvals(a)
        ....:     max_evals.append(evals[0].real)
        ....:
 
     In [34]: print "Average max eigenvalue is: %f" % (sum(max_evals)/len(max_evals))
     [stdout:0] Average max eigenvalue is: 10.193101
     [stdout:1] Average max eigenvalue is: 10.064508
     [stdout:2] Average max eigenvalue is: 10.055724
     [stdout:3] Average max eigenvalue is: 10.086876
 
     In [35]: %autopx
     Auto Parallel Disabled
 
 
 Engines as Kernels
 ******************
 
 Engines are really the same object as the Kernels used elsewhere in IPython,
 with the minor exception that engines connect to a controller, while regular kernels
 bind their sockets, listening for connections from a QtConsole or other frontends.
 
 Sometimes for debugging or inspection purposes, you would like a QtConsole connected
 to an engine for more direct interaction.  You can do this by first instructing
 the Engine to *also* bind its kernel, to listen for connections:
 
 .. sourcecode:: ipython
 
     In [50]: %px from IPython.parallel import bind_kernel; bind_kernel()
 
 Then, if your engines are local, you can start a qtconsole right on the engine(s):
 
 .. sourcecode:: ipython
 
     In [51]: %px %qtconsole
 
 Careful with this one, because if your view is of 16 engines it will start 16 QtConsoles!
 
 Or you can view just the connection info, and work out the right way to connect to the engines,
 depending on where they live and where you are:
 
 .. sourcecode:: ipython
 
     In [51]: %px %connect_info
     Parallel execution on engine(s): [0, 1, 2, 3]
     [stdout:0] 
     {
       "stdin_port": 60387, 
       "ip": "127.0.0.1", 
       "hb_port": 50835, 
       "key": "eee2dd69-7dd3-4340-bf3e-7e2e22a62542", 
       "shell_port": 55328, 
       "iopub_port": 58264
     }
 
     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-60125.json 
     or even just:
         $> ipython <app> --existing 
     if this is the most recent IPython session you have started.
     [stdout:1] 
     {
       "stdin_port": 61869,
     ...
 
 .. note::
 
     ``%qtconsole`` will call :func:`bind_kernel` on an engine if it hasn't been done already,
     so you can often skip that first step.
 
 
 Moving Python objects around
 ============================
 
 In addition to calling functions and executing code on engines, you can
 transfer Python objects to and from your IPython session and the engines. In
 IPython, these operations are called :meth:`push` (sending an object to the
 engines) and :meth:`pull` (getting an object from the engines).
 
 Basic push and pull
 -------------------
 
 Here are some examples of how you use :meth:`push` and :meth:`pull`:
 
 .. sourcecode:: ipython
 
     In [38]: dview.push(dict(a=1.03234,b=3453))
     Out[38]: [None,None,None,None]
 
     In [39]: dview.pull('a')
     Out[39]: [ 1.03234, 1.03234, 1.03234, 1.03234]
 
     In [40]: dview.pull('b', targets=0)
     Out[40]: 3453
 
     In [41]: dview.pull(('a','b'))
     Out[41]: [ [1.03234, 3453], [1.03234, 3453], [1.03234, 3453], [1.03234, 3453] ]
     
     In [42]: dview.push(dict(c='speed'))
     Out[42]: [None,None,None,None]
 
 In non-blocking mode :meth:`push` and :meth:`pull` also return
 :class:`AsyncResult` objects:
 
 .. sourcecode:: ipython
 
     In [48]: ar = dview.pull('a', block=False)
 
     In [49]: ar.get()
     Out[49]: [1.03234, 1.03234, 1.03234, 1.03234]
 
 
 Dictionary interface
 --------------------
 
 Since a Python namespace is just a :class:`dict`, :class:`DirectView` objects provide
 dictionary-style access by key and methods such as :meth:`get` and
 :meth:`update` for convenience. This make the remote namespaces of the engines
 appear as a local dictionary. Underneath, these methods call :meth:`apply`:
 
 .. sourcecode:: ipython
 
     In [51]: dview['a']=['foo','bar']
 
     In [52]: dview['a']
     Out[52]: [ ['foo', 'bar'], ['foo', 'bar'], ['foo', 'bar'], ['foo', 'bar'] ]
 
 Scatter and gather
 ------------------
 
 Sometimes it is useful to partition a sequence and push the partitions to
 different engines. In MPI language, this is know as scatter/gather and we
 follow that terminology. However, it is important to remember that in
 IPython's :class:`Client` class, :meth:`scatter` is from the
 interactive IPython session to the engines and :meth:`gather` is from the
 engines back to the interactive IPython session. For scatter/gather operations
 between engines, MPI, pyzmq, or some other direct interconnect should be used.
 
 .. sourcecode:: ipython
 
     In [58]: dview.scatter('a',range(16))
     Out[58]: [None,None,None,None]
 
     In [59]: dview['a']
     Out[59]: [ [0, 1, 2, 3], [4, 5, 6, 7], [8, 9, 10, 11], [12, 13, 14, 15] ]
 
     In [60]: dview.gather('a')
     Out[60]: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]
 
 Other things to look at
 =======================
 
 How to do parallel list comprehensions
 --------------------------------------
 
 In many cases list comprehensions are nicer than using the map function. While
 we don't have fully parallel list comprehensions, it is simple to get the
 basic effect using :meth:`scatter` and :meth:`gather`:
 
 .. sourcecode:: ipython
 
     In [66]: dview.scatter('x',range(64))
 
     In [67]: %px y = [i**10 for i in x]
     Parallel execution on engines: [0, 1, 2, 3]
 
     In [68]: y = dview.gather('y')
 
     In [69]: print y
     [0, 1, 1024, 59049, 1048576, 9765625, 60466176, 282475249, 1073741824,...]
 
 Remote imports
 --------------
 
 Sometimes you will want to import packages both in your interactive session
 and on your remote engines.  This can be done with the :class:`ContextManager`
 created by a DirectView's :meth:`sync_imports` method:
 
 .. sourcecode:: ipython
 
     In [69]: with dview.sync_imports():
        ....:     import numpy
     importing numpy on engine(s)
 
 Any imports made inside the block will also be performed on the view's engines.
 sync_imports also takes a `local` boolean flag that defaults to True, which specifies
 whether the local imports should also be performed.  However, support for `local=False`
 has not been implemented, so only packages that can be imported locally will work
 this way.
 
 You can also specify imports via the ``@require`` decorator.  This is a decorator
 designed for use in Dependencies, but can be used to handle remote imports as well.
 Modules or module names passed to ``@require`` will be imported before the decorated
 function is called.  If they cannot be imported, the decorated function will never
 execute and will fail with an UnmetDependencyError. Failures of single Engines will
 be collected and raise a CompositeError, as demonstrated in the next section.
 
 .. sourcecode:: ipython
 
     In [69]: from IPython.parallel import require
 
     In [70]: @require('re'):
        ....: def findall(pat, x):
        ....:     # re is guaranteed to be available
        ....:     return re.findall(pat, x)
           
     # you can also pass modules themselves, that you already have locally:
     In [71]: @require(time):
        ....: def wait(t):
        ....:     time.sleep(t)
        ....:     return t
 
 .. _parallel_exceptions:
 
 Parallel exceptions
 -------------------
 
 In the multiengine interface, parallel commands can raise Python exceptions,
-just like serial commands. But, it is a little subtle, because a single
+just like serial commands. But it is a little subtle, because a single
 parallel command can actually raise multiple exceptions (one for each engine
 the command was run on). To express this idea, we have a
 :exc:`CompositeError` exception class that will be raised in most cases. The
 :exc:`CompositeError` class is a special type of exception that wraps one or
 more other types of exceptions. Here is how it works:
 
 .. sourcecode:: ipython
 
-    In [76]: dview.block=True
+    In [78]: dview.block = True
+    
+    In [79]: dview.execute("1/0")
+    [0:execute]: 
+    ---------------------------------------------------------------------------
+    ZeroDivisionError                         Traceback (most recent call last)<ipython-input-1-05c9758a9c21> in <module>()
+    ----> 1 1/0
+    ZeroDivisionError: integer division or modulo by zero
+
+    [1:execute]: 
+    ---------------------------------------------------------------------------
+    ZeroDivisionError                         Traceback (most recent call last)<ipython-input-1-05c9758a9c21> in <module>()
+    ----> 1 1/0
+    ZeroDivisionError: integer division or modulo by zero
 
-    In [77]: dview.execute('1/0')
+    [2:execute]: 
     ---------------------------------------------------------------------------
-    CompositeError                            Traceback (most recent call last)
-    /home/user/<ipython-input-10-5d56b303a66c> in <module>()
-    ----> 1 dview.execute('1/0')
-
-    /path/to/site-packages/IPython/parallel/client/view.pyc in execute(self, code, targets, block)
-        591                 default: self.block
-        592         """
-    --> 593         return self._really_apply(util._execute, args=(code,), block=block, targets=targets)
-        594 
-        595     def run(self, filename, targets=None, block=None):
-
-    /home/user/<string> in _really_apply(self, f, args, kwargs, targets, block, track)
-
-    /path/to/site-packages/IPython/parallel/client/view.pyc in sync_results(f, self, *args, **kwargs)
-         55 def sync_results(f, self, *args, **kwargs):
-         56     """sync relevant results from self.client to our results attribute."""
-    ---> 57     ret = f(self, *args, **kwargs)
-         58     delta = self.outstanding.difference(self.client.outstanding)
-         59     completed = self.outstanding.intersection(delta)
-
-    /home/user/<string> in _really_apply(self, f, args, kwargs, targets, block, track)
-
-    /path/to/site-packages/IPython/parallel/client/view.pyc in save_ids(f, self, *args, **kwargs)
-         44     n_previous = len(self.client.history)
-         45     try:
-    ---> 46         ret = f(self, *args, **kwargs)
-         47     finally:
-         48         nmsgs = len(self.client.history) - n_previous
-
-    /path/to/site-packages/IPython/parallel/client/view.pyc in _really_apply(self, f, args, kwargs, targets, block, track)
-        529         if block:
-        530             try:
-    --> 531                 return ar.get()
-        532             except KeyboardInterrupt:
-        533                 pass
-
-    /path/to/site-packages/IPython/parallel/client/asyncresult.pyc in get(self, timeout)
-        101                 return self._result
-        102             else:
-    --> 103                 raise self._exception
-        104         else:
-        105             raise error.TimeoutError("Result not ready.")
-
-    CompositeError: one or more exceptions from call to method: _execute
-    [0:apply]: ZeroDivisionError: integer division or modulo by zero
-    [1:apply]: ZeroDivisionError: integer division or modulo by zero
-    [2:apply]: ZeroDivisionError: integer division or modulo by zero
-    [3:apply]: ZeroDivisionError: integer division or modulo by zero
+    ZeroDivisionError                         Traceback (most recent call last)<ipython-input-1-05c9758a9c21> in <module>()
+    ----> 1 1/0
+    ZeroDivisionError: integer division or modulo by zero
+
+    [3:execute]: 
+    ---------------------------------------------------------------------------
+    ZeroDivisionError                         Traceback (most recent call last)<ipython-input-1-05c9758a9c21> in <module>()
+    ----> 1 1/0
+    ZeroDivisionError: integer division or modulo by zero
 
 Notice how the error message printed when :exc:`CompositeError` is raised has
 information about the individual exceptions that were raised on each engine.
 If you want, you can even raise one of these original exceptions:
 
 .. sourcecode:: ipython
 
     In [80]: try:
-       ....:     dview.execute('1/0')
+       ....:     dview.execute('1/0', block=True)
        ....: except parallel.error.CompositeError, e:
        ....:     e.raise_exception()
-       ....:     
-       ....:     
+       ....: 
+       ....: 
     ---------------------------------------------------------------------------
-    RemoteError                               Traceback (most recent call last)
-    /home/user/<ipython-input-17-8597e7e39858> in <module>()
-          2     dview.execute('1/0')
-          3 except CompositeError as e:
-    ----> 4     e.raise_exception()
-
-    /path/to/site-packages/IPython/parallel/error.pyc in raise_exception(self, excid)
-        266             raise IndexError("an exception with index %i does not exist"%excid)
-        267         else:
-    --> 268             raise RemoteError(en, ev, etb, ei)
-        269 
-        270 
-
-    RemoteError: ZeroDivisionError(integer division or modulo by zero)
-    Traceback (most recent call last):
-      File "/path/to/site-packages/IPython/parallel/engine/streamkernel.py", line 330, in apply_request
-        exec code in working,working
-      File "<string>", line 1, in <module>
-      File "/path/to/site-packages/IPython/parallel/util.py", line 354, in _execute
-        exec code in globals()
-      File "<string>", line 1, in <module>
+    ZeroDivisionError                         Traceback (most recent call last)<ipython-input-1-05c9758a9c21> in <module>()
+    ----> 1 1/0
     ZeroDivisionError: integer division or modulo by zero
 
 If you are working in IPython, you can simple type ``%debug`` after one of
 these :exc:`CompositeError` exceptions is raised, and inspect the exception
 instance:
 
 .. sourcecode:: ipython
 
     In [81]: dview.execute('1/0')
+    [0:execute]: 
     ---------------------------------------------------------------------------
-    CompositeError                            Traceback (most recent call last)
-    /home/user/<ipython-input-10-5d56b303a66c> in <module>()
-    ----> 1 dview.execute('1/0')
-
-    /path/to/site-packages/IPython/parallel/client/view.pyc in execute(self, code, targets, block)
-        591                 default: self.block
-        592         """
-    --> 593         return self._really_apply(util._execute, args=(code,), block=block, targets=targets)
-        594 
-        595     def run(self, filename, targets=None, block=None):
-
-    /home/user/<string> in _really_apply(self, f, args, kwargs, targets, block, track)
-
-    /path/to/site-packages/IPython/parallel/client/view.pyc in sync_results(f, self, *args, **kwargs)
-         55 def sync_results(f, self, *args, **kwargs):
-         56     """sync relevant results from self.client to our results attribute."""
-    ---> 57     ret = f(self, *args, **kwargs)
-         58     delta = self.outstanding.difference(self.client.outstanding)
-         59     completed = self.outstanding.intersection(delta)
-
-    /home/user/<string> in _really_apply(self, f, args, kwargs, targets, block, track)
-
-    /path/to/site-packages/IPython/parallel/client/view.pyc in save_ids(f, self, *args, **kwargs)
-         44     n_previous = len(self.client.history)
-         45     try:
-    ---> 46         ret = f(self, *args, **kwargs)
-         47     finally:
-         48         nmsgs = len(self.client.history) - n_previous
-
-    /path/to/site-packages/IPython/parallel/client/view.pyc in _really_apply(self, f, args, kwargs, targets, block, track)
-        529         if block:
-        530             try:
-    --> 531                 return ar.get()
-        532             except KeyboardInterrupt:
-        533                 pass
-
-    /path/to/site-packages/IPython/parallel/client/asyncresult.pyc in get(self, timeout)
-        101                 return self._result
-        102             else:
-    --> 103                 raise self._exception
-        104         else:
-        105             raise error.TimeoutError("Result not ready.")
-
-    CompositeError: one or more exceptions from call to method: _execute
-    [0:apply]: ZeroDivisionError: integer division or modulo by zero
-    [1:apply]: ZeroDivisionError: integer division or modulo by zero
-    [2:apply]: ZeroDivisionError: integer division or modulo by zero
-    [3:apply]: ZeroDivisionError: integer division or modulo by zero
-    
-    In [82]: %debug
-    > /path/to/site-packages/IPython/parallel/client/asyncresult.py(103)get()
-        102             else:
-    --> 103                 raise self._exception
-        104         else:
-    
-    # With the debugger running, self._exception is the exceptions instance.  We can tab complete
-    # on it and see the extra methods that are available.
-    ipdb> self._exception.<tab>
-    e.__class__         e.__getitem__       e.__new__           e.__setstate__      e.args
-    e.__delattr__       e.__getslice__      e.__reduce__        e.__str__           e.elist
-    e.__dict__          e.__hash__          e.__reduce_ex__     e.__weakref__       e.message
-    e.__doc__           e.__init__          e.__repr__          e._get_engine_str   e.print_tracebacks
-    e.__getattribute__  e.__module__        e.__setattr__       e._get_traceback    e.raise_exception
-    ipdb> self._exception.print_tracebacks()
-    [0:apply]: 
-    Traceback (most recent call last):
-      File "/path/to/site-packages/IPython/parallel/engine/streamkernel.py", line 330, in apply_request
-        exec code in working,working
-      File "<string>", line 1, in <module>
-      File "/path/to/site-packages/IPython/parallel/util.py", line 354, in _execute
-        exec code in globals()
-      File "<string>", line 1, in <module>
+    ZeroDivisionError                         Traceback (most recent call last)<ipython-input-1-05c9758a9c21> in <module>()
+    ----> 1 1/0
     ZeroDivisionError: integer division or modulo by zero
 
-
-    [1:apply]: 
-    Traceback (most recent call last):
-      File "/path/to/site-packages/IPython/parallel/engine/streamkernel.py", line 330, in apply_request
-        exec code in working,working
-      File "<string>", line 1, in <module>
-      File "/path/to/site-packages/IPython/parallel/util.py", line 354, in _execute
-        exec code in globals()
-      File "<string>", line 1, in <module>
+    [1:execute]: 
+    ---------------------------------------------------------------------------
+    ZeroDivisionError                         Traceback (most recent call last)<ipython-input-1-05c9758a9c21> in <module>()
+    ----> 1 1/0
     ZeroDivisionError: integer division or modulo by zero
 
-
-    [2:apply]: 
-    Traceback (most recent call last):
-      File "/path/to/site-packages/IPython/parallel/engine/streamkernel.py", line 330, in apply_request
-        exec code in working,working
-      File "<string>", line 1, in <module>
-      File "/path/to/site-packages/IPython/parallel/util.py", line 354, in _execute
-        exec code in globals()
-      File "<string>", line 1, in <module>
+    [2:execute]: 
+    ---------------------------------------------------------------------------
+    ZeroDivisionError                         Traceback (most recent call last)<ipython-input-1-05c9758a9c21> in <module>()
+    ----> 1 1/0
     ZeroDivisionError: integer division or modulo by zero
 
-
-    [3:apply]: 
-    Traceback (most recent call last):
-      File "/path/to/site-packages/IPython/parallel/engine/streamkernel.py", line 330, in apply_request
-        exec code in working,working
-      File "<string>", line 1, in <module>
-      File "/path/to/site-packages/IPython/parallel/util.py", line 354, in _execute
-        exec code in globals()
-      File "<string>", line 1, in <module>
+    [3:execute]: 
+    ---------------------------------------------------------------------------
+    ZeroDivisionError                         Traceback (most recent call last)<ipython-input-1-05c9758a9c21> in <module>()
+    ----> 1 1/0
+    ZeroDivisionError: integer division or modulo by zero
+    
+    In [82]: %debug
+    > /.../site-packages/IPython/parallel/client/asyncresult.py(125)get()
+        124             else:
+    --> 125                 raise self._exception
+        126         else:
+    
+    # Here, self._exception is the CompositeError instance:
+    
+    ipdb> e = self._exception
+    ipdb> e
+    CompositeError(4)
+    
+    # we can tab-complete on e to see available methods:
+    ipdb> e.<TAB>
+    e.args               e.message            e.traceback
+    e.elist              e.msg
+    e.ename              e.print_traceback
+    e.engine_info        e.raise_exception
+    e.evalue             e.render_traceback
+    
+    # We can then display the individual tracebacks, if we want:
+    ipdb> e.print_traceback(1)
+    [1:execute]: 
+    ---------------------------------------------------------------------------
+    ZeroDivisionError                         Traceback (most recent call last)<ipython-input-1-05c9758a9c21> in <module>()
+    ----> 1 1/0
     ZeroDivisionError: integer division or modulo by zero
 
 
 All of this same error handling magic even works in non-blocking mode:
 
 .. sourcecode:: ipython
 
     In [83]: dview.block=False
 
     In [84]: ar = dview.execute('1/0')
 
     In [85]: ar.get()
+    [0:execute]: 
     ---------------------------------------------------------------------------
-    CompositeError                            Traceback (most recent call last)
-    /home/user/<ipython-input-21-8531eb3d26fb> in <module>()
-    ----> 1 ar.get()
-
-    /path/to/site-packages/IPython/parallel/client/asyncresult.pyc in get(self, timeout)
-        101                 return self._result
-        102             else:
-    --> 103                 raise self._exception
-        104         else:
-        105             raise error.TimeoutError("Result not ready.")
-
-    CompositeError: one or more exceptions from call to method: _execute
-    [0:apply]: ZeroDivisionError: integer division or modulo by zero
-    [1:apply]: ZeroDivisionError: integer division or modulo by zero
-    [2:apply]: ZeroDivisionError: integer division or modulo by zero
-    [3:apply]: ZeroDivisionError: integer division or modulo by zero
+    ZeroDivisionError                         Traceback (most recent call last)<ipython-input-1-05c9758a9c21> in <module>()
+    ----> 1 1/0
+    ZeroDivisionError: integer division or modulo by zero
+
+    [1:execute]: 
+    ---------------------------------------------------------------------------
+    ZeroDivisionError                         Traceback (most recent call last)<ipython-input-1-05c9758a9c21> in <module>()
+    ----> 1 1/0
+    ZeroDivisionError: integer division or modulo by zero
+
+    [2:execute]: 
+    ---------------------------------------------------------------------------
+    ZeroDivisionError                         Traceback (most recent call last)<ipython-input-1-05c9758a9c21> in <module>()
+    ----> 1 1/0
+    ZeroDivisionError: integer division or modulo by zero
+
+    [3:execute]: 
+    ---------------------------------------------------------------------------
+    ZeroDivisionError                         Traceback (most recent call last)<ipython-input-1-05c9758a9c21> in <module>()
+    ----> 1 1/0
+    ZeroDivisionError: integer division or modulo by zero