Update documentation

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

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 ;; 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 ;; `jupyter-request-id'. `jupyter-request-id' will time out. it looks like the
;; poller is not noticing the stdin event in this case. ;; 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) (defun jupyter--ioloop (client)
"Return the function used for communicating with CLIENT's kernel." "Return the function used for communicating with CLIENT's kernel."
(let ((sid (jupyter-session-id (oref client session))) (let ((sid (jupyter-session-id (oref client session)))
@ -453,11 +456,14 @@ subprocess."
"Insert a request into CLIENT's pending requests. "Insert a request into CLIENT's pending requests.
Pending requests are `jupyter-request's that have a nil Pending requests are `jupyter-request's that have a nil
`jupyter-request--id'. The `jupyter-send' method for a `jupyter-request--id'. The `jupyter-send' method for a
`jupyter-kernel-client' sends message data to the ioloop `jupyter-kernel-client' sends a message to the ioloop subprocess
subprocess to encode and send off to the kernel. When the which encodes the message and sends it off to the kernel.
subprocess sends a message to the kernel, it sends the message ID
associated with the request back to the parent Emacs process When the subprocess sends the message to the kernel, it sends the
which is when the `jupyter-request--id' field becomes non-nil. 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 are stored in a ring located in the
`:pending-requests' property of an ioloop subprocess. REQ is `: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 client method runs any callbacks for the message and possibly
runs the client handler for the channel the message was received runs the client handler for the channel the message was received
on. The channel's `jupyter-handle-message' method will then pass on. The channel's `jupyter-handle-message' method will then pass
the message to the appropriate message handler based on message the message to the appropriate message handler based on the
type which terminates the execution path. message type.
So when a message is received from the kernel the following steps So when a message is received from the kernel the following steps
are taken: are taken:

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 If a valid kernel is found, its kernelspec is used to start a new
kernel. Starting a kernel involves the following steps: kernel. Starting a kernel involves the following steps:
1. Create a new `jupyter-session'. 1. Write the connection info of MANAGER's session to a file in
the `jupyter-runtime-directory'. Using the standard naming
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
convention, i.e. after a call to `jupyter-start-kernel' the convention, i.e. after a call to `jupyter-start-kernel' the
connection file will be named kernel-PID.json where PID is the connection file will be named kernel-PID.json where PID is the
process ID of the kernel subprocess. 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 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) (unless (jupyter-kernel-alive-p manager)
(cl-destructuring-bind (kernel-name . (resource-dir . spec)) (cl-destructuring-bind (kernel-name . (resource-dir . spec))
(car (jupyter-find-kernelspecs (oref manager name))) (car (jupyter-find-kernelspecs (oref manager name)))