New connect_request message type added.

IPython/zmq/entry_point.py

@@ -1,235 +1,239 b''
 """ Defines helper functions for creating kernel entry points and process
 launchers.
 """
 
 # Standard library imports.
 import os
 import socket
 from subprocess import Popen, PIPE
 import sys
 
 # System library imports.
 import zmq
 
 # Local imports.
 from IPython.core.ultratb import FormattedTB
 from IPython.external.argparse import ArgumentParser
 from IPython.utils import io
 from exitpoller import ExitPollerUnix, ExitPollerWindows
 from displayhook import DisplayHook
 from iostream import OutStream
 from session import Session
 from heartbeat import Heartbeat
 
 def bind_port(socket, ip, port):
     """ Binds the specified ZMQ socket. If the port is zero, a random port is
     chosen. Returns the port that was bound.
     """
     connection = 'tcp://%s' % ip
     if port <= 0:
         port = socket.bind_to_random_port(connection)
     else:
         connection += ':%i' % port
         socket.bind(connection)
     return port
 
 
 def make_argument_parser():
     """ Creates an ArgumentParser for the generic arguments supported by all 
     kernel entry points.
     """
     parser = ArgumentParser()
     parser.add_argument('--ip', type=str, default='127.0.0.1',
                         help='set the kernel\'s IP address [default: local]')
     parser.add_argument('--xrep', type=int, metavar='PORT', default=0,
                         help='set the XREP channel port [default: random]')
     parser.add_argument('--pub', type=int, metavar='PORT', default=0,
                         help='set the PUB channel port [default: random]')
     parser.add_argument('--req', type=int, metavar='PORT', default=0,
                         help='set the REQ channel port [default: random]')
     parser.add_argument('--hb', type=int, metavar='PORT', default=0,
                         help='set the heartbeat port [default: random]')
 
     if sys.platform == 'win32':
         parser.add_argument('--parent', type=int, metavar='HANDLE', 
                             default=0, help='kill this process if the process '
                             'with HANDLE dies')
     else:
         parser.add_argument('--parent', action='store_true', 
                             help='kill this process if its parent dies')
 
     return parser
 
 
 def make_kernel(namespace, kernel_factory, 
                 out_stream_factory=None, display_hook_factory=None):
     """ Creates a kernel, redirects stdout/stderr, and installs a display hook
     and exception handler.
     """
     # If running under pythonw.exe, the interpreter will crash if more than 4KB
     # of data is written to stdout or stderr. This is a bug that has been with
     # Python for a very long time; see http://bugs.python.org/issue706263.
     if sys.executable.endswith('pythonw.exe'):
         blackhole = file(os.devnull, 'w')
         sys.stdout = sys.stderr = blackhole
         sys.__stdout__ = sys.__stderr__ = blackhole 
 
     # Install minimal exception handling
     sys.excepthook = FormattedTB(mode='Verbose', color_scheme='NoColor', 
                                  ostream=sys.__stdout__)
 
     # Create a context, a session, and the kernel sockets.
     io.raw_print("Starting the kernel at pid:", os.getpid())
     context = zmq.Context()
     session = Session(username=u'kernel')
 
     reply_socket = context.socket(zmq.XREP)
     xrep_port = bind_port(reply_socket, namespace.ip, namespace.xrep)
     io.raw_print("XREP Channel on port", xrep_port)
 
     pub_socket = context.socket(zmq.PUB)
     pub_port = bind_port(pub_socket, namespace.ip, namespace.pub)
     io.raw_print("PUB Channel on port", pub_port)
 
     req_socket = context.socket(zmq.XREQ)
     req_port = bind_port(req_socket, namespace.ip, namespace.req)
     io.raw_print("REQ Channel on port", req_port)
 
     hb = Heartbeat(context, (namespace.ip, namespace.hb))
     hb.start()
-    io.raw_print("Heartbeat REP Channel on port", hb.port)
+    hb_port = hb.port
+    io.raw_print("Heartbeat REP Channel on port", hb_port)
 
     # Redirect input streams and set a display hook.
     if out_stream_factory:
         sys.stdout = out_stream_factory(session, pub_socket, u'stdout')
         sys.stderr = out_stream_factory(session, pub_socket, u'stderr')
     if display_hook_factory:
         sys.displayhook = display_hook_factory(session, pub_socket)
 
     # Create the kernel.
-    return kernel_factory(session=session, reply_socket=reply_socket, 
-                          pub_socket=pub_socket, req_socket=req_socket)
+    kernel = kernel_factory(session=session, reply_socket=reply_socket, 
+                            pub_socket=pub_socket, req_socket=req_socket)
+    kernel.record_ports(xrep_port=xrep_port, pub_port=pub_port,
+                        req_port=req_port, hb_port=hb_port)
+    return kernel
 
 
 def start_kernel(namespace, kernel):
     """ Starts a kernel.
     """
     # Configure this kernel/process to die on parent termination, if necessary.
     if namespace.parent:
         if sys.platform == 'win32':
             poller = ExitPollerWindows(namespace.parent)
         else:
             poller = ExitPollerUnix()
         poller.start()
 
     # Start the kernel mainloop.
     kernel.start()
 
 
 def make_default_main(kernel_factory):
     """ Creates the simplest possible kernel entry point.
     """
     def main():
         namespace = make_argument_parser().parse_args()
         kernel = make_kernel(namespace, kernel_factory, OutStream, DisplayHook)
         start_kernel(namespace, kernel)
     return main
 
 
 def base_launch_kernel(code, xrep_port=0, pub_port=0, req_port=0, hb_port=0,
                        independent=False, extra_arguments=[]):
     """ Launches a localhost kernel, binding to the specified ports.
 
     Parameters
     ----------
     code : str,
         A string of Python code that imports and executes a kernel entry point.
 
     xrep_port : int, optional
         The port to use for XREP channel.
 
     pub_port : int, optional
         The port to use for the SUB channel.
 
     req_port : int, optional
         The port to use for the REQ (raw input) channel.
 
     hb_port : int, optional
         The port to use for the hearbeat REP channel.
 
     independent : bool, optional (default False) 
         If set, the kernel process is guaranteed to survive if this process
         dies. If not set, an effort is made to ensure that the kernel is killed
         when this process dies. Note that in this case it is still good practice
         to kill kernels manually before exiting.
 
     extra_arguments = list, optional
         A list of extra arguments to pass when executing the launch code.
 
     Returns
     -------
     A tuple of form:
         (kernel_process, xrep_port, pub_port, req_port)
     where kernel_process is a Popen object and the ports are integers.
     """
     # Find open ports as necessary.
     ports = []
     ports_needed = int(xrep_port <= 0) + int(pub_port <= 0) + \
                    int(req_port <= 0) + int(hb_port <= 0)
     for i in xrange(ports_needed):
         sock = socket.socket()
         sock.bind(('', 0))
         ports.append(sock)
     for i, sock in enumerate(ports):
         port = sock.getsockname()[1]
         sock.close()
         ports[i] = port
     if xrep_port <= 0:
         xrep_port = ports.pop(0)
     if pub_port <= 0:
         pub_port = ports.pop(0)
     if req_port <= 0:
         req_port = ports.pop(0)
     if hb_port <= 0:
         hb_port = ports.pop(0)
 
     # Build the kernel launch command.
     arguments = [ sys.executable, '-c', code, '--xrep', str(xrep_port), 
                   '--pub', str(pub_port), '--req', str(req_port),
                   '--hb', str(hb_port) ]
     arguments.extend(extra_arguments)
 
     # Spawn a kernel.
     if sys.platform == 'win32':
 
         # If using pythonw, stdin, stdout, and stderr are invalid. Popen will
         # fail unless they are suitably redirected. We don't read from the
         # pipes, but they must exist.
         redirect = PIPE if sys.executable.endswith('pythonw.exe') else None
 
         if independent:
             proc = Popen(['start', '/b'] + arguments, shell=True,
                          stdout=redirect, stderr=redirect, stdin=redirect)
         else:
             from _subprocess import DuplicateHandle, GetCurrentProcess, \
                 DUPLICATE_SAME_ACCESS
             pid = GetCurrentProcess()
             handle = DuplicateHandle(pid, pid, pid, 0, 
                                      True, # Inheritable by new processes.
                                      DUPLICATE_SAME_ACCESS)
             proc = Popen(arguments + ['--parent', str(int(handle))],
                          stdout=redirect, stderr=redirect, stdin=redirect)
 
         # Clean up pipes created to work around Popen bug.
         if redirect is not None:
             proc.stdout.close()
             proc.stderr.close()
             proc.stdin.close()
 
     else:
         if independent:
             proc = Popen(arguments, preexec_fn=lambda: os.setsid())
         else:
             proc = Popen(arguments + ['--parent'])
 
     return proc, xrep_port, pub_port, req_port, hb_port

