Skip to content
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

Console doesn't show output until code is done running #936

Closed
ellisonbg opened this issue Sep 22, 2016 · 6 comments · Fixed by #1049
Closed

Console doesn't show output until code is done running #936

ellisonbg opened this issue Sep 22, 2016 · 6 comments · Fixed by #1049
Assignees
Labels
bug pkg:console status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion.
Milestone

Comments

@ellisonbg
Copy link
Contributor

import time
for i in range(10):
    print(i)
    time.sleep(1)

This should show output as it comes back but only shows the output after everything has run.

@ellisonbg ellisonbg added this to the 0.90 milestone Sep 22, 2016
@ellisonbg ellisonbg added the bug label Sep 22, 2016
@jasongrout
Copy link
Contributor

Works for me with e8eda3a. What commit are you on?

consoleprint

@blink1073
Copy link
Contributor

AFAIK the issue was that it doesn't scroll, which made it look like it was not updating.

@jasongrout
Copy link
Contributor

Oh yeah, I'm remembering the conversation now...

@AlexTugarev
Copy link
Member

I am also interested in this issue because. We have situations where the progress of a longer running process is reported via stream messages, but the user needs to scroll manually to see the progress.

This is my test case with ipykernel. You need to await the end of the stream to see the lines with the higher numbers.

from time import sleep
for i in range(1,200):
  print(i)
  sleep(0.02)

But I want to add some details on this issue. It seems like the scroll down action is triggered when the execute_reply message was received by the client. Please correct me if I am wrong about this, but it was hard to follow the signals.

Now consider a kernel sends a lot of stream messages in a row on the iopub channel while executing code and completes with an idle message on the iopub and an execute_reply on the shell channel. It happens that the execute_reply message arrives amongst the stream messages on client side. If you at the websocket frames, it looks like:

...
stream
...
stream
execute_reply
stream
...
stream
status:idle

From what I've understood, the iopub channel is busy sending all the message but the shell channel is idling, which means the execute_reply message supersedes on the websocket.

In ipykernel I've found a suspicious sleep call right before sending the execute_reply message. I assume this is a workaround for that issue. This workaround kind of works for our kernel too, but I think it only obscures a conceptual problem because the channels cannot be synchronized.

cf. https://github.com/ipython/ipykernel/blob/83da0a17a00ec9f3dded65b3434980bfb2c84080/ipykernel/kernelbase.py#L92
and https://github.com/ipython/ipykernel/blob/83da0a17a00ec9f3dded65b3434980bfb2c84080/ipykernel/kernelbase.py#L399

That was verbose, right? My real question about this issue is, can the output area in the console be scrolled down automatically on insertion of new lines? I guess this would solve the issue.

@ellisonbg
Copy link
Contributor Author

Yes, we should scroll the console down when any new lines are added to the output. Honestly I would scroll it down on any model change to the last cell?

@blink1073
Copy link
Contributor

That makes sense to me, I'll implement it tomorrow.

@blink1073 blink1073 self-assigned this Oct 6, 2016
@lock lock bot added the status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion. label Aug 10, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Aug 10, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug pkg:console status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants