-
Notifications
You must be signed in to change notification settings - Fork 241
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
Improve handling of "rapid fire" completion requests #241
Comments
nsc Global docs here describe that certain requests may be prioritized higher than existing requests. Hard to tell under which exact conditions this would occur, and whether, once newer requests finish, older ones would be resumed. I might try to monkey-patch my way around Ammonite's CompilerLifecycleManager.complete being synchronized and just feed concurrent requests into its Pressy and see what happens. |
We made the architecture for this in Jupyter and while it's handy for debugging, it's not widely used (from a ZeroMQ standpoint). However, each client should have a unique session ID so it could be keyed on that. |
@jameskoch The scala presentation compiler, which handles completions, should support concurrent completion requests, yes. Ammonite doesn't use that and just blocks until a completion result arrives. I guess the I'm going to tweak the |
#242 allows |
@jameskoch I can look into having Ammonite accept concurrent completion requests, if you haven't already. |
I haven't pushed ahead on this, and I wouldn't be nearly as effective as you in doing so. Have at it! |
com-lihaoyi/Ammonite#893 should allow to handle more of the completion logic from almond, and make it interruptible in particular. |
The nteract front end is far more aggressive than Jupyter notebook about requesting completions from the kernel as the user types. There's some great UX that can be unlocked if this could work more seamlessly w/ Almond.
Ideally, when Almond receives a new completion request it would quickly interrupt an in-flight one to prioritize the new/latest one.
Would need to think about how this works in the "multiple front-ends attached to a single kernel" model (I don't know much about that world).
Discussed a bit in this nteract issue.
The text was updated successfully, but these errors were encountered: