-
Notifications
You must be signed in to change notification settings - Fork 159
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
Timeout during background ESS command ? #1104
Comments
Another example |
Another error on
|
The idea is that all Emacs freezes should be considered bugs. So instead of setting a large timeout, two things should ideally happen:
We currently have the infrastructure for (1) but not for (2). So I've been collecting the commands that should be implemented asynchronously with Because async commands will be callback-based, we can't use the |
Ok, let's discuss further. But let's fix the default to inf for now. I am having serious issues. Can no longer start R processes with long startup times properly. They just freeze and ESS is not loaded properly. #1102 is almost surely related to this as well.
I think doing the other way around is more natural: collect all time sensitive commands and set short timeout only for those, or do async. Leave all others to the backward compatible default. You never know who is using ess-command and how. Things might start breaking in third packages like org-mode and personal code of our users. Designers of the old code didn't envisage timeouts like these. Things can go wrongly in unexpected ways, particularly with chained commands. Also designers of new code will have to consider timeouts, which complicates reasoning and implementation. I think we can do much better than timeouts. Async can also be used for time sensitive stuff.
Yes and no. For most interactive commands I, as a user, expect them to take a bit (fetching stuff, display help, print etc). So it's ok to wait, and it is also ok to interrupt with C-g when output no longer needed or it's partial but enough. For instance C-c C-d C-e output can be very long, I would like to C-g and stop the printing (currently the printing continues to the R console, which is not ok, but well, you get the idea). |
This is definitely what I was planning for this release. In the future we could switch
I guess it will be more productive to discuss this over an actual implementation of In the short term here are our options:
Both work for me. I think (2) would help me design the foreground command API when the time comes by making sure the approach works for all the collected use cases. |
Got it. I really thought you insist on moving to 2s everywhere at once.
But this means breaking everyone else's ESS in the meanwhile :)
Sure, but I am still a bit confused. Wouldn't it make sense to enhance the |
Right it became apparent that longer timeouts were needed in several places as people updated their ESS and reported issues.
If we keep |
My uninformed estimate is that the large majority of user commands are expected (must?) be locking. I would say about 90/10% ratio. I also vaguely remember some other emacs IDEs to use large timeouts for sync commands by default. We can check, but I think this is largely the expected behavior on the developer side. |
I am very pleasantly surprised that this is no longer the case with your changes. So we no loner have output spilling to R console on C-g under any circumstance? That's pretty amazing!! How does it work in 2 words?
Do you need us to catch up on your recent changes then? I am on a break myself, and it might take a while till I am fully back to full loop. |
Thanks! Summary of the
I suspect the sentinel approach will synergise well with the evaluation queue planned in #1017 and may allow us to simplify the treatement of async commands. With the sentinel we'll never pop the queue while an async command is running. |
Another important change is that we're now using the Rd AST to generate some aspects of the documentation (links) #1099. In the future it'd be nice to generate it solely from the AST. |
When I do
C-c C-d C-e
on a relatively large object I am gettingTimeout during background ESS command
(implemented in ee0266e)I don't think 1s global default timeout is a good idea. "instantaneous" is a relative concept. It can easily span > 1 s on remote machines and it almost always spans > 1s for
C-c C-d C-e
I think the default should be 30s. C-g should do the job and it's up to the developer to decide whether to use shorter delays. For eldoc completion, like the cause of #1062, it can be 1s indeed, but then some calls will never be cached, so no completion. Not ideal either.
The text was updated successfully, but these errors were encountered: