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
This also removes the use of `shell-command-to-string`, replacing it directly
with `process-file`. `shell-command-to-string` uses `shell-file-name` directly
which may not work properly when `default-directory` is a remote directory as
the remote directory may have a different shell than the local one. See #75.
This also fixes an edge case when there is only one blank line after the source
block. The previous version would consider the beginning of the last line of
the code block as the end instead of the beginning of the `#+end_src` line in
that case.
