REPL: introduce a new jupyter notebook based REPL #1016
Conversation
VSCode has introduced a native jupyter notebook API. Wire up a "kernel" for Swift to provide a native REPL experience within VSCode. This is primarily a PoC implementation that demonstrates how such an implementation could work. The primary limitation in the current implementation is the IO processing in the LLDB REPL. We can apply a heuristic to capture the error message (termination on an empty string), but do not have such a heuristic for the output and currently only capture the first line of the output, leaving the remaining output in the buffer. Improving the stream handling would significantly improve the experience. Co-authored-by: Jeremy Day <[email protected]>
|
@plemarquand anything to do here to move this along? |
|
@compnerd I did finally get a chance to try this out last week and found that the "Evaluate in REPL" functionality didn't work as I expected. Putting the cursor on If I write the same code out in the input window at the bottom of the notebook and execute it, it does get evaluated as I expect. I imagine there is work we could do here to hook everything up to the REPL hosted by the extension, but I think a better long term approach is to build a real Swift Jupyter kernel with something like xeus, likely as its own standalone repo, and then load in or depend on it in the VS Code extension. This would make it a "first class" experience that would be portable to other Jupyter environments. The Swift REPL could still power the kernel as you have it designed here. |
VSCode has introduced a native jupyter notebook API. Wire up a "kernel" for Swift to provide a native REPL experience within VSCode. This is primarily a PoC implementation that demonstrates how such an implementation could work.
The primary limitation in the current implementation is the IO processing in the LLDB REPL. We can apply a heuristic to capture the error message (termination on an empty string), but do not have such a heuristic for the output and currently only capture the first line of the output, leaving the remaining output in the buffer. Improving the stream handling would significantly improve the experience.