This avoids a bug in `org-mode`. Although the documentation of
`org-src-lang-modes` says the mode can be a symbol or a string, the
customization type only specifies symbol so having a string causes errors when
`custom-initialize-reset` is called after
`org-babel-jupyter-aliases-from-kernelspecs`.
Also fix misuse of `alist-get`. `alist-get` uses `assq` for comparison by
default, but we are comparing strings. This caused issues when caching REPL
buffers and the subsequent re-use of them during testing.
For assoc lang org-src-lang-modes may return symbol sh, (inter 'sh) will
return an error.
For some languages like C++, the corresponding language mode shall be c++
On Windows systems we can't poll the STDIN of the created subprocess when using
`jupyter-ioloop` since Windows does not allow polling file handles. To get
around this we create a (PUSH, PULL) socket pair that the parent Emacs process
uses to communicate with its subprocess. See dzop/emacs-zmq#10 and thanks to
@fleimgruber for investigating this issue.
The previous mechanism to communicate with a kernel was too low level from the
perspective of a client. The client interfaced directly with the subprocess
abstraction, `jupyter-ioloop`, and had to handle all "events" that occurred in
the `jupyter-ioloop`, e.g. when a channel was started or stopped. But in
reality such events should not be the concern of a client.
A client should only care about events that are directly related to kernel
messages and not events related to the implementation details of *how*
communication occurs.
This commit abstracts out the way in which a client communicates with its
kernel by introducing a new `jupyter-comm-layer` class. The
`jupyter-comm-layer` class takes care of managing the communication channel
between a kernel and its clients as well as sending events to all registered
clients. This way, clients operate solely at the level of events on the
communication layer. All a client does is register itself to receive events on
the communication layer and send events on the layer.
* jupyter-base.el (jupyter-session-endpoints): New function.
* jupyter-client.el (jupyter-kernel-client): Remove ioloop and channels slots.
Add kcomm slot.
(initialize-instance): Unconditionally stop channels.
(jupyter-initialize-connection): Change into a method call.
Call `jupyter-initialize-connection` on the `kcomm` slot.
(jupyter-with-client-buffer): Remove stale comment.
(jupyter-send): Call `jupyter-send` on the `kcomm` slot.
(jupyter-ioloop-handler): Remove all method definitions, replace `sent` and
`message` methods with their `jupyter-event-handler` equivalents.
(jupyter-hb-pause, jupyter-hb-unpause, jupyter-hb-beating):
(jupyter-channel-alive-p, jupyter-start-channel, jupyter-stop-channel):
(jupyter-start-channels, jupyter-stop-channels):
Replace with calls to their equivalents using the `kcomm` slot.
* jupyter-comm-layer.el: New file.
* jupyter-kernel-manager (jupyter-make-client): Set a client's `kcomm` slot to
`jupyter-channel-ioloop-comm`.
* jupyter-messages.el (jupyter-decode-message): Use `list` directly. There
seemed to be issues when using the new `jupyter-sync-channel-comm` due to
using quoted lists.
* test/jupyter-test.el: Add `jupyter-comm-layer` test. Update other tests.
* test/test-helper.el: Add `jupyter-comm-layer` mock objects. Update
`jupyter-echo-client`.
This accounts for changes in
dzop/emacs-zmq@b35b0b5fcd, in particular byte
compiling the form passed to `zmq-start-process` too early causes issues with
macro expansion if there are library dependencies.
Instead of using `jupyter-eval` which creates unnecessary `:execute-input` and
`:execute-result` messages, use the `:user-expressions` key of an execute
request to compute the Pkg prompt. This way the only message generated is an
`:execute-reply` and we avoid modifying the execution count.
This requires JuliaLang/IJulia.jl@85eb54ae17