IPython/zmq/ipkernel.py

@@ -1,586 +1,612 b''
 #!/usr/bin/env python
 """A simple interactive kernel that talks to a frontend over 0MQ.
 
 Things to do:
 
 * Implement `set_parent` logic. Right before doing exec, the Kernel should
   call set_parent on all the PUB objects with the message about to be executed.
 * Implement random port and security key logic.
 * Implement control messages.
 * Implement event loop and poll version.
 """
 
 #-----------------------------------------------------------------------------
 # Imports
 #-----------------------------------------------------------------------------
 from __future__ import print_function
 
 # Standard library imports.
 import __builtin__
 import atexit
 import sys
 import time
 import traceback
 
 # System library imports.
 import zmq
 
 # Local imports.
 from IPython.config.configurable import Configurable
 from IPython.utils import io
 from IPython.utils.jsonutil import json_clean
 from IPython.lib import pylabtools
 from IPython.utils.traitlets import Instance, Float
 from entry_point import (base_launch_kernel, make_argument_parser, make_kernel,
                          start_kernel)
 from iostream import OutStream
 from session import Session, Message
 from zmqshell import ZMQInteractiveShell
 
 #-----------------------------------------------------------------------------
 # Main kernel class
 #-----------------------------------------------------------------------------
 
 class Kernel(Configurable):
 
     #---------------------------------------------------------------------------
     # Kernel interface
     #---------------------------------------------------------------------------
 
     shell = Instance('IPython.core.interactiveshell.InteractiveShellABC')
     session = Instance(Session)
     reply_socket = Instance('zmq.Socket')
     pub_socket = Instance('zmq.Socket')
     req_socket = Instance('zmq.Socket')
 
     # Private interface
 
     # Time to sleep after flushing the stdout/err buffers in each execute
     # cycle.  While this introduces a hard limit on the minimal latency of the
     # execute cycle, it helps prevent output synchronization problems for
     # clients.
     # Units are in seconds.  The minimum zmq latency on local host is probably
     # ~150 microseconds, set this to 500us for now.  We may need to increase it
     # a little if it's not enough after more interactive testing.
     _execute_sleep = Float(0.0005, config=True)
 
     # Frequency of the kernel's event loop.
     # Units are in seconds, kernel subclasses for GUI toolkits may need to
     # adapt to milliseconds.
     _poll_interval = Float(0.05, config=True)
 
     # If the shutdown was requested over the network, we leave here the
     # necessary reply message so it can be sent by our registered atexit
     # handler.  This ensures that the reply is only sent to clients truly at
     # the end of our shutdown process (which happens after the underlying
     # IPython shell's own shutdown).
     _shutdown_message = None
+
+    # This is a dict of port number that the kernel is listening on. It is set
+    # by record_ports and used by connect_request.
+    _recorded_ports = None
     
     def __init__(self, **kwargs):
         super(Kernel, self).__init__(**kwargs)
 
         # Before we even start up the shell, register *first* our exit handlers
         # so they come before the shell's
         atexit.register(self._at_shutdown)
 
         # Initialize the InteractiveShell subclass
         self.shell = ZMQInteractiveShell.instance()
         self.shell.displayhook.session = self.session
         self.shell.displayhook.pub_socket = self.pub_socket
 
         # TMP - hack while developing
         self.shell._reply_content = None
 
         # Build dict of handlers for message types
         msg_types = [ 'execute_request', 'complete_request', 
                       'object_info_request', 'history_request',
                       'shutdown_request']
         self.handlers = {}
         for msg_type in msg_types:
             self.handlers[msg_type] = getattr(self, msg_type)
 
     def do_one_iteration(self):
         """Do one iteration of the kernel's evaluation loop.
         """
         try:
             ident = self.reply_socket.recv(zmq.NOBLOCK)
         except zmq.ZMQError, e:
             if e.errno == zmq.EAGAIN:
                 return
             else:
                 raise
         # FIXME: Bug in pyzmq/zmq?
         # assert self.reply_socket.rcvmore(), "Missing message part."
         msg = self.reply_socket.recv_json()
         
         # Print some info about this message and leave a '--->' marker, so it's
         # easier to trace visually the message chain when debugging.  Each
         # handler prints its message at the end.
         # Eventually we'll move these from stdout to a logger.
         io.raw_print('\n*** MESSAGE TYPE:', msg['msg_type'], '***')
         io.raw_print('   Content: ', msg['content'],
                      '\n   --->\n   ', sep='', end='')
 
         # Find and call actual handler for message
         handler = self.handlers.get(msg['msg_type'], None)
         if handler is None:
             io.raw_print_err("UNKNOWN MESSAGE TYPE:", msg)
         else:
             handler(ident, msg)
             
         # Check whether we should exit, in case the incoming message set the
         # exit flag on
         if self.shell.exit_now:
             io.raw_print('\nExiting IPython kernel...')
             # We do a normal, clean exit, which allows any actions registered
             # via atexit (such as history saving) to take place.
             sys.exit(0)
 
 
     def start(self):
         """ Start the kernel main loop.
         """
         while True:
             time.sleep(self._poll_interval)
             self.do_one_iteration()
