Successor notice?

[philipturner]

I have been working on Swift-Colab for a while, and it seems like a logical successor to google/swift-jupyter. Google is not actively developing this repository anymore, or really anything revolving around the Swift for TensorFlow project. And I learned the hard way that they won't assist my effort to bring it back.

I put a crash course on how Swift-Colab continued the legacy of google/swift-jupyter in ColabSupportHistory.md. It doesn't support Docker anymore, but it's entirely possible to add that as a feature in Swift-Colab 3.0. @marcrasi I am wondering whether you could put a notice on this repo's README, linking to the spin-off that has more up-to-date documentation.

[marcrasi]

Hi! Sounds like a good idea. Do you think this is a good message: https://github.com/google/swift-jupyter/pull/135 ? If so, I could merge that.

[philipturner]

After rewriting your code from scratch, I can only say great work! I fixed a lot of issues and enabled a lot of new features, which I'm in the middle of documenting right now. One example was Google Drive integration, and another was the limitation that you can only import Swift packages in the first cell. Would you mind checking out what I added, after I finish with the documentation overhaul?

You may find ColabSupportHistory.md to be insightful. Do you remember whether Google had the S4TF toolchain pre-downloaded on their servers, or did it download at runtime like Swift-Colab does now?

[liuliu]

Do you also want to include my fork as an alternative to continue run Jupyter Notebook / Jupyterlab locally? https://github.com/liuliu/swift-jupyter/

Moved environment management into Bazel and switched code that delegate out to IPython to implement with Swift (Enhanced EnableJupyterDisplay.swift and removed EnableIPythonDisplay.swift).

[philipturner]

@liuliu I’m trying to add Docker and JupyterLab support to Swift-Colab, and I would like to consolidate all the new activity into one repo. Would you mind merging your work into the Swift Numerics Working Group’s effort to expand platforms supported by Swift-Colab? If so, the thread is here:

https://github.com/philipturner/swift-colab/issues/16

Not to downplay the work you put into the fork, but I don’t know if it’s professional to promote a fork of the repo as an alternative to the main repo itself. Like you could just accept a PR with the fork’s commits instead of going to such great lengths as modifying your own README.

Since Swift-Colab is becoming the successor to swift-jupyter, I would be willing to mention the fork in my own README as a temporary workaround.

[liuliu]

@philipturner no worries. Yeah, I looked at that codebase and don't have clear instructions how to compile locally (seems missing Package.swift or other ways to manage compiling swift source).

My change are not nearly as comprehensive, most notably probably just remove the EnableIPythonDisplay.swift because that caused issues for me in Jupyter Notebook (does it happen for you? When evaluating a simple cell many times when EnableIPythonDisplay.swift called previously, the LLDB process will exit normally (not even crash, because I attach LLDB to that LLDB process :) it will just exit normally without any crashes).

Oh, another thing I just thought about: how did you do code completion? I switched to sourcekit-lsp, but it has this issue where shadowed variables are not legit (reasonable, but unusable for a notebook).

[philipturner]

I didn’t do code completion.

https://github.com/googlecolab/colabtools/issues/2841

[liuliu]

The old completer is probably based on @marcrasi 's LLDB based code completion. I briefly looked at how to port that back to mainline Swift LLDB. Seems to have more refactoring required to mainline Swift / LLVM than I would like and I stopped there.

sourcekit-lsp's completion is better in the sense that LSP's code completion protocol is lightyears ahead of Jupyter: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_completion v.s. https://jupyter-client.readthedocs.io/en/stable/messaging.html#completion

Unfortunately, the way sourcekit-lsp worked make it not so good for cell-by-cell execution environment (mostly because the executed code concatenation cannot form a legit code file).

[philipturner]

After skimming the JS file referenced in the googlecolab/colabtools issue, I saw a lot of JS-side Python code processing, and using “LSP” from Monaco editor. Perhaps the old implementation combined LLDB Jupyter-side with Monaco JS-side.

If the new solution that Colab’s authors (hopefully) come up with restricts completion to Jupyter-side, I will be more restricted in capabilities. Nevertheless, bypassing restrictions on technology is my specialty. I’ll see what creative workarounds and reimplementations I can physically pull off.