`jupyter-channels.el` depends on the `jupyter-send` method defined in
`jupyter-messages.el` whereas `jupyter-messages.el` does not depend on any
functions in `jupyter-channels.el`.
* jupyter-channel.el: Require `jupyter-messages`
* jupyter-messages.el: Remove `jupyter-channels` require
* Add `jupyter-channel--reset-socket` which does the work of connecting the
heartbeat channel to its endpoint and takes care of possibly reseting the
socket after sending a ping.
* Actually set the paused slot to nil when un-pausing the
heartbeat channel
* Ensure the heartbeat socket is actually a socket when
receiving. This is to handle edge cases when the
heartbeat channel is stopped, but there still is a timer
left in the `timer-list`.
- Allow specifying a msg-id before a call to `jupyter-send`
- This avoid sending a message to the browser displaying the widgets on every
message send to the kernel. The previous implementation generated a new ID
without allowing the caller to pass one in.
- Simplify message polling by sending received messages from the kernel to the
parent Emacs process at the moment of arrival.
To make up for this:
- Move the functions defined in `jupyter-connection.el` to `jupyter-base.el`
- Add a `session` field to the `jupyter-kernel-manager` and `jupyter-channel`
classes
- Add a `kernel-info` field to the `jupyter-repl-client`
- Add a `conn-info` field to a `jupyter-session`
- Add a `session` field to `jupyter-kernel-client`
- Distinguish between an asynchronous channel and a synchronous one
- `jupyter-async-channel` :: Messages are sent and received through an ioloop
subprocess that the channel has access to. The
subprocess uses the `jupyter-sync-channel` for
sending and receiving messages.
- `jupyter-sync-channel` :: Messages are sent and received through a
`zmq-socket` in the current Emacs session.
- Define `jupyter-send` and `jupyter-recv` methods for channels.
- Update `jupyter-kernel-client` and ioloop interfaces to take into account
changes with channels.
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.
- `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 function returns a socket based on a channel type and endpoint. The
channel type is mapped to the required socket type based on
`jupyter-channel-socket-types`. This is a convenience function to avoid having
to use `jupyter-channel-socket-types` directly.
