8000 Incremental flushing of messages in fine grained incremental mode · Issue #4911 · python/mypy · GitHub
[go: up one dir, main page]
Skip to content
< 8000 div id="partial-discussion-header" class="gh-header mb-3 js-details-container Details js-socket-channel js-updatable-content issue" data-channel="eyJjIjoiaXNzdWU6MzE0MzM1NTc5IiwidCI6MTc0ODQ5OTU5MX0=--3d126d71c65e9a5554f69e7d51cbac18d62e9506ae31cca69ab92212f3d331d7" data-url="/python/mypy/issues/4911/show_partial?partial=issues%2Ftitle&sticky=true" data-gid="MDU6SXNzdWUzMTQzMzU1Nzk=">

Incremental flushing of messages in fine grained incremental mode #4911

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.

Sign up for GitHub

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

Jump to bottom
Open
ilevkivskyi opened this issue Apr 14, 2018 · 2 comments
Open

Incremental flushing of messages in fine grained incremental mode #4911

ilevkivskyi opened this issue Apr 14, 2018 · 2 comments
Labels
feature needs discussion priority-2-low topic-fine-grained-incremental

Comments

@ilevkivskyi
Copy link
Member

I previously proposed to switch from alphabetic order of processing of targets to topologically sorted w.r.t. to dependencies. The argument was that it may give some minor performance boost because we will reach a fixed point faster. However, there is another argument, in this case we can incrementally flush errors, because after we fully processed all targets in an SCC there is no way back.
@gvanrossum
Copy link
Member

But since fine-grained mode is usually invoked from the daemon we'll also need a re-architecting of the daemon's client-server protocol to allow returning errors as they are produced. @msullivan implemented that for non-daemon mode a while back. It's a great improvement over the original "flush at end" approach, and (for runs that take longer) I miss it.

@msullivan
Copy link
Collaborator

This is a dupe of #4702 but I'll close that one. I think this would work, but it will require a rework so that we don't depend on error reprocessing (#4801)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature needs discussion priority-2-low topic-fine-grained-incremental
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@msullivan @JukkaL @gvanrossum @ilevkivskyi
0