Replies: 3 comments
|
The server-side counterpart of this code wasn't open sourced - it only exists in Blaze. I believe the approach you describe would work, because only the Blaze server interprets |
0 replies
|
I sent a PR here #29750 with a nice GIF demo of the issue and the fix. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I realized that due to our client - server architecture, the JVM server is not attached to the terminal and won't be able to process SIGWINCH properly, only the client can implement a SIGWINCH handler.
c51d2bd added a note in the client code saying
But I am unable to find references to it anywhere. Was this commit accidentally included a change from another CL?
My main problem with this is that the curses outputs are emitted from the JVM server, which means currently, on the event of the terminal resizing mid-build, bazel would emit wrong curses, and we end up with multiple lines of duplicated outputs.
On a daily basis, a common workflow I use is to start a new terminal inside tmux, run a build, and while it's running, create a new vertical split pane to multitask something else. This new vertical split caused the terminal to change its width by half, which results in Bazel outputs getting all mangled up.
I suspect we can make the client handle the signal and send an RPC to notify the server of this event.
But I'm curious if there are other code blocks inside Google, as referenced above, that may block this effort.
All reactions