[IPython-dev] messaging protocol

[Brian Granger]

On Sun, Apr 10, 2011 at 9:27 PM, Robert Kern <robert.kern at gmail.com> wrote:
> On 2011-04-10 23:09 , Brian Granger wrote:
>> On Sat, Apr 9, 2011 at 11:18 PM, Robert Kern<robert.kern at gmail.com>  wrote:
>>> On 2011-04-10 01:06 , Brian Granger wrote:
>>>> On Fri, Apr 8, 2011 at 2:05 PM, Robert Kern<robert.kern at gmail.com>    wrote:
>>>>> On 4/8/11 3:32 PM, Fernando Perez wrote:
>>>>>> On Fri, Apr 8, 2011 at 1:21 PM, Thomas Kluyver<takowl at gmail.com>      wrote:
>>>>>>>
>>>>>>> In fact, now that we're using AST instead of code blocks, we could actually
>>>>>>> do what you suggest. We could check the last node, and only run it
>>>>>>> interactively if it was a single expression. Whether or not that's what we
>>>>>>> want to do, I don't know: any views?
>>>>>>
>>>>>> That's a very good point.  The fragile heuristics we had were
>>>>>> precisely because we lacked this information.  But I really do like
>>>>>> this suggestion, because I think it provides the most intuitive
>>>>>> semantics.  Things like:
>>>>>>
>>>>>> for i in range(10):
>>>>>>      plot(foo[i])
>>>>>>
>>>>>> won't produce 10 different Out[] outputs, and yet any last-block
>>>>>> expression, even if it contains some multline string or other complex
>>>>>> formatting that makes it be more than one *line of text* will still be
>>>>>> executed interactively, yielding just one result.
>>>>>>
>>>>>> I'm very much +1 on this idea.  Big benefit of your recent tackling
>>>>>> inputsplitter!! Awesome.
>>>>>
>>>>> I don't think we need to solve this in the splitter. You can do everything you
>>>>> need to do in the display trap. The logic is very simple. The display trap sets
>>>>> the displayhook before the code In[N] is executed. Every time the displayhook
>>>>> gets called during this execution, the display trap records the object and its
>>>>> formatted representation, overwriting whatever was there. Once the execution is
>>>>> done, *then* the formatted representation is given to the reply message (or
>>>>> printed if in the terminal frontend) and the history DB (if it is storing
>>>>> outputs), and the object is shoved into Out[N]. Then the display trap is cleared
>>>>> before In[N+1] is executed.
>>>>
>>>> This is a good point that is worth investigating.  The only hitch is
>>>> that the formatted representation is not sent in the reply to the
>>>> original code execution request.  It is published over the PUB socket,
>>>> which makes sure that gets sent to all frontends.  This means that the
>>>> display hook data can be sent out to all frontends *before* the
>>>> execute reply message goes back.  But we might still be able to get
>>>> this to work.  It is attractive because it would be this logic out of
>>>> the splitter, where it seems a bit out of place.
>>>
>>> Replace "reply message" with "displayhook PUB message" in what I wrote. You just
>>> need to explicitly tell the DisplayHook when to actually send the message/print
>>> the repr in the actual execution cycle. It should not do it on every __call__.
>>> That's all. That was the design I had in the ipwx prototype way back when.
>>
>> I don't think it is that simple as the display hook PUB message gets
>> send out immediately:
>>
>> a = 10
>>
>> a     # the PUB message happens here, before blocks are done being executed
>>
>> time.sleep(10)
>>
>> Thus, the display hook *can't* have the information it needs to make
>> the decision about what to publish.  Upon further thinking, I don't
>> see how we can get around this.
>
> I'm not sure how much more clearly I can state this: just don't make the
> DisplayHook send the PUB message in it's __call__(). Have the __call__() only
> collect the object and the formatted representations. Add another method that
> actually formulates the PUB message and send it out. Call that method explicitly
> after the cell has finished executing.

I do understand the model you are proposing.  Implementing it would
require that the sending of the PUB message be delayed until the cell
has finished executing.  It is this delay that our current model is
incompatible with.  Any traffic (stdout, stderr, display hook) that is
sent out over the PUB channel is send *immediately*.  This is required
so that the users sees these things in real time as the code is
executed, not after.

Cheers,

Brian

> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless enigma
>  that is made terrible by our own mad attempt to interpret it as though it had
>  an underlying truth."
>   -- Umberto Eco
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com