I heard a lot about how the last 10% of a project’s deliverables take more time and effort than the previous 90%, and I am, once again, noticing this. Not that I’m saying we currently have a 90% complete Scilab kernel (actually, I don’t really know), but the idea still applies.
After writing code to handle the Jupyter communication infrastructure, threading, Scilab integration, building and [limited] processing of the most complex messages, we end up still having to handle simpler message types, that request and reply tiny bits® of information essential for a correct backend behavior.
Taking Jupyter messaging documentation as reference (as always, btw), we try to write proper handlers for the listed messages:
Introspection
Introspection requests can be used by a client to get detailed information about a variable/object. They are issued when an appropriate frontend receives a page payload, that are e.g. returned from the IPython kernel on the execute _reply for commands like “var_name?” or “var_name??” (Payloads aren’t implemented on the Scilab kernel yet).
inspect_request message specification
inspect_reply message specification
Our inspect_{request,reply} message handler, from JupyterKernel class
Completion
On many interactive shells, the Tab key is a shortcut for displaying the autocompletion options for the current variable or command being entered. Jupyter defines a type of message for offloading this completion resolution to the kernel.
complete_request message specification
complete_reply message specification
Our complete_{request,reply} message handler, from JupyterKernel class
The result can be seen by clicking Tab after a partial command name on QtConsole:
(The kernel dying [heartbeat thread doesn't respond in time, I guess] is a bug to be solved)
Completeness
On some Jupyter frontends, you can force the submission of a command for execution with Shift+Enter, but it’s more convenient when it send complete commands automatically (when typing just Enter), waiting for more input when a multiline one (like for loops or if/else blocks) is being entered. For querying this information from the running kernel, Jupyter defines a specific message format.
is_complete_request message specification
is_complete_reply message specification
Our is_complete_{request,reply} message handler, from JupyterKernel class
Again, testing on a QtConsole, we compare the results for complete and incomplete commands.
As we are approaching the week of GSoC Final Term Evaluation, I’ll probably have time for just one more update (inside GSoC’s time frame, I mean, as I pretend to keep working on it), where I wish to show a server input request implementation working.