[IPython-dev] Qt/Curses interfaces future: results of the weekend mini-sprint (or having fun with 0mq)

[Barry Wark]

On Tuesday, March 23, 2010, Brian Granger <ellisonbg at gmail.com> wrote:
> Barry,
>
> Good to hear from you.

It feels good to try to get involved again. A PhD and starting a
family and a company have intervened. The last two will doubtless do
so again, but this announcement is too exciting not to draw me in a
bit.

>
>> Congratulations Brian and Fernando! This is a huge advance for UI
>> integration (and possible for parallel ipython as well).
>
> Thanks!
>
>> Having written several two-process UI/kernel systems, I suspect that
>> the direction things are heading will make it quite easy to implement
>> a UI frontend for the kernel using modern UI toolkits (e.g. Qt, Cocoa,
>> WPF, etc.)
>
> It should be.  I personally can't wait to see a Cocoa version of a UI :)

yes, I'm looking forward to doing some
hacking.

>
>> I suppose this new paradigm brings to the fore the ongoing discussion
>> of protocol for communication between frontend and the kernel. As this
>> could affect format for a persistent "notebook" format (it would be
>> nice to be able to send a notebook or notebook section to the kernel),
>> it might be worth considering the two issues together.
>
> The Python bindings to 0MQ (pyzmq) have the ability to
> serialize/unseralize Python objects using JSON or pickle.  In our
> prototype, we have chosen JSON because:
>
> * JSON can be handled by virtually any language, including in browser JS.
> * It leads to a very pythonic interface for messages in python.
> * It is reasonably fast.
> * Very flexible.
> * Take almost 0 code to support.
>
> Thus, my current leaning for UI<->kernel messages is JSON.  XML is a
> possibility, but it just doesn't seem to fit.

I see the logic in JSON over XML for sure and see your point about its
flexibility over, e.g. Protocol Buffets (see below). My take is that
JSON serialization seems to work best in dynamically types languages
whereas a mote structured approach fits better into statically typed
languages. Given the first implementations will almost certainly be in
python, I'm fine throwing my chips in with JSON for now as long ad
we're careful with string encodigs etc.

>
> But, I think that XML is worth thinking about for the notebook
> persistence format.  Using JSON for that doesn't seem like a good fit.
>  Maybe it is though, I had never though about that.  the other option
> is pure python code, which I like, but I am not sure there is broad
> support for it.
>
>> The previous
>> discussion settled, I think, leaning towards an XML notebook. Assuming
>> an entity that describes a block of python code, the UI->kernel
>> message could be an XML-serialized block and the response could be the
>> corresponding XML-serialized output. The other possibility is to
>> separate notebook format (XML) from UI<->kernel protocol.
>
> I do think the UI<->kernel protocol should be isolated from the
> notebook format.  The reason is that the UI<->kernel will know zip
> about the notebook.  It is only responsible for code execution.
> Another reason I want this separation is that different UIs might need
> different things for the notebook format.

True. On the flip side, notebooks hold
the inputs that get sent to the kernel plus the outputs that come
back. Why repeat code to serialize these items into different formats
etc. I'm not trying to take a strong stand on this one, just thinking
out loud.

And wouldn't it be nice for the project to have a consistent notebook
format across frontends? Seems like a useabity disaster to
be unable to take notebooks between platforms and/or frontends.

>
> Here is my current thinking about the notebook format.  We have had
> multiple attempts at creating a notebook format.  Fernando and Robert
> Kern mentored a GSOC project long ago that created an SML based
> notebook format.  Then Min created one that used XML and sqlalchemy.
> Both never took off.  Why?  My take is that a notebook format is
> useless until there is:
>
> 1. A kernel that the notebook frontend can actually talk to.
> 2. A nice notebook frontend that people actually want to use.
>
> Thus, I think we should start with (1), then do (2) and *lastly* worry
> about how to save the frontend sessions (notebook format).  I think
> that once we have (1) and (2) working, the notebook format will fall
> into place much more naturally.

Very true.

