Weird layout when commands output large amounts of text

[multimeric]

I'm using the bash kernel, but I assume this isn't specific to that kernel.

If I create a cell that has tons of output, like grep --help here, the cell is initially positioned correctly:

Then, when I run the cell, the output is now present, but the cell is still positioned in the center of the screen instead of the top:

When I go forward a slide and then back, this resolves itself:

Here's a notebook that can be used to reproduce this. Note that this uses the Bash kernel:

rise_bug.ipynb.txt

[multimeric]

This seems to be related to the top property of the <section id="slide-0-0"> element. It must be being calculated wrongly. In my example, it's initially set to 538.3px, which correctly puts it in the middle of the page. Then when I run the cell, it changes to 509.8px, so it does update, but not very much. Then finally when I re-open the slideshow, it has top: 0px. I wonder if, because this output is printed to stdout progressively by the command, Jupyter calculates the new location of the cell before all of the output has all been produced, and then stops updating?

Does anyone have any idea what part of RISE calculates this offset, and where to amend this behaviour?

[parmentelat]

hiya

I remember having struggled with this behaviour at the time IIRC its root cause is some sort of race condition between the various engines at work in the system, namely the execution of the cell by jupyter, its rendering by codemirror, and reveal's own internal machinery I can't be more accurate at this point because it was all quite a while ago, but I also remember having added a configurable timer that you can tweak in the configuration area of RISE you may want to try and enlarge this a bit

[multimeric]

Hi, thanks for the advice! Unfortunately I tweaked this number up to something obscenely high (2000 ms), and it still didn't fix the issue. I can verify that the customized config was being loaded because I also enabled autolaunch which was working correctly.

[multimeric]

I think I might have identified a bug in RISE here, by debugging the JS as it executes in my browser. The parameter that you refer to seems to configure the complete_config.aync_timeout variable, but the variable that is used to determine the timeout is called complete_config.sync_timeout:

https://github.com/damianavila/RISE/blob/8bf44513fe65a61e7240837c2a701f8d4f7753e7/classic/rise/static/main.js#L363

[parmentelat]

is this something we can close now with your 2 PRs merged in 5.7.2.dev2 ?

[multimeric]

In my opinion neither of them are a "true" fix, they're both just workarounds. But if you would like to close this issue you may.