[IPython-dev] [sage-devel] Re: Jupyter notebook by default?

[Volker Braun]

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>