[IPython-dev] [sage-devel] Re: Jupyter notebook by default?
Volker Braun
vbraun.name at gmail.com
Wed Jan 6 04:05:32 EST 2016
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 <ja... at jasongrout.org
> <javascript:>> wrote:
>
>>
>> ---------- Forwarded message ----------
>> From: Jonathan Frederic <jon.f... at gmail.com <javascript:>>
>> Date: Tue, Jan 5, 2016 at 11:42 AM
>> Subject: Re: [sage-devel] Re: Jupyter notebook by default?
>> To: Jason Grout <grout... at gmail.com <javascript:>>
>> Cc: sage-devel <sage-... at googlegroups.com <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 <grout... at gmail.com
>> <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
>>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20160106/66c89112/attachment.html>
More information about the IPython-dev
mailing list