On Wednesday, January 6, 2016 at 10:05:32 AM UTC+1, Volker Braun wrote: > > 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. > > The technical implementation is virtual scrolling, this is what the > terminal does and this is how the browser should do it, too. >
Jon mentioned that there are a few levels for large output to cause problems. The lowest bar is putting the output on the page, which is by far the easiest to hit, causing an unresponsive browser. This is the level that can be addressed by virtual scrolling / truncating output in UI. Fortunately, it’s also the easiest one to implement. If we truncate instead of virtual-scroll, then we have a choice for whether truncated output is included in the document or not, which alleviates the problem of opening notebooks that have a problematic amount of output. But it’s putting that on the page that’s ~always the problem, not loading the notebook JSON itself, so I’m somewhat less concerned about that. The next level where it can cause problems is the output coming over the network in the first place. We can throttle this in the notebook server, as was implemented for 4.2 <https://github.com/jupyter/notebook/pull/506> months ago. Again, this moves the bar for when output causes trouble, but isn’t a complete solution. Dumping truncated output to a file is complicated a bit by the separations we have in place, but it should be doable. -MinRK > > > On Tuesday, January 5, 2016 at 8:21:53 PM UTC+1, Jason Grout wrote: >> >> (cross-posting to ipython-dev) >> >> Jon, >> >> At the recent San Francisco meetings, we talked about this. What do you >> think about: >> >> 1. keeping track of the size of the io messages sent from any specific >> kernel execution >> 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 >> 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) >> >> This: >> >> * allows small output through >> * provides an explanatory message >> * provides the last bit of output as well >> >> One thing to figure out: a limit on size of output that is text may not >> be appropriate for output that is images, etc. >> >> Thanks, >> >> Jason >> >> >> On Tue, Jan 5, 2016 at 12:11 PM, Jason Grout <ja...@jasongrout.org> >> wrote: >> >>> >>> ---------- Forwarded message ---------- >>> From: Jonathan Frederic <jon.f...@gmail.com> >>> Date: Tue, Jan 5, 2016 at 11:42 AM >>> Subject: Re: [sage-devel] Re: Jupyter notebook by default? >>> To: Jason Grout <grout...@gmail.com> >>> Cc: sage-devel <sage-...@googlegroups.com> >>> >>> >>> Jason, >>> >>> Thanks for pulling me in on this. >>> >>> William, >>> >>> 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. >>> >>> Also, in you experience, which of these options work the best? >>> >>> 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 >>> - Too many messages sent on the websocket >>> - The notebook json file growing too large and consequently becoming >>> unopenable >>> - Too much data being appended to the DOM, crashing the browser >>> >>> >>> Thanks! >>> -Jon >>> >>> On Tue, Jan 5, 2016 at 10:19 AM, Jason Grout <grout...@gmail.com> wrote: >>> >>>> >>>> >>>> On Tuesday, January 5, 2016 at 8:17:45 AM UTC-7, William wrote: >>>>> >>>>> >>>>> One example of a subtle feature in Sage (notebook and worksheets) not >>>>> in Jupyter, which I was just reminded of, is output limiting. In Sage >>>>> there are numerous rules/options to deal with people doing stuff like: >>>>> >>>>> while True: >>>>> print "hi!" >>>>> >>>>> ... which is exactly what students will tend to do by accident... >>>>> Jupyter doesn't deal with this, but it might not be too hard to >>>>> implement in theory. One of the main problems is figuring out what >>>>> the arbitrary rate limiting defaults "should" be; it's arbitrary, and >>>>> depends a lot on whether everything is local, over the web, etc. so >>>>> getting a bunch of people to agree is hard, which might mean they will >>>>> never implement anything. >>>>> >>>> >>>> >>>> William, >>>> >>>> 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. >>>> >>>> Jason >>>> >>> >>> >>> >> -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
