`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
* Handle the case of no time specification by defaulting to midnight when
decoding time
* Properly handle fractions in `jupyter--decode-time`
* Implement `jupyter--encode-time`
* Consider a time object to be a length 4 list of integers and encode the
object using `jupyter--encode-time` when encoding in `jupyter--encode`
* Add tests for time decoding/encoding
This introduces a way of keeping track of both the encoded and decoded parts of
a message, only decoding the parts of a message when needed, and only encoding
the parts of a message when needed.
If the objects passed to `jupyter--encode` or `jupyter--decode` are lists with
the first element being the symbol `message-part`, then the second element of
the list is interpreted as being the encoded message and the third element
being the decoded part of the message. If either the encoded or the decoded
part are nil, then `jupyter--encode` or `jupyter--decode` will fill those
message parts in and on subsequent calls, passing in the same list, no work
will need to be performed.
This avoids double encoding messages when relaying messages between the channel
subprocess and the browser displaying widgets. This speeds up the communication
process. The cost is storing two representations of the same message, i.e.
speed vs memory.
Fixes:
- Use `eq` instead of `equal` in message status predicates
- Fix time string decoding
- `parse-time-string` was returning all nil on Emacs 26
- Include validation for parent header in `jupyter--encode-message`
- Use `jupyter-message-header' to access the message header instead of `plist-get`
- Add missing namespace to sha256 function
- Any function defined should have a `jupyter-` prefix
- Remove `cl-lib` dependency in `jupyter-messages.el`
- Include `subr-x` in `jupyter-base.el`
- Use `tramp-file-name-user` instead of `tramp-file-name-real-user` since the
latter is missing in Emacs 26
- 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.
- `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.
Where `jupyter-request-*` are the `jupyter-kernel-client` request methods. This
required the underlying messages request message functions to be renamed to
`jupyter-message-*-request` from `jupyter-*-request`.
With this new implementation, all communication between the kernel and the
client happens in a subprocess. When the client would like to send a message,
the parent emacs process generates the required plist and sends it to the
subprocess for encoding and sending to the kernel. When a message is received,
the subprocess decodes it and prints it to the pipe for the parent emacs
process to read.
This implementation also introduces the use of futures to avoid having to wait
for subprocess output when sending a message to the kernel. Every
`jupyter-request-*` function now returns a primitive future object which is
just a cons cell with the `car` equal to `:jupyter-future`. When the `cdr` of
the future is non-nil, then it is the message ID of the sent request. This acts
as a check to ensure that the message ID is available from the future object,
if the `cdr` is nil the ID is not available, but if the `cdr` is non-nil then
it is the message ID. The convenience function `jupyter-ensure-id` ensures that
the message ID is available and returns the ID.
The future acts as a stand in for the message ID of the encoded request which
will be retrieved from the subprocess once the message has been encoded and
sent to the kernel. This future object is meant to be passed to
`jupyter-add-receive-callback` and other related functions the same way as an
actual message id.
