Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Throttle rate of output messages #663

Open
fischman opened this issue Oct 11, 2013 · 10 comments
Open

Throttle rate of output messages #663

fischman opened this issue Oct 11, 2013 · 10 comments
Labels
Milestone

Comments

@fischman
Copy link

Building a large project with ninja output going to an emacs compilation buffer is painful b/c emacs doesn't do so well with 10k-line-buffers.

IWBN to have a rate-limit on progress messages, such as "don't emit a progress message more often than once per seconds". Could be done with an env var or a cmd-line option to ninja (I weakly prefer env var).

WDYT, worth writing a patch for?

@nico
Copy link
Collaborator

nico commented Oct 11, 2013

This might make sense for the one-line-overwriting mode, but terminals seem to be fast enough to handle the current behavior.

emacs probably gets the output one sees when running ninja | cat – the more unixy way of handling this would be to write a standalone program that reads lines from stdin and only writes one every N ms to stdout, dropping the rest, and have emacs consume ninja output through that. This sounds general enough that it might already exist.

@fischman
Copy link
Author

Nico: I thought about an external throttler, but that seems to fail because
it'd be unable to keep line that are associated together, i.e. multi line
errors, or output belonging to an action.
On Oct 10, 2013 6:36 PM, "Nico Weber" [email protected] wrote:

This might make sense for the one-line-overwriting mode, but terminals
seem to be fast enough to handle the current behavior.

emacs probably gets the output one sees when running ninja | cat – the
more unixy way of handling this would be to write a standalone program that
reads lines from stdin and only writes one every N ms to stdout, dropping
the rest, and have emacs consume ninja output through that. This sounds
general enough that it might already exist.


Reply to this email directly or view it on GitHubhttps://github.com//issues/663#issuecomment-26106826
.

@nico
Copy link
Collaborator

nico commented Oct 11, 2013

Clearly, ninja should have xml output, then the filter would be easier to write :-D

Does this help: http://stackoverflow.com/questions/11239201/can-i-limit-the-length-of-the-compilation-buffer-in-emacs ?

@fischman
Copy link
Author

Sadly comint-truncate-buffer actually makes things far worse.

@fischman
Copy link
Author

Nico: since none of the workarounds work WDYT of the proposed patch above?

@nico
Copy link
Collaborator

nico commented Apr 24, 2014

There's a long list of things people want to configure ninja's output. I'd like to collect a list of all of that and put that in a tracking bug, and ideally come up with some cohesive way to address most of them.

@fischman
Copy link
Author

Filed #746 for the tracking bug.

@fischman
Copy link
Author

I've been out of the ninja game for years so unsubscribing from this. Feel free to close if no longer useful, or @ me if you want me to see a followup.

@bradneuman
Copy link

I recently started using cmake with ninja in emacs and encountered this same problem. Built-in support for this would be much nicer, but I took the approach of creating a quick-and-dirty "throttling" script in python here: https://gist.github.com/bradneuman/3f2bcb3b3a31f00129f69fead4d94c5f

YMMV and you may have to change the (very simple) regex I used there, but for now it did the trick for me. It just throttles to one-per-second for lines matching a certain regex and prints everything else

@jonesmz

This comment was marked as abuse.

@jhasse jhasse added this to the 2.0.0 milestone Apr 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants