`jupyter-websocket-io` now returns, in addition to an IO function, a
kernel action subscriber. A client now sends messages to the
subscriber to interrupt or shutdown a kernel instead of doing so using
a `kernel` slot.
Also add the `jupyter-kernel-action` convenience function for
evaluating arbitrary code on a client's kernel.
Sending a shutdown request actually restarts a kernel behind a Jupyter
notebook, so shutdown using the kernel's method.
Disconnect the client after shutting down so that
`jupyter-connected-p` returns nil after shutdown.
This is to handle message relaying in `jupyter-widget-client`.
* jupyter-client.el (jupyter-send): Do it. Update doc.
* jupyter-widget-client.el (jupyter-widgets-on-message): Change
argument order of `jupyter-send` call.
Somehow this was not done until now. I had in my mind that shutting
down and interrupting a kernel was part of the responsibility of the
manager class. This is how it is done in the reference
jupyter/jupyter_client implementation, I think.
* jupyter-client.el (jupyter-shutdown-kernel)
(jupyter-interrupt-kernel): New functions.
* jupyter-repl.el
(jupyter-repl-restart-kernel): Use the `jupyter-shutdown-kernel`
method to restart a client's kernel.
* jupyter-client.el (jupyter-client-has-manager-p): Do it.
(initialize-instance)
* jupyter-repl.el
(jupyter-repl-kill-buffer-query-function)
* test/jupyter-test.el (jupyter-repl-client-predicates): Update all callers.
Remove `jupyter-channel-ioloop-comm.el`, `jupyter-comm-layer.el`, `jupyter-ioloop-comm.el`.
Remove the kcomm slot of a client, replace it with a kernel slot.
jupyter-server.el: Remove kernel communication related code.
Remove `jupyter-kernel-lifetime`.
* jupyter-kernel-manager.el (jupyter-kernel-lifetime): Do it. Update
all subclasses. All methods it defined no longer take a type. This
is in preparation of removing most of them altogether.
(jupyter-kernel-manager): Update doc.
* jupyter-kernel-process-manager.el
(jupyter-kernel-process): Update documentation.
(jupyter--kernel-died-process-sentinel): Remove type check.
* test/jupyter-test.el (jupyter-local-tcp-conn-info): Remove.
(jupyter-kernel-lifetime): Remove.
[conn] Have `jupyter-kernel-manager.el` re-direct to the new interface
* jupyter-kernel-manager.el
(jupyter-kernel-alive-p): Check that the kernel is
live, not an Emacs connection to it.
(jupyter-start-kernel)
[jupyter-kernel, jupyter-kernel-manager]: Use `jupyter-launch`.
(jupyter-shutdown-kernel) [jupyter-kernel-manager]: Use `jupyer-shutdown`.
(jupyter-kill-kernel) [jupyter-kernel]: Ditto. Remove a method
definition.
(jupyter-make-client): Use `jupyter-client`.
(jupyter-interrupt-kernel) [jupyter-kernel-manager]: Use `jupyer-interrupt`.
* jupyter-kernel-process-manager.el: Remove.
Don't add finalizer to cleanup process.
Cleanup is done in other ways, e.g. in
`jupyter--gc-kernel-processes`. Also it doesn't make sense to delete
a general kernel because the object that represents it in Emacs is no
longer accessible.
* jupyter-channel-ioloop-comm.el
(jupyter-channel-ioloop-comm): Remove it from the super-class list.
Add a `hb` slot to compensate.
(jupyter-hb-beating-p, jupyter-hb-pause)
(jupyter-hb-unpause): Relocated from...
* jupyter-comm-layer.el: ...here.
* jupyter-client.el (jupyter-hb-beating-p, jupyter-hb-pause)
(jupyter-hb-unpause): Check for a `hb` slot instead of it.
Previously it was hard to step through the code whenever messages were
coming in live from a kernel due to the asynchronous nature of
handling process output in Emacs.
