You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 26, 2019. It is now read-only.
Sometimes a notebook cell execution result may end up adding an element (such as a <script>) to the DOM in order to load an external resource. Bokeh is one example of this as it wants to load some JS files from a CDN.
Subsequent notebook cells may depend on these resources being loaded, so "run all" doesn't work. Sometimes workarounds can be recommended, such as forcing "inline" mode for Bokeh so that the JS is sent in a Websocket message.
@jhpedemonte: So here's my new proposal: we execute all code cells in a loop, then wait for result to come back and pass that to jupyter-js-output-area to handle. The latter is what adds HTML/JS to the DOM. When handling results, we can add a check to see if any <script> were added to the DOM. If so, we add onLoad handlers and queue up any remaining results until those scripts have loaded.
The text was updated successfully, but these errors were encountered:
I'm assuming, for Bokeh at least, the behavior is the same in the notebook server when the user does a Run All, yes?
I suggest not tackling this just yet. I'd like to see how many other libraries have this problem. If they haven't provided a setting like Bokeh's "inline", then they don't technically work properly in the notebook server either. I don't think we should invent execution flows here. (I'd rather see the notebook execution model address this async problem, which I think @lbustelo has mentioned in the past.)
I'm assuming, for Bokeh at least, the behavior is the same in the notebook server when the user does a Run All, yes?
yes
I'd like to see how many other libraries have this problem.
I don't think we should invent execution flows here.
Agreed. I intended this to be an investigation/experiment. Perhaps a component of that is surveying which technologies have this problem in the notebook to help evaluate the scope of the issue.
Sure. I'm saying let's do it as a background task instead of going out and actively finding things that break. Plenty of other things we gotta get working in the meantime.
Sometimes a notebook cell execution result may end up adding an element (such as a
<script>
) to the DOM in order to load an external resource. Bokeh is one example of this as it wants to load some JS files from a CDN.Subsequent notebook cells may depend on these resources being loaded, so "run all" doesn't work. Sometimes workarounds can be recommended, such as forcing "inline" mode for Bokeh so that the JS is sent in a Websocket message.
One solution was proposed in #108 (comment) :
The text was updated successfully, but these errors were encountered: