[IPython-dev] Moving forward with the frontends
Gael Varoquaux
gael.varoquaux at normalesup.org
Mon Jun 23 16:36:36 EDT 2008
On Mon, Jun 23, 2008 at 01:26:18PM -0700, Barry Wark wrote:
> > * We do not want it multithreaded. The reason being that this shell will
> > be used to manipulate existing Wx objects. As Wx is not multithreaded,
> > we cannot execute the code the user enters in a separate thread. As we
> > want to manipulate objects displayed by the GUI, we cannot run in a
> > seperate process. In the long run we can think of a "%bg" like magic
> > to execute in a seperate thread, but on the short term I will make my
> > life easier and run everything in one thread.
> I don't want to sound like a broken record and I don't have personal
> pride staked on this solution so it's OK if you choose otherwise, but
> I think going with a Twisted-based approach is the right plan. I would
> look forward to working with you to make FrontEndBase work for your
> use. There's a WX reactor for Twisted so we can guarantee that code
> gets executed in the WX runloop thread. Using Twisted's deferToThread
> (eg. via IPython.kernel.engineservice.ThreadedEngineService) makes it
> possible for long-running code to not block the UI.
OK, I am not sure I understand fully this approach. The name made me
think there were threads involved, and thus it wouldn't work in the
context of Wx. I guess I need to do some googling/reading to find out
more about the reactors.
> > * The feature of ipython we are interested in are magics, "?" and "??",
> > tab completion, history, and alike...
> As soon as we can refactor the IPython 0.8 core so that it plays
> nicely with the IPython.kernel.engineservice.IEngineBase interface,
> all frontends could get this behavior for free. If you can't wait for
> that refactoring, going with the existing Wx frontend is your only
> option at this point.
Fernando, Brian, Ville, what is the timeframe for this? What is the
amount of work required?
Gaƫl
More information about the IPython-dev
mailing list