- Use `ignore-errors` around `jupyter-connection` slots since they can be
inherited by the `parent-instance`. Note that checking if the slot is
available does not also check if the slots availability in the
`parent-instance`
- Set `addr` where it is used, namely in `cl-loop`
This is a function which should be called on a `jupyter-kernel-client` and it
returns a request object which can be used to add callbacks to messages that
have no parent message such as the status: startup message sent be a kernel.
Break it into several macros which perform various subtasks like processing a
command received from the parent emacs process and collecting messages into a
sorted list based on `jupyter-message-time`
This way when creating kernel clients with `jupyter-kernel-manager`, we can set
the `parent-instance` of the newly created client to the manager thereby
inheriting the `jupyter-session` from the kernel manager.
Also have `jupyter-channel` objects inherit from a `jupyter-connection` so that
we can define `jupyter-send` and `jupyter-recv` methods for channels in the future.
- Rename `jupyter-received-message-types` to `jupyter-message-types` and add
message types for requests as well. Also change the keys to keywords instead
of symbols. Using plists with keywords is in line with `jupyter-messages` and
the arguments of the jupyter request functions.
- Rename `jupyter-request-run-callbacks` to `jupyter--run-callbacks`. This is
more of an internal function so mark it as such.
- Change the order of the first two arguments in `jupyter-add-callback` and
`jupyter-wait-until`. In both cases you are adding a callback to a request or
waiting for some condition to be satisfied on the request not on the message
type. This is also the reason why `jupyter-wait-until-received` keeps the
message type as the first argument. We are waiting until a message of a
certain type is received for a request, but the more important object in this
case is the message type.
- Update other files to take into account these changes.
- `jupyter-client.el` only contains client related code
- `jupyter-kernel-manager` related code is placed in `jupyter-kernel-manager.el`
- Socket creating functions and generating connection info plist function are
placed in `jupyter-connection.el`. This also contains the
`jupyter-connection` class.
- Kernelspec related functions are placed in `jupyter-kernelspec.el`
- Move general utility functions and variables requires necessary for `jupyter`
into `jupyter-base.el`. This also contains the `jupyter-session` and
`jupyter-request` struct definitions.
This avoids problems with a reply message and a status idle message being
received at identical times for a request. Two messages can be received at the
same time when the fractional seconds resolution of the time stamps received
from the kernel are not high enough. If the iopub channel had a higher priority
it would mean that the idle message would be received before the reply when
they have identical time stamps. Since request objects are removed from the
client when an idle message is received this would prevent any reply callbacks
from running.
To combat this problem, prioritize the shell messages over any other type of
message.
- Introduce `run-handlers-p` for `jupyter-request` objects. When this field is
non-nil, a clients `jupyter-handle-message` method will pass the message to
the channels `jupyter-handle-message` after running any callbacks. Otherwise
the channel handlers will not be run. This gives a way to suppress the
channel handlers for a request.
- Also remove the use of `jupyter-callback` since `jupyter-handle-message` for
a client just removes requests when an idle message is received. The callback
object was used to check if a callback actually ran.
This method dispatches to the appropriate message handlers based on the type of
channel passed to `jupyter-handle-message`. This method is also defined for a
`jupyter-kernel-client` in which case any callbacks for a message will be run
and then the message passed to the channel handlers.
