Swift in Jupyter

Development LLDB
1

Hi,

This is Anutosh here (a Project Jupyter and an llvm/clang member) but more importantly a swift newbie :slight_smile:

At Project Jupyter, we are trying to bring all languages to the browser using JupyterLite & Web Assembly in the form of a REPL.

The latest one being C++ , one can now do C++

  1. Completely in the browser, no local setup required whatsoever
  2. Interactively in the form of a REPL

Feel free to try out the C++ kernels on this link JupyterLite

You shall also find a few demo notebooks starting with cppxx.ipynb for demonstrating the use case

Feel free to explore anything from BLAS & LAPACK routines through Openblas & Xtensor, to interactive Jupyter widgets to Graphics using SDL.

  1. You can also fetch any 3rd party lib/package as and when you want to use it (and its all gone as soon as you close the instance) . For eg

image
image840Ă—378 66.4 KB

I plan to ideate more on having a similar kernel for swift just like we did for C++. I say this cause I see quite some similarities

A) For C++, we used clang-repl (based on clang & LLVM's ORC JIT and for this we compiled clang & lld using emscripten)

I see swift offers a repl too built on top of lldb (although architecturally different from clang-repl , I would like to ideate a bit on this)

I would like to discuss more here but being new to swift I have quite some doubts. I tried looking on swift's github trying to locate people/teams responsible for maintaining the swift REPL but wasn't successful.

As a first step could someone point me to the maintainers for this project so that I can put forward my doubts ?

7 Likes
2

This has been done before (incidentally, I was involved in 2 such attempts in the past). The first one was based on using LLDB directly via swift-jupyter as part of Google's Swift4TensorFlow project. The second attempt was based around the new VSCode notebook model.

The LLDB project itself is maintained as part of llvm.org; we do have a fork of it primarily maintained by folks who are already part of the LLDB community.

2 Likes
3

If you want to pick up the work that I had started for the VSCode based approach: VSCode jupyter notebook based REPL is the post and it links to the original PR.

1 Like
4

Hi,

Thanks for the reply.

I see the Swift Repl is probably a wrapper over LLDB (and this LLDB is maintained as a fork from llvm)

So my next questions is

  1. Is it documented somewhere as to what efforts were taken by people working on the REPL to have this separate fork on lldb under swift ? After making the required changes on top of lldb what effort was taken to write the swift repl ? Would it make sense to push this work upstream ?

  2. What's the library proving C/C++ API to interact with the swift REPL ? It is swiftImmediate by any chance ? (swift/lib/Immediate at main · swiftlang/swift · GitHub)

Asking this cause as I said for the C++ kernel (GitHub - compiler-research/xeus-cpp: Jupyter kernel for the C++ programming language) whose link I attached above, we used libclangInterpreter from llvm (llvm-project/clang/lib/Interpreter/CMakeLists.txt at main · llvm/llvm-project · GitHub) that exposes the API to interact with clang-repl.

Regards,
Anutosh Bhat

5

I'm not sure what the question here actually is intending to ask. LLDB requires forking because of the additional language mode. That language mode requires having the Swift compiler, which is not upstream. While it would be ideal to have the language support in upstream LLDB, that is a massive undertaking.

What work are you referring to? The basis for the REPL has been upstreamed, and others in the community have used that to build additional REPLs, such as the one that mojo has.

Again, this is very unclear. Who is the actor interacting with the REPL. If you look at the code in the pull request I posted above, there is no library in the middle - it is simply communicating over stdin/stdout.

If this is in context of implementing a jupyter notebook, I would recommend against that. My experiences with writing a jupyter notebook kernel with the C++ APIs was that it is far too fragile. That is why the VSCode notebook approach dooes the direct communication.

6

Hi,

Thanks for your reply. Clears few things for me .

I'm not sure what the question here actually is intending to ask

By this I meant if it was documented anywhere as to what efforts were taken to come up with the swift repl once lldb was forked.

Who is the actor interacting with the REPL

Let me explain what I wanted to convey here. When I say “interact with the REPL,” I mean interacting with the interpreter that the Jupyter Kernel Protocol hooks into.

For example, in kernels for languages like C++, R, Python, or Octave that use the xeus framework, xeus handles the Jupyter Kernel Protocol part. As the docs put it:

“xeus is a library meant to facilitate the implementation of kernels for Jupyter. It takes the burden of implementing the Jupyter Kernel protocol so developers can focus on implementing the interpreter part of the kernel.”

This is the architecture as per the docs

image
image692Ă—628 38.9 KB

So the architecture works like this:

  • xeus implements all the message-passing and protocol compliance.

  • The kernel developer implements an interpreter — the piece that actually takes the code from a execute_request message and runs it.

  • This interpreter talks to the C/C++ API of the language’s REPL/runtime.

Examples:

  1. xeus-cpp

  2. xeus-r

    • Interpreter: the R runtime from r-base

    • C API exposed via Rinternals.h / Rembedded.h to evaluate R code.

  3. xeus-python Interpreter: CPython runtime via the Python C API

    • In practice, xeus-python calls into IPython’s InteractiveShell (a Python object) through pybind11.

So in all these cases, the “interpreter” you implement in C++ is really a bridge:

  • On one side, it receives code from Jupyter via xeus.

  • On the other side, it calls into the native REPL API of the target language to run that code and return results.

So basically what I wanted to know is

  1. If swift repl was based on a “SwiftInterpreter” class as such ? and if there is some way to interact with it through an API (for parsing and executing)
  2. That being said according to the stuff I went through I understand that the swift repl is based on the concept of a “debugger” more than that of an “interpreter” (correct me if I am wrong)

I am still exploring more if I can find some proof of concept for a xeus-swift Kernel.

7

Depends on your view point I suppose. Ultimately, the debugger is a REPL - it reads commands, evaluates, and prints.

The Swift REPL relies on LLDB’s underlying implementation detail of JITing and code injection for the execution capabilities.

8

Thanks again for your reply.

Yes I have been educating myself with the “debugger as a REPL” concept these days.

So I guess we can confirm

  1. There’s no interpreter class as such being offered by Swift.
  2. There’s no C++ API as such to interact with Swift repl and If I am looking to programmatically interact with Swift's REPL, I'd have to use LLDB's C++ API rather than anything provided directly by Swift.

Let me know if that’s correct ?

9

There’s no C++ API as such to interact with Swift repl and If I am looking to programmatically interact with Swift's REPL, I'd have to use LLDB's C++ API rather than anything provided directly by Swift

Unfortunately there is no API at all. You would need to launch the lldb process in repl mode and communicate with it via stdin/stdout.

1 Like
10

Hey Augusto,

Thanks a lot for the reply. I was just looking at Swift Immediate and thinking if this could help (swift/include/swift/Immediate/Immediate.h at main · swiftlang/swift · GitHub)

Not sure if this can be put to use, Probably its not maintaining an incremental state or persistent variables (as maybe what clangInterpreter does for clang-repl) and is only meant to compile one chunk of Swift and run it then ?

11

Hey @augusto2112 ,

Getting back after a while but I did some research.

Feel free to correct me if I am wrong here but this is what I realize

  1. There was a compiler centric REPL even before the debugger centric one. (I think its this what I was looking for based on my questions above)

  2. This also used to expose a runREPL (Remove integrated REPL by slavapestov · Pull Request #31187 · swiftlang/swift · GitHub)
    and it was probably this function that I would have ended up using for my usecase with Jupyter

  3. It was finally removed here Remove integrated REPL by slavapestov · Pull Request #31187 · swiftlang/swift · GitHub
    after some discussion on the RFC (RFC: Removing the integrated REPL - #21 by dan-zheng)

I think a compiler centric REPL would help me case so much more as mostly Jupyter Kernels implementing support for REPLs end up having interpreter/compiler based REPLs and not really debugger based :\

12

Maybe you are interested, (@compnerd fyi) but I do have a working kernel, and can be used from colab as well.

6 Likes
13

Thanks @pedronahum.

One of the reasons that I had taken the alternative approach here was that there was a significant amount of complexity in our work with the Jupyter environment whilst working on S4TF. The VSCode environment could use the host image setup and allowed for a simpler setup for the kernel. I am still somewhat interested in seeing the VSCode based notebook.

However, having the traditional setup can still be good. Looking forward to what you end up with :slight_smile:

Saleem

2 Likes
14

Hi @compnerd,

S4TF has been a huge source of motivation! I'm trying my best to keep some of those ideas alive.

Regarding the kernel, I’m looking for the most accessible way to get the Swift libraries I'm working on running on GPUs and TPUs, and this traditional setup felt like the safest path. I promise to keep everyone posted on how it goes!

Best,

Pedro N.

15

I’m glad to hear that!

That makes sense. I’d point out the alternative option/consideration. The VSCode based approach that I was referring to is similar in that you have a Jupyter style notebook, but rather than requiring the docker container and everything else that entails, you simply run on the host. Look for a post that I made about a year or so ago about it (the PR for that is still on GH under the vscode-swift project).

But, given that runs on the host, I’m not sure if that will help with the TPU side, but you should be able to get a simpler setup that works across CPU and GPU I suspect.

1 Like
16

Thanks for the additional considerations @compnerd. Will take a closer look. Maybe we can even piggy back parts of the code used to update the swift kernel. Let me check…

Best,

Pedro N.