Re: [sage-devel] Re: Jupyter notebook by default?
Volker Braun <[email protected]>
| Newsgroups | gmane.comp.python.ipython.devel |
|---|---|
| Message-ID | <59b5c876-b745-4352-9b7e-38f9fe3f2800__48022.9237619371$1452071151$gmane$org@googlegroups.com> |
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. 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 <[email protected] > <javascript:>> wrote: > >> >> ---------- Forwarded message ---------- >> From: Jonathan Frederic <[email protected] <javascript:>> >> Date: Tue, Jan 5, 2016 at 11:42 AM >> Subject: Re: [sage-devel] Re: Jupyter notebook by default? >> To: Jason Grout <[email protected] <javascript:>> >> Cc: sage-devel <[email protected] <javascript:>> >> >> >> 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 <[email protected] >> <javascript:>> 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 >>> >> >> >> > _______________________________________________ IPython-dev mailing list [email protected] https://mail.scipy.org/mailman/listinfo/ipython-dev