fix celltoolbar layout on FF
Ok, bug was due to an extra empty div... This seem to lok ok on both FF and Chrome OS X.
Think of adding
$.getScript('/static/js/celltoolbarpresets/example.js')
to your custom.js to fully test.
Move kernel code into IPython.kernel
inprocess Kernel in kernel.inprocess
zmq Kernel in kernel.zmq
KernelManager stuff and ulities in top-level kernel
Main functional change: allow custom kernel Popen command
- [x] adds `KernelManager.kernel_cmd` configurable for launching a custom kernel
- [x] splits entry_point.base_launch_kernel into two steps: making the launch cmd and launching the subprocess
- [x] figure out where the entry_point functions belong, if it should be anywhere else
- [x] move IPython.zmq.kernelmanagerabc to IPython.kernel.kernelmanagerabc
- [x] move IPython.lib.kernel/IPython/zmq.entry_point to IPython.kernel.launcher / connect
- [x] move zmq.ipkernelapp.IPKernelApp to zmq.kernelapp (I'll look at merging the classes, and see if it makes
- [x] move IPython.zmq to IPython.kernel.zmq
- [x] move IPython.inprocess to IPython.kernel.inprocess
- [x] move embed_kernel from zmq.ipkernelapp to zmq.embed
- [x] move MultiKernelManager to IPython.kernel.multikernelmanager.
- [x] move IPython.zmq.blockingkernelmanager to IPython.kernel.blockingkernelmanager.
- [x] move IPython.zmq.kernelmanager to IPython.kernel.kernelmanager.
- [x] move IPython.ipkernel.Kernel to IPython.kernel.kernel.
- merged IPKernelApp into KernelApp, they are no longer separate classes
- embed_kernel moved to its own file
- ipkernel now only contains the Kernel class
- associated imports updated
future pyzmq compatibility
update base pyzmq version to 2.1.11
removes MockSocket to avoid compatibility issues with various versions of Python+PyZMQ in test_session.
Consolidate host IP detection in utils.localinterfaces
This PR replaces a number of hard-coded 127.0.0.1 references with
LOCALHOST, and consolidates the computation of LOCALHOST,
LOCAL_IPS, and a new PUBLIC_IPS in the localinterfaces module.
It's unclear to me when LOCALHOST would not be 127.0.0.1. I suppose
you could have another IP in the 127.0.0.0/8 block, or a IPv6 address.
It may also be possible to not have a loopback interface at all. In
that case it's possible that we need a LOOPBACK variable in
utils.localinterfaces which is a valid loopback interface or None, so
that consumers can differentiate between generic IPs pointing back to
the local host and the loopback interface.
