[IPython-user] ipython1-cocoa branch

Brian Granger ellisonbg.net@gmail....
Thu Apr 3 11:39:21 CDT 2008

>  Sorry it's taken me so long to get back to you. I've been busy on an
>  other parallel development environment; my wife gave birth to twins on
>  the 21st (our first kids). I haven't had a lot of time to catch up on
>  email since then ;)

No problem.  And congratulations!

>  >  1) I think we might be able to get rid of the InteractiveEngineService
>  >  class.  We have been planning for the EngineService itself to have all
>  >  of the core interactive method s like `complete`.  So, I think we can
>  >  move `complete` to the regular EngineSevice class.  This will keep
>  >  things simple.
>  Great. I added a new interface in case we wanted to separate the
>  concerns of an engine that might be used interactively from one which
>  may be a non-interactive node in a grid. Proliferation of interfaces
>  isn't necessarily a good thing, though.

If you want, feel free to move the complete method to the
IEngineService interface and classes.

>  >
>  >  2) feed_block.  I am not sure that I like the idea of having
>  >  feed_block in the Interpreter and EngineService classes.  I don't
>  >  remember how they got there.  But, here is my thinking on this.
>  >  feed_block is seems like a remnant from IPython0, where each line is
>  >  compiled one by one to determine the prompts.  But, IPython1 is not
>  >  setup this way.  It doesn't and can't really know about prompts (that
>  >  is fort the frontend to handle) and it is not line oriented.  Instead,
>  >  it is block oriented.  By this, I mean it is up to the frontend to
>  >  pass a block of python code to the Engine/Interpreter - it simply take
>  >  the block, compiles it and runs it.
>  My thought was that many front ends will have to implement an almost
>  identical "if this block is complete, then send to engine, else
>  display continuation prompt" behavior. DRY suggests that we put this
>  somewhere accessable to all front-end writers. Perhaps we should write
>  a front-end package that provides basic functionality such as this...?

Yep :)

>  >
>  >  One thing to keep in mind is that the Engine may be busy (running user
>  >  code) when you try to call feed_block to figure out the right prompt
>  >  in the frontend.  Because of this, I think all prompt decisions need
>  >  to be made by the frontend without calling into the Engine.  There are
>  >  some exceptions to this, but overall, this is how we have designed
>  >  things.  But, I think we probably need to have a bigger discussion
>  >  with everyone else on this issue.
>  Agreed. My reason to put it in the controller is to make it easier for
>  front-end writers. I think exposing e.g. the feed_block and prompt
>  generation behavior via Deferreds for front-end writers would be very
>  helpful in reducing the amount of code redundancy between frontends. I
>  haven't investigated the workbook front end at all yet. Perhaps some
>  of this code already exists there and could be refactored to be used
>  by many front ends...

Yep :)

> >
>  >  3) It looks like you are using the ThreadedEngineService.  What is the
>  >  reason for this?  I am just wondering if we need to think about where
>  >  to put the threading stuff.  It might make sense to have in the actual
>  >  Interpreter, but I am not sure.  What are your thoughts on this?
>  The threaded select reactor has to be run on the main thread. Since
>  calls to the engine are blocking, this blocks the main Cocoa thread
>  (and thus menus etc.) when the engine is executing. I was hoping that
>  the ThreadedEngineService would help the situation. The
>  ThreadedEngineService was a bit rotted in the main branch, so I've (I
>  hope) gotten it working again in the ipython1-cocoa branch.
>  I'm not sure exactly what "threading stuff" you're referring to. I
>  think I've made my case in a prev. thread that re-inventing GUI
>  integration outside of Twisted feels like unnecessary redundancy. I
>  understand the requirement to have a workable solution without Twisted
>  though.

Yes, if you want to not block the Cocoa event loop, using the
EngineService is the best approach.  The only problem with this is
that if someone runs code that doesn't release the GIL, it will still
block the Cocoa event loop.  The solution in this base is the use the
asynchronous MultiEngineClient, which enables an engine to be run in a
diferent process.  This would be a very nice feature as it immediately
allows you to connect to engines running elsewhere.

>  >
>  >  4) Another route would have been to skip using the EngineService stuff
>  >  and Twisted and just use the actual Interpreter object (which we could
>  >  add threads to ?).  Do you think it makes more sense to use Twisted
>  >  and the EngineService like you have done?  Not sure what you think
>  >  about this.
>  My experience is that writing multi-threaded UIs is more difficult
>  than writing asynchronous front-ends using Twisted (or Cocoa bindings
>  or name-your-poison). I think, as discussed in the prev. thread on GUI
>  integration, the Interpreter will have to be capable of threading to
>  handle maptlotlib at the command line. However, getting this threading
>  right in the context of different GUI threads/paradigms (e.g. Cocoa,
>  Wx, Qt, Swing/SWT?, etc.) sounds like a huge list of edge cases.
>  Putting Twisted between ipython1 and the GUI thread seems to make
>  things "just work." I'm not a religious zealot on the issue, however.
>  If there were a simple solution that didn't require Twisted, I'm all
>  for it.

I agree about the difficulties of threading.  In my experience, things
with Twisted just magically work.  Especially because you want to
avoid blocking the Cocoa event loop, twisted does make sense.



>  Take care,
>  Barry
>  >
>  >  Cheers,
>  >
>  >  Brian
>  >
>  >  4)
>  >
>  >
>  >
>  >  On Thu, Mar 13, 2008 at 1:59 AM, Barry Wark <barrywark@gmail.com> wrote:
>  >
>  >
>  > > I've created an ipython1-cocoa branch on launchpad.net for developing
>  >  >  the cocoa frontend for ipython1. It adds an IEngineInteractive
>  >  >  interface and InteractiveEngine implementation (as well as associated
>  >  >  tests) to ipython1.kernel.engineservice as well as
>  >  >  ipython1.frontend.cocoa.cocoa_frontend and tests.
>  >  >  ipython1.frontend.cocoa.cocoa_frontend contains a Cocoa wrapper for
>  >  >  InteractiveEngine and a delegate to turn an NSTextView (the standard
>  >  >  text view in Cocoa) into an interactive terminal-style prompt for the
>  >  >  InteractiveEngine service. The ipython1.frontend.cocoa.examples
>  >  >  directory contains an XCode project of an app that uses the frontend
>  >  >  to provide an interactive prompt and namespace display.
>  >  >
>  >  >  I propose this as a starting point for a cocoa frontend for ipython1.
>  >  >  The only potentiall sticky points are the additions to
>  >  >  ipython1.kernel.engineservice. Please let me know what y'all think.
>  >  >
>  >  >  Barry
>  >
>  >
>  > >  _______________________________________________
>  >  >  IPython-user mailing list
>  >  >  IPython-user@scipy.org
>  >  >  http://lists.ipython.scipy.org/mailman/listinfo/ipython-user
>  >  >
>  >

More information about the IPython-user mailing list