You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have started looking closer at this, and I now think that the REPL / SwiftREPL is not the right abstraction to expose through the SBAPI. The REPL / SwiftREPL handles a bunch of commandline UI stuff that is not relevant for a consumer like Jupyter that implements its own UI.
For example, `SwiftREPL::CompleteCode` returns completions in a way that is very specific to how the commandline works (when there is 1 completion, it returns an insertable string so that the UI can insert the text; when there are >1 completions, it returns more detailed "displayable" completions that can't be inserted directly into code because they have type information). The ideal completion API for a consumer like Jupyter would always return some structured data with both "insertable" and "displayable" completions, so that the Jupyter UI can decide what to do with them.
I'm going to try adding a completion function to the SBAPI that is independent from the SwiftREPL completer. This SBAPI completer will return structured completion data.
Additional Detail from JIRA
md5: 26b1e6db75851f3854e3d3732eb2a0f8
Issue Description:
As commented in the Swift Forums (https://forums.swift.org/t/jupyter-kernel-launch-the-debugger-with-the-current-triple-in-repl-mode)) this API would be very useful for implementing LLDB-based REPLs from a Python environment (like a Jupyter kernel).
The text was updated successfully, but these errors were encountered: