I saw a stacktrace when exiting sbtn on windows due to an interrupted
exception being thrown during thread joining. We only want to throw this
exception if we didn't successfully join the thread. I also noticed that
we would try to join the thread forever. There was supposed to be a
timelimit so that we would eventually stop blocking even if we were
unable to join the thread. The limit was set but not respected.
With the thin client, when running the command `exit`, it is often the
case that the log message `[info] disconnected` is printed on the same
line as the prompt. This is because there is a small flush delay on the
network client's output stream channel that causes the disconnected info
message to be logged before the the newline that jline 3 echoes to the
client has been printed. To fix this we can manually flush the terminal
output stream before exiting.
It is possible for downstream dependencies to print or log messages
containing ansi escape sequences and/or color codes. In older versions
of sbt, these would be printed even if the user had disabled ansi codes
or color via the sbt.log.noformat or sbt.color parameters. This commit
adds a general api to EscHelpers that strips general ansi codes and
color codes independently via flags. We can then use that api to ensure
that all bytes written to System.out are stripped of ansi escape and
color codes if the terminal properties demand this.
The motivation was that JLine 3 will prepend the prompt string with
\E[?2004h, which turns on bracketed paste mode
(https://en.wikipedia.org/wiki/ANSI_escape_code). If the sbt shell is
started with a terminal that doesn't support general ansi escape codes,
such as the jEdit shell, ?2004h gets printed to the shell. To fix this,
we can strip ansi codes from all output if the terminal doesn't support
general ansic codes. This has the additional side effect of any ansi
codes that appear in log messages or printlns that are added by non-sbt
code will be stripped. It's unlikely that this is all that common.
In addition to the JLine use case, I've noticed that utest prints
colored output during test runs. Prior to this change, the colored
output was present even when sbt was run with `-Dsbt.color=false` and
after this change, the colors are correctly stripped.
With sbtn, the system properties are passed in as regular command
arguments. We need to parse them before we call Terminal.withStreams or
else system properties like -Dsbt.color=false are ignored.
A user reported that the watchBeforeCommand callback was not being
invoked in sbt 1.4.{0, 1}. This was an oversight that occurred when
refactoring watch for the thin client and there previously had been no
regression test for that callback.
For reasons I don't fully understand, it is necessary to go in and out
of raw mode to get console input to echo on windows. This was reported
as sbt new not echoing input in #5952.
I noticed that if you run `sbt -Dsbt.log.noformat=true` there are colors
printed when using the latest sbt code. When running with that property
set, the expectation is there are no colors.
When the read methods of InputStream that take an Array[Byte] as input
are called, they are supposed to return -1 if there are no bytes
available due to an EOF. Previously it was incorrectly writing the -1 as
a byte in the array and returning 1. Now it correctly returns -1.
The condition for closing the WriteableInputStream was also incorrect.
We should only close the input stream if it returns -1 in raw mode.
Fixes#5999
EvaluateTask was holding references to SafeState that could be quite
large. This was reported as #5992. In that project, I ran the `ci` task
and observed the OOM as reported. I took a heap dump prior to OOM and
got the retained size graph from visualvm (which took hours to compute).
The lastEvaluatedState was holding a reference to SafeState that was
1.7GB. The project max heap size was set to 2GB. Instead of using the
lastEvaluatedState, we can just use StandardMain.exchange.withState.
The cached instances of state were used for task cancellation and
completions. While it is possible that early on in booting
StandardMain.exchange.withState could return a null state, in practice
this won't happen because it is set early on during the sbt boot
commands.
After this change, I successfully ran the `ci` task in the #5992 issue
project with the same memory parameters as their ci config.
This channge should turn color on by default in ci builds (see
https://github.com/sbt/sbt/issues/5269). It can still be disabled with
-Dsbt.color=false.
Disabling virtual io prevents the thin client from working. It is
possible that a user may manually start a server with -Dsbt.color=false
but still want to connect a thin client.
Running sbt with -Dsbt.supershell=true and -Dsbt.color=true doesn't work
well because the isAnsiSupported flag is set to false when
-Dsbt.color=false. This causes the processing that ensures that
supershell lines do not get interleaved with normal log lines to be
skipped. To fix this, we can enable ansi codes when supershell is
explicitly enabled.
The ConsoleAppender formatEnabledInEnv field was being used both as an
indicator that ansi codes were supported and that color codes are
enabled. There are cases in which general ansi codes are not supported
but color codes are and these use cases need to be handled separately.
To make things more explicit, this commit adds isColorEnabled and
isAnsiSupported to the Terminal companion object so that we can be more
specific about what the requirements are (general ansi escape codes or
just colors). There are a few cases in ConsoleAppender itself where
formatEnabledInEnv was used to set flags for both color and ansi codes.
When that is the case, we use Terminal.isAnsiSupported because when that
is true, colors should at least work but there are terminals that
support color but not general ansi escape codes.
It is currently the case that all tagged log messages going through a
ConsoleAppender have color codes added and then subsequently stripped
out. This didn't work well in combination with -Dsbt.color=true and
-Dsbt.ci=true because the -Dsbt.color=true was causing
ConsoleAppender.formatEnabledInEnv to be set to true which caused ansi
codes to be enabled. Travis CI supports color codes but not other ansi
escape sequences (this is also often true of embedded shells like in
intellij or jedit). This commit reworks the ConsoleAppender so that we
only add colors if useFormat is enable dand only add
ClearScreenAfterCursor if ansi codes are supported. It also reworks the
ConsoleAppender.write method so that if useFormat is true but
ansiCodesSupported is false that we only remove the non color related
ansi escape sequences so that colors remain.
In canonical mode, System.in will return -1 for ctrl+d on an empty line.
The result of this behavior was that if a user entered ctrl+d during run
in a task that was reading from System.in, sbt would end up exiting
whenever the task exited. This happened because the WriteableInputStream
would close itself when it read -1 from the input stream, which it
assumed meant that the underlying input stream itself had been closed.
When the jline reader tried to read from the closed
WriteableInputStream, it would throw an exception and if the line reader
was for the console channel, it would be interpreted as the user had
inputted ctrl+d in the sbt shell which is supposed to exit sbt. This
change fixes that behavior so that sbt can continue reading input after
the run task exits.
eugene yokota
Adrien Piquerez
Ethan Atkins
xuwei-k