With sbt 1.4.x, non-ascii utf-8 characters are not handled correctly in
the console. It was not clear from the jline 3 documentation but the
NonBlockingReader.read method is supposed to return unicode points
rather than utf8 bytes. To fix this, we can decode the input and return
the code point rather than the directy byte from the input stream.
Ref https://github.com/sbt/sbt/pull/4443
Fixes https://github.com/sbt/sbt/issues/5750
In #4443 I implemented an optimization where the metabuild would no longer re-resolve numerous sbt artifacts for metabuilds each time, and instead use whatever the JARs provided by the launcher. At the time, this technique didn't work for Coursier so I've placed in some workarounds for it. Now that Coursier's resolution has improved, it seems like the workaround is actually causing more harm. This removes the bandaid, and local testing shows that it seems to be working.
For instance, we no longer need to put in `ThisBuild / useCoursier := false` in sbt/sbt's `project/plugins.sbt`.
* Refactor so as to be testable
* Queue stores the _beginning_ timestamp of each GC time delta
* Message states the correct time over which the GC time was recorded
* Add heap stats from java.lang.Runtime to the message
When the sbt main loop is blocked by console, any other connected client
is prompted that they can kill the task by typing cancel. The
implementation for the console task is to write some input that will
cause the console to exit because the scala 2.12 console cannot be
safely killed with an interrupt. This input, however, was being blocked
from written to the console because the console input stream was holding
the readThread lock. We can be fix this and propagate the input to the
console we wish to terminate by synchronizing on a different lock
object. This should have no impact outside of cancelling the console
because that is the only place where we call the write method of
WriteableInputStream.
When a batch command is run with the thin client, it logs an info
message that the command completed. This is unnecessary given that
completion is implied by the success or failure method that follows. It
made the output look a little different in the thin client vs the
console.
If a user runs sbt -Dsbt.ci=true with the latest code, sbt immediately
exits. This was because we were passing the SimpleTerminal into jline3
and jline 3 would end up exiting immediately. Instead we can still make
a console terminal if there is a console available. An alternative
approach would have been to use a dumb terminal with -Dsbt.ci=true, but
the dumb terminal experience is not great (tab completions don't work
for example), so I thought this was a better fix.
Tab completions did not work well in sbt 1.4.x when run with
-Dsbt.color=false. This was because we were stripping a bunch of ansi
codes, which caused some problems with the jline 3 completion engine.
Instead of stripping the ansi codes, we can set the jline max_colors
capability to 1 if color is disabled. With this change, the completions
are similar to 1.3.13 except that in jline 2 the user has to hit tab
twice to see all of the available candidates while in jline 3, the
candidates are immediately printed below the prompt.
eugene yokota
Ethan Atkins
Taichi Yamakawa
Taichi Yamakawa
Adrien Piquerez
kenji yoshida
nafg