A modern, Promise ready, NodeJS Jupyter 5.2.3 Kernel with comm and display support. This work was heavily inspired by Nicolas Riesco's IJavascript kernel and is, in some sense, a continuation of that.

Currious of what it can do? Well ... have a look.

• Allows plain cell results
  
• Resolves promisified values into plain results
  
• Masks undefined results
• Permits creating and working with comms from within a cell (via Jupyter comm_create and comm_msg)
• Capable of handling comm messages originating from the kernel
• Able to display custom MIME specific content (via Jupyter display_create messages)
• Can print strings (via stream messages)
• Supports kernel restarting via the Notebook UI
• Has error stack tracing

Requires NodeJS v12.3+ installed on the machine that hosts the Jupyter Notebook server alongside the NeluKernelu JS kernel.

We're not (yet) on NPM so, for now, you would have to manually do a git clone followed by a npm install which not only fetches the dependencies, but also makes the kernel available to Jupyter.

If you then want to use it, just open jupyter (via jupyter notebook, for instance) and you should see it listed there.

Due to security considerations, the following NodeJS objects are not available to be used from within a cell:

• global
• process

Whenever a Notebook is started which targets this NodeJS kernel, a special kernel object is created and made available on each and every code cell. This object exposes kernel functionality into cell-space.

The running kernel version is made available via kernel.version. This exposes an object with 2 properties:

• name - a x.y.z.w string where x.y.z follows the Jupyter Client Specs currrently supported and w is a source build number
• code - a numeric codification of name for easier usage. The value is actually computed as xyz000 + w where x, y and z are the name digits and w is the current build number

To get the current running user-name, just call kernel.userName. This is helpful to deduce the current user especially in hub-like (+ oAuth) environments.

can be achieved via doing a kernel.print() call passing in the string that you want shown underneath the cell like so:
If you want to get fancy, you can also work with formattable constructs the same way you would go using util.format. Thus, you can do things like:
Note: By design, console.log does not have the same effect as kernel.print. Using the traditional console.log has the effect of logging to the system console instead of the user's notebook.

The user can currently open a Jupyter communication channel (comm, for short) in one of two ways:

• through kernel.commManager.newComm() which creates a new comm that has a target name of jknb.comm and an initial data payload of {} (empty JS object) or
• through kernel.commManager.newCommFor() which takes in 3 parameters offering increased flexibility:
  • targetName - mandatory, the comm's target name
  • initialData - optional (defaults to {}), the comm's initial-data object payload
  • metaData - optional (defaults to {}), the comm's metadata object payload Both these methods yeild a new SessionKernelComm instance which can be used to both send and receive messages.

can be achieved via calls to a comm's instance SessionKernelComm.send() method. The only mandatory argument being the JS object that we want to be broadcasted on that comm.

is done subscribing to the "message" event of the desired SessionKernelComm instance like so:

wComm.on("message", ({ data }) => kernel.print(JSON.stringify(data)));

The registered message handler will receive one parameter which will always be an object with a single property, data that carries whatever payload received through that comm.

To display something into an output cell, you need to call kernel.display on an instance of a class that extends JupyterDisplayableMessage in which you overwrite _toDisplay() returning whatever JS object you would like to display as a result. Here's an example:

• Testing! The automatic kind ...
• Handling of comm_close messages
• Handle comm_open messages originating from outside the kernel
• Make kernel interruption work for all/most of the cases
• Research the rest of the Jupyter Widgets, document the findings inside a reengineered markdown entry and provide an implementation

• Victor ADASCALITEI - repo owner
• Radu MILICI

Contribute! PRs are more then welcomed, but bugs and/or feature requests are also fine. Every bit of effort is appreciated.