Support echoing output from other clients #6123
Conversation
|
Sweet, Min! How hard would it be to get this in qtconsole and the notebook, too? |
|
QtConsole should be easy enough. Notebook seems harder, since I don't know where the output would go (I don't think it should go in an existing cell). |
|
The messages already arrive, so it's just a question of what to do with them. |
| help="""Whether to include output from clients | ||
| other than this one sharing the same kernel. | ||
|
|
||
| Outputs are not displayed |
There was a problem hiding this comment.
Looks like you got half way through writing this - it should presumably end like "... until you next run code here."
|
+1 once in has finish his sentences. |
|
I need to do the qtconsole side as well. I should focus on Contents and multi-user for the next couple of days, but I'll get back to this one. |
| Outputs are not displayed | ||
| """ | ||
| ) | ||
| other_output_prefix = Unicode("[remote]", config=True, |
There was a problem hiding this comment.
I would include a space after the [remote] to separate this from the In/Out prompt visually.
|
Very cool! I left one inline comment. I playing around with this I did find something I would consider a bug:
I thought we were only letting the owning frontend kill the kernel upon existing? |
|
Adding this to the QtConsole shouldn't be too bad, but I agree that the UI for the notebook is a bit more uncertain. We will probably have to try out a few things... |
722d384 to
1e062ca
Compare
|
Works in QtConsole, and sentences completed. I don't plan to address the exiting behavior here because I can't reproduce it, and I don't think it's related to this PR. |
1e062ca to
8781cc0
Compare
|
Should be ready to review |
| @@ -347,7 +347,7 @@ def _insert_continuation_prompt(self, cursor): | |||
| #--------------------------------------------------------------------------- | |||
| def _handle_clear_output(self, msg): | |||
| """Handle clear output messages.""" | |||
| if not self._hidden and self._is_from_this_session(msg): | |||
| if not include_output(msg): | |||
There was a problem hiding this comment.
I think the not here is wrong.
|
Other than those things, 👍 |
8781cc0 to
3354039
Compare
in the zmq console Can result in outputs like: ``` In [1]: 1 [remote]In [1]: 1 [remote]Out[1]: 1 [remote]In [2]: 3 [remote]Out[2]: 3 Out[3]: 1 ``` Note that there will be inconsistencies in prompt numbers because some execution may take place after the in-prompt is drawn.
matches zmq console. Doesn't include `[remote] ` prefix, because true async output makes it less important.
3354039 to
5adedb3
Compare
in qtconsole
5adedb3 to
0d5f7a8
Compare
|
Typo fixed, and remote input is highlighted in the qtconsole |
| if self.include_other_output: | ||
| return True | ||
| else: | ||
| return from_here |
There was a problem hiding this comment.
Name of function is a little weird if it's other input too, but that fine I guess. Also isn't the last equivalent to return self.include_other_output and from_here ? If so it seem it could be simplified with the previous block. Handwaving i would say if (include_other and (not from_here or 'execute_input')), but maybe it becomes hard to read.
There was a problem hiding this comment.
I had also looked at this block, and seen that it could be return self.include_other_output or from_here, but I don't think that's any clearer than spelling it out as Min has done.
Therefore, merging.
|
+1, small comment that we maybe can simplify logic. |
Support echoing output from other clients
Support echoing output from other clients
…anything was ever incorporated into the IPython Notebook. Here's a brief overview of the changes: - Display of messages from other clients can be toggled on and off from within a notebook, either using the ``<M-m>e`` keyboard shortcut in the web UI, or through the option in the "Kernel" menu. - notebook.js controls whether messages are displayed through a callback that is invoked from kernel.js when no callbacks are available for a message. - The UI displays ``execute_input`` messages originating from an other clients in new cells at the end of the notebook. Output messages (``execute_result`` et al.) will only be displayed if a cell exists with a matching message ID. Pending design questions: - Should each ``execute_input`` message cause a new cell to be created? - Should new cells be placed at the end of the notebook, or elsewhere? If the latter, what criteria should be followed?
in the zmq console
Can result in outputs like:
Note that there will be inconsistencies in prompt numbers because some execution may take place after the in-prompt is drawn.
closes #1873