[IPython-dev] Ipython frontend (async, sync, line or block oriented...)

[Barry Wark]

On Mon, Aug 18, 2008 at 9:57 AM, Barry Wark <barrywark at gmail.com> wrote:
> Laurent,
>
> Sorry to take a couple of days to get back to you. I imagine you'll
> see from my responses below that Gaël and I have differing views on
> many of the design decisions that have gone into the curent frontend
> package. That's good, I think. Let me give you a quick overview of our
> goals in the frontend package and then I'll try to answer your
> specific questions inline below.
>
> The new IPython architecture (previously called ipython1) provides
> many opportunities to separate the interpreter logic from UI (terminal
> or GUI) logic. The frontend package is intended to make it easier
> (though not trivial) to write frontends for the IPython interpreter
> (where interpreter is IPython.kernel.core.interpreter.Interpreter, the
> new ipython1 interpreter, or an
> IPython.kernel.engineservice.IEngineService, the new ipython1
> network/remote-aware IPython engine). There is a minimal functional
> spec in docs/source/development that highlights the many use casess
> we're trying to support. Briefly, they fall into three categories:
> 1) terminal-based frontends to a single Interpreter instance; very
> similar to the current IPython UI experience
> 2) GUI-based frontends to a single Interpreter instance; this is the
> category for both your and Gaël's efforts. Because the current
> architecture is more separable, it will (hopefully) be easier to write
> a GUI frontend to the Interpreter using the new architecture.
> 3) GUI-based frontends that make use of Twisted and the
> IPython.kernel.engineservice architecture to provide a frontend to one
> or more local or remote engine services. This is the goal of my (still
> evolving) Cocoa frontend. I personally think this is a very promissing
> new possibility for new UI's for interactive computing that we haven't
> been able to explore with IPython in the ipyhton0 architecture.
>
> Clearly, supporting a diverse range of use cases is a difficult task.
> The goal of frontend is to provide whatever common functionality we
> can identify that supports all three of these use cases, embodied in a
> common base class FrontendBase. In addition, Gael has spearheaded
> creating common base classes for each of these use cases. The
> intention *is not* to create a common UI widget or event library for
> IPython. Frontend writiers will still have to make decisions (and,
> gasp, write code) to do "the right thing" with their UI system's
> events and widgets.
>
> Much of the original architecture for the frontend package was
> motivated by use case #3 above. Hence, the frontend API is biased
> towards treating code in blocks, rather than in lines. Gael's work
> required line-oriented APIs. We're still struggling to resolve this
> discrepancy. My goal in the next several weeks is to get the Cocoa
> frontend (asyncrhonous, block-oriented) to a stable state, thus
> stabilizing the frontend API for use case #3 and then to work on
> integrating Gael's use case and code in a more seamless way.
>
> more answers below...
>
> cheers,
> Barry
>
> On Sun, Aug 17, 2008 at 5:38 AM, Laurent Dufrechou
> <laurent.dufrechou at gmail.com> wrote:
>> Hi barry,
>> I've started to take a look at your work. Seems from my quick review
>> that you've done an asynchroneous frontend, block oriented while gaël
>> as gone through the opposite :) sync and line oriented.
>
> correct
>
>>
>> In fact, seems you've used ipython1 while gael has gone ipython0 no?
>> (If I remember well, ipython1 can instanciate remote ipython instance)
>
> correct

Sorry, not entirely correct. Gael is using both the ipyhon1 and
ipython0 APIs and interpreters in his frontend. This is because the
ipython1 Interpreter is not yet as full-featured as the ipyhon0
frontend. Gael was under time constraints while writing his frontend.
Unfortunatley he didn't have time to bring the ipyhon1 interpreter up
to the feature set he needed and so had to go with this hybrid
approach. As you might guess, this ultimatley leads to his frontend
suffering from some of the tight-integration of UI and Interpreter
suffered by old IPython frontends.


>
>>
>> Can you explain me the difference between block oriented and line oriented?
>
> If you're familiar with Mathematica and Matlab, the UI of Mathematical
> provides  good model for block oriented input whereas the Matlab
> command line (and the ipython0 terminal UI) provides a good model for
> line-oriented input.
>
> Line-oriented input is often more natural for people who are used to
> command-line UIs. The distributed nature of the ipython1 architecture
> (and the associated network latencies, loss of connections, etc.) make
> line-oriented UIs difficult. In this case, the block-oriented UI is a
> better model of the underlying architecture and so (I think) a better
> UI paradigm because it helps the user's mental model come into line
> with the software model.
>
> Having used both Mathematica and Matlab, I've found that my Matlab use
> patterns have migrated towards more block-like usage, so I personally
> don't find the block-oriented UI a problem, but personal preferences
> are, well, personal. We'll see.
>
>>
>> Line oriented is (I think) that you feed ipython instance with line
>> and ipython instance determine by itself block bounds.
>> So I think block oriented is that it is the frontend taht determine
>> the bounds of the block?
>
> Correct. This determination is an example of the common code that all
> block-oriented frontends will require and is therefore included in the
> frontend package.
>
>>
>> Cheers,
>> Laurent
>>
>