-        
+
+    def record_ports(self, xrep_port, pub_port, req_port, hb_port):
+        """Record the ports that this kernel is using.
+
+        The creator of the Kernel instance must call this methods if they
+        want the :meth:`connect_request` method to return the port numbers.
+        """
+        self._recorded_ports = {
+            'xrep_port' : xreq_port,
+            'pub_port' : pub_port,
+            'req_port' : req_port,
+            'hb_port' : hb_port
+        }
+
     #---------------------------------------------------------------------------
     # Kernel request handlers
     #---------------------------------------------------------------------------
 
     def _publish_pyin(self, code, parent):
         """Publish the code request on the pyin stream."""
 
         pyin_msg = self.session.msg(u'pyin',{u'code':code}, parent=parent)
         self.pub_socket.send_json(pyin_msg)
 
     def execute_request(self, ident, parent):
         try:
             content = parent[u'content']
             code = content[u'code']
             silent = content[u'silent'] 
         except:
             io.raw_print_err("Got bad msg: ")
             io.raw_print_err(Message(parent))
             return
 
         shell = self.shell # we'll need this a lot here
 
         # Replace raw_input. Note that is not sufficient to replace 
         # raw_input in the user namespace.
         raw_input = lambda prompt='': self._raw_input(prompt, ident, parent)
         __builtin__.raw_input = raw_input
 
         # Set the parent message of the display hook and out streams.
         shell.displayhook.set_parent(parent)
         sys.stdout.set_parent(parent)
         sys.stderr.set_parent(parent)
 
         # Re-broadcast our input for the benefit of listening clients, and
         # start computing output
         if not silent:
             self._publish_pyin(code, parent)
 
         reply_content = {}
         try:
             if silent:
                 # runcode uses 'exec' mode, so no displayhook will fire, and it
                 # doesn't call logging or history manipulations.  Print
                 # statements in that code will obviously still execute.
                 shell.runcode(code)
             else:
                 # FIXME: runlines calls the exception handler itself.
                 shell._reply_content = None
 
                 # For now leave this here until we're sure we can stop using it
                 #shell.runlines(code)
 
                 # Experimental: cell mode!  Test more before turning into
                 # default and removing the hacks around runlines.
                 shell.run_cell(code)
         except:
             status = u'error'
             # FIXME: this code right now isn't being used yet by default,
             # because the runlines() call above directly fires off exception
             # reporting.  This code, therefore, is only active in the scenario
             # where runlines itself has an unhandled exception.  We need to
             # uniformize this, for all exception construction to come from a
             # single location in the codbase.
             etype, evalue, tb = sys.exc_info()
             tb_list = traceback.format_exception(etype, evalue, tb)
             reply_content.update(shell._showtraceback(etype, evalue, tb_list))
         else:
             status = u'ok'
 
         reply_content[u'status'] = status
         # Compute the execution counter so clients can display prompts
         reply_content['execution_count'] = shell.displayhook.prompt_count
 
         # FIXME - fish exception info out of shell, possibly left there by
         # runlines.  We'll need to clean up this logic later.
         if shell._reply_content is not None:
             reply_content.update(shell._reply_content)
 
         # At this point, we can tell whether the main code execution succeeded
         # or not.  If it did, we proceed to evaluate user_variables/expressions
         if reply_content['status'] == 'ok':
             reply_content[u'user_variables'] = \
                          shell.get_user_variables(content[u'user_variables'])
             reply_content[u'user_expressions'] = \
                          shell.eval_expressions(content[u'user_expressions'])
         else:
             # If there was an error, don't even try to compute variables or
             # expressions
             reply_content[u'user_variables'] = {}
             reply_content[u'user_expressions'] = {}
 
         # Payloads should be retrieved regardless of outcome, so we can both
         # recover partial output (that could have been generated early in a
         # block, before an error) and clear the payload system always.
         reply_content[u'payload'] = shell.payload_manager.read_payload()
         # Be agressive about clearing the payload because we don't want
         # it to sit in memory until the next execute_request comes in.
         shell.payload_manager.clear_payload()
 
         # Send the reply.
         reply_msg = self.session.msg(u'execute_reply', reply_content, parent)
         io.raw_print(reply_msg)
 
         # Flush output before sending the reply.
         sys.stdout.flush()
         sys.stderr.flush()
         # FIXME: on rare occasions, the flush doesn't seem to make it to the
         # clients... This seems to mitigate the problem, but we definitely need
         # to better understand what's going on.
         if self._execute_sleep:
             time.sleep(self._execute_sleep)
         
         self.reply_socket.send(ident, zmq.SNDMORE)
         self.reply_socket.send_json(reply_msg)
         if reply_msg['content']['status'] == u'error':
             self._abort_queue()
 
     def complete_request(self, ident, parent):
         txt, matches = self._complete(parent)
         matches = {'matches' : matches,
                    'matched_text' : txt,
                    'status' : 'ok'}
         completion_msg = self.session.send(self.reply_socket, 'complete_reply',
                                            matches, parent, ident)
         io.raw_print(completion_msg)
 
     def object_info_request(self, ident, parent):
         object_info = self.shell.object_inspect(parent['content']['oname'])
         # Before we send this object over, we turn it into a dict and we scrub
         # it for JSON usage
         oinfo = json_clean(object_info._asdict())
         msg = self.session.send(self.reply_socket, 'object_info_reply',
                                 oinfo, parent, ident)
         io.raw_print(msg)
 
     def history_request(self, ident, parent):
         output = parent['content']['output']
         index = parent['content']['index']
         raw = parent['content']['raw']
         hist = self.shell.get_history(index=index, raw=raw, output=output)
         content = {'history' : hist}
         msg = self.session.send(self.reply_socket, 'history_reply',
                                 content, parent, ident)
         io.raw_print(msg)
-        
+
+    def connect_request(self, ident, parent):
+        if self._recorded_ports is not None:
+            content = self._recorded_ports.copy()
+        else:
+            content = {}
+        msg = self.session.send(self.reply_socket, 'connect_reply',
+                                content, parent, ident)
+        io.raw_print(msg)
+
     def shutdown_request(self, ident, parent):
         self.shell.exit_now = True
         self._shutdown_message = self.session.msg(u'shutdown_reply', {}, parent)
         sys.exit(0)
