Consider managing FSI sessions in FSAC directly

ionide / ionide-vscode-fsharp

VS Code plugin for F# development

http://ionide.io

MIT License

856 stars 277 forks source link

Consider managing FSI sessions in FSAC directly #1720

Open baronfel opened 2 years ago

baronfel commented 2 years ago

Managing sessions directly in FSAC would allow for more full featured treatments for features like the watcher, as well as serving as the foundation for notebook approaches.

There would be some book-keeping around identifying which evaluation session a particular interaction command would be associated with, so we'd want to spec out a small set of custom LSP endpoints specifically for dealing with this, but it would be possible to do something like:

User sends line/selection/file to FSI session via custom LSP endpoint
FSAC identifies the session by some kind of ID and performs the evaluation of the provided line/selection/file
FSAC sends any output of the evaluation to VSCode for display
FSAC extracts the session state after the evaluation using the session.GetBoundValues() API and returns that data to VSCode for display in a watcher (if open)

Originally posted by @baronfel in https://github.com/ionide/ionide-vscode-fsharp/pull/1716#issuecomment-1150607217

Krzysztof-Cieslak commented 2 years ago

User sends line/selection/file to FSI session via custom LSP endpoint

I do wonder if there's some way of just redirecting stdio of the console app into the FCS-hosted FSI session so we keep the ability to type into the terminal. This probably would mean that our "enhanced FSI" would be a separate process (i.e. not FSAC) but since it'd be used just for FSI-related things it shouldn't be too perf-expensive

Krzysztof-Cieslak commented 2 years ago

Proof of concept for the idea of just wrapping FCS-hosted FSI session into console app, it also starts HTTP server which can be used for getting the info about the session: https://github.com/ionide/Falcon/blob/master/src/Falcon/Program.fs

Krzysztof-Cieslak commented 2 years ago

CC: @jcmrva, it may be interesting for you

AngelMunoz commented 2 years ago

This might be kind of related, I've been looking today into the FSI watcher (mostly to test the waters and fun) and I found out it is very annoying to create webviews, would there be interest to also host FSI related Webviews in that out or process server? I'm not too familiar with the code extensions API so I'm not sure if you can just use any URL but that would also give us an edge to use F# tooling for the website rather than just try to force strings for webviews

jcmrva commented 2 years ago

@Krzysztof-Cieslak I like it!

I do wonder if there's some way of just redirecting stdio of the console app into the FCS-hosted FSI session so we keep the ability to type into the terminal.

That would be ideal.

I'm hoping that could also address one of the unintuitive behaviors of the current implementation: sessions started in the terminal with dotnet fsi aren't recognized. One learns to use it correctly but it would be nice to make that seamless.

Krzysztof-Cieslak commented 2 years ago

This might be kind of related, I've been looking today into the FSI watcher (mostly to test the waters and fun) and I found out it is very annoying to create webviews, would there be interest to also host FSI related Webviews in that out or process server?

We can't really easily host webviews out of the process since they won't have access to CSS styling of VSCode - I guess we could probably hack around it somehow, but it doesn't sound trivial enough to justify the effort and potential complexity.