Don't assume history requests succeed in qtconsole #745

Merged
merged 3 commits into from Sep 9, 2011

Conversation

Projects
None yet
2 participants
@minrk
Member

minrk commented Aug 29, 2011

If there was an error in user startup code, the history request will be aborted. It is generally not acceptable in frontends to assume that requests succeed. This assumption is made all over our frontend code, and should be be fixed. For now, this handles a known issue of the qtconsole crashing hard when invalid input is given to startup code (e.g. ipython qtconsole -c "DNE").

If the history request was aborted (this means a different request raised an error, causing the queue to be flushed), it will be tried again, exactly once, after waiting for the abort flush.

minrk added some commits Aug 3, 2011

make ConsoleWidget LoggingConfigurable
This adds the attribute Widget.log, which is hooked up to the
running application's logger.
Don't assume history request succeeded
errors in startup can cause the history request to be aborted.  There could be any of
a number of reasons the history request should fail, and the frontend should *never*
assume that the status is 'ok'.
@epatters

This comment has been minimized.

Show comment
Hide comment
@epatters

epatters Aug 30, 2011

Contributor

Thanks for the fix, Min. I noticed this crash recently myself.

That said, this approach makes me a little leery. The Qt console (and no doubt other frontends as well) makes many different requests: for execution, history, tab completion, object info, etc. It seems painful to have check status and possibly retry the request under all these differences circumstances. I wonder if it possible to abstract at least some of this away, e.g. by having BaseFrontendMixin handle the retries automatically.

This is all somewhat vague. I will think about this some more and see if I can produce anything more substantial.

Contributor

epatters commented Aug 30, 2011

Thanks for the fix, Min. I noticed this crash recently myself.

That said, this approach makes me a little leery. The Qt console (and no doubt other frontends as well) makes many different requests: for execution, history, tab completion, object info, etc. It seems painful to have check status and possibly retry the request under all these differences circumstances. I wonder if it possible to abstract at least some of this away, e.g. by having BaseFrontendMixin handle the retries automatically.

This is all somewhat vague. I will think about this some more and see if I can produce anything more substantial.

@epatters

This comment has been minimized.

Show comment
Hide comment
@epatters

epatters Aug 30, 2011

Contributor

OK, I have an implementation plan for more robust error handling. Since this will involve some refactoring, I think it's worth merging this now as an interim fix.

Contributor

epatters commented Aug 30, 2011

OK, I have an implementation plan for more robust error handling. Since this will involve some refactoring, I think it's worth merging this now as an interim fix.

minrk added a commit that referenced this pull request Sep 9, 2011

Merge pull request #745 from minrk/history
Don't assume history requests succeed in qtconsole

closes gh-667

@minrk minrk merged commit 17494a1 into ipython:master Sep 9, 2011

mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this pull request Nov 3, 2014

Merge pull request #745 from minrk/history
Don't assume history requests succeed in qtconsole

closes gh-667
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment