Jupyter Blog - C++

C++ in Jupyter — Interpreting C++ in the Web

2025-06-19T15:29:00+00:00

Scientists and engineers utilize programming languages not only to build software systems but also to drive interactive exploratory workflows. They leverage developer tools to explore and reason through problems effectively. This process involves executing code, examining visualizations, loading data, and running additional code. Rapid iteration is particularly crucial during the exploratory phase of any technical project.

For this reason, the most popular tools for exploratory work tend to be interpreted languages, such as Python or R. The “Read-Eval-Print-Loop” (REPL) places the user at the center of these iterative workflows. While compiled languages such as C++ are essential for performance-sensitive applications, engineers accustomed to interactive tools often struggle in such environments.

At CERN, the C++ programming language has been pivotal to their data analysis platform for particle physics, notably in the ROOT framework. ROOT is underpinned by the Cling C++ interpreter, which is built on the Clang and LLVM stack. The Cling interpreter, co-created by Vassil Vassilev and Axel Naumann in the 2010s, effectively turned C++ into an agile scientific scripting language!

These interactive workflows are where the Jupyter stack shines compared to traditional IDEs. Indeed, the Jupyter project was designed with exploratory computing in mind. Crucially, it was built from the ground up to be language-agnostic, accommodating multiple programming languages seamlessly. In 2017, the Xeus-Cling Jupyter kernel was announced. Developed by Sylvain Corlay, Johan Mabille and Loic Gouarin, it integrated Cling in the Jupyter ecosystem, taking advantage of the rich features of Jupyter, such as rich mime type display and interactive widgets.

An example C++ Jupyter notebook powered by the original Xeus-Cling kernel

Packaging the Cling project proved challenging as it required patching the code base of Clang, and was not released as frequently as the LLVM stack, causing difficulties with rolling software distributions like conda-forge.

In an effort led by Cling co-creator Vassil Vassilev, the Clang-Repl project was born, which consists in building the foundations for interactive C++ in the core of Clang. Clang-Repl has been undergoing active development for a few years now and a Jupyter kernel for Clang-Repl, Xeus-Cpp, has also been developed, providing a similar set of features to Xeus-Cling.

Building the new C++ kernel upon Xeus was crucial as it enabled the porting of the C++ kernel to the Web browser with JupyterLite.

Scaling Jupyter with JupyterLite

The standard approach for Jupyter-based computing relies on providing each user with computing resources in the backend. Serving a few thousand end users necessitates substantial resources and complex deployment strategies.

The JupyterLite project shifts this paradigm by running code directly in the user’s Web browser, by relying on a WebAssembly build of the kernel and required libraries. This eliminates the linear relationship between the number of users and the required resources.

For instance, the NumPy.org website features a JupyterLite code console on its main page, offering a computational environment to thousands of monthly visitors without incurring any cloud costs. Similarly, the Capytale deployment of Jupyter, used in French high schools, operates on the same model. It accounts for over half a million registered users and hosts more than 200,000 user sessions weekly.

In order to provide a broad range of packages and libraries for this new platform, the JupyterLite team at QuantStack developed the Emscripten-forge distribution, utilizing the conda package manager for creating WebAssembly environments. Emscripten-forge comprises the main packages of the Python scientific computing ecosystem, as well as the R programming language, and several command-line applications powering the JupyterLite terminal.

Today, we are proud to announce that Xeus-Cpp and LLVM are available in emscripten-forge, effectively enabling interpreted C++ in the browser.

The new C++ Jupyter kernel in action in JupyterLite.

Feel free to try it out in your browser by clicking the link below!

We now dive into the details on the internals of the WebAssembly build of Xeus-Cpp, and the key features of the project.

Walking up the stack

Emulated Just-in-Time Compilation and WebAssembly

A fundamental challenge inherent to the WebAssembly is that it operates in a sandboxed Harvard architecture: code and data reside in completely distinct memory spaces. This makes conventional JIT compilation unfeasible in the browser, as it prohibits dynamic modification of executable memory.

The WebAssembly backend for Clang-Repl was introduced during the LLVM 17 development cycle, with the introduction of a WASM-specific IncrementalExecutor, sidestepping the standard LLVM JIT approach used on native platforms. This new WasmIncrementalExecutor class handled the WebAssembly-specific execution model as follows:

The LLVM IR from the REPL’s Partial Translation Unit (PTU) is compiled into an object file.
This object file is passed to wasm-ld with flags to generate a standalone WebAssembly module.
The resulting .wasm module acts as a dynamically linked side module, designed to be loaded on top of a persistent main module at runtime.

These side modules, while similar to shared libraries, are treated as auxiliary WASM modules that are dynamically attached to the main application using Emscripten’s dlopen mechanism. They share memory with the main module and can resolve symbols defined in previous executions. As a result, each REPL input produces a corresponding .wasm module that is compiled, linked, and loaded at runtime, incrementally extending the current execution environment.

Following the initial version in LLVM 17, the support for WebAssembly was incrementally consolidated by a series of pull requests addressing various issues and corner cases with respect to symbol duplication, memory corruption, and dynamic linking failures. We believe the version available today in LLVM 20 is a solid foundation to build upon.

For a deeper understanding of the constraints of the WebAssembly platform for JIT compilation, refer to the GSOC report: Anubhab Ghosh — WASM Clang-Repl.

Porting Xeus-Cpp to Emscripten-forge

In addition to challenges with emulating JIT compilation in WebAssembly, packaging Xeus-Cpp for emscripten-forge presented another challenge: managing shared objects within the initial WebAssembly executable, which are typically built statically for other xeus kernels. This issue was addressed in the following PRS:

As a result of this work, required side modules are now specified as metadata in the Jupyter kernelspec kernel.json file, enabling JupyterLite to automatically detect and utilize them.

Features

Inline documentation

To fully integrate C++ as a first-class citizen within the Jupyter ecosystem, supporting inline documentation is crucial. Similar to the Python kernel, utilizing the ? magic command should allow users to inspect the following type, perform a lookup in the available documentation, and display the relevant information.

The C++ kernel comes equipped with a lookup file for the standard library, making it possible to execute queries like ?std::vector seamlessly.

Inline help feature in the C++ JupyterLite kernel

This can be enabled for third-party libraries. Check out the documentation to enable inline help for your package.

This feature, inherited from the Xeus-Cling project, was initially created by Loic Gouarin.

Rich display

One of the core benefits of integrating C++ into the Jupyter ecosystem is the ability to leverage Jupyter’s rich MIME display system. Rather than limiting output to plain text, Xeus-Cpp allows you to render rich content like images, HTML tables, LaTeX, or even custom visualizations, all directly from C++.

This is made possible by the function xcpp::display, which sends a MIME bundle to the frontend. Each bundle can include multiple representations of the same object, such as text/plain, image/png, or even custom mime types.

This is illustrated in the following example:

Rich mime type rendering feature of the Xeus-Cpp kernel

A custom renderer for any given type can be defined by defining the mime_bundle_repr function in the corresponding namespace, which is then picked up by Xeus-Cpp’s display system through Argument-Dependent Lookup (ADL). A large collection of mime types are supported by the JupyterLab frontend, which can also be extended with plugins to support custom mime types.

Advanced Graphics

Another compelling example leveraging the rich rendering capabilities, is to combine it with frameworks such as SDL for rich graphic content. Emscripten has built-in support for SDL (enabled with the -s USE_SDL=2 compilation flag), which allows us to leverage its power in C++ notebooks.

To illustrate this, we ported Kevin Beason’s legendary smallpt global illumination renderer (a path tracer in 99 lines of C++) into a C++ notebook. The scene is rendered using SDL onto an in-memory canvas, and the resulting image is captured and displayed with xcpp::display.

This setup showcases the seamless integration of SDL and the Jupyter display system:

Use SDL for real-time or offscreen rendering
Then pipe the result through xcpp::display(…) as a PNG or pixel buffer.

PR #299 added an example notebook supporting smallpt with SDL-based rendering. Feel free to access the notebook through our lite link . Since the number of samples per pixel (spp) directly correlates with how long the process runs (approximately 2 minutes in our case), we’ve included debug logs to keep users informed during rendering, so they aren’t left wondering about the progress.

Smallpt tiny raytracer in action in JupyterLite

This approach paves the way for interactive C++ graphics demos, ray tracing notebooks, and even the prototyping of browser-based video games from within WebAssembly C++ notebooks.

Loading Third-Party Libraries

For a user’s perspective, a key difference between a Jupyter kernel for a compiled language like C++ and e.g. Python concerns how third-party libraries can be utilized. In Python, one merely needs to import the relevant installed packages, while in the case of C++, the relevant compiled libraries must be loaded in addition to including the corresponding headers.

Thankfully, Clang-Repl provides the LoadDynamicLibrary to dynamically load shared objects, which was adapted to the WebAssembly based in LLVM PR #133037. Instead of relying directly on raw dlopen calls, this function ensures that memory layout, symbol resolution, and constructor invocation are handled correctly — even in a WebAssembly environment.

Building on top of this, the CppInterOp project made these features available via a high-level C++ API.

Showcasing the dynamic loading of shared objects with CppInterOp

Library authors interested in facilitating the use of their package with the Jupyter kernel can include the calls to CppInterop’s LoadLibrary can simply be included in user-facing headers.

This has been done for example, in the Symengine library.

Symbolic Computing with Symengine

A compelling example of the Jupyter rich display system’s advanced capabilities with Xeus-Cpp is the SymEngine package, a powerful C++ library for symbolic computing.

Originally designed as a backend for symbolic Python libraries like SymPy, SymEngine offers native support for expression trees, calculus and Latex/MathJax rendering of mathematical expressions. We have integrated SymEngine into the emscripten-forge distribution, making it readily available for use. Once installed, it works seamlessly with Xeus-Cpp, requiring no additional setup.

SymEngine expressions can be rendered via xcpp::display(), which produces LaTeX-formatted expressions and delegates their rendering to MathJax in the frontend.

Rich mime type rendering used with Symengine

Array-based Computing

Jupyter notebooks are particularly popular among data scientists, students, and practitioners of scientific computing. Array-based computing is at the center of the practice, be it in Python with NumPy, in R, GNU Octave, or Julia.

A framework for array-based computing is C++ is Xtensor. Xtensor’s syntax closely mirrors that of NumPy, supporting features like array broadcasting, lazy evaluation, and element-wise operations with an idiomatic C++ API. Using Xtensor in combination with the C++ Jupyter kernel provides a similar user experience to that of NumPy with the Python Jupyter kernel.

JupyterLite used in combination with Xtensor, utilizing rich display for tables.

Built on top of Xtensor, Xtensor-BLAS brings the high-level syntax of Xtensor with the performance of OpenBLAS. It provides convenient, NumPy-style access to BLAS and LAPACK routines making operations like matrix inversion or system solving easy to express and execute.

JupyterLite used in combination with Xtensor-BLAS

To use these libraries inside a JupyterLite notebook, all you need is to include Xtensor-BLAS in your environment (available via emscripten-forge). Under the hood, Xtensor-BLAS dynamically loads libopenblas, which is bundled automatically as a dependency.

SIMD Acceleration

We can take a step further with SIMD (Single Instruction, Multiple Data) acceleration.

Using raw WebAssembly intrinsics : WebAssembly includes 128-bit SIMD instructions, which are provided in Clang’s <wasm_simd128.h> header. They can be used to perform vectorized operations directly.

Xeus-Cpp kernel showcasing the use of SIMD instructions

Using Xsimd : Here’s an improved version of your text with better flow, clarity, and conciseness.

Rewriting specialized vectorized routines for WebAssembly can be cumbersome. This is where frameworks like Xsimd come in. It provides a high-level SIMD API in C++ that abstracts platform-specific SIMD instructions. With Xsimd, you can efficiently operate on batches of numbers using familiar arithmetic operators or mathematical functions, while benefiting from optimized performance under the hood.

Xsimd powers SIMD acceleration in Xtensor and is also used in many other projects, including Apache Arrow, Firefox, Velox, Pythran, and Krita. Here’s how the same example would look when when using Xsimd instead of raw intrinsics:

Xeus-Cpp kernel showcasing the Xsimd library

Magic Commands

In addition to interpreting standard C++ code, Xeus-Cpp also supports magic commands, special notebook commands prefixed with % or %% that allow for extended functionality not defined by the C++ language itself.

These magics let you interact with the runtime environment, manage files, or perform meta-operations, all from within a code cell. The following magics are available:

%file : The %file magic enables file creation and editing directly from a code cell. You can append to an existing file using the -a flag

Using the %file magics in Xeus-Cpp-lite

%timeit : A %timeit magic has also been prototyped via PR #289 by @kr-2003, enabling performance measurement for expressions in the notebook.

However, due to the lack of last value printing support in Clang-Repl, this feature currently relies on a workaround and hasn’t yet been merged. Once upstream support is in place, %timeit will be integrated cleanly and available out of the box.

Here’s a preview of the %timeit magic in action:

Using the %timeit magics in Xeus-Cpp-lite

Magic commands open the door to a more expressive and interactive notebook experience for C++. While support is currently limited to a few core magics, this is just the beginning — with more capabilities and enhancements expected in the near future.

Interactive Widgets

Beyond rich mime type rendering and inline documentation, the Jupyter widgets system allows users to create interactive components in the Jupyter notebook, leveraging by-directional communication with the kernel for more interactivity.

The xwidgets package is a C++ implementation of the Jupyter widget protocol, comprising an implementation of all the core Jupyter widgets, and which underlies other interactive visualization libraries like xleaflet or xcanvas.

Here are a couple examples demonstrating interactive widgets through xwidgets & xcanvas with Xeus-Cpp-lite.

Displaying a slider using xwidgets

Displaying a canvas through xcanvas

If you inspect the codebase of xwidgets or xcanvas, you will notice that it contains very little code. All that is required on the C++ end is a declaration of the attributes that should be synchronized with the frontend, and serialization methods for complex data types.

Most of the programmatic logic for Jupyter interactive widgets lies in the frontend implementation. The consequence for the C++ Jupyter kernel is that with seemingly little implementation effort, we could enable an entire ecosystem of widget libraries, covering a large range of use cases. Interactive widgets for 2-D plotting (bqplot, plotly) and 3-D plotting (ipyvolume), GIS (ipyleaflet), efficient rendering of meshes (ipygany), graph visualization (ipycytoscape), and many more could be almost automatically connected to the C++ world.

How to deploy JupyterLite with Xeus-Cpp

The GitHub repository https://github.com/jupyterlite/xeus-lite-demo is a template for creating a JupyterLite deployment on GitHub pages that includes the packages specified in a conda environment.

The process is as follows:

Create a new repository from the GitHub template.
Enable the deployment on GitHub pages from a GitHub action, as shown in the README.
Edit the environment file to include the desired packages.

For example, to deploy an C++ kernel with Symengine & Xtensor-blas installed, the environment.yml file would contain the following:

name: xeus-cpp
channels:
  - https://repo.prefix.dev/emscripten-forge-dev
  - conda-forge
dependencies:
  - xeus-cpp
  - symengine
  - xtensor-blas

The deployment linked at the beginning of this article was created with this template.

Future work

The journey of interactive C++ in Jupyter, both natively and in the browser, is still evolving. While Xeus-Cpp already offer powerful foundations, several exciting developments are underway that will further expand their capabilities across platforms

Debugger Support:

Currently, only a few Jupyter kernels like Xeus-Python offer full integration with the Jupyter Debug Protocol to enable the Jupyterlab debugger. We’re working to bring that experience to C++ as well.

This summer, thanks to Google Summer of Code 2025, Abhinav Kumar will be implementing native debugging support in Xeus-Cpp.The approach is based on using LLDB and its Debug Adapter Protocol (lldb-dap). Modeled after Xeus-Python, it leverages LLDB’s Clang and JIT debugging capabilities to enable breakpoints, variable inspection, and step-through execution directly within the JupyterLab debugger interface.

We already have a proof-of-concept demonstrating that debugging C++ in Jupyter is possible. You can track this effort here: xeus-cpp issue #282.

In the longer term, we aim to explore extending debugging to the browser through Xeus-Cpp.

Cuda Support in Xeus-Cpp:

CUDA support in Clang-Repl was broken by the time LLVM 20 was released, but that changed with this upstream patch:

LLVM PR: #136404 — Enable CUDA support in clang-repl

We’re now preparing to bring CUDA support directly to Xeus-Cpp, enabling GPU programming from a Jupyter notebook. Early planning is underway:

GitHub issue: #300 — CUDA REPL support in xeus-cpp

Last Value Printing:

In cling, a widely appreciated feature is last value printing, simply writing a variable at the end of a cell automatically displays its value, without needing any manual printing. This behavior naturally carried over to xeus-cling, making interactive exploration even smoother.

This feature stands almost done in Clang-Repl:

LLVM PR: #84769 — Last Value Printing in clang-repl

Once merged, this will be integrated into Xeus-Cpp, enabling seamless REPL experience for C++ users.

How to contribute?

Whether you’re a developer, package maintainer, educator, or simply curious about C++ in the browser, contributions are always welcome!

Packaging for the Browser

Many of the capabilities in xeus-cpp-lite rely on packages built for the WebAssembly platform via emscripten-forge. If you’re interested in porting a library or creating a new recipe, please visit emscripten-forge.org for detailed guidelines and examples.

PRs and discussions are welcome at github.com/emscripten-forge, especially if you’re looking to bring more numerical, graphical, or scientific libraries into the browser.

Improving Xeus-Cpp, CppInterOp and Clang-Repl

We welcome contributions to the broader xeus project, which is part of the Project Jupyter ecosystem. Xeus-Cpp in particular is actively seeking contributors, whether to improve kernel behavior, expand feature support, or explore new magic commands and UI integrations.

On the LLVM side, the Clang-Repl component is still under active development and can greatly benefit from community contributions, particularly around WebAssembly backend improvements and incremental execution features.

Areas of Need & Opportunities for Collaboration

In addition to code contributions, we are seeking funding opportunities to advance the project. We’ve identified several areas where focused effort could significantly enhance the ecosystem, and we warmly welcome collaborators or potential funding partners interested in helping us move these efforts forward, including:

Integration testing: LLVM currently lacks tests for Clang-Repl + WebAssembly. Establishing a reliable test harness in this area is both challenging and critical.
Interactive plotting: A robust plotting library or plugin for Xeus-Cpp would make the kernel far more expressive for teaching, data exploration, and scientific computing.
Plugin system for magics: Further decoupling kernel extensions would simplify development and allow community-driven growth. A concrete description of this project is framed on CERN’s website.

If you or your organization shares the vision of making modern C++ more accessible, especially in-browser, we’d love to hear from you.

About the Authors

Anutosh Bhat is a scientific software engineer at QuantStack. His contributions range from the core of LLVM and Xeus, to their packaging for the Emscripten-forge software distribution. In the course of this endeavor, Anutosh was granted commit rights to the LLVM project.

Vassil Vassilev is a Research Software Consultant with Princeton at CERN. As the co-creator of Cling and the lead developer of the Clang-Repl and CppInterOp projects, he has spearheaded the development of interpreted C++ for over a decade.

Acknowledgements

The work by Vassil Vassilev on this project is done in the context of the Compiler Research group, funded by the National Science Foundation grant OAC-2311471.

The work by Anutosh Bhat on this project is funded by QuantStack, as part of a broader initiative to enable the data science ecosystem within the Web browser.

Work on prototyping the WebAssembly infrastructure for Clang-Repl was done by Anubhab Ghosh, supported through Google Summer of Code 2023 via the LLVM mentoring organization.

A significant portion of the Xeus-Cpp codebase was inherited from the Xeus-Cling project and adapted for the Clang-Repl interpreter. This includes work by Sylvain Corlay, Johan Mabille, Loic Gouarin, and Martin Renou.

We are grateful to Thorsten Beier, the creator and lead developer of the emscripten-forge software distribution, for his support in packaging LLVM and Xeus-Cpp.

We extend our gratitude to Martin Renou and Anastasiia Sliusar for devising the processing of conda packages in the frontend, which underlies the support of third-party libraries in WebAssembly environments used by Xeus-Cpp and xeus-r. We are grateful to Johan Mabille for creating xeus and for his code reviews within the xeus stack. We also thank Jeremy Tuloup for creating JupyterLite.

We are grateful to Matthew Barton, Tharun Anandh & Abhinav Kumar for their numerous and significant contributions to the Xeus-Cpp project.

Finally, we are immensely grateful to the authors and maintainers of Emscripten and LLVM for building such remarkable technologies and for their engagement and support during our numerous interactions on GitHub.

A Curiously Recurring Widget Library

2021-01-27T14:22:00+00:00

Diving into the implementation of xwidgets

Interactive widgets allow Jupyter users to create user interfaces inline in their notebooks, and to turn them into standalone applications with tools such as Voilà.

Language backends for Jupyter interactive widgets exist in Python (with ipywidgets), and C++ (with xwidgets, and the xeus-cling C++ Jupyter kernel), reusing the same frontend implementation of the widgets in JavaScript.

Simple interactive widgets at play in JupyterLab with the xeus-cling C++ kernel

In this article, we dive into some of the C++ techniques used in the implementation of the xwidgets library, including

discussions on value semantics and RAII (Resource Acquisition Is Initialization),
an original application of CRTP (Curiously Recurring Template Pattern),
an original implementation of the observer pattern, xproperty,
a plea for allowing the overloading of the dot operator in C++, to enable better proxy types.

For readers interested in knowing more about interpreted C++, we recommend the following posts:

Interactive workflows for C++ with Jupyter (Jupyter blog), by Sylvain Corlay, Loic Gouarin, Johan Mabille, and Wolf Vollprecht.
- Interactive C++ for Data Science (LLVM blog), by Vassil Vassilev, David Lange, Simeon Ehrig, and Sylvain Corlay
- Interpreted C++ for GIS with Jupyter (Jupyter blog), by Martin Renou

Jupyter widgets are special objects that trigger the creation of a counterpart JavaScript model object in the Jupyter frontend upon creation. The state of the object in the backend is synchronized with the state of the JavaScript frontend object. Views of that widget model are instantiated upon display.

The MVC (Model View Controller) architecture of Jupyter widgets, and synchronization with the backend

This MVC (Model-View-Controller) architecture for Jupyter interactive widgets allowed us to reuse all of the frontend implementation, by simply providing an alternative backend in C++, implementing the same messaging protocol.

In order to tie the lifetime of the kernel and frontend objects, we decided to use the RAII (Resource Acquisition Is Initialization) pattern. RAII is a common programming idiom that consists of tying the lifetime of an object with the holding of a resource. Most typically, the resource is

acquired in the constructor of the object,
released in the destructor of the object.

The RAII pattern is not common in garbage-collected languages because unlike in C++, the time when objects are destroyed is not deterministic. The Python programming language mitigates that issue by introducing context managers, often used to e.g. open and close files.

A consequence of relying on object lifetime for resource management in C++ is to adopt the “value semantics” for widget instances, instead of “reference semantics” which is more typical for widget frameworks like Qt.

Note: value semantics vs reference semantics

If you are not familiar with the concepts of value and reference semantics in C++, I recommend reading the excellent FAQ of isocpp.org.

To summarize:

- with value semantics, objects hold actual values, and copying an object copies their attributes. With value semantics, one should provide implementations of copy, and move constructors*, as well as* copy and move assignment operators*. Besides, values should not have virtual methods.*

- with reference semantics*, objects are manipulated through references (or pointers) and never by value. Reference semantics is typically used for polymorphic programming with* virtual methods*. With reference semantics, it is recommended to delete copy and move constructors, as well as copy and move assignment operators to avoid accidental copies when passing objects to functions taking arguments by values, causing object slicing. (They can also be made private). Explicit cloning of a reference semantics object is generally allowed via a call to a* clone virtual method.

In a C++ codebase, the existence of public copy or move constructors alongside virtual methods in the same class is generally a sign of a bad design.

The use of value semantics for xwidgets provides clear lifetime management for associated resources. Careful use of the move semantics provides fine-grained control.

Illustration of the move semantics for xwidgets

Another advantage of using value semantics in xwidgets is that C++ beginners who are typical users of the Jupyter notebook (often used by instructors) can easily manipulate “widgets as values” without having to deal with manual memory allocation etc.

With value semantics, addressing the lifetime of objects becomes the responsibility of the framework author, in a carefull implementation of (copy and move) constructors, destructors, and (copy and move) assignment operators.

Static polymorphism and the CRTP pattern

While the use of value semantics provides fine-grained control over the lifetime of widgets, it prevents the use of virtual methods in their implementation. Code reuse is achieved with static polymorphism techniques and specifically the CRTP pattern.

The Curiously Recurring Template Pattern (CRTP) is the practice of making a class X derive from a class template instantiation using X itself as a template argument.

class X : public base<X>

CRTP is commonly used by matrix or tensor algebra libraries making use of expression templates (such as xtensor, eigen, or blitz) to prevent the overhead of virtual function dispatch for operations likely to be performed in a loop, such as element access.

Placing common code in a CRTP base allows code reuse without the overhead of virtual dispatch. However, the template base class is specialized for each final type increasing the resulting binary size. This can be mitigated by factoring as much of the code in a base class that would not be templated by the derived type.

CRTP in xwidgets — closing the recursion

In order to allow for code reuse without virtual inheritance, xwidgets’ class hierarchy is entirely based on CRTP. Our naming scheme is that CRTP bases, which should not be instantiated directly are prefixed with the letter x and final concrete widget types are not.

Upon construction of e.g. the button widget, constructors of base types are called in the order of inheritance, which is why we need to establish the connection with the frontend in the constructor of the most derived type, after all attributes have been initialized, and send a message to the frontend with all the values.

The pattern for creating the most derived type being always the same, we defined the xmaterialize template class closing the CRTP hierarchy with

using button = xmaterialize<xbutton>;

The xmaterialize template class is defined as final, to prevent further inheritance. The constructors and assignment operators forward to those of the CRTP bases and implement the RAII pattern.

template <template <class> class B, class... P>
class xmaterialize final : public B<xmaterialize<B, P...>>
{
public:

    using self_type = xmaterialize<B, P...>;
    using base_type = B<self_type>;

    template <class... A>
    xmaterialize(A&&...)
        : base_type(std::forward<A>(args)...)
    {
        this->open();      //  RAII: create the frontend model.
    }

    template <template <class> class B, class... P>
    inline xmaterialize<B, P...>::~xmaterialize()
    {
        if (!this->moved_from())
        {
            this->close();  // RAII: delete the frontend model.
        }
    }

...

};

The full implementation of xmaterialize (as of xwidgets 0.25) is available here. Beyond the logic described in this section, it also includes the handling of the move semantics and the method chaining API which is the subject of a later section.

Precompilation and binary size optimization

Even though xwidgets is fully based on template types, we decided to precompile all final widget types for faster interactive use with the xeus-cling kernel. This is achieved with

an extern declaration in the header (here in xbutton.hpp)

extern template class xmaterialize<xbutton>;

and in the source file (here in xbutton.cpp), an instruction for the precompilation

template class XWIDGETS_API xmaterialize<xbutton>;

Doing this for all widget types of the library initially resulted in a large compiled binary size. Using the button widget as an example, we see that base types are templated by the final type in the class hierarchy button -> xbutton<button> -> xwidgets<button> -> xobject<button>, and therefore, their binary representation is duplicated for each final type.

A strategy for reducing the binary size has been to factor out as much of the logic of xobject<D> in a non-template base xcommon improving compilation speed and preventing binary code duplication.

Xproperty: an implementation of the observer pattern

In order to update the frontend upon changes of widget properties, xwidgets relies on an implementation of the observer pattern called xproperty. xproperty is to xwidgets what traitlets are to ipywidgets.

