`avy-with` is a macro that might not be defined at compile time, but at the
same time we do not want to depend on `avy` so we have to ensure that we only
do byte compilation when first loading the function at run time.
See https://github.com/dzop/emacs-jupyter/issues/70#issuecomment-476940527
* jupyter-kernel-manager.el
(jupyter--kernel-sentinel): Make ignored argument optional.
(jupyter--start-kernel): Don't set the process sentinel.
(jupyter-start-kernel): Report any errors after timeout.
Set the process sentinel as a last step.
The `execution-count` slot of a `jupyter-kernel-client` is now updated higher
up in the message handling process which makes these handlers unnecessary.
There is really no reason for this sync since it happens after checking if the
kernel is busy and the execution-count is now updated whenever an execute_input
message is received in the `jupyter-handle-message` of a
`jupyter-kernel-client`.
When a kernel restarts, `jupyter-start-kernel` will overwrite the slots
corresponding to external resources of the old, shutdown, kernel, like the
connection file. Ensure resources are cleaned up before overwriting those
slots.
Mainly variable re-naming and in preparation for adding in auto-restart
support.
* `jupyter-hb-consider-dead-periods` -> `jupyter-hb-max-failures`
* Also convert to a customizable variable
* `kernel-died-cb` -> `dead-cb`
For this case, no tunnels actually need to be created since docker can expose
ports using the -p flag to `docker run`. This is assumed here. A complete
example to start a kernel in a docker container using one of the official
Jupyter docker images is below:
docker pull jupyter/base-notebook
docker run --name test -it --rm -p 56406-56410:56406-56410 \
jupyter/base-notebook start.sh jupyter-kernel \
--ip=0.0.0.0 \
--KernelManager.control_port=56406 \
--KernelManager.hb_port=56407 \
--KernelManager.iopub_port=56408 \
--KernelManager.shell_port=56409 \
--KernelManager.stdin_port=56410
`accept-process-output` will return when any output has been read from a
process (after it has been handled by the process filter function) which is
usually the time when we want to check on the wait condition so there is no
need to have such a low time resolution.
A shutdown-reply message received by a request implies that no other messages
will be received for that request since the kernel will shutdown. Also set
`jupyter-request-idle-received-p` to `t` in such cases.
