hiro/emacs-jupyter
1
0
Fork 0
mirror of https://github.com/vale981/emacs-jupyter synced 2025-03-05 15:41:37 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

Update documentation

Browse source
This commit is contained in:
Nathaniel Nicandro 2018-05-15 23:41:19 -05:00
parent d74a28bc0c
commit 94171eba4a
2 changed files with 19 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
jupyter-client.el
View file

@ -370,6 +370,9 @@ Any other command sent to the subprocess will be ignored."
;; then we send a request, and wait for the request id to come back with
;; `jupyter-request-id'. `jupyter-request-id' will time out. it looks like the
;; poller is not noticing the stdin event in this case.
;;
;; One option would be to have two separate poll commands, one for STDIN and
;; the other for the channels. But first write a test case for this scenario.
(defun jupyter--ioloop (client)
"Return the function used for communicating with CLIENT's kernel."
(let ((sid (jupyter-session-id (oref client session)))
@ -453,11 +456,14 @@ subprocess."
"Insert a request into CLIENT's pending requests.
Pending requests are `jupyter-request's that have a nil
`jupyter-request--id'. The `jupyter-send' method for a
`jupyter-kernel-client' sends message data to the ioloop
subprocess to encode and send off to the kernel. When the
subprocess sends a message to the kernel, it sends the message ID
associated with the request back to the parent Emacs process
which is when the `jupyter-request--id' field becomes non-nil.
`jupyter-kernel-client' sends a message to the ioloop subprocess
which encodes the message and sends it off to the kernel.
When the subprocess sends the message to the kernel, it sends the
message ID associated with the request back to the parent Emacs
process which is when the `jupyter-request--id' field becomes
non-nil. This acts as a synchronization method so that the parent
Emacs process can guarantee a message has been sent.
Pending requests are stored in a ring located in the
`:pending-requests' property of an ioloop subprocess. REQ is
@ -766,8 +772,8 @@ When a message is received from the kernel, the
client method runs any callbacks for the message and possibly
runs the client handler for the channel the message was received
on. The channel's `jupyter-handle-message' method will then pass
the message to the appropriate message handler based on message
type which terminates the execution path.
the message to the appropriate message handler based on the
message type.
So when a message is received from the kernel the following steps
are taken:

15
jupyter-kernel-manager.el
View file

@ -167,20 +167,17 @@ match `name', the first one on the list is used.
If a valid kernel is found, its kernelspec is used to start a new
kernel. Starting a kernel involves the following steps:
1. Create a new `jupyter-session'.
2. Create a new connection info plist with random ports for the
channels. See `jupyter-create-connection-info'.
2. Write the connection info to a file in the
`jupyter-runtime-directory'. Using the standard naming
1. Write the connection info of MANAGER's session to a file in
the `jupyter-runtime-directory'. Using the standard naming
convention, i.e. after a call to `jupyter-start-kernel' the
connection file will be named kernel-PID.json where PID is the
process ID of the kernel subprocess.
4. Start a kernel subprocess passing the connection info file as
2. Start a kernel subprocess passing the connection info file as
the {connection_file} argument in the kernelspec argument
vector of the kernel."
vector of the kernel.
3. Connect the control channel of MANAGER to the kernel."
(unless (jupyter-kernel-alive-p manager)
(cl-destructuring-bind (kernel-name . (resource-dir . spec))
(car (jupyter-find-kernelspecs (oref manager name)))