getLine in eval code lens causes connection got disposed

[michaelmesser]

Your environment

Which OS do you use:

MacOS
Which LSP client (editor/plugin) do you use:

VS Code+vscode-haskell

Describe your project (alternative: link to the project):

resolver:
  url: https://raw.githubusercontent.com/commercialhaskell/stackage-snapshots/master/lts/19/7.yaml

packages:
- .

Steps to reproduce

{-
>>> getLine
-}

Run the Evaluate code lens

Expected behaviour

Not sure

Actual behaviour

{-
>>> getLine
"Content-Length: 191\r"
-}

VSCode shows error message: Connection got disposed.

Include debug information

[xsebek]

Hi @michaelmesser, this is a known limitation of the hls-eval-plugin.

My understanding of the plugin is that it runs in the same process as HLS, so you can not easily redirect its stdout/stderr.
Redirecting stdin seems even trickier than output because it's not clear how you should interact with it from the editor.

If you want, we could use this Issue to discuss what should be the Expected behaviour. 🙂

• See also Capture stdout and stderr in eval plugin #1977

---

^{If you are looking for a workaround, you can get IO String with simple pure "My Input" or you can write your tested functions to accept String and separate the input/output handling. I hope that's helpful. 😉}

[michaelpj]

Maybe we could capture this limitation in the docs? We have a few "Known limitations" sections in the Features page.

[xsebek]

Actual behaviour

>>> getLine
"Content-Length: 191\r"

Btw. is the string stolen from the input sent to HLS and making it close the connection? 🤔

@anka-213 pointed out in #1977 that HLS moves its stdout, maybe a similar thing is necessary for stdin here?

[pepeiborra]

@anka-213 pointed out in #1977 that HLS moves its stdout, maybe a similar thing is necessary for stdin here

Yes, this is right. The redirection is done in Development.IDE.Main