<div dir="ltr">IMHO output capture into a web browser isn't really different from the scrollback buffer of a terminal. We obviously enjoy the infinite scrollback but do not want an unbounded drawing surface in the terminal (= dom nodes in the web browser). And certainly nobody wants a piece of their output discarded in a long-running computation. <div><br></div><div>The technical implementation is virtual scrolling, this is what the terminal does and this is how the browser should do it, too.</div><div><div><br><br>On Tuesday, January 5, 2016 at 8:21:53 PM UTC+1, Jason Grout wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir="ltr"><div>(cross-posting to ipython-dev)</div><div><br></div>Jon,<div><br></div><div>At the recent San Francisco meetings, we talked about this.  What do you think about:</div><div><br></div><div>1. keeping track of the size of the io messages sent from any specific kernel execution</div><div>2. When the total size of io reaches some specific size (user-configurable), transmitting a special "throwing away output, but here's how to save the output to a file if you want in the future, or how to increase the limit" message</div><div>3. keep a running buffer of the last bit of output attempted to be sent, and send it when the execution finishes (so basically a ring buffer that overwrites the oldest message)</div><div><br></div><div>This:</div><div><br></div><div>* allows small output through</div><div>* provides an explanatory message</div><div>* provides the last bit of output as well</div><div><br></div><div>One thing to figure out: a limit on size of output that is text may not be appropriate for output that is images, etc.</div><div><br></div><div>Thanks,</div><div><br></div><div>Jason</div><div><br><div><br><div class="gmail_quote">On Tue, Jan 5, 2016 at 12:11 PM, Jason Grout <span dir="ltr"><<a href="javascript:" target="_blank" gdf-obfuscated-mailto="UT4FEb9oBwAJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">ja...@jasongrout.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Jonathan Frederic</b> <span dir="ltr"><<a href="javascript:" target="_blank" gdf-obfuscated-mailto="UT4FEb9oBwAJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">jon.f...@gmail.com</a>></span><br>Date: Tue, Jan 5, 2016 at 11:42 AM<br>Subject: Re: [sage-devel] Re: Jupyter notebook by default?<br>To: Jason Grout <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="UT4FEb9oBwAJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">grout...@gmail.com</a>><br>Cc: sage-devel <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="UT4FEb9oBwAJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">sage-...@googlegroups.com</a>><br><br><br><div dir="ltr">Jason,<div><br></div><div>Thanks for pulling me in on this.  </div><div><br></div><div>William,</div><div><br></div><div>I agree, getting a bunch of people to agree on stuff can seem impossible.  However, you mention Sage offers a couple options to mitigate output overflows, can you point me to those options?  The Jupyter Notebook should provide multiple options too - this will also make it easier for everyone to agree.</div><div><br></div><div>Also, in you experience, which of these options work the best?  </div><div><br></div><div>I was thinking initially of doing something simple, like hard limiting data/time, then printing an error if that's exceeded.  In the Jupyter Notebook, we have to worry about</div><div>- Too many messages sent on the websocket</div><div>- The notebook json file growing too large and consequently becoming unopenable</div><div>- Too much data being appended to the DOM, crashing the browser</div><div><br></div><div><br></div><div>Thanks!</div><div>-Jon</div></div><div><div><div><br><div class="gmail_quote">On Tue, Jan 5, 2016 at 10:19 AM, Jason Grout <span dir="ltr"><<a href="javascript:" target="_blank" gdf-obfuscated-mailto="UT4FEb9oBwAJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">grout...@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br>On Tuesday, January 5, 2016 at 8:17:45 AM UTC-7, William wrote:<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>One example of a subtle feature in Sage (notebook and worksheets) not
<br>in Jupyter, which I was just reminded of, is output limiting.  In Sage
<br>there are numerous rules/options to deal with people doing stuff like:
<br>
<br>while True:
<br>   print "hi!"
<br>
<br>... which is exactly what students will tend to do by accident...
<br>Jupyter doesn't deal with this, but it might not be too hard to
<br>implement in theory.  One of the main problems is figuring out what
<br>the arbitrary rate limiting defaults "should" be; it's arbitrary, and
<br>depends a lot on whether everything is local, over the web, etc. so
<br>getting a bunch of people to agree is hard, which might mean they will
<br>never implement anything.
<br></blockquote><div><br></div><div><br></div><div>William,</div><div><br></div><div>Jon Frederic in the Jupyter dev meeting happening right now said that he will be working on output limiting as one of his next things.</div><span><font color="#888888"><div><br></div><div>Jason</div></font></span></blockquote></div><br></div>
</div></div></div><br></div>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div></div></div>