-        
+
     #---------------------------------------------------------------------------
     # Protected interface
     #---------------------------------------------------------------------------
 
     def _abort_queue(self):
         while True:
             try:
                 ident = self.reply_socket.recv(zmq.NOBLOCK)
             except zmq.ZMQError, e:
                 if e.errno == zmq.EAGAIN:
                     break
             else:
                 assert self.reply_socket.rcvmore(), \
                        "Unexpected missing message part."
                 msg = self.reply_socket.recv_json()
             io.raw_print("Aborting:\n", Message(msg))
             msg_type = msg['msg_type']
             reply_type = msg_type.split('_')[0] + '_reply'
             reply_msg = self.session.msg(reply_type, {'status' : 'aborted'}, msg)
             io.raw_print(reply_msg)
             self.reply_socket.send(ident,zmq.SNDMORE)
             self.reply_socket.send_json(reply_msg)
             # We need to wait a bit for requests to come in. This can probably
             # be set shorter for true asynchronous clients.
             time.sleep(0.1)
 
     def _raw_input(self, prompt, ident, parent):
         # Flush output before making the request.
         sys.stderr.flush()
         sys.stdout.flush()
 
         # Send the input request.
         content = dict(prompt=prompt)
         msg = self.session.msg(u'input_request', content, parent)
         self.req_socket.send_json(msg)
 
         # Await a response.
         reply = self.req_socket.recv_json()
         try:
             value = reply['content']['value']
         except:
             io.raw_print_err("Got bad raw_input reply: ")
             io.raw_print_err(Message(parent))
             value = ''
         return value
     
     def _complete(self, msg):
         c = msg['content']
         try:
             cpos = int(c['cursor_pos'])
         except:
             # If we don't get something that we can convert to an integer, at
             # least attempt the completion guessing the cursor is at the end of
             # the text, if there's any, and otherwise of the line
             cpos = len(c['text'])
             if cpos==0:
                 cpos = len(c['line'])
         return self.shell.complete(c['text'], c['line'], cpos)
 
     def _object_info(self, context):
         symbol, leftover = self._symbol_from_context(context)
         if symbol is not None and not leftover:
             doc = getattr(symbol, '__doc__', '')
         else:
             doc = ''
         object_info = dict(docstring = doc)
         return object_info
 
     def _symbol_from_context(self, context):
         if not context:
             return None, context
 
         base_symbol_string = context[0]
         symbol = self.shell.user_ns.get(base_symbol_string, None)
         if symbol is None:
             symbol = __builtin__.__dict__.get(base_symbol_string, None)
         if symbol is None:
             return None, context
 
         context = context[1:]
         for i, name in enumerate(context):
             new_symbol = getattr(symbol, name, None)
             if new_symbol is None:
                 return symbol, context[i:]
             else:
                 symbol = new_symbol
 
         return symbol, []
 
     def _at_shutdown(self):
         """Actions taken at shutdown by the kernel, called by python's atexit.
         """
         # io.rprint("Kernel at_shutdown") # dbg
         if self._shutdown_message is not None:
             self.reply_socket.send_json(self._shutdown_message)
             io.raw_print(self._shutdown_message)
             # A very short sleep to give zmq time to flush its message buffers
             # before Python truly shuts down.
             time.sleep(0.01)
 
 
 class QtKernel(Kernel):
     """A Kernel subclass with Qt support."""
 
     def start(self):
         """Start a kernel with QtPy4 event loop integration."""
 
         from PyQt4 import QtCore
         from IPython.lib.guisupport import get_app_qt4, start_event_loop_qt4
 
         self.app = get_app_qt4([" "])
         self.app.setQuitOnLastWindowClosed(False)
         self.timer = QtCore.QTimer()
         self.timer.timeout.connect(self.do_one_iteration)
         # Units for the timer are in milliseconds
         self.timer.start(1000*self._poll_interval)
         start_event_loop_qt4(self.app)
 
 
 class WxKernel(Kernel):
     """A Kernel subclass with Wx support."""
 
     def start(self):
         """Start a kernel with wx event loop support."""
 
         import wx
         from IPython.lib.guisupport import start_event_loop_wx
 
         doi = self.do_one_iteration
          # Wx uses milliseconds
         poll_interval = int(1000*self._poll_interval)
 
         # We have to put the wx.Timer in a wx.Frame for it to fire properly.
         # We make the Frame hidden when we create it in the main app below.
         class TimerFrame(wx.Frame):
             def __init__(self, func):
                 wx.Frame.__init__(self, None, -1)
                 self.timer = wx.Timer(self)
                 # Units for the timer are in milliseconds
                 self.timer.Start(poll_interval)
                 self.Bind(wx.EVT_TIMER, self.on_timer)
                 self.func = func
 
             def on_timer(self, event):
                 self.func()
 
         # We need a custom wx.App to create our Frame subclass that has the
         # wx.Timer to drive the ZMQ event loop.
         class IPWxApp(wx.App):
             def OnInit(self):
                 self.frame = TimerFrame(doi)
                 self.frame.Show(False)
                 return True
 
         # The redirect=False here makes sure that wx doesn't replace
         # sys.stdout/stderr with its own classes.
         self.app = IPWxApp(redirect=False)
         start_event_loop_wx(self.app)
 
 
 class TkKernel(Kernel):
     """A Kernel subclass with Tk support."""
 
     def start(self):
         """Start a Tk enabled event loop."""
 
         import Tkinter
         doi = self.do_one_iteration
         # Tk uses milliseconds
         poll_interval = int(1000*self._poll_interval)
         # For Tkinter, we create a Tk object and call its withdraw method.
         class Timer(object):
             def __init__(self, func):
                 self.app = Tkinter.Tk()
                 self.app.withdraw()
                 self.func = func
                 
             def on_timer(self):
                 self.func()
                 self.app.after(poll_interval, self.on_timer)
                 
             def start(self):
                 self.on_timer()  # Call it once to get things going.
                 self.app.mainloop()
 
         self.timer = Timer(doi)
         self.timer.start()
 
 
 class GTKKernel(Kernel):
     """A Kernel subclass with GTK support."""
     
     def start(self):
         """Start the kernel, coordinating with the GTK event loop"""
         from .gui.gtkembed import GTKEmbed
         
         gtk_kernel = GTKEmbed(self)
         gtk_kernel.start()
 
 
 #-----------------------------------------------------------------------------
 # Kernel main and launch functions
 #-----------------------------------------------------------------------------
 
 def launch_kernel(xrep_port=0, pub_port=0, req_port=0, hb_port=0,
                   independent=False, pylab=False):
     """Launches a localhost kernel, binding to the specified ports.
 
     Parameters
     ----------
     xrep_port : int, optional
         The port to use for XREP channel.
 
     pub_port : int, optional
         The port to use for the SUB channel.
 
     req_port : int, optional
         The port to use for the REQ (raw input) channel.
 
     hb_port : int, optional
         The port to use for the hearbeat REP channel.
 
     independent : bool, optional (default False) 
         If set, the kernel process is guaranteed to survive if this process
         dies. If not set, an effort is made to ensure that the kernel is killed
         when this process dies. Note that in this case it is still good practice
         to kill kernels manually before exiting.
 
     pylab : bool or string, optional (default False)
         If not False, the kernel will be launched with pylab enabled. If a
         string is passed, matplotlib will use the specified backend. Otherwise,
         matplotlib's default backend will be used.
 
     Returns
     -------
     A tuple of form:
         (kernel_process, xrep_port, pub_port, req_port)
     where kernel_process is a Popen object and the ports are integers.
     """
     extra_arguments = []
     if pylab:
         extra_arguments.append('--pylab')
         if isinstance(pylab, basestring):
             extra_arguments.append(pylab)
     return base_launch_kernel('from IPython.zmq.ipkernel import main; main()',
                               xrep_port, pub_port, req_port, hb_port, 
                               independent, extra_arguments)
 
 
 def main():
     """ The IPython kernel main entry point.
     """
     parser = make_argument_parser()
     parser.add_argument('--pylab', type=str, metavar='GUI', nargs='?', 
                         const='auto', help = \
 "Pre-load matplotlib and numpy for interactive use. If GUI is not \
 given, the GUI backend is matplotlib's, otherwise use one of: \
 ['tk', 'gtk', 'qt', 'wx', 'inline'].")
     namespace = parser.parse_args()
 
     kernel_class = Kernel
 
     kernel_classes = {
         'qt' : QtKernel,
         'qt4': QtKernel,
         'inline': Kernel,
         'wx' : WxKernel,
         'tk' : TkKernel,
         'gtk': GTKKernel,
     }
     if namespace.pylab:
         if namespace.pylab == 'auto':
             gui, backend = pylabtools.find_gui_and_backend()
         else:
             gui, backend = pylabtools.find_gui_and_backend(namespace.pylab)
         kernel_class = kernel_classes.get(gui)
         if kernel_class is None:
             raise ValueError('GUI is not supported: %r' % gui)
         pylabtools.activate_matplotlib(backend)
 
     kernel = make_kernel(namespace, kernel_class, OutStream)
 
     if namespace.pylab:
         pylabtools.import_pylab(kernel.shell.user_ns, backend,
                                 shell=kernel.shell)
 
     start_kernel(namespace, kernel)
 
 
 if __name__ == '__main__':
     main()

docs/source/development/messaging.txt

@@ -1,758 +1,782 b''
 .. _messaging:
 
 ======================
  Messaging in IPython
 ======================
 
 
 Introduction
 ============
 
 This document explains the basic communications design and messaging
 specification for how the various IPython objects interact over a network
 transport.  The current implementation uses the ZeroMQ_ library for messaging
 within and between hosts.
 
 .. Note::
 
    This document should be considered the authoritative description of the
    IPython messaging protocol, and all developers are strongly encouraged to
    keep it updated as the implementation evolves, so that we have a single
    common reference for all protocol details.
    
 The basic design is explained in the following diagram:
 
 .. image:: frontend-kernel.png
    :width: 450px
    :alt: IPython kernel/frontend messaging architecture.
    :align: center
    :target: ../_images/frontend-kernel.png
 
 A single kernel can be simultaneously connected to one or more frontends.  The
 kernel has three sockets that serve the following functions:
 
 1. REQ: this socket is connected to a *single* frontend at a time, and it allows
    the kernel to request input from a frontend when :func:`raw_input` is called.
    The frontend holding the matching REP socket acts as a 'virtual keyboard'
    for the kernel while this communication is happening (illustrated in the
    figure by the black outline around the central keyboard).  In practice,
    frontends may display such kernel requests using a special input widget or
    otherwise indicating that the user is to type input for the kernel instead
    of normal commands in the frontend.
 
 2. XREP: this single sockets allows multiple incoming connections from
    frontends, and this is the socket where requests for code execution, object
    information, prompts, etc. are made to the kernel by any frontend.  The
    communication on this socket is a sequence of request/reply actions from
    each frontend and the kernel.
 
 3. PUB: this socket is the 'broadcast channel' where the kernel publishes all
    side effects (stdout, stderr, etc.) as well as the requests coming from any
    client over the XREP socket and its own requests on the REP socket.  There
    are a number of actions in Python which generate side effects: :func:`print`
    writes to ``sys.stdout``, errors generate tracebacks, etc.  Additionally, in
    a multi-client scenario, we want all frontends to be able to know what each
    other has sent to the kernel (this can be useful in collaborative scenarios,
    for example).  This socket allows both side effects and the information
    about communications taking place with one client over the XREQ/XREP channel
    to be made available to all clients in a uniform manner.
 
    All messages are tagged with enough information (details below) for clients
    to know which messages come from their own interaction with the kernel and
    which ones are from other clients, so they can display each type
    appropriately.
 
 The actual format of the messages allowed on each of these channels is
 specified below.  Messages are dicts of dicts with string keys and values that
 are reasonably representable in JSON.  Our current implementation uses JSON
 explicitly as its message format, but this shouldn't be considered a permanent
 feature.  As we've discovered that JSON has non-trivial performance issues due
 to excessive copying, we may in the future move to a pure pickle-based raw
 message format.  However, it should be possible to easily convert from the raw
 objects to JSON, since we may have non-python clients (e.g. a web frontend).
 As long as it's easy to make a JSON version of the objects that is a faithful
 representation of all the data, we can communicate with such clients.
 
 .. Note::
 
    Not all of these have yet been fully fleshed out, but the key ones are, see
    kernel and frontend files for actual implementation details.
 
    
 Python functional API
 =====================
 
 As messages are dicts, they map naturally to a ``func(**kw)`` call form.  We
 should develop, at a few key points, functional forms of all the requests that
 take arguments in this manner and automatically construct the necessary dict
 for sending.
 
 
 General Message Format
 ======================
 
 All messages send or received by any IPython process should have the following
 generic structure::
     
     {
       # The message header contains a pair of unique identifiers for the
       # originating session and the actual message id, in addition to the
       # username for the process that generated the message.  This is useful in
       # collaborative settings where multiple users may be interacting with the
       # same kernel simultaneously, so that frontends can label the various
       # messages in a meaningful way.
       'header' : { 'msg_id' : uuid,
                    'username' : str,
            'session' : uuid
          },
 
       # In a chain of messages, the header from the parent is copied so that
       # clients can track where messages come from.
       'parent_header' : dict,
 
       # All recognized message type strings are listed below.
       'msg_type' : str,
 
       # The actual content of the message must be a dict, whose structure
       # depends on the message type.x
       'content' : dict,
     }
 
 For each message type, the actual content will differ and all existing message
 types are specified in what follows of this document.
 
 
 Messages on the XREP/XREQ socket
 ================================
 
 .. _execute:
 
 Execute
 -------
 
 This message type is used by frontends to ask the kernel to execute code on
 behalf of the user, in a namespace reserved to the user's variables (and thus
 separate from the kernel's own internal code and variables).
 
 Message type: ``execute_request``::
 
     content = {
         # Source code to be executed by the kernel, one or more lines.
     'code' : str,
 
     # A boolean flag which, if True, signals the kernel to execute this
     # code as quietly as possible.  This means that the kernel will compile
     # the code witIPython/core/tests/h 'exec' instead of 'single' (so
     # sys.displayhook will not fire), and will *not*:
     #   - broadcast exceptions on the PUB socket
     #   - do any logging
     #   - populate any history
     #
     # The default is False.
     'silent' : bool,
 
     # A list of variable names from the user's namespace to be retrieved.  What
     # returns is a JSON string of the variable's repr(), not a python object.
     'user_variables' : list,
 
     # Similarly, a dict mapping names to expressions to be evaluated in the
     # user's dict.
     'user_expressions' : dict,
     }
 
 The ``code`` field contains a single string, but this may be a multiline
 string.  The kernel is responsible for splitting this into possibly more than
 one block and deciding whether to compile these in 'single' or 'exec' mode.
 We're still sorting out this policy.  The current inputsplitter is capable of
 splitting the input for blocks that can all be run as 'single', but in the long
 run it may prove cleaner to only use 'single' mode for truly single-line
 inputs, and run all multiline input in 'exec' mode.  This would preserve the
 natural behavior of single-line inputs while allowing long cells to behave more
 likea a script.  This design will be refined as we complete the implementation.
 
 The ``user_`` fields deserve a detailed explanation.  In the past, IPython had
 the notion of a prompt string that allowed arbitrary code to be evaluated, and
 this was put to good use by many in creating prompts that displayed system
 status, path information, and even more esoteric uses like remote instrument
 status aqcuired over the network.  But now that IPython has a clean separation
 between the kernel and the clients, the notion of embedding 'prompt'
 maninpulations into the kernel itself feels awkward.  Prompts should be a
 frontend-side feature, and it should be even possible for different frontends
 to display different prompts while interacting with the same kernel.
 
 We have therefore abandoned the idea of a 'prompt string' to be evaluated by
 the kernel, and instead provide the ability to retrieve from the user's
 namespace information after the execution of the main ``code``, with two fields
 of the execution request:
 
 - ``user_variables``: If only variables from the user's namespace are needed, a
   list of variable names can be passed and a dict with these names as keys and
   their :func:`repr()` as values will be returned.
 
 - ``user_expressions``: For more complex expressions that require function
   evaluations, a dict can be provided with string keys and arbitrary python
   expressions as values.  The return message will contain also a dict with the
   same keys and the :func:`repr()` of the evaluated expressions as value.
 
 With this information, frontends can display any status information they wish
 in the form that best suits each frontend (a status line, a popup, inline for a
 terminal, etc).
 
 .. Note::
 
    In order to obtain the current execution counter for the purposes of
    displaying input prompts, frontends simply make an execution request with an
    empty code string and ``silent=True``.
 
 Execution semantics
     Upon completion of the execution request, the kernel *always* sends a
     reply, with a status code indicating what happened and additional data
     depending on the outcome.
 
     The ``code`` field is executed first, and then the ``user_variables`` and
     ``user_expressions`` are computed.  This ensures that any error in the
     latter don't harm the main code execution.
 
     Any error in retrieving the ``user_variables`` or evaluating the
     ``user_expressions`` will result in a simple error message in the return
     fields of the form::
 
        [ERROR] ExceptionType: Exception message
 
     The user can simply send the same variable name or expression for
     evaluation to see a regular traceback.
 
 Execution counter (old prompt number)
     The kernel has a single, monotonically increasing counter of all execution
     requests that are made with ``silent=False``.  This counter is used to
     populate the ``In[n]``, ``Out[n]`` and ``_n`` variables, so clients will
     likely want to display it in some form to the user, which will typically
     (but not necessarily) be done in the prompts.  The value of this counter
     will be returned as the ``execution_count`` field of all ``execute_reply```
     messages.
 
 Message type: ``execute_reply``::
 
     content = {
       # One of: 'ok' OR 'error' OR 'abort'
       'status' : str,
 
       # The global kernel counter that increases by one with each non-silent
       # executed request.  This will typically be used by clients to display
       # prompt numbers to the user.  If the request was a silent one, this will
       # be the current value of the counter in the kernel.
       'execution_count' : int,
     }
 
 When status is 'ok', the following extra fields are present::
 
     {
       # The execution payload is a dict with string keys that may have been
       # produced by the code being executed.  It is retrieved by the kernel at
       # the end of the execution and sent back to the front end, which can take
       # action on it as needed.  See main text for further details.
       'payload' : dict,
 
       # Results for the user_variables and user_expressions.
       'user_variables' : dict,
       'user_expressions' : dict,
 
       # The kernel will often transform the input provided to it.  If the
       # '---->' transform had been applied, this is filled, otherwise it's the
       # empty string.  So transformations like magics don't appear here, only
       # autocall ones.
       'transformed_code' : str,
       }
 
 .. admonition:: Execution payloads
     
    The notion of an 'execution payload' is different from a return value of a
    given set of code, which normally is just displayed on the pyout stream
    through the PUB socket.  The idea of a payload is to allow special types of
    code, typically magics, to populate a data container in the IPython kernel
    that will be shipped back to the caller via this channel.  The kernel will
    have an API for this, probably something along the lines of::
 
        ip.exec_payload_add(key, value)
 
    though this API is still in the design stages.  The data returned in this
    payload will allow frontends to present special views of what just happened.
 
    
 When status is 'error', the following extra fields are present::
 
     {
       'exc_name' : str,   # Exception name, as a string
       'exc_value' : str,  # Exception value, as a string
 
       # The traceback will contain a list of frames, represented each as a
       # string.  For now we'll stick to the existing design of ultraTB, which
       # controls exception level of detail statefully.  But eventually we'll
       # want to grow into a model where more information is collected and
       # packed into the traceback object, with clients deciding how little or
       # how much of it to unpack.  But for now, let's start with a simple list
       # of strings, since that requires only minimal changes to ultratb as
       # written.
       'traceback' : list,
     }
 
 
 When status is 'abort', there are for now no additional data fields.  This
 happens when the kernel was interrupted by a signal.
 
 Kernel attribute access
 -----------------------
 
 While this protocol does not specify full RPC access to arbitrary methods of
 the kernel object, the kernel does allow read (and in some cases write) access
 to certain attributes.
 
 The policy for which attributes can be read is: any attribute of the kernel, or
 its sub-objects, that belongs to a :class:`Configurable` object and has been
 declared at the class-level with Traits validation, is in principle accessible
 as long as its name does not begin with a leading underscore.  The attribute
 itself will have metadata indicating whether it allows remote read and/or write
 access.  The message spec follows for attribute read and write requests.
 
 Message type: ``getattr_request``::
 
     content = {
         # The (possibly dotted) name of the attribute
 	'name' : str,
     }
 
 When a ``getattr_request`` fails, there are two possible error types:
 
 - AttributeError: this type of error was raised when trying to access the
   given name by the kernel itself.  This means that the attribute likely
   doesn't exist.
 
 - AccessError: the attribute exists but its value is not readable remotely.
 
 
 Message type: ``getattr_reply``::
 
     content = {
         # One of ['ok', 'AttributeError', 'AccessError'].
         'status' : str,
 	# If status is 'ok', a JSON object.
 	'value' : object,
     }
 
 Message type: ``setattr_request``::
 
     content = {
         # The (possibly dotted) name of the attribute
 	'name' : str,
 	
 	# A JSON-encoded object, that will be validated by the Traits
 	# information in the kernel
 	'value' : object,
     }
 
 When a ``setattr_request`` fails, there are also two possible error types with
 similar meanings  as those of the ``getattr_request`` case, but for writing.
     
 Message type: ``setattr_reply``::
 
     content = {
         # One of ['ok', 'AttributeError', 'AccessError'].
         'status' : str,
     }
 
 
 Object information
 ------------------
 
 One of IPython's most used capabilities is the introspection of Python objects
 in the user's namespace, typically invoked via the ``?`` and ``??`` characters
 (which in reality are shorthands for the ``%pinfo`` magic).  This is used often
 enough that it warrants an explicit message type, especially because frontends
 may want to get object information in response to user keystrokes (like Tab or
 F1) besides from the user explicitly typing code like ``x??``.
 
 Message type: ``object_info_request``::
 
     content = {
         # The (possibly dotted) name of the object to be searched in all
 	# relevant namespaces
         'name' : str,
 
     	# The level of detail desired.  The default (0) is equivalent to typing
 	# 'x?' at the prompt, 1 is equivalent to 'x??'.
 	'detail_level' : int,
     }
 
 The returned information will be a dictionary with keys very similar to the
 field names that IPython prints at the terminal.
     
 Message type: ``object_info_reply``::
 
     content = {
     # Boolean flag indicating whether the named object was found or not.  If
     # it's false, all other fields will be empty.
     'found' : bool,
     
     # Flags for magics and system aliases
     'ismagic' : bool,
     'isalias' : bool,
 
     # The name of the namespace where the object was found ('builtin',
     # 'magics', 'alias', 'interactive', etc.)
     'namespace' : str,
 
     # The type name will be type.__name__ for normal Python objects, but it
     # can also be a string like 'Magic function' or 'System alias'
     'type_name' : str,
 
     'string_form' : str,
 
     # For objects with a __class__ attribute this will be set
     'base_class' : str,
 
     # For objects with a __len__ attribute this will be set
     'length' : int,
 
     # If the object is a function, class or method whose file we can find,
     # we give its full path
     'file' : str,
 
     # For pure Python callable objects, we can reconstruct the object
     # definition line which provides its call signature.  For convenience this
     # is returned as a single 'definition' field, but below the raw parts that
     # compose it are also returned as the argspec field.
     'definition' : str,
 
     # The individual parts that together form the definition string.  Clients
     # with rich display capabilities may use this to provide a richer and more
     # precise representation of the definition line (e.g. by highlighting
     # arguments based on the user's cursor position).  For non-callable
     # objects, this field is empty.
     'argspec' : { # The names of all the arguments
                   args : list,
 		  # The name of the varargs (*args), if any
                   varargs : str,
 		  # The name of the varkw (**kw), if any
 		  varkw : str,
 		  # The values (as strings) of all default arguments.  Note
 		  # that these must be matched *in reverse* with the 'args'
 		  # list above, since the first positional args have no default
 		  # value at all.
 		  func_defaults : list,
 		  },
 
     # For instances, provide the constructor signature (the definition of
     # the __init__ method):
     'init_definition' : str,
     
     # Docstrings: for any object (function, method, module, package) with a
     # docstring, we show it.  But in addition, we may provide additional
     # docstrings.  For example, for instances we will show the constructor
     # and class docstrings as well, if available.
     'docstring' : str,
 
     # For instances, provide the constructor and class docstrings
     'init_docstring' : str,
     'class_docstring' : str,
     
     # If it's a callable object whose call method has a separate docstring and
     # definition line:
     'call_def' : str,
     'call_docstring' : str,
     
     # If detail_level was 1, we also try to find the source code that
     # defines the object, if possible.  The string 'None' will indicate
     # that no source was found.
     'source' : str,
     }
 '
     
 Complete
 --------
 
 Message type: ``complete_request``::
 
     content = {
         # The text to be completed, such as 'a.is'
     'text' : str,
 
     # The full line, such as 'print a.is'.  This allows completers to
     # make decisions that may require information about more than just the
     # current word.
     'line' : str,
 
     # The entire block of text where the line is.  This may be useful in the
     # case of multiline completions where more context may be needed.  Note: if
     # in practice this field proves unnecessary, remove it to lighten the
     # messages.
     
     'block' : str,
 
     # The position of the cursor where the user hit 'TAB' on the line.
     'cursor_pos' : int,
     }
 
 Message type: ``complete_reply``::
 
     content = {
         # The list of all matches to the completion request, such as
     # ['a.isalnum', 'a.isalpha'] for the above example.
     'matches' : list
     }
 
     
 History
 -------
 
 For clients to explicitly request history from a kernel.  The kernel has all
 the actual execution history stored in a single location, so clients can
 request it from the kernel when needed.
 
 Message type: ``history_request``::
 
     content = {
     
       # If True, also return output history in the resulting dict.
       'output' : bool,
 
       # If True, return the raw input history, else the transformed input.
       'raw' : bool,
 
       # This parameter can be one of: A number,  a pair of numbers, None
       # If not given, last 40 are returned.
       #  - number n: return the last n entries.
       #  - pair n1, n2: return entries in the range(n1, n2).
       #  - None: return all history
       'index' : n or (n1, n2) or None,
     }
 
 Message type: ``history_reply``::
 
     content = {
       # A dict with prompt numbers as keys and either (input, output) or input
       # as the value depending on whether output was True or False,
       # respectively.
       'history' : dict,
     }
 
 
+Connect
+-------
+
+When a client connects to the request/reply socket of the kernel, it can issue
+a connect request to get basic information about the kernel, such as the ports
+the other ZeroMQ sockets are listening on. This allows clients to only have
+to know about a single port (the XREQ/XREP channel) to connect to a kernel.
+
+Message type: ``connect_request``::
+
+    content = {
+    }
+
+Message type: ``connect_reply``::
+
+    content = {
+        'xrep_port' : int  # The port the XREP socket is listening on.
+        'pub_port' : int   # The port the PUB socket is listening on.
+        'req_port' : int   # The port the REQ socket is listening on.
+        'hb_port' : int    # The port the heartbeat socket is listening on.
+    }
+
+
+
 Kernel shutdown
 ---------------
 
 The clients can request the kernel to shut itself down; this is used in
 multiple cases:
 
 - when the user chooses to close the client application via a menu or window
   control.
 - when the user types 'exit' or 'quit' (or their uppercase magic equivalents).
 - when the user chooses a GUI method (like the 'Ctrl-C' shortcut in the
   IPythonQt client) to force a kernel restart to get a clean kernel without
   losing client-side state like history or inlined figures.
 
 The client sends a shutdown request to the kernel, and once it receives the
 reply message (which is otherwise empty), it can assume that the kernel has
 completed shutdown safely.
 
 Upon their own shutdown, client applications will typically execute a last
 minute sanity check and forcefully terminate any kernel that is still alive, to
 avoid leaving stray processes in the user's machine.
 
 For both shutdown request and reply, there is no actual content that needs to
 be sent, so the content dict is empty.
 
 Message type: ``shutdown_request``::
 
     content = {
     }
 
 Message type: ``shutdown_reply``::
 
     content = {
     }
 
 .. Note::
 
    When the clients detect a dead kernel thanks to inactivity on the heartbeat
    socket, they simply send a forceful process termination signal, since a dead
    process is unlikely to respond in any useful way to messages.
     
 
 Messages on the PUB/SUB socket
 ==============================
 
 Streams (stdout,  stderr, etc)
 ------------------------------
 
 Message type: ``stream``::
 
     content = {
         # The name of the stream is one of 'stdin', 'stdout', 'stderr'
     'name' : str,
     
     # The data is an arbitrary string to be written to that stream
     'data' : str,
     }
 
 When a kernel receives a raw_input call, it should also broadcast it on the pub
 socket with the names 'stdin' and 'stdin_reply'.  This will allow other clients
 to monitor/display kernel interactions and possibly replay them to their user
 or otherwise expose them.
 
 Python inputs
 -------------
 
 These messages are the re-broadcast of the ``execute_request``.
 
 Message type: ``pyin``::
 
     content = {
         # Source code to be executed, one or more lines
     'code' : str
     }
 
 Python outputs
 --------------
 
 When Python produces output from code that has been compiled in with the
 'single' flag to :func:`compile`, any expression that produces a value (such as
 ``1+1``) is passed to ``sys.displayhook``, which is a callable that can do with
 this value whatever it wants.  The default behavior of ``sys.displayhook`` in
 the Python interactive prompt is to print to ``sys.stdout`` the :func:`repr` of
 the value as long as it is not ``None`` (which isn't printed at all).  In our
 case, the kernel instantiates as ``sys.displayhook`` an object which has
 similar behavior, but which instead of printing to stdout, broadcasts these
 values as ``pyout`` messages for clients to display appropriately.
 
 Message type: ``pyout``::
 
     content = {
         # The data is typically the repr() of the object.
     'data' : str,
     
     # The counter for this execution is also provided so that clients can
     # display it, since IPython automatically creates variables called _N (for
     # prompt N).
     'execution_count' : int,
     }
     
 Python errors
 -------------
 
 When an error occurs during code execution
 
 Message type: ``pyerr``::
 
     content = {
        # Similar content to the execute_reply messages for the 'error' case,
        # except the 'status' field is omitted.
     }
 
 Kernel crashes
 --------------
 
 When the kernel has an unexpected exception, caught by the last-resort
 sys.excepthook, we should broadcast the crash handler's output before exiting.
 This will allow clients to notice that a kernel died, inform the user and
 propose further actions.
 
 Message type: ``crash``::
 
     content = {
        # Similarly to the 'error' case for execute_reply messages, this will
        # contain exc_name, exc_type and traceback fields.
 
        # An additional field with supplementary information such as where to
        # send the crash message
        'info' : str,
     }
 
 
 Future ideas
 ------------
     
 Other potential message types, currently unimplemented, listed below as ideas.
     
 Message type: ``file``::
 
     content = {
     'path' : 'cool.jpg',
     'mimetype' : str,
     'data' : str,
     }
 
     
 Messages on the REQ/REP socket
 ==============================
 
 This is a socket that goes in the opposite direction: from the kernel to a
 *single* frontend, and its purpose is to allow ``raw_input`` and similar
 operations that read from ``sys.stdin`` on the kernel to be fulfilled by the
 client.  For now we will keep these messages as simple as possible, since they
 basically only mean to convey the ``raw_input(prompt)`` call.
 
 Message type: ``input_request``::
 
     content = { 'prompt' : str }
 
 Message type: ``input_reply``::
 
     content = { 'value' : str }
     
 .. Note::
 
    We do not explicitly try to forward the raw ``sys.stdin`` object, because in
    practice the kernel should behave like an interactive program.  When a
    program is opened on the console, the keyboard effectively takes over the
    ``stdin`` file descriptor, and it can't be used for raw reading anymore.
    Since the IPython kernel effectively behaves like a console program (albeit
    one whose "keyboard" is actually living in a separate process and
    transported over the zmq connection), raw ``stdin`` isn't expected to be
    available.
 
    
 Heartbeat for kernels
 =====================
 
 Initially we had considered using messages like those above over ZMQ for a
 kernel 'heartbeat' (a way to detect quickly and reliably whether a kernel is
 alive at all, even if it may be busy executing user code).  But this has the
 problem that if the kernel is locked inside extension code, it wouldn't execute
 the python heartbeat code.  But it turns out that we can implement a basic
 heartbeat with pure ZMQ, without using any Python messaging at all.
 
 The monitor sends out a single zmq message (right now, it is a str of the
 monitor's lifetime in seconds), and gets the same message right back, prefixed
 with the zmq identity of the XREQ socket in the heartbeat process. This can be
 a uuid, or even a full message, but there doesn't seem to be a need for packing
 up a message when the sender and receiver are the exact same Python object.
 
 The model is this::
 
     monitor.send(str(self.lifetime)) # '1.2345678910'
 
 and the monitor receives some number of messages of the form::
 
     ['uuid-abcd-dead-beef', '1.2345678910']
 
 where the first part is the zmq.IDENTITY of the heart's XREQ on the engine, and
 the rest is the message sent by the monitor.  No Python code ever has any
 access to the message between the monitor's send, and the monitor's recv.
 
 
 ToDo
 ====
 
 Missing things include:
 
 * Important: finish thinking through the payload concept and API.
 
 * Important: ensure that we have a good solution for magics like %edit.  It's
   likely that with the payload concept we can build a full solution, but not
   100% clear yet.
 
 * Finishing the details of the heartbeat protocol.
 
 * Signal handling: specify what kind of information kernel should broadcast (or
   not) when it receives signals.
 
 .. include:: ../links.rst