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.
* Port scimax's org facility functions
We provide a hydra to easily use the functions.
By default, the binding to call the hydra is `C-c h`
The hydra is only created if the hydra package is loaded.
* Move org extensions to its own file.
* Integrate revision comments
* Replaced manual placement of src blocks with
`org-element-interpret-data`
* Refactor some functions
* Add a hydra to `jupyter-org-interaction-mode-map`
Only actually define the Hydra if the package `hydra` exists.
* Refactor org extension functions.
* org-extensions: refactor and cleanup
* Remove compiler warnings
* Change condition-case for ignore-errors
* Functions that restart the kernel now work
* Use ivy and avy functions only if package exists
* org-extensions: change hydra bindings
* Match the hydra bindings better to emacs conventions
* org-extensions: improvements and code refactoring
* add where external functions should be found
* take into account empty RESULTS when moving blocks
* org-extensions: use context variable for jumping
* org-extensions: improve jumping to block function
* Set a default variable to specify how many lines of context to show
* Consider the case when a user supplies the nil value
Changing `major-mode`s would kill the local `jupyter-current-client` variable
which we don't want to happen. There is no reason (that I can think of) to
change the `major-mode' in a REPL buffer anyways.
