aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/runtime/ExperimentalEventHandler.java
Commit message (Collapse)AuthorAge
* ExperimentalEventHandler: properly complete buildGravatar Klaus Aehlig2018-04-25
| | | | | | | | | | | | When completing the build and doing the final flush of the incomplete stdout/stderr lines, remove any existing progress bar first (and redraw afterwards) to avoid interference. Also, upon receiving the AfterCommandEvent, just call completeBuild instead of trying to do the same manually again. Change-Id: If375be798a5e66558676f0ffb845fb64279584f8 PiperOrigin-RevId: 194203925
* Fix screen flicker caused by small writes.Gravatar jmmv2018-02-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | ExperimentalEventHandler is in charge of composing the pretty progress bar that Bazel displays. This progress bar is a multi-line message with control characters printed on the terminal. The progress bar was composed by issuing many individual writes to an AnsiTerminal. Because the AnsiTerminal in this case was backed by an error stream (which are unbuffered), each of these writes resulted in a gRPC to the Bazel client to write the message to the console. gRPC calls are much more expensive than calls to a file descriptor, and, in general, even small writes to a file descriptor should be avoided when preparing long messages. To fix this, fully buffer the output messages sent to the AnsiTerminal until explicitly flushed. ExperimentalEventHandler was already doing the right thing regarding flushes but did not account for the fact that each write would be (unintentionally) sent directly to the terminal. The flicker was significant: on a pathological case (building sandboxfs with Bazel on my MacBook Pro 13" on macOS), this change shaves about 5 seconds of build time on the previous 45 second-long build. I think this only happened with "bazel run" and "bazel test" invocations and not "bazel build", but I haven't really confirmed this. RELNOTES: None. PiperOrigin-RevId: 185405892
* Avoid crash when a test and its alias are specified on the command line for ↵Gravatar lberki2017-11-03
| | | | | | | "blaze test". RELNOTES: None. PiperOrigin-RevId: 174386473
* ExperimentalEventHandler: clean up in afterCommandGravatar Klaus Aehlig2017-09-27
| | | | | | | | | | | The experimental event handler honors the AfterCommandEvent which tells to clean up resources. Do so properly, by also flushing output and resetting the terminal (and then flushing it). As a nice side effect, this event handler does not need a separate release handling from the command dispatcher. Change-Id: If93cfa1b0f8d12e94fa4f57c9e2ee67362bd7d11 PiperOrigin-RevId: 170175617
* More BUILD file refactorings.Gravatar philwo2017-09-06
| | | | | | | | | Split collect, concurrent, vfs, windows into package-level BUILD files. Move clock classes out of "util", into their own Java package. Move CompactHashSet into its own Java package to break a dependency cycle. Give nestedset and inmemoryfs their own package-level BUILD files. PiperOrigin-RevId: 167702127
* Now really rename all logger instances to "logger".Gravatar lberki2017-09-05
| | | | | | | Turns out, my previous search expression didn't find the ones that were not "final LOG" or "final log" and a surprising number of places were missing the "final" tag. RELNOTES: None. PiperOrigin-RevId: 167547507
* Rewrite all code to use the new Java 8 java.time classes.Gravatar Philipp Wollermann2017-09-05
| | | | | | | This removes our dependency on third_party/joda_time, which can be removed in the next commit. Change-Id: Ibda131d34d0abdc2d675db4bfbd2e99480c055ee PiperOrigin-RevId: 167515260
* Make the print function output debug messagesGravatar vladmos2017-08-11
| | | | | RELNOTES: The `print` function now prints debug messages instead of warnings. PiperOrigin-RevId: 164880003
* Only report progress after a build has started.Gravatar Benjamin Peterson2017-07-31
| | | | | | | | | | | | Rather than assuming that all events are part of a build until NoBuildEvent or BuildCompleteEvent are posted, only start reporting build progress after a BuildStartingEvent or a NoBuildEvent with showProgress() true happens. This fixes https://github.com/bazelbuild/bazel/issues/3449. Change-Id: I78372a2286a4595cf3301c998be2c9036ad0f4b7 PiperOrigin-RevId: 163447622
* experimental UI: keep console updated till the endGravatar Klaus Aehlig2017-07-14
| | | | | | | | | | | | | | | | For commands that do not send a BuildFinishedEvent, we normally use the NoBuildEvent to determine the end of the build and hence the moment where the UI should not any more interfere with the output. For some requests, like fetch, however, we should continue to report progress till the very end (as there is no output to interfere with). Do so, and also be sure that the experimental UI also reports downloads if not explicitly in a loading or analysis phase. While there, also group digits in the number of downloaded bytes, to increase readability. Change-Id: I31efeee5bdb1d29b2ecf842acb3e383e297707f8 PiperOrigin-RevId: 161935456
* Automated conversion to Java 8Gravatar laurentlb2017-06-30
| | | | | | | With a few manual fixes for readability. RELNOTES: None. PiperOrigin-RevId: 160582556
* Fix comment in ExperimentalEventHandlerGravatar aehlig2017-06-22
| | | | | | | | The "is is line with" should read "is in line with". While there, also fix the formating of that comment. RELNOTES: None. PiperOrigin-RevId: 159683437
* Extract the ansi color escape sequences to an enumGravatar Ulf Adams2017-06-19
| | | | | | | | | | I want to make the color scheme configurable, which requires an abstraction to represent color, so it can be looked up / stored in a map / etc. Closes #2487. Change-Id: I2f8bd0dd19ecd6a243ac9b7acc7be52e59c90021 PiperOrigin-RevId: 159426774
* experimental UI: move stopUpdateThread() out of synchronized, againGravatar Klaus Aehlig2017-06-09
| | | | | | | | | | | | | | | The experimental UI uses a thread to regularly update itself to reflect time-based changes. As that that thread has to call synchronized methods any waiting for it to finish has to happen outside any synchronized block. Unfortunately, 9e0308e0f7 accidentally moved the stopUpdateThread() in buildComplete() into the synchronized block, thus giving an opportunity for deadlocks. Move it out again. Also, as the accounting for pending transports now happens in synchronized methods in the state tracker, the buildEventTransportClosed() method does not have to be synchronized any more---thus eliminating the second deadlock opportunity. Change-Id: Icacb2ee70f4bedde1c1aac2bcfefc6fabf42fdd3 PiperOrigin-RevId: 158537844
* CountingOutputStream: properly flush()Gravatar Klaus Aehlig2017-06-01
| | | | | | | | | | | If console output limiting is enabled in the actual output stream is wrapped in a CountingOutputStream to hard-limit the number of bytes written. As on the console, the two streams, stdout and stderr, might interleave, proper flushing of writes is important. Therefore, make sure flushing is propagated through the CountingOutputStream. Change-Id: I591a2a1ae798a9d8ef704118b22960ff9773a59e PiperOrigin-RevId: 157707049
* Experimental UI: don't show dates for no-build commandsGravatar Klaus Aehlig2017-06-01
| | | | | | | | | | | When building with timestamps enabled, it is useful to know the date as well, e.g., when later looking at logs. This, however, is not the case if the command does not build (e.g., "bazel help", "bazel query"), or, in general, if the first output is only produced after the command is completed. Change-Id: I75ef38fbb98e886b1dc38899efa10188055f87e2 PiperOrigin-RevId: 157700578
* experimental UI: don't double track pending transportsGravatar Klaus Aehlig2017-05-29
| | | | | | | | | | As the state tracker keeps track of which transports we still have to wait for, make the event handler just ask the state tracker. In this way, we also handle gracefully if the closing of a transport is reported more than once. Change-Id: I0e1959d827268319ec00541994314c9325ef2307 PiperOrigin-RevId: 157395608
* Experimental UI: Support multiple BuildEventTransportAnnouncedEventsGravatar buchgr2017-05-29
| | | | | | | | We initially didn't consider that multiple BuildEventStreamer instances might exist during a build. RELNOTES: None. PiperOrigin-RevId: 157385069
* experimental UI: Support limiting consoleGravatar Klaus Aehlig2017-05-23
| | | | | | | | | | | | Add an option allowing to set a hard limit on the number of characters bazel will write to stdout/stderr (combined). In this way, it can be avoided to overwhelm the user with information (especially, if the invocation of bazel is wrapped in some way). Once the limit is approaching, bazel will try hard to meaningfully reduce the output, but will ultimately resort to just dropping output completely. Change-Id: I49cce96cc6a025c9753632dd489021766df81077 PiperOrigin-RevId: 156849105
* experimentalUI: show date, if timestamps are enabledGravatar Klaus Aehlig2017-05-12
| | | | | | | | | | | While builds usually finish in a single day, for console logs (especially those collected on a CI system) it is still useful to know the date they where collected on. So, if --show_timestamps is given, show a line with the current date at the beginning of the build to not lose the information due to the shorter time stamps, compare #2989. Change-Id: Ief2ae011cdb4de7ac5d5a9acd4d200913220b2a3 PiperOrigin-RevId: 155859302
* experimental_ui: improve --show_timestamp handlingGravatar Klaus Aehlig2017-05-05
| | | | | | | | | | Move the position of the timestamp to the beginning of the line to have a more readable log. Also, show the timestamp for progress as well. While there, reduce timestamp to second precision, to reduce noise. Change-Id: Ibfa6caca2e0d207f54e3660bccbf894bba3c5ae3 PiperOrigin-RevId: 155181731
* Automated g4 rollback of commit d9fea57268ff01c001fbcbdc2bd057c86c362e6f.Gravatar buchgr2017-04-25
| | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Rollforward with fix for test flakiness. BEP transport closed events are delivered via their own threadpool and thus might not have been sent immediately. BuildEventStreamerTest#testSimpleStream now waits for a bit until the event has been delivered. I ran the test with --runs_per_test=1000 several times and had no further failures. *** Original change description *** Automated g4 rollback of commit 3d596d63f883fff56001ed7b2e5cf51dba45f082. *** Reason for rollback *** Made BuildEventStreamerTest#testSimpleStream 3% flaky based on --runs_per_test=1000. RELNOTES: None PiperOrigin-RevId: 154170833
* Automated g4 rollback of commit 3d596d63f883fff56001ed7b2e5cf51dba45f082.Gravatar ajmichael2017-04-25
| | | | | | | | *** Reason for rollback *** Made BuildEventStreamerTest#testSimpleStream 3% flaky based on --runs_per_test=1000. RELNOTES: None PiperOrigin-RevId: 154090559
* BEP: Show protocol upload in the UIGravatar buchgr2017-04-24
| | | | | | | | | | | | | | | | | | | | | | The BEP (build event protocol) upload may at times take longer than the build itself. This is especially true for cached builds, where there is little build work, but the protocol still needs to be uploaded. In this case the bazel UI will now display that it's waiting for BEP upload, both in the current and the new experimental UI (--experimental_ui). When executing a run command, blaze waits for the BEP upload to finish before it runs the target. Major Modifications: - The BuildEventTransport interface now also has a name() method that returns a string. When waiting for a transport to finish the BEP upload, this string is displayed in the UI. - The BuildEventStreamer now emits two new events AnnounceBuildEventTransportsEvent and BuildEventTransportClosed on the event bus. This is how the experimental UI is informed about BEP upload progress. RELNOTES: None PiperOrigin-RevId: 154052401
* Experimental UI: increase progress rate limit with time, if no in-place updateGravatar Klaus Aehlig2017-04-10
| | | | | | | | | | In the experimental UI, increase the rate limit for updates to the progress bar over time, if it cannot be updated in place. In this way, we can get snappy first progress descriptions, while not overwhelming the user with too many progress messages. Change-Id: I769f1a9ef4304b613d40ece42b87df22881549cd PiperOrigin-RevId: 152502295
* Experimental UI: only show progress in terminal title if curses enabledGravatar Klaus Aehlig2017-04-07
| | | | | | | | | If told to not use curses, also do no show the progress in the terminal title, even if told to do so. If curses are not available, most likely OSC controll sequences are not available either. Change-Id: I0e14e36aaa32dfeffb52ed701e31b83085d63e68 PiperOrigin-RevId: 152393651
* Abstract from DownloadProgressEvent to generic FetchProgress Gravatar Klaus Aehlig2017-03-10
| | | | | | | | | | | In this way, we can easily add other fetch-like events to be reported in a similar way as plain downloads. -- Change-Id: I518df5ba27b6593eca98d30407b582f509a52aeb Reviewed-on: https://cr.bazel.build/9313 PiperOrigin-RevId: 149655918 MOS_MIGRATED_REVID=149655918
* Post DownloadProgressEvents in ProgressInputStream Gravatar Klaus Aehlig2017-03-03
| | | | | | | | | | | In this way, the experimental UI will report about the progress of downloads. Fixes #2563. Fixes #1260. -- Change-Id: I034e0f2bc8df0a1f46b28298d3d1fccc8daaaded Reviewed-on: https://cr.bazel.build/9115 PiperOrigin-RevId: 149013682 MOS_MIGRATED_REVID=149013682
* Use guava Uninterruptibles#joinUninterruptibly utility method instead of ↵Gravatar Janak Ramakrishnan2016-08-22
| | | | | | | rolling our own in ExperimentalEventHandler. -- MOS_MIGRATED_REVID=130935928
* ExperimentalEventHandler: narrow scope of synchronized blocksGravatar Klaus Aehlig2016-08-02
| | | | | | | | | | | | | | | | ...to in particular never own a lock while waiting for the update thread to finish. This avoids a deadlock when the update thread tries to enter the synchronized part of doRefresh while the thread trying to stop the update thread holds the lock. Also renable experimental_ui_test now that the race condition leading to the deadlock is fixed. The absence of flakiness has been verified by running the test locally 100 times. Fixes #1560. -- Change-Id: I5d85b347e6cb7a1da8d5a724d6f9cd7461e33e5b Reviewed-on: https://bazel-review.googlesource.com/#/c/4225 MOS_MIGRATED_REVID=129079398
* ExperimentalEventHandler: avoid recursive starting of the updateThreadGravatar Klaus Aehlig2016-08-02
| | | | | | | | | | | | | | | | Break the situation where an update thread tries to start another update thread early, by telling the doRefresh method when it is called from within an update thread. While no second thread would be started in this case anyway (as the global variables indicate that a thread is already in existence), a lock is still required for this step, which can cause all kinds of problems. Note that we don't have to worry about the update thread being about to be stopped in that moment, as only global events indicating completion stop the update thread. -- Change-Id: Ib025ba2b12bcd339c590593213eeedfd9cb230d3 Reviewed-on: https://bazel-review.googlesource.com/#/c/4224 MOS_MIGRATED_REVID=129077891
* Add a final event on the event busGravatar Klaus Aehlig2016-07-11
| | | | | | | | | | | | | Add an event to the event bus that is guaranteed to come after the completion of the command. Listeners can use this event to clean up any resources that still need to be cleaned up. As first customer, add the ExperimentalEventHandler so that it is guaranteed not to leak the update thread. -- Change-Id: Ia20bae8a00541aa1338e49f74a7320ac098ab71d Reviewed-on: https://bazel-review.googlesource.com/#/c/4011 MOS_MIGRATED_REVID=126909844
* ExperimentalEventHandler: remove deadlock in update threadGravatar Klaus Aehlig2016-07-08
| | | | | | | | | | | | | | | | | When the progress bar has to be updated, but we cannot do so immediately, e.g., due to rate limiting, we start a thread to do this eventually (the "update thread"). That thread gets stopped if either we realize during an update of the progress bar that it is no longer needed, or if we get informed about the completion of the build. Now, since the update thread does updates of the progress bar (that is its whole purpose) it can get the duty to stop itself. To avoid the deadlock when the thread there blockingly waits for itself to terminate, just skip that termination and let the update thread run till the end of the build. -- Change-Id: Iba08806f5e416f1fa1825969eceaf6cf54c24e6c Reviewed-on: https://bazel-review.googlesource.com/#/c/4010 MOS_MIGRATED_REVID=126906395
* Experimental UI: make stopUpdateThread() more insistingGravatar Klaus Aehlig2016-07-06
| | | | | | | | | | | | | | | | | The stopUpdateThread() method tries to stop the update thread by calling the interrupt() and join() methods on that thread. When getting interrupted while waiting for the thread to join, do not ignore the exception, instead try again to make sure we don't leave that method before the other thread is actually stopped. While there, also clean up the synchronized blocks for the thread handling: all blocks that handle multiple global variables like buildComplete, updateThread, etc, are synchronized while the actual thread-manipulating operations are outside those blocks. -- MOS_MIGRATED_REVID=126679343
* experimental UI: enforce a minimal progress rate limiting if curses unavailableGravatar Klaus Aehlig2016-07-01
| | | | | | | | | | | | | | | | | | If the progress bar cannot be updated in place, every additional writing of the progress bar clutters up the log. Of course, this could be controlled by adding --show_progress_rate_limit or even --noshow_progress options to the invocation; however, it turns out that users expect a bazel to just automatically reduce its output rate. Therefore, specify a minimal value for the progress rate limit of 2 seconds if the progress bar cannot be updated in place. Also, increase the time rate for purely time-based updates to 20s in this case. Moreover, only automatically redraw the progress bar after an INFO/WARNING/... message, if it can be updated in place. -- Change-Id: I7d06aa04acec457ec0a5d20ac32ede4cf80f7170 Reviewed-on: https://bazel-review.googlesource.com/#/c/3944 MOS_MIGRATED_REVID=126387987
* ExperimentalEventHandler: remove unnecessary inheritanceGravatar Klaus Aehlig2016-06-30
| | | | | | | | | | | | | The ExperimentalEventHandler uses no functionality of BlazeCommandEventHandler, hence there really is no need whatsoever for ExperimentalEventHandler to be a subclass of BlazeCommandEventHandler. So, remove this inheritance to clean up our class hierarchy; instead let the ExperimentalEventHandler just implement the EventHandler interface. -- Change-Id: I504f727190a12882dd8b7c37811a821e3ba50400 Reviewed-on: https://bazel-review.googlesource.com/#/c/3926 MOS_MIGRATED_REVID=126282974
* Make experimental UI resistent to late-reported eventsGravatar Klaus Aehlig2016-06-29
| | | | | | | | | | | | | Sometimes the event reporting the completion of the last action can, effectively, overtake the event reporting the completion of last action. To avoid late writing to the output stream don't start the update thread after the completion of the build is reported. There is nothing to update then any more anyway. -- Change-Id: Ibbb6d025635a9daa233c2b28ca64a1ae4896ce47 Reviewed-on: https://bazel-review.googlesource.com/#/c/3922 MOS_MIGRATED_REVID=126182576
* experimental UI: honor --show_timestampsGravatar Klaus Aehlig2016-06-29
| | | | | | | | | | | In the experimental UI, also support the --show_timestamps option which asks that for each event a timestamp be added to the the output. Fixes #1436. -- Change-Id: I8f9db958525edfbca12ed2c1f1396f25f865b897 Reviewed-on: https://bazel-review.googlesource.com/#/c/3916 MOS_MIGRATED_REVID=126165328
* experimental UI: honor --progress_in_terminal_titleGravatar Klaus Aehlig2016-06-27
| | | | | | | | | | Make the experimental UI honor the --progress_in_terminal_title options which requests that the terminal title be set to a description of the current progress. -- Change-Id: I8ebded9ebb7e9f821344165fca6b5f6b9b254c68 Reviewed-on: https://bazel-review.googlesource.com/#/c/3904 MOS_MIGRATED_REVID=125953773
* experimental UI: Avoid empty linesGravatar Klaus Aehlig2016-06-27
| | | | | | | | | | ...to save a bit of horizontal space in the scroll-back buffer. The color-coding already gives enough navigation hints. -- Change-Id: Id0e5decc6bd495a99ec839c096700406d8d1bab9 Reviewed-on: https://bazel-review.googlesource.com/#/c/3902 MOS_MIGRATED_REVID=125943242
* experimental UI: flush buffersGravatar Klaus Aehlig2016-06-24
| | | | | | | | | At the end of the build (or when realizing that there will be no build phase), the experimental UI drops into full streaming mode. When doing so, do not forget to flush all buffered incomplete lines for stdout and stderr. -- MOS_MIGRATED_REVID=125770854
* experimental UI: consider progress bar refreshed on every redrawGravatar Klaus Aehlig2016-06-23
| | | | | | | | | | | | | | | | | Whenever the UI has to write a line to the progress buffer, it removes the progress bar, write the line and re-adds the progress bar. Of course, the re-added progress bar is the one that represents the up-to-date state at the time of it being re-added. Therefore, this also is a refresh of the progress bar. So update the time stamp tracking the last refresh. In this way rate-limits on refreshes are honored more correctly; also, requirements of the progress bar having to be refreshed after a certain point in time that have been fulfilled by that implicit refresh are recognized as such, keeping the output less flickering. -- Change-Id: I44bcd85a149cb88fcde126119100a6e1ff1ba45d Reviewed-on: https://bazel-review.googlesource.com/#/c/3873 MOS_MIGRATED_REVID=125664608
* experimental UI: after analysis summarize the work done thereGravatar Klaus Aehlig2016-06-23
| | | | | | | | | | | | | At the end of the analysis phase, show the amount of work done during this phase (e.g., number of packages loaded) in a way similar to the last progress message shown for loading. In this way, users will over time learn the number of packages their project depends on; thus the progress shown during loading will become more meaningful to them. -- Change-Id: If56fab5704c419be988e55f0c1705b3732c11369 Reviewed-on: https://bazel-review.googlesource.com/#/c/3872 MOS_MIGRATED_REVID=125656896
* Add an option for the number of actions shown in the experimental UIGravatar Klaus Aehlig2016-06-21
| | | | | | | | | | | | | | Currently, the experimental UI always shows the 3 oldest, still running actions. While this seems a reasonable default, some users requested to be able to change the number of actions shown. Hence replace the hard-coded value by a flag. While there, also fix an off-by-one error in deciding when to put the ellipsis symbol. -- Change-Id: I037d208360fa1d3f100c99ab1ab1f5fc140138ac Reviewed-on: https://bazel-review.googlesource.com/#/c/3811 MOS_MIGRATED_REVID=125427168
* experimental UI: be less verbose about test summariesGravatar Klaus Aehlig2016-06-21
| | | | | | | | | | | | | | | | | | | | | | | | | | To keep the noise of messages in the scroll-back buffer low, limit which test summaries are shown there. - If a test fails to build, the error message about the build failure is already in the scroll-back buffer---and more useful to the user anyway. - If a test is not run (either because the user interrupted the build, or because of a build error), then either the user is aware of it anyway or the information about the build failure is present and more useful. Also, this is only detected at the end of the build, were a summary of the tests is shown; hence avoid duplication here. - If a test has status failed and there is precisely one failure log, then the summary does not provide any useful information compared to the individual FAIL message in the scrollback buffer. While there, also show the precise status of the summary. -- Change-Id: I13665db24f956c8d8b651dc38859649085b8bbcf Reviewed-on: https://bazel-review.googlesource.com/#/c/3830 MOS_MIGRATED_REVID=125339810
* experimental UI: delay updates after action completionGravatar Klaus Aehlig2016-06-20
| | | | | | | | | | | | | Very often, when an action completes, a new one is started directly afterwards. With this in mind, delay the refresh after the completion of an action as long as acceptable by the refresh rate limiting. If indeed an action starts within that time, we have replaced a double refresh of the progress bar by a single one, thus make it appear less flickering. -- Change-Id: I0e9143d6bba9929265ad2b6a3699486a1d5b3b2b Reviewed-on: https://bazel-review.googlesource.com/#/c/3823 MOS_MIGRATED_REVID=125165516
* experimental UI: also report the strategy of running actionsGravatar Klaus Aehlig2016-06-20
| | | | | | | | | | In the experimental UI, for the running actions also report their strategy. This will give a more complete picture of what Bazel is currently doing. -- Change-Id: I9553c952ed494e0db225b2a1ae5e8eba00f68617 Reviewed-on: https://bazel-review.googlesource.com/#/c/3820 MOS_MIGRATED_REVID=125162808
* Make experimental UI honor --noshow_progressGravatar Klaus Aehlig2016-06-15
| | | | | | | | | | | | While there is little value in using the experimental UI if no progress output is desired, we still want the experimental UI to serve as a drop-in replacement for the old one, including the ability to not show any progress. -- Change-Id: I54c67a6f432541611da8b4ab7e7f88bb85926391 Reviewed-on: https://bazel-review.googlesource.com/#/c/3803 MOS_MIGRATED_REVID=124833575
* experimental ui: not only report errors, but also failures immediatelyGravatar Klaus Aehlig2016-06-09
| | | | | | | | | | | | When a user is running a test with lots of runs (e.g., to debug flakyness), it is useful to immediately see individual failures and not wait for the summary of tests. Therefore, report failure events just like errors in the scrollback buffer. -- Change-Id: If32d1201f59cec75d99d18a50fc881c3596c3081 Reviewed-on: https://bazel-review.googlesource.com/#/c/3770 MOS_MIGRATED_REVID=124437705
* ExperimentalEventHandler: fix off-by-one errorGravatar Klaus Aehlig2016-06-08
| | | | | | | | | | | | | | | | | | Java's Arrays.copyOfRange expects as "to" argument the index of the first character not to be copied. As indices start with 0, the first index outside the array is, in fact, the length itself (and not one more than the length). This off-by-one error so far never caused any problems, as Arrays.copyOfRange is guaranteed to accept arbitrary large "to" values and helpfully pads with 0-bytes. As 0-bytes are not shown on most terminals, the output still looked correct. However, that off-by-one error did mess up the output for users of the --experimental_show_artifacts flag. -- Change-Id: I135ff720740db5c224a47668fc7513cbb7110f9f Reviewed-on: https://bazel-review.googlesource.com/#/c/3771 MOS_MIGRATED_REVID=124332337
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-05 15:27:48 +0000