https://github.com/sbt/sbt/pull/4143 kept failing, and while I was debugging,
I noticed that the target that it was downloading scala-compiler was in
/tmp/... for the remote instance.
This moves the fakeboot to a full path, which should make the build
less susceptible to failure due to random network issues.
The change contributed in https://github.com/sbt/sbt/pull/4130 to start sbt within VS Code looked ok at first, but when I published the extension and started using it, I realized that it's a bit broken.
Basically there's no cleanup logic (that I could find), so simply closing VS Code would leave `project/target/active.json` behind, which lets VS Code extension to attempt connection, and it fails because there's no server running. To workaround this, I'll attempt to connect to the socket to confirm sbt server is up.
When source generators write into the unmanaged source directory, bad
things can happen. Continuous builds will loop indefinitely and
compiling will fail because the generated sources get added to the
source list twice, causing the incremental compiler to complain about
compiling classes it has already seen. My two-pronged solution is to
de-duplicate the sources task and to filter out managed source files in
watch sources. The drawback to the latter is that it causes the source
generation task to be executed twice per compile.
Fixes#3482 take 3
There are two bugs related REPL and JLine.
1. JLine getting disabled (up arrow not working) on the second run of `console` task.
2. Typed characters not showing up even on the `console` task.
The first issue was fixed by #4054 which added `t.init`. When I noticed the second problem, I fixed it in #4082 (adds `t.restore`) but undid the first fix. This attempts to fix both the issues.
I believe GitHub does a better job displaying this prominently,
particularly for first time contributors.
We can always bring back the pull request template if we have new content.