Skip to content
This repository has been archived by the owner on Dec 8, 2022. It is now read-only.

Jupyter #43

Open
inumanag opened this issue Sep 5, 2019 · 4 comments
Open

Jupyter #43

inumanag opened this issue Sep 5, 2019 · 4 comments
Assignees
Labels
Interop Issues related to interoperability with other systems or languages

Comments

@inumanag
Copy link
Collaborator

inumanag commented Sep 5, 2019

No description provided.

@arshajii arshajii added the Interop Issues related to interoperability with other systems or languages label Sep 6, 2019
@jodiew
Copy link
Contributor

jodiew commented Sep 14, 2019

Minimal Seq Language Kernel

This an overview of the messages used by the Jupyter Kernel, in the context of implementing a kernel for the Seq language using the python wrapper.

Required Messages

These are the messages required to be implemented to have a functioning kernel. Many of the details of these messages are handled by the python wrapper.

Kernel Info

Information about the kernel for the client

Reply fields:

  • protocol_version - the message protocol version number
  • implementation (str) - the kernel implementation name
  • implementation_version - the kernel version
  • language_info - information about the language
    • name (str)
    • version
    • mimetype (str)
    • file_extension (str)
    • pygments_lexer (str) - for highlighting, only if different from name
    • codemirror_mode (str or dict) - for notebook highlighting, only if different from name
    • nbconvert_exporter (str) - how the notebooks should be exported, default 'script' exporter
  • banner (str) - information about the kernel
  • help_links (list) - optional, displayed in the help menu in the notebook ui
    • text (str)
    • url (str)

Execute

Execute code

Request fields:

  • code (str) - code to be executed
  • silent (bool) - if the result should be broadcast, default False
  • store_history (bool) - if the kernel should populate history, False if silent is True
  • user_expressions (dict)
  • allow_stdin (bool) - if the kernel can prompt the user for input requests, default True
  • stop_on_error(bool) - if the execution queue aborts when an exception is encountered, default False

Reply fields:

  • status (str) - one of: 'ok', 'error', 'abort'
  • execution_count (int)
  • payload (list) - optional and deprecated
  • user_expressions (dict)

Stream

Broadcast text to be displayed to the frontend. Not required, but necessary to have code output sent to the notebook.

Fields:

  • name (str) - one of 'stdout' or 'stderr'
  • text (str) - the text to be broadcast

REPL Wrapper

All that is needed on the Seq language side is some kind of REPL wrapper or Python bindings to handle code execution and the resulting output. There is an example of such a wrapper in the bash kernel example.

Relevant Links

bash_kernel
Python Wrapper Kernel
Messaging in Jupyter
Kernel Info Message
Execute Message
Stream Message

@jodiew
Copy link
Contributor

jodiew commented Sep 16, 2019

This might be useful: Metakernel

@jodiew
Copy link
Contributor

jodiew commented Sep 17, 2019

Microsoft Language Server & Jupyter Kernel

Features
It seems that even though the LSP and Kernel messaging are different protocols they would need to interact with Seq in very similar ways (code completion, highlighting, etc.). I think we could create a set of common code that handles the interaction between any protocol and the language and then implement the two different messaging protocols with that library of common code.

@inumanag
Copy link
Collaborator Author

Hi @jodiew:

We will need these for now:

  • Simple execute (with stdout / stderr separation)
  • Introspection/Hover (create a dummy Python functions that just shows the location of hover)
  • Signature Help (same as above)

and a syntax highlighter for VSCode and Sublime. Probably in TextMate format as it is more versatile.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Interop Issues related to interoperability with other systems or languages
Projects
None yet
Development

No branches or pull requests

3 participants