>
>> In this
>> case, something like Google's protocol buffers make sense. These
>> protocol buffer messages are somewhat easier (and much faster) to work
>> with from many languages than XML, but are not as easily human
>> readable (if at all) and would add yet an other non-stdlib dependency.
>> Just starting the discussion...
>
> Yes, I like protocol buffers.  The main reasons I see to go with them are:
>
> * Performance.
> * Less flexible - can make sure that a message has the right structure, etc.
>
> In the case of the UI<->kernel protocol, our messages are pretty small
> so performance isn't much of an issue and I think for now we want them
> to be super flexible.  This brings me back to JSON.
>
>> Looking forward to hacking some UIs,
>
> Cool.
>
> Brian
>
>> Barry
>>
>>
>>
>> On Tue, Mar 23, 2010 at 3:05 PM, Brian Granger <ellisonbg at gmail.com> wrote:
>>> All,
>>>
>>> As Fernando has summarized our work very well. I too am very excited
>>> about this development.  One thing that I don't think Fernando
>>> mentioned is that stdout/stderr and Out (displayhook) are all handled
>>> asynchronously AND broadcast to all users.
>>>
>>> Thus, if you run the following
>>>
>>> Py>>> for i in range(10):
>>>  ...   print i
>>>  ...   i**2
>>>  ...   time.sleep(1)
>>>  ...
>>>
>>> You get the result asynchronously:
>>>
>>> 0
>>> Out : 0
>>> Out : None
>>> [then wait 1 second]
>>> 1
>>> Out : 1
>>> Out : None
>>> [then wait 1 second]
>>> 2
>>> Out : 4
>>> Out : None
>>> [then wait 1 second]
>>> 3
>>> Out : 9
>>> Out : None
>>> [then wait 1 second]
>>> 4
>>> Out : 16
>>> Out : None
>>> [then wait 1 second]
>>>
>>> etc.  If another user is connected to the kernel, They will also
>>> receive these (along with the corresponding input) asynchronously.  In
>>> a terminal based frontend these things are a little bit difficult to
>>> demonstrate, but in a nice GUI frontend, we could imagine a nice a
>>> interface to represent these things.
>>>
>>> Cheers,
>>>
>>> Brian
>>>
>>> PS: Fernando, do you notice that time.sleep(1) (which returns None)
>>> also triggers displayhook?  That is a bit odd.  Do we want to filter
>>> out None from the displayhook?
>>>
>>>
>>> On Tue, Mar 23, 2010 at 2:01 PM, Fernando Perez <fperez.net at gmail.com> wrote:
>>>> Hi all,
>>>>
>>>> I realize that we have a significant task ahead in sorting some thorny
>>>> issues out to get 0.11 ready for release, especially with respect to
>>>> GUI handling.  But the big refactor of 0.11 starts to give us a clean
>>>> codebase on which new/better interfaces using ipython can be built,
>>>> and for that several people want to  contribute right away, so it's
>>>> best that we build a path forward for those contributions, even if
>>>> some of us still have to finish the 0.11 struggle.
>>>>
>>>> Wendell is looking into curses and Gerardo and Omar in Colombia are
>>>> looking at Qt, and it would be fantastic to be able to get these
>>>> developments moving forward soon.  So Brian and I got together over
>>>> the weekend and  did a design/coding sprint that turned out to be
>>>> surprisingly fun and productive.  This is the summary of those
>>>> results.  I hope this thread can serve as a design brief we'll later
>>>> formalize in the docs and which can be used to plan for a possible
>>>> GSOC submission, for example (which the Qt guys have in mind).
>>>>
>>>> The basic issue we need to solve is the ability to have out-of-process
>>>> interfaces that are efficient, simple to develop,  and that support
>>>> fully asynchronous operation.  In today's ipython, you type code into
>>>> a program that is the same tasked with executing the code,  so that if
>>>> your code crashes, it takes the interface down with it.  So we need to
>>>> have a two-process system where the user-facing client and the kernel
>>>> that executes code live in separate processes (we'll retain a minimal
>>>> in-process interface for embedding,  no worries, but the bulk of the
>>>> real-world use should be in two processes).
>>>>
>>>> We want the user-facing client (be it readline-, curses- or qt-based)
>>>> to remain responsive when the kernel is executing code, and to survive
>>>> a full kernel crash.  So client/kernel need to communicate, and the
>>>> communication should hopefully be possible *even when the kernel is
>>>> busy*, at least to the extent that low-level messaging should continue
>>>> to function even if the kernel is busy with Python  code.
> --
> Brian E. Granger, Ph.D.
> Assistant Professor of Physics
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu
> ellisonbg at gmail.com
>