[IPython-dev] messaging protocol

[Brian Granger]

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.

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