Add an option to connect a running REPL instance to the extension

[davidanthoff]

This came out of the discussion at #1027.

The idea would broadly be that one can load some package in a REPL, and then this REPL would be "connected" to VS Code, so that one can send code pieces to that REPL, the plot gallery etc all work.

This is a fairly involved project:

• We would probably generally need the notion of multiple running Julia REPLs in the extension (right now we only have one).
• We would need to figure out how a given REPL knows to which VS Code instance it should connect (we should take a look how the node stuff implements the auto debugger attach functionality)

I think we should hold off from doing anything about this until we have finished both a) the debugger stuff (#957) and b) the workspace UI (#1003), otherwise this will get too complicated. But eventually it would be good to support this scenario.

[haberdashPI]

Great! I've subscribed to those two issues. If I have the resources to contribute to this when it makes sense to start working on it, I'd love to help.

[haberdashPI]

A potentially simpler solution occurred to me for my particular use case. It seems like these capabilities would be sufficient for my needs:

1.) The concept of multiple REPL sessions.
2.) An API to programmatically start a new REPL session with a specified name and a specified command for starting said REPL (e.g. tmux new-session -A -s 'my-project-workspace-julia-session-1' julia)

I think that approach could solve some of the issues you raise with your second point. The julia REPL would know which VSCode instance to run, because said instance would be the one it was launched by (and presumably there is some process by which, when starting julia you tell it about vscode??).

[davidanthoff]

Oh, so you mean that you wouldn't start the Julia REPL from a shell terminal, but instead the julia extension starts it somehow, and then can pass information to that instance on how to connect back to the running extension version? Yes, that would work, that is essentially how we start REPLs currently.

Still, it would actually be neat if I could just in a terminal shell run some julia version (say one that I just compiled from source) and then easily connect to that... But I actually think the biggest lift will be support for multiple REPLs. We'll need UI for that, and then the whole extension right now is structured around the idea that there is only one... I think we'll probably need something like a list of active REPL's, the concept of which one is the "active" one right now (i.e. where code gets sent when executed). In terms of UI, I think once we add the workspace explorer, we could probably nicely integrate it there: it would just be a tree-view, with the REPLs at the top, and then for each REPL it would show the vars of that REPL.

[haberdashPI]

Yes, that's what I mean. I agree it would be neat to be able to connect within a repl. Definitely more versatile. So if I understand, the main challenge is getting the extension to handle multiple REPLs.

One key thing I do in my multi-language extension, that would probably help somewhat here, is to determine the default REPL not on the basis of the "active" REPL, but based on the file the text is being sent from (using the API for storing per-workspace persistent information to map filenames to REPL names); obviously there should be an option to change which REPL you want to use, but I find this to be a pretty sane default assumption.

[haberdashPI]

Hi! Super excited by all the work happening here! Great job!

Is this something that makes sense for me to start looking into now that the above two features have merged?

[davidanthoff]

I think just in terms of next steps, I think it would probably be to make the workspace view that we just merged (and still have one major PR pending) able to handle multiple Julia processes. We'll need that in any case once we merge the notebook stuff, because each notebook will have its own kernel, which is very similar to multiple REPLs. I kind of imagine that we would add one extra top level to the tree in the workspace that represents all the REPLs and kernels that are currently running.

I think once we have that we should add the ability to just start multiple Julia REPLs from the extension (but still have the extension start them).

And then, once all of that is up and running, we could sort out how we can make a Julia instance that was not started by the extension connect to the extension. I actually have a pretty neat design for this now: VS Code added the ability to set env vars from an extension for any terminal that is started in VS Code. So we could set one that gives a named pipe name where any new Julia instance can connect to the extension. We would then just need a super minimal VSCode.jl package that a user can load from a self-started Julia instance. That package would check whether the env var is set, and if yes, connect to that extension instance and load the code that is needed for the integration. I think that whole part would be fairly simply and smooth now.

[davidanthoff]

Oh, and to answer your question: I think @pfitzseb has the best sense right now re the workspace view and in what order we would want to sequence such a change in.

[altre]

Could this also solve microsoft/vscode-remote-release#3096 ? So, start julia in screen and then reconnect a remote vs code instance to it?

[davidanthoff]

Also see my suggestion at the end of JuliaLang/julia#36368. Once that is in base, we could actually get to a point where one starts a shell in VS Code, and if one then starts julia inside that shell, it would have the full integration loaded automatically from the start.

[haberdashPI]

Could this also solve microsoft/vscode-remote-release#3096 ? So, start julia in screen and then reconnect a remote vs code instance to it?

My understanding is yes: that's one of the main reasons I want this feature.

[kescobo]

Is it possible that something else got this to start working? Last couple of days when starting VS code after restarting my computer, I still have my previous session active. I haven't done anything special on my end... seems weird.