mirror of
https://github.com/vale981/emacs-jupyter
synced 2025-03-05 23:41:38 -05:00
Update documentation
This commit is contained in:
parent
d74a28bc0c
commit
94171eba4a
2 changed files with 19 additions and 16 deletions
|
@ -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:
|
||||||
|
|
|
@ -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)))
|
||||||
|
|
Loading…
Add table
Reference in a new issue