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`
Setup the necessary hooks before starting the kernel so that we can ensure that
the startup message is caught.
A short delay is also added whenever we start a channel. This was necessary for
the client to catch the startup message of a python kernel.
- 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.
- `jupyter-shutdown-kernel` assumes that the kernel is able to be communicated
with, but when startup fails we know its not so just delete the process
immediately.
- When deleting the connection info file after a kernel dies, make sure that
the file exists first.
Also make `jupyter-wait-until-startup` private by renaming to
`jupyter--wait-until-startup`. Startup messages are only sent once at kernel
startup, since the only way to start a kernel is through a
`jupyter-kernel-manager` it makes more sense to only allow a kernel manager to
wait for a startup message.
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.
