Optimized builds/runs from IdeSession

[snoyberg]

Goal: in addition to the current runStmt API, we should be able to kick off an optimized build and manage its runtime with a similar API to runStmt.

[Mikolaj]

Should I implement buffer timeout when running the exes? And/or separate buffer modes for stdout and stderr? I haven't investigated yet, but that will probably involve importing IdeBackendRTS into Main of the executable, etc. If so, I'd do that later on, as stage 2 of the implementation. Stage 1, with all other features (data dir, args, env, all RunActions operations), is ready, but not tested yet.

But perhaps this is too intrusive for an executable and not needed as much? To make this consistent, I would also need to modify the generated .cabal file to build executables in this way, I suppose?

[snoyberg]

While it would be nice, I think including the buffer timeout code would be too intrusive. Let's start off without it, and we'll start doing some testing. If user testing reveals that we really do need the timeout code, let's investigate again.

[dcoutts]

The existing RunActions API for snippets provides a way to interrupt. It uses an exception so it's not a forcible termination. The obvious equivalent for running compiled exes is to send a SIGINT, and that's what our patch does currently.

What we're currently missing is that second level: the ability to forcibly interrupt with a SIGTERM.

[dcoutts]

What we're currently missing is that second level: the ability to forcibly interrupt with a SIGTERM.

Ignore this, I'm wrong. So I think this is all fine.

[Mikolaj]

A tested and fixed version is ready on branch runExe, ready to be merged. Here are the differences in behaviour compared to running snippets:

• we don't control things on the exe side: no setting of buffer modes for stdin, stdout, stderr, no timeout on buffers, no setting of UFT8 encoding (test "Make sure encoding is UTF8" would fail for runExe); possibly there are some workarounds for any of these, but nothing obvious springs to my mind
• the exes are not registered anywhere in the session state and so are not killed at session shutdown nor at session restart; a side effect is that session can be updated, etc. when the exes are running, without any problems; a bad side effect is that non-terminating exes permanently consume resources if not explicitly killed (via interrupt or forceCancel)
• there is no counterpart to the resume operation
• there are no breakpoints, etc.
• the obvious things:
  • the need to run buildExe first
  • having only the main function executed
  • not reporting the exceptions raised, and other result kinds, but just an ExitStatus of the exe
  • etc.

[snoyberg]

I'm a little concerned that exes aren't being tracked by the session state and automatically killed, but overall that might be a good situation for users, so let's wait until we have user testing to back up any change requests. Everything else makes perfect sense, thank you.

Let me know when we should update to a newer ide-backend commit and start testing this.

[Mikolaj]

Merged to experimental and tested with ide-backend tests.