In order to trigger observers and validators in the owner object upon assignment of new values, xproperty relies on the overload of the assignment operator =.

template <class T, class O>
template <class V>
inline auto xproperty<T, O>::operator=(V&& value) -> reference
{
    // Before assigning the new value, invoke validators
    // which may also mutate the value.
    m_value = owner()->template invoke_validators<T>(m_name, std::forward<V>(value));

    // Call class-level observer.
    owner()->notify(m_name, m_value);

    // Call registered observers for that attribute
    owner()->invoke_observers(m_name);

    // Return the new value 
    return m_value;
}

Jupyter interactive widgets have many attributes that may be specified at construction time.

In the Python implementation, this is handled with keyword arguments, but the C++ programming language does not support keyword arguments. There exist various approaches to enable this feature with advanced metaprogramming techniques. In the case of xwidgets, this need is limited to the initialization of xproperty attributes, which allowed us to adopt a more scoped approach: a method chaining API for property initialization:

auto slider = slider<double>::initialize()
  .min(-1.0)
  .max(1.0)
  .description("Another slider")
.finalize();

this was enabled by overriding the function call operator () on xproperties to pass an intial value (only when the said property is an rvalue). A static initialize method is used instead of the default constructor to prevent the initialization of the JavaScript counterpart while all attributes may not have been set yet. The frontend counterpart is only acquired with the finalize() call.

Building upon xwidgets

Jupyter interactive widgets are not limited to the controls available in the core package. In fact, there is a rich ecosystem of widget libraries built upon the core framework: ipyvolume (3-D plotting), ipyleaflet (maps visualization), bqplot (2-D plotting), ipygany (3-D mesh visualization), ipycanvas (generic drawing), ipywebrtc (streaming video and audio), and many many more.

For the C++ programming language, we have already provided:

xleaflet (the C++ equivalent to ipyleaflet, reusing the same frontend),
xwebrtc (the C++ equivalent to ipywebrtc, reusing the same frontend).

Screencast of xleaflet in JupyterLab, loading and visualizing a GeoJSON dataset in a C++ notebook.

Potentially, C++ backend to all Jupyter interactive widget packages could be provided, creating a huge opportunity for interactive data visualization in C++.

C++ should allow overloading the dot operator

xwidgets and xproperty makes heavy use of value semantics, and proxy objects.

At the moment, to access an attribute or method of a value held in an xproperty object, we must first call the function call operator () to access the undelying object first, which is cumbersome.
This is also an issue in other places in the xwidgets stack, when making use of e.g. reference proxies.

Being able to automatically map all methods of the underlying type to be accessible in the xproperty would be incredibly powerful, and remove the need for explicitly accessing the underlying.

Interestingly, the C++ standard does have the equivalent operator overload when it comes to pointer semantics, with the arrow operator ->. If overloading the dot operator . was allowed, this could enable this kind of usecase:

struct V
{
    void f();
};

struct X
{
    V& operator.() { return m_value; }
    V m_value;
};

in which case, X::f would call V::f .

Allowing the overloading of the dot operator . would also enable usecases such as smart references (similar to smart pointers, but with value semantics) and fully-fledged reference proxies (such as the return type of operator[] for std::vector<bool>).

Try it online!

Thanks to MyBinder, you can try xwidgets without the need of installing anything on your computer. Just follow this link:

About the author

Sylvain Corlay is the founder and CEO of QuantStack, an open-source software development studio comprising maintainers of key projects of the scientific computing ecosystem.

As an open-source developer, Sylvain is very active in the Jupyter project, contributing to the Xeus stack, Jupyter interactive widgets, Voilà dashboards. He is a member of the Jupyter steering committee and was the vice chair of JupyterCon 2020. Sylvain also contributes to the conda-forge project and he is the co-creator of the Xtensor C++ tensor algebra library.

A C++ API for Vega-Lite

2020-12-02T15:27:00+00:00

In this post, we present the first public release of XVega, a C++ library for producing Vega-Lite charts.

Data science workflows differ from traditional software development in that engineers make use of available tools to explore and reason about a problem. In such exploratory work, engineers load data, crunch numbers, produce simple visualizations and iterate… Progress happens in quick incremental iterations, which is possible when tooling does not get in the way.

This kind of interactive computing is generally associated with the Python or R programming languages. However, with the advent of the Cling C++ interpreter from CERN, and the subsequent development of the xeus-cling Jupyter kernel, new possibilities have opened up in this space.

The Jupyter stack — that started in the scientific Python community has evolved into a language-agnostic framework that can now be leveraged by C++ developers. It bridges the gap between the countless scientific computing libraries and tools available in C++ and the Jupyter ecosystem.

The scientific C++ stack now has numerous projects under its belt — such as xtensor, xframe, etc. However, there is little support for visualization — especially for interactive plots. While there exist matplotlib-cpp and matplotplusplus (with their plotting API resembling the original matplotlib library) — they suffer from the same cons as the original library does (such as the imperative API and the confusion between dual object-oriented and state-based interface).

Owing to all these shortcomings, along with the observation that JupyterLab comes with existing support for Vega and Vega-Lite Charts (through the application/vnd.vegalite.v3+json MIME type), one can leverage this support to bridge the gap rather than reinvent the wheel. Apart from standalone use — one could also integrate such a system into other projects such as xeus-SQLite.

The main idea is to programmatically fill in a JSON that conforms to the Vega-Lite specification and respects the notion of grammar of graphics. It is analogous to what Altair did for Python. We will expose different APIs responsible for filling in certain parts of the JSON.

The fundamentals with XVega are still the same, i.e. the three essential elements of a Chart are Data, Marks and Encodings as usual and importing the library is as simple as writing two statements:

#include "xvega/xvega.hpp"

using namespace xv;

The experience is similar to what Altair offers and, hence, the central piece to the library is the Chart() object — which knows how to emit the JSON dictionary representing the data and visualization encodings.

For those unfamiliar with the Vega ecosystem, a quick recap for the above terms is given below:

Marks — What graphic should represent the data?
Encodings — Mapping between Data and Visual Elements of the Chart (such as x-axis, etc.).
Encoding Types: Quantitative (real-valued), Nominal (unordered categorical), Ordinal (ordered categorical), Temporal (time-series).

Basic usage of XVega showcasing the essential elements — Data, Marks and Encodings.

The core strength of using such a system is the separation of specification and execution. The declarative API makes it easy to specify “what” should be done rather than focus on incidental details of the “how”. It means that rather than having a special “hist()” function for plotting a histogram, passing “bin=True” does the job.

Simply stating bin=True bins the x-axis giving us the Histogram directly — without using a dedicated function.

We can of-course customize the binning parameters with a “Bin()” object instead. And while we are doing that, let’s add a colour encoding as well to get a sense of the 3rd dimension.

More control can be achieved using a custom Bin() object — used to set the binning parameters.

Another plus of using Vega-Lite is the possibility of using transformations within the specification rather than doing it before.
(E.g., one can do linear regression as a part of this declarative API).

Usage of layering and transformations in XVega.

Lastly, support for Interactions and Selections is a no-brainer. It’s as simple as defining what to use and adding it to the Chart() object.

Zooming and Panning along with Tooltips using Interval Selection in XVega

Developing such a system for C++ comes with its own challenges and to provide a seamless experience like Altair, several things are needed to be taken care of:

Multiple types for a single entity: the Vega-Lite specification allows variables of different kinds (such as a boolean type and an integer type may be equally valid for a particular property). Variants and Visitors in C++ allow us to achieve this.
Out of order keyword arguments: Method chaining is the classical approach to tackle out-of-order keyword arguments in C++ and is what is used in XVega indeed.
Optional fields: A lot of values in the Vega-Lite specification are optional, and this is made possible by the optionally contained values in C++ (i.e. using std::optional).

Installation

You can install XVega with conda or mamba:

mamba install -c conda-forge xvega

conda install -c conda-forge xvega

What is coming?

XVega is still at an early stage and under active development. We are currently working on integrating it with the xeus-sqlite and other SQL Jupyter kernels to enable the visualization from SQL queries. We are also working on improving the compilation time of XVega with Cling.

Acknowledgements

This work on XVega was funded by QuantStack. Thanks to Sylvain Corlay and Johan Mabille for their continuous support.

It is an exciting time for the interactive C++ ecosystem, as so much innovation is happening in the Cling and Jupyter projects. There is a lot more to come for sure. If you are interested in helping us build that future, come talk to us at Gitter and GitHub.

About the Author

My name is Madhur Tandon, and I currently work with QuantStack as a Scientific Software Engineer. Before joining QuantStack, I have worked with Mozilla, Deepnote, INCF (International Neuroinformatics Coordinating Facility), TCS Research and Elucidata. I have also been a speaker at JupyterCon 2020 and PyData Delhi 2017 and 2018. I graduated from IIIT-Delhi this year with a Bachelor’s degree in Computer Science with Honors. Besides core Data Science and Machine Learning, I am interested in tools that enable and enhance data scientists’ workflow and experience.

Xeus is now a Jupyter subproject

2020-02-04T12:08:00+00:00

It is a great pleasure to announce that the Xeus project has been incorporated as a Jupyter subproject. Xeus will now be subject to the Jupyter governance and code of conduct.

For reference, the Jupyter Enhancement Proposal (JEP) for the Xeus incorporation is available here.

What is Xeus?

The Xeus project is a C++ implementation of the Jupyter kernel protocol. Xeus is not a kernel, but a library meant to facilitate the authoring of kernels.
Several Jupyter kernels have been created with Xeus:

xeus-cling, a kernel for the C++ programming language, based on the Cling C++ interpreter. The cling project comes from CERN and is at the foundation of the ROOT project.

The xeus-cling Jupyter kernel for the C++ programming language.

xeus-python, a kernel for the Python programming language, embedding the Python interpreter.

The xeus-python Jupyter kernel for the Python programming language

xeus-calc, a calculator kernel, meant as an educational example on how to make Jupyter kernels with Xeus.

Beyond these three kernels built on top of Xeus by the Xeus maintainers, third-parties have developed other Jupyter kernels with Xeus:

JuniperKernel, a kernel for the R programming language by Spencer Aiello.
xeus-fift, a kernel for the fift programming language by Michael Zaikin. The fift programming language was developed by Telegram to create TON blockchain contracts.
SlicerJupyter, a kernel for the Python programming language by Kitware which integrates into the Qt event loop of the Kitware “Slicer” project.

Finally, the xeus-python kernel includes a first implementation of the Jupyter debugger protocol used by the Jupyter debugger project. xeus-python enables the Debug Adapter Protocol over the Control channel through new debug request/reply and debug event messages.

Why moving Xeus under the Jupyter governance?

While Xeus started as a side project for QuantStack engineers, the project now has several stakeholders who depend on it. We think that moving the project to an open governance organization may be a better way to reflect this situation.

Acknowledgements

Xeus was started by the team of open-source developers at QuantStack as a separate project, but with the full intent to incorporate it into Jupyter. The initial project development at QuantStack was funded by Bloomberg.
Now, Xeus contributors work in many institutions, including Université Paris-Saclay and École Polytechnique.

About the Author

Johan Mabille is a Scientific Software Developer at QuantStack, specializing in high-performance computing in C++. He holds master’s degree in computer science from Centrale-Supelec.

As an open source developer, Johan coauthored xtensor, xeus, and xsimd. He also made major contributions to the JupyterLab debugger project and bqplot.

Field Report on the Kernel Community Workshop

2019-10-07T13:24:00+00:00

From May 27th to May 29th 2019, thirty developers from the Jupyter community met in Paris for a three-days workshop on the Jupyter kernel protocol.

Attendees to the Jupyter Community Workshop on Kernels

For three days, attendees worked full time on the Jupyter project, including hacking sessions and discussions on improvements to Jupyter protocols and standards.

We were lucky to count five core developers to the project and several more regular contributors to the larger ecosystem in the group!

Beyond the hacking sessions, each day was concluded with a series of presentations and demos of the progress made during the workshop.

Why a workshop on Jupyter kernels?

The Jupyter Kernel protocol is one of the main extension points of the Jupyter ecosystem. Dozen of language kernels have been developed by the community, and these languages can then leverage the other components of the stack, such as the notebook, the console, and interactive widgets.

One of the objectives of this event was to foster collaboration between kernel developers and core contributors and develop common tools used across all language kernels. Another goal was to work improving the protocol, to support visual debugging, parameterized kernels, etc.

Technical Achievements

A lot of work was done during the workshop. Several people were working on new Jupyter kernels for programming languages.

We were amazed to see how much was achieved in just three days. Today, we are still working on projects that stemmed from this community workshop.

JupyterLab Debugger

One area in which the Jupyter team is actively working is support for visual debugging in JupyterLab. This is a major endeavor spanning from the front-end to the back-end, including changes to the Jupyter protocol.

The kernel workshop was the occasion for several developers (Wolf Vollprecht, Maarten Breddels, Johan Mabille, Loic Gouarin) to get together and hack on the implementation of the frontend. A lot of work had been done ahead of the workshop with a new Python kernel based on the Xeus library. This new kernel includes a backend to the Debug Adapter Protocol over kernel messages.

The JupyterLab Visual Debugger

There are other key contributors to the debugger project who did not attend the community workshop. We should mention Jeremy Tuloup and Afshin Darian who are spearheading the frontend development.

A Calculator Jupyter Kernel based on xeus

Vasavan Thirusittampalam and Thibault Lacharme were in the middle of their summer internships as scientific software developers at QuantStack when they attended the workshop. During the event, they set themselves up to implement a new Jupyter kernel in C++!

At the end of the workshop, they were able to demonstrate a functional calculator kernel based on xeus, a C++ implementation of the Jupyter protocol! This was later polished and resulted in the publication of a blog post on the Jupyter blog: “Building a Calculator Jupyter Kernel”. This example may serve as an example for people interested in creating new language kernels with xeus.

A prototype Julia backend to Jupyter interactive Widgets.

During the workshop Sebastian Gutsche (who is the author of the Singular Jupyter kernel and a co-author of the GAP kernel), set himself to develop a backend to Jupyter interactive widgets for the Julia progamming language. The current state of the code can be found here.

The Julia backend to jupyter widgets is still early-stage but should this project be completed, it would enable other Jupyter widget libraries for the users of the Julia Jupyter kernel, such as ipyvolume, ipyleaflet, bqplot, etc.

The Julia backend to Jupyter widgets

Parameterized Kernelspecs

Paul Ivanov and Kyle Kelley worked on ironing out the proposal for the support of parameterized kernelspecs. The objective is to make it possible to pass user-specified arguments to kernels upon launch.

In the proposal, the parameters expected by the kernel executable and the possible values for these parameters may be specified in the kernelspec file or a companion file to the kernelspec in the form of a JSON schema.

Paul and Kyle produced extensive notes on various aspects on the subjects such as

the storing of previously used values of the parameters (in notebooks)
the web UI design on how to specify parameters
the definition of default values

More details will be shared at a later stage on the subject of parameterized kernelspecs.

Note: the subject of parameterized kernelspecs was also central in the earlier community workshop about the Jupyter server organized at IBM by Luciano Resende.

Forking of Jupyter Kernels

Starting of kernels is an expensive operation, and executing a whole notebook even more. For certain use cases (such as dashboards based on Voilà), it is useful to have a pre-executed notebook ready, so that dashboards can be presented instantly to a user. To enable this, Maarten Breddels came up with the idea of forking kernels and put together a proof-of-concept implementation. The implementation can be found in pull requests to jupyter_client (PR #441) and ipykernel (PR #410).

Forking kernels will also allow interesting features such as an undo/rollback of cell execution in the notebook. While it is still a proof of concept, this subject has already sparked interest in the community.

Acknowledgments

This event would not have been possible without the generous support provided by Bloomberg, who made this workshop series possible

We are grateful to CFM for gracefully hosting the event.

We should also thank Ana Ruvalcaba from Project Jupyter for her incredible work on the logistics and finances of the Jupyter Community Workshop series.

Building a Calculator Jupyter Kernel

2019-07-16T08:36:00+00:00

A step-by-step guide for authoring language kernels with Xeus

An early device for interactive computing

In order to provide a language-agnostic scientific development environment, the Jupyter project is built upon a well-specified protocol to communicate with the Kernel, the part of the infrastructure responsible for executing the code.

For a programming language to leverage the potential of the Jupyter ecosystem, such as JupyterHub, JupyterLab, and interactive widgets, all that is needed is a Kernel to be created for that language that is, an executable implementing the specified inter-process communication. Dozens of kernels have already been implemented bringing Jupyter to many programming languages.

We are completing our engineering degree and interning at QuantStack. We recently attended the Jupyter Community Workshop on the kernel protocol that took place in Paris in late May. In this occasion, we set ourselves to write a new Jupyter kernel.

Today, we are proud to announce the first release of xeus-calc, a calculator kernel for Jupyter! xeus-calc is meant to serve as a minimal, self-containedexample of Jupyter kernel. It is built upon the xeus project, a modern C++ implementation of the protocol. This article is a step-by-step description on how the kernel was implemented.

You may find this post especially useful if you are creating a new programming language and you want it to work in Jupyter from the start.

Xeus

Implementing the Jupyter kernel protocol from scratch may be a tedious and difficult task. One needs to deal with ZMQ sockets and complex concurrency issues, rely on third-party libraries for cryptographically signing messages or parsing JSON efficiently. This is where the xeus project comes into play: it takes all of that burden so that developers can focus on the parts that are specific to their use case.

In the end, the kernel author only needs to implement a small number of virtual functions inherited from the xinterpreter class.

#include "xeus/xinterpreter.hpp"
#include "nlohmann/json.hpp"

using xeus::xinterpreter;
namespace nl = nlohmann;

namespace custom
{
    class custom_interpreter : public xinterpreter
    {
    public:

        custom_interpreter() = default;
        virtual ~custom_interpreter() = default;

     private:

        void configure() override;
        nl::json execute_request_impl(int execution_counter,
                                      const std::string& code, 
                                      bool silent, 
                                      bool store_history,
                      const nl::json::node_type* user_expressions,
                                      bool allow_stdin) override;
    
        nl::json complete_request_impl(const std::string& code,
                                       int cursor_pos) override;

        nl::json inspect_request_impl(const std::string& code,
                                      int cursor_pos,
                                      int detail_level) override;

        nl::json is_complete_request_impl(const std::string& code)
        override;

        nl::json kernel_info_request_impl() override;
    };
}

Typically, a kernel author will make use of the C or C++ API of the target programming language and embed the interpreter into the application.

This differs from the wrapper kernel approach documented in the ipykernel package where kernel authors make use of the kernel protocol implementation of ipykernel, typically spawning a separate process for the interpreter and capturing its standard output.

Jupyter kernels based on xeus include:

xeus-cling: a C++ kernel built upon the cling C++ interpreter from CERN
xeus-python: a new Python kernel for Jupyter.
JuniperKernel: a new R kernel for Jupyter based on xeus.

In this post, instead of calling into the API of an external interpreter, we implement the internal logic of the calculator in the kernel itself.

Exposing the xeus calculator to Jupyter

A calculator project

First, to implement your own Jupyter kernel, you should install Xeus. You can either download it with conda, or install it from sources as detailed in the readme.

Now that the installation is out of the way, let’s focus on the implementation itself.

Recall that the main class for the calculator kernel must inherit from the xinterpreterclass so that Xeus can correctly route the messages received from the front-end.

This class defines the behavior of the kernel for each message type that is received from the front-end.

kernel_info_request_impl: returns the information about the kernel, such as the name, the version or even a “banner”, that is a message that is prompted to console clients upon launch. This is a good place to be creative with ASCII art.
complete_request_impl: checks if the code can be completed, by that we mean semantic completion, and makes a suggestion accordingly. This way the user can receive a proposition for an adequate completion to the code he is currently writing. We did not use it during our implementation as you will see later, it is safe to return a JSON with a status value only, if you do not want to handle completion.
is_complete_request_impl: whether the submitted code is complete and ready for evaluation. For example, if brackets are not all closed, there is probably more to be typed. This message is not used by the notebook front-end but is required for the console, which shows a continuation prompt for further input if it is deemed incomplete. It also checks whether the code is valid or not. Since the calculator expects single-line inputs, it is safe to return an empty JSON object. This may be refined in the future.
inspect_request_impl: concerns documentation. It inspects the code to show useful information to the user. We did not use it in our case and went with the default implementation (that is to return an empty JSON object).
execute_request_impl: the main function. An execute_request message is sent by the front-end to ask the kernel to execute the code on behalf of the user. In the case of the calculator, this means parsing the mathematical expression, evaluating it and returning the result, as described in the next section.

Implementation of the calculator

First things first, we need to find a way to parse mathematical expressions. To do so, we turn the user input into Reverse Polish Notation (or RPN), a name full of meaning for the wisest among our readers (or at least the oldest) who used RPN calculators in high school.

The RPN, also called Postfix notation, presents the mathematical expression in a specific way : the operands go first followed by the operator. The main advantage of this notation is how it implicitly displays the precedence of operators.

Reverse Polish Notation illustration

The main logic of the calculator is provided by two main functions dealing respectively with parsing and evaluating the user expression and a third one for handling spaces in the expression.

First we have the parsing function (parse_rpn) transforming the expression into this representation. For this purpose we implement the Shunting-yard algorithm.

It is based on the use of a stack data structure to change the order of the elements in the expression, depending on their type : operator, operand or parenthesis.

Transforming a user expression into RPN

Now that we have the expression turned into RPN (with spaces delimiting operands and operators) we need to do the computation. For this purpose we have the function compute_rpn. Its implementation is based on a loop through a stringstream (hence the need for space delimiters) which performs operations in the right order.

Note that the result is not returned as an execute_reply message but is sent on a broadcasting channel instead, so that other clients to the kernel can also see it. The function execute_reply_impl actually returns the status of the execution only, as you may see in the code below.

nl::json interpreter::execute_request_impl(int execution_counter,
                                           const std::string& code,
                                           bool /*silent*/,
                                           bool /*store_history*/,
                                           nl::json /*user_exprs*/,
                                           bool /*allow_stdin*/)
{
    nl::json pub_data;
    std::string result = "Result = ";
    auto publish = [this](const std::string& name, 
                          const std::string& text) {
        this->publish_stream(name,text);
    };
    try
    {
        std::string spaced_code = formating_expr(code);
        result += std::to_string(compute_rpn(parse_rpn(spaced_code,
                                                       publish),
                                             publish));
        pub_data["text/plain"] = result;
        publish_execution_result(execution_counter,
                                 std::move(pub_data),
                                 nl::json::object());
        nl::json jresult;
        jresult["status"] = "ok";
        jresult["payload"] = nl::json::array();
        jresult["user_expressions"] = nl::json::object();
        return jresult;
    }
    catch (const std::runtime_error& err)
    {
        nl::json jresult;
        publish_stream("stderr", err.what());
        jresult["status"] = "error";
        return jresult;
    }
}

And that’s it for our calculator! It is as simple as that.

Yet remember that Xeus is a library, not a kernel by itself. We still have to create an executable that gathers the interpreter and the library. This is done in a main function whose implementation looks like:

int main(int argc, char* argv[])                       
{                           
    // Load configuration file                           
    std::string file_name = 
        (argc == 1) ? "connection.json" : argv[2];                           
    xeus::xconfiguration config = 
        xeus::load_configuration(file_name);                                                   
    
    // Create interpreter instance                           
    using interpreter_ptr = std::unique_ptr<xeus_calc::interpreter>;                           
    interpreter_ptr interpreter = 
        std::make_unique<xeus_calc::interpreter>();                              
    
    // Create kernel instance and start it                           
    xeus::xkernel kernel(config, 
                         xeus::get_user_name(), 
                         std::move(interpreter));                           
    kernel.start();                                                   
    return 0;
}

First, we need to load the configuration file. To do so, we check if one was passed as an argument, otherwise, we look for the connection.json file.

Then, we instantiate the interpreter that we previously set up. Finally, we can create the kernel with all that we defined beforehand. The kernel constructor accepts more parameters that allow customizing some predefined behaviors. You can find more details in the Xeus documentation. Start the kernel and we are good to go!

Now that everything is set, we can test out our homemade calculator kernel.

As you can see in the demonstration below, the code displays step-by-step how the computation is done with RPN. This is done with publish_streamstatements, which is equivalent to std::cout for the Jupyter notebook, very useful for debugging purposes.

The final result, a functional calculator!

You should now have all the information you need to implement your own Jupyter kernel. As you noticed, the Xeus library makes this task quite simple. All that you have to do is to inherit from the xinterpreter virtual class and implement the functions related to the messaging protocol. Nothing more is required.

This project can be found on GitHub. Feel free to contribute to the project if you wish to improve it, keeping in mind that xeus-calc should remain lean and simple!

Note that the current implementation only supports arithmetical operators. However it can be easily extended and we may add functional support in the near future.

Acknowledgments

We would like to thank the whole QuantStack team for their help throughout the process of making this blog post.

We are also grateful to the organizers of the Jupyter community workshop on kernels as we actually started to endeavor during the event.

About the authors

Vasavan Thiru is completing a master’s degree at Sorbonne Université Pierre & Marie Curie in applied mathematics for mechanics. He is currently interning as a scientific software developer at QuantStack.

Thibault Lacharme is finishing a master’s degree in Quantitative Finance at Université Paris Dauphine. Thibault is currently on his internship as a scientific software developer at QuantStack.

A new Python kernel for Jupyter

2019-01-09T09:16:00+00:00

Project Jupyter aims at providing a consistent set of tools for interactive computing workflows across multiple programming languages. Jupyter projects are popular at all stages of a research project from the exploration phase to the communication of results and teaching.

The flagship project of Jupyter, the Notebook, and its modernized version, JupyterLab are web applications allowing the creation of documents including prose, executable code, and interactive visualizations.

The kernel is the part of the backend responsible for executing code written by the user in the web application. For example, in the case of a Python notebook, execution of the code is typically handled by ipykernel, the reference implementation.

History

Initially, the IPython project included everything from the notebook web application to the kernel and server implementation. Later on, the language-agnostic parts (the notebook format, messaging protocol, qtconsole, notebook web application) were split into separate projects with a clearer scope, together forming Project Jupyter.

The Big Split(TM) of IPython

Splitting IPython into multiple packages was a good decision in that it brought a clear separation of concerns between the projects. The ipykernel project was elected as the reference implementation of the Jupyter kernel protocol.

This came at a cost since ipykernel brought all the history and technical debt of IPython with it. Besides, Python is not a natural language for a base implementation. As a result, R and Julia kernels don’t use the reference implementation but use their own implementation of the protocol.

Furthermore, the standard implementation of the Jupyter Interactive Widgets lies in the Python package ipywidgets. That means that once you, as a kernel developer, implemented the Jupyter kernel protocol, you would still need to make your own backend for the interactive widgets if you want widgets support (and you should want it, honestly…).

To prevent this useless duplication of effort, which harms sustainability, we set ourselves to implement a solid reusable implementation of the Jupyter kernel protocol, xeus.

C++ implementation of the kernel protocol

Xeus is a C++ implementation of the Jupyter kernel protocol. It is not a kernel by itself but a library that helps kernel authoring. Xeus is very helpful when developing a kernel for a language that has a C or a C++API (Python, Lua, SQL, etc.). It takes the cumbersome task of implementing the Jupyter messaging protocol for you so you just can focus on the core interpreter tasks: executing code, inspecting, completing, etc.

C++ is a good choice for a standard implementation of the protocol, it is a common denominator of most of the languages out there, it has a massive developer community and is widely adopted in the industry for performance middleware applications.

With xeus, it is also very easy to reimplement core logic (server, kernel, history management etc.), if need be, by simply inheriting from xeus library classes.

Xeus is already known for being used as a base for the C++ kernel xeus-cling.

A xeus-based C++ Kernel

Xeus-cling is a xeus-based C++ kernel for the Jupyter Notebook. It’s very useful for teaching or learning C++. C++ has never been this interactive, thanks to the combined power of Jupyter, xeus, and cling. And even more impressive than executing interpreted C++, it supports interactive widgets, thanks to the xwidgets project.

Just like xeus is a C++ implementation of the Jupyter kernel protocol, xwidgets is a C++ implementation of the Jupyter Interactive Widgets protocol, and it can be used as a base for other implementations.

You can try it right now with binder, without the need of installing anything on your computer, just by clicking on this link.

Interactive C++ in the Jupyter Notebook

A xeus-based Python kernel

Today, I am pleased to announce a new Python kernel based on xeus: xeus-python.

Xeus-python supports error formatting, rich display, interactive widgets, input requests, code completion, code inspection, etc.

Thanks to xeus and pybind11, it was very straightforward to have a first simple version of a Python kernel written in C++. It took a couple of months to have the features listed above, with a relatively small amount of code (< 3000 lines of C++) and a good coverage of ipykernel’s features.

Simple code execution

Error formatting

Code completion

Ipywidgets support

Just like with xeus-cling, you can try it online without the need of installing anything on your computer following this link.

Why another Python kernel?

Obviously, xeus-python does not cover 100% of the features of ipykernel. For examples, IPython magics are not supported yet by xeus-python. However:

xeus-python is a lot lighter than ipykernel and IPython combined, which makes it a lot easier to implement new features on top of it. Our next goal is to augment the protocol to implement a Python debugger in JupyterLab.
xeus-based kernels are more versatile in that one can overload e.g. the concurrency model. This is something that Kitware’s SlicerJupyter project takes advantage of to integrate with the Qt event loop of their Qt-based desktop application.

Acknowledgments

The development of xeus, xwidgets, xeus-python, and related packages are led by QuantStack.

This development is sponsored by Bloomberg.

About the Author

Martin Renou is a Scientific Software Engineer at QuantStack. Before joining QuantStack, he studied at the French Aerospace Engineering School SUPAERO. He also worked at Logilab in Paris and Enthought in Cambridge. As an open source developer at QuantStack, Martin worked on a variety of projects, from xsimd, xtensor, and xframe in C++ to ipyleaflet and ipywebrtc in Python and JavaScript.

Interpreted C++ for GIS with Jupyter

2018-04-24T08:35:00+00:00

A live interactive map in a C++ Jupyter notebook

The recent release of the Jupyter kernel for C++, based on the Cling interpreter enabled a number of new workflows for the users of the C++ programming language.

Features of the xeus-cling C++ kernel for Project Jupyter include:

Showing quick-help pages for functions and classes of the STL and user-defined types, by prefixing them with a question mark:
For example, typing ?std::vector results in a pager displaying the page from cppreference on std::vector.

Quick-help page for classes and functions of the STL

Making use of the rich display features of the Jupyter stack, for user-defined types.
This can be enabled simply by overloading mime_bundle_repr in the namespace of the class for which we wish to have a rich representation in the front-end. The overload is picked up by the display system through argument-dependent lookup (ADL).

Using Jupyter’s rich display mechanism in C++

Another aspect of the newly released C++ kernel is the implementation of the Jupyter widgets protocol, enabling bi-directional communication between the front-end and the kernel.The xwidgets package, built upon xeus provides a complete implementation of the protocol, together with the implementation of most of the controls available in the reference ipywidgets Python package.

Bidirectional communication with the front-end using Jupyter interactive widgets

More than a limited set of base controls, Jupyter widgets are a framework upon which one can build arbitrarily complex interactions. A large number of interactive widget libraries has been built upon ipywidgets. Popular examples include pythreejs (a Jupyter-threejs bridge), bqplot (an interactive plotting library for Jupyter), and ipyleaflet (a Jupyter-leafletjs bridge) allowing rich interactive maps in the Jupyter notebook.

A common trait of most of these packages is that most of the logic is implemented in the front-end, while the back-end only involves synchronization of data attributes.

A fully-specified communication protocol and a thin back-end architecture facilitate the job of kernel authors willing to bring the power of these visualization libraries to their language of choice.

Hence, we have taken on the endeavor of providing a C++ implementation of the most popular Jupyter interactive widget libraries. These packages can be used in the C++ kernel, as well as in compiled application making use of the Jupyter kernel protocol.

Today, we are proud to announce the first release of xleaflet, the C++ counterpart to the popular ipyleaflet package, and which makes use of the same front-end component.

You can get started by simply creating a map inline in the Jupyter notebook.

Specifying a center location and zoom level
Specifying the tile layers to be displayed among the predefined base maps

A simple map with a specified center and zoom level, displaying the default tiles

A number of other attributes can be set in the map widget. To mimic named parameters, all widgets of xwidgets and xleaflet are provided with a generator class which can be used to initialize attributes using method-chaining syntax.

Making use of the generator class to specify any number of attributes of the map upon construction

In addition to the base map feature, a broad number of features of the leaflet JavaScript library are exposed to the C++ backend directly. This includes markers, marker clusters, image overlays, a variety of controls.

Using the marker widget

Whenever an attribute of a widget is modified in the front-end or in the back-end, the other side will properly reflect the data change.

For example, setting marker.location to a new value in the previous example will actually move the marker on the map. Reversely, if the draggable attribute was set to true, whenever the marker position changes in the front-end, the value is reflected in the C++ model.

Observer on the marker position

Another example is the support of the GeoJSON format, which allows one to load a JSON file locally and display its content on the map.

Support for the GeoJSON format

The bidirectional communication between the front-end and the C++ back-end makes it easier for the end user to create interactive web applications without having to write any JavaScript.

Using the rich features of xleaflet, one can start building fully-fledged GIS application in C++.

If you are interested in trying xleaflet right now in your web browser, we provided a binder for you.

Simply click on the following binder link and start playing with interactive GIS in C++ in your web browser:

Click on the image to launch the live demo.

Check out the documentation for more detailed information about xleaflet.

Aknowledgements

The software presented in this post was built upon the work of a large number of people including the Jupyter team, the Cling developers, the developers of xeus and xwidgets, and the developers of leafletjs.

We are especially grateful to Sylvain Corlay, Loic Gouarin, Johan Mabille, and Wolf Vollprecht.

The development of xeus, xwidgets and related packages at QuantStack is sponsored by Bloomberg.

About the Author

Martin Renou is a Scientific Software developer at QuantStack. Prior to joining QuantStack, Martin studied at the French Institute of Aeronautics and Space. As an open source developer, he worked on a variety of projects, notably SciviJS, a JavaScript library for 3-D mesh visualization.

Interactive Workflows for C++ with Jupyter

2017-11-29T16:33:00+00:00

Scientists, educators and engineers not only use programming languages to build software systems, but also in interactive workflows, using the tools available to explore a problem and reason about it.

Running some code, looking at a visualization, loading data, and running more code. Quick iteration is especially important during the exploratory phase of a project.

For this kind of workflow, users of the C++ programming language currently have no choice but to use a heterogeneous set of tools that don’t play well with each other, making the whole process cumbersome, and difficult to reproduce.

We currently lack a good story for interactive computing in C++.

In our opinion, this hurts the productivity of C++ developers:

Most of the progress made in software projects comes from incrementalism. Obstacles to fast iteration hinder progress.
This also makes C++ more difficult to teach. The first hours of a C++ class are rarely rewarding as the students must learn how to set up a small project before writing any code. And then, a lot more time is required before their work can result in any visual outcome.

Project Jupyter and Interactive Computing

The goal of Project Jupyter is to provide a consistent set of tools for scientific computing and data science workflows, from the exploratory phase of the analysis to the presentation and the sharing of the results. The Jupyter stack was designed to be agnostic of the programming language, and also to allow alternative implementations of any component of the layered architecture (back-ends for programming languages, custom renderers for file types associated with Jupyter). The stack consists of

a low-level specification for messaging protocols, standardized file formats,
a reference implementation of these standards,
applications built on top of these libraries: the Notebook, JupyterLab, Binder, JupyterHub
and visualization libraries integrated into the Notebook and JupyterLab.

Adoption of the Jupyter ecosystem has skyrocketed in the past years, with millions of users worldwide, over a million Jupyter notebooks shared on GitHub and large-scale deployments of Jupyter in universities, companies and high-performance computing centers.

Jupyter and C++

One of the main extension points of the Jupyter stack is the kernel, the part of the infrastructure responsible for executing the user’s code. Jupyter kernels exist for numerous programming languages.

Most Jupyter kernels are implemented in the target programming language: the reference implementation ipykernel in Python, IJulia in Julia, leading to a duplication of effort for the implementation of the protocol. A common denominator to a lot of these interpreted languages is that the interpreter generally exposes a C API, allowing the embedding into a native application. In an effort to consolidate these commonalities and save work for future kernel builders, we developed xeus.

Xeus is a C++ implementation of the Jupyter kernel protocol. It is not a kernel itself but a library that facilitates the authoring of kernels, and other applications making use of the Jupyter kernel protocol.

A typical kernel implementation using xeus would in fact make use of the target interpreter as a library.

There are a number of benefits of using xeus over implementing your kernel in the target language:

Xeus provides a complete implementation of the protocol, enabling a lot of features from the start for kernel authors, who only need to deal with the language bindings.
Xeus-based kernels can very easily provide a back-end for Jupyter interactive widgets.
Finally, xeus can be used to implement kernels for domain-specific languages such as SQL flavors. Existing approaches use a Python wrapper. With xeus, the resulting kernel won’t require Python at run-time, leading to large performance benefits.

Interpreted C++ is already a reality at CERN with the Cling C++ interpreter in the context of the ROOT data analysis environment.

As a first example for a kernel based on xeus, we have implemented xeus-cling, a pure C++ kernel.

Redirection of outputs to the Jupyter front-end, with different styling in the front-end.

Complex features of the C++ programming language such as, polymorphism, templates, lambdas, are supported by the cling interpreter, making the C++ Jupyter notebook a great prototyping and learning platform for the C++ users. See the image below for a demonstration:

Features of the C++ programming language supported by the cling interpreter

Finally, xeus-cling supports live quick-help, fetching the content on cppreference in the case of the standard library.

Live help for the C++standard library in the Jupyter notebook

We realized that we started using the C++ kernel ourselves very early in the development of the project. For quick experimentation, or reproducing bugs. No need to set up a project with a cpp file and complicated project settings for finding the dependencies… Just write some code and hit Shift+Enter.

Visual output can also be displayed using the rich display mechanism of the Jupyter protocol.

Using Jupyter’s rich display mechanism to display an image inline in the notebook

Another important feature of the Jupyter ecosystem are the Jupyter Interactive Widgets. They allow the user to build graphical interfaces and interactive data visualization inline in the Jupyter notebook. Moreover it is not just a collection of widgets, but a framework that can be built upon, to create arbitrary visual components. Popular interactive widget libraries include

bqplot (2-D plotting with d3.js)
pythreejs (3-D scene visualization with three.js)
ipyleaflet (maps visualization with leaflet.js)
ipyvolume (3-D plotting and volume rendering with three.js)
nglview (molecular visualization)

Just like the rest of the Jupyter ecosystem, Jupyter interactive widgets were designed as a language-agnostic framework. Other language back-ends can be created reusing the front-end component, which can be installed separately.

xwidgets, which is still at an early stage of development, is a native C++ implementation of the Jupyter widgets protocol. It already provides an implementation for most of the widget types available in the core Jupyter widgets package.

C++ back-end to the Jupyter interactive widgets

Just like with ipywidgets, one can build upon xwidgets and implement C++ back-ends for the Jupyter widget libraries listed earlier, effectively enabling them for the C++ programming language and other xeus-based kernels: xplot, xvolume, xthreejs…

xplot is an experimental C++ back-end for the bqplot 2-D plotting library. It enables an API following the constructs of the Grammar of Graphics in C++.

In xplot, every item in a chart is a separate object that can be modified from the back-end, dynamically.

Changing a property of a plot item, a scale, an axis or the figure canvas itself results in the communication of an update message to the front-end, which reflects the new state of the widget visually.

Changing the data of a scatter plot dynamically to update the chart

Warning: the xplot and xwidgets projects are still at an early stage of development and are changing drastically at each release.

Interactive computing environments like Jupyter are not the only missing tool in the C++ world. Two key ingredients to the success of Python as the lingua franca of data science is the existence of libraries like NumPy and Pandas at the foundation of the ecosystem.

xtensor is a C++ library meant for numerical analysis with multi-dimensional array expressions.

xtensor provides

an extensible expression system enabling lazy NumPy-style broadcasting.
an API following the idioms of the C++ standard library.
tools to manipulate array expressions and build upon xtensor.

xtensor exposes an API similar to that of NumPy covering a growing portion of the functionalities. A cheat sheet can be found in the documentation:

Scrolling the NumPy to xtensor cheat sheet

However, xtensor internals are very different from NumPy. Using modern C++ techniques (template expressions, closure semantics) xtensor is a lazily evaluated library, avoiding the creation of temporary variables and unnecessary memory allocations, even in the case complex expressions involving broadcasting and language bindings.

Still, from a user perspective, the combination of xtensor with the C++ notebook provides an experience very similar to that of NumPy in a Python notebook.

Using the xtensor array expression library in a C++ notebook

In addition to the core library, the xtensor ecosystem has a number of other components

xtensor-blas: the counterpart to the numpy.linalg module.
xtensor-fftw: bindings to the fftw library.
xtensor-io: APIs to read and write various file formats (images, audio, NumPy’s NPZ format).
xtensor-ros: bindings for ROS, the robot operating system.
xtensor-python: bindings for the Python programming language, allowing the use of NumPy arrays in-place, using the NumPy C API and the pybind11 library.
xtensor-julia: bindings for the Julia programming language, allowing the use of Julia arrays in-place, using the C API of the Julia interpreter, and the CxxWrap library.
xtensor-r: bindings for the R programming language, allowing the use of R arrays in-place.

Detailing further the features of the xtensor framework would be beyond the scope of this post.

If you are interested in trying the various notebooks presented in this post, there is no need to install anything. You can just use binder:

The Binder project, which is part of Project Jupyter, enables the deployment of containerized Jupyter notebooks, from a GitHub repository together with a manifest listing the dependencies (as conda packages).

All the notebooks in the screenshots above can be run online, by just clicking on one of the following links:

xeus-cling: the main xeus-cling example notebook,

xtensor: the C++ N-D array expression library in a C++ notebook,

xwidgets: the C++ back-end for Jupyter interactive widgets,

xplot: the C++ back-end to the bqplot 2-D plotting library for Jupyter.

JupyterHub is the multi-user infrastructure underlying open wide deployments of Jupyter like Binder but also smaller deployments for authenticated users.

The modular architecture of JupyterHub enables a great variety of scenarios on how users are authenticated, and what service is made available to them. JupyterHub deployment for several hundreds of users have been done in various universities and institutions, including the Paris-Sud University, where the C++ kernel was also installed for the students to use.

In September 2017, the 350 first-year students at Paris-Sud University who took the “Info 111: Introduction to Computer
Science” class wrote their first lines of C++ in a Jupyter notebook.

The use of Jupyter notebooks in the context of teaching C++ proved especially useful for the first classes, where students can focus on the syntax of the language without distractions such as compiling and linking.

Acknowledgements

The software presented in this post was built upon the work of a large number of people including the Jupyter team and the Cling developers.

We are especially grateful to Patrick Bos (who authored xtensor-fftw), Nicolas Thiéry, Min Ragan Kelley, Thomas Kluyver, Yuvi Panda, Kyle Cranmer, Axel Naumann and Vassil Vassilev.

We thank the DIANA/HEP organization for supporting travel to CERN and encouraging the collaboration between Project Jupyter and the ROOT team.

We are also grateful to the team at Paris-Sud University who worked on the JupyterHub deployment and the class materials, notably Viviane Pons.

The development of xeus, xtensor, xwidgets and related packages at QuantStack is sponsored by Bloomberg.

About the Authors (alphabetical order)

Sylvain Corlay, Scientific Software Developer at QuantStack

Loic Gouarin, Research Engineer at Laboratoire de Mathématiques at Orsay

Johan Mabille, Scientific Software Developer at QuantStack

Wolf Vollprecht, Scientific Software Developer at QuantStack

Jupyter Blog - C++

C++ in Jupyter — Interpreting C++ in the Web

Scaling Jupyter with JupyterLite

Walking up the stack

Emulated Just-in-Time Compilation and WebAssembly

Porting Xeus-Cpp to Emscripten-forge

Features

Inline documentation

Rich display

Advanced Graphics

Loading Third-Party Libraries

Symbolic Computing with Symengine

Array-based Computing

SIMD Acceleration

Magic Commands

Interactive Widgets

How to deploy JupyterLite with Xeus-Cpp

Future work

How to contribute?

Packaging for the Browser

Improving Xeus-Cpp, CppInterOp and Clang-Repl

Areas of Need & Opportunities for Collaboration

About the Authors

Acknowledgements

A Curiously Recurring Widget Library

Using the RAII pattern for a widget library

Static polymorphism and the CRTP pattern

CRTP in xwidgets — closing the recursion

Precompilation and binary size optimization

Xproperty: an implementation of the observer pattern

Method chaining for widget initialization

Building upon xwidgets

C++ should allow overloading the dot operator

Try it online!

About the author

A C++ API for Vega-Lite

Installation

What is coming?

Acknowledgements

About the Author

Xeus is now a Jupyter subproject

What is Xeus?

Why moving Xeus under the Jupyter governance?

Acknowledgements

About the Author

Field Report on the Kernel Community Workshop

Why a workshop on Jupyter kernels?

Technical Achievements

JupyterLab Debugger

A Calculator Jupyter Kernel based on xeus

A prototype Julia backend to Jupyter interactive Widgets.

Parameterized Kernelspecs

Forking of Jupyter Kernels

Acknowledgments

Building a Calculator Jupyter Kernel

Xeus

A calculator project

A new Python kernel for Jupyter

History

C++ implementation of the kernel protocol

A xeus-based C++ Kernel

A xeus-based Python kernel

Why another Python kernel?

Acknowledgments

About the Author

Interpreted C++ for GIS with Jupyter

Aknowledgements

About the Author

Interactive Workflows for C++ with Jupyter

Project Jupyter and Interactive Computing

Jupyter and C++

Acknowledgements

About the Authors (alphabetical order)