[IPython-user] ipython1.frontend status
Thu Jun 5 10:44:55 CDT 2008
On Wed, Jun 4, 2008 at 11:27 PM, Laurent Dufréchou
> Hello barry,
> We want screenshots! ^_^
> Don't see if you saw my previous mail but i'm really interested in your work
> because of the ipython1 compatibility + remote execution.
> Here are two questions:
> -Do you support ctrl+c (break in a loop)?
Not currently, but because the frontend uses
ipython1.kernel.engineservice.EngineService to execute python blocks
asynchronously, there's no reason you couldn't move the engine
out-of-thread or out-of-process just by changing its instantiation
(e.g. using ipcluster.py and the TaskClient interface). As long as the
block execution is out of thread/process, supporting the appearence of
an interrupt command is simple... the frontend simply ignores the
result of that execution. However, telling an engine to stop
evaluation of a block isn't currently supported by ipython1.core (as
far as I know...), so there's no easy way to actually stop execution
of the block.
> -Do you support in loop stdout?:
> I mean:
> If (1):
> print "hello"
> Does it display lot of hello WHILE executing the loop?
No, and I don't know how this could be accomplished in the ipython1
model. I'm certainly not the most qualified to talk about this (Brian,
Min, Fernndo, fell free to step in when I get my foot in my mouth),
but the ipython1 execution model is built around the idea of an
executable block: the client (in this case, the frontend), sends an
executable block to the engine (possibly via a controller) and waits
for the result of that executed block. I don't believe there's any
facility for getting incremental stdout from the execution of a block.
That's something you should bring up with Brain/Min/Fernando. If it
was added, there would be no problem in adding support for that
facility to the frontend.FrontEndBase.
> -Do you support completion (althought it is not really important, 'cause
> must be easy no?)
The ipython1.core doesn't support completion (yet), but as soon as it
does, the Cocoa fronend will as well.
> If not, do you see any problem to implement this? I ask this because it was
> the hardest things i had to implement on my wx frontend.
> And I want to be sure before switching ot ipython1 core not to loose these
> important features.
> By the way, can you explain me difference between 'I wrote a delegate for
> NSTextView' and subclassing? (sorry)
Sure. As Johann mentioned the difference between subclassing and
delegation is a vast topic in OO programming! In Cocoa, delegation is
used not to hide (in the C++ sense) methods from the delegate code but
to hid complexity of the implementation from the writer of the
delegate code (a big difference if you subscribe to the Objective-C
way of doing things). Anyways, big classes like Cocoa's NSTextView or
NSApplication (the main applicaiton class) or NSDocument (the core of
the document-based application architecture) etc. have an instance
variable that keeps a reference to a delegate object instance. At
"important" points in the life of these classes (the API is very
explicit about what these points are), they ask the delegate what to
do or how to handle a given state/input etc. Many things that would
normally require subclassing to change the base classes behavior (in
this case, making NSTextView behave more like Mathematica's notebook)
can be done by implementing a delegate that responds appropriately to
these queries from the NSTextView and then telling the text view
instance to use an instance of my delegate class as its delegate. The
advantage of this pattern (over subclassing) _in this case_ is that I
don't have to know anything about the implementation of NSTextView to
write my delegate, only its public API, and there's little chance of
me screwing up this complex implementation with my overriden methods).
So, for the Cocoa frontend, a delegate for Cocoa's NSTextView is the
easiest way to implement the logic that turns a text view widget into
an ipython1 frontend notebook widget. I suspect, however, that
subclassing will be the easier route in Qt and Wx.
> 2008/6/5 Barry Wark <firstname.lastname@example.org>:
>> Hi all,
>> Following discussion of the last couple days, I thought I'd update
>> folks on the status of ipython1.frontend in the ipython1-cocoa branch.
>> I've made a first stab at the frontend.frontendbase module and have
>> implemented a bare-bones Cocoa frontend for ipython1. I subclassed
>> Cocoa's text view widget (well, actually I wrote a delegate for the
>> NSTextView, but it could have been done as a subclass) and also
>> subclassed frontend.frontendbase.FrontEndBase. Besides the code to
>> handle the appropriate events/text layout etc. which are specific to
>> Cocoa, my Cocoa frontend required about 200 lines of code. I think
>> it's a pretty good start for similar endeavors in Qt or Wx etc.
>> One issue that's come up is that the deferred result
>> ipython1.kernel.engineservice.EngineService.execute has a string
>> representation of the block's output (in result['display']['pprint']),
>> but there's no way to get the actual python object that generated that
>> string. This prevents the frontend from e.g. rendering an image result
>> inline. I realize this is because the engine may be remote, but in the
>> case of (1) serializeable objects or (2) local engines, it seems that
>> we might want to add an option to execute to return the actual result
>> as well as its pprint/repr...
>> IPython-user mailing list
> Laurent Dufrechou
> Hardware Engineering
> 16 Blv Abbé Louis LE CAM
> 56100 Lorient
> Tél : +33(0)635028304
> Fax : +33(0)297884812
More information about the IPython-user