[IPython-dev] Help! TR: TR: Ipython plugin

[Laurent Dufréchou]

For the callback, I see it difficult to avoid (but not impossible)

When i wrote wxIpython i fall in such a situation, whether to chose callback
approach or state machine approach.
Has you said, It should be better not to use callback.
This is what I did at first place.
The only problem was responsiveness because you will do some polling...
So the only methods I use currently for call back are:
	
    def _askExit(self):
        wx.CallAfter(self.ask_exit_callback, ())

    def _afterExecute(self):
        wx.CallAfter(self.parent.evtStateExecuteDone, ())

_askExit(self) is called when user type : "Exit()" <-- this callback can be
avoid
_afterExecute(self) is called for performance reason, to avoid polling of
the GUI.

So please keep in mind the _afterExecute problem :)

Another problem (THE hardest!)
If user do:

while (1):
	print "hello"

--> problems: display "hello" for each loop
--> support ctrl+c

I had to use a callback with multithread synchronization (ugghhh) to display
all the hello in my gui and be able to do a ctrl+c to break the loop.
This was the worst thing for me that condense all the problem with GUI.
If you can solve this with your approach without a big hack I'll be more
than happy!

The inter multithread 'synchro' could be avoid but would have implied
ipython core modification, that was not my objective...
(the multithread alone can't be avoid if you want to support ctrl+c)

I AM VERY VERY VERY interested in a ipython core + twisted with xml rpc +
GUI loop:
This will permit me to launch an ipython core + wx or qt or ??? in a
different process and be able to create graphical apps while the display gui
as its own GUI loop!
We must find a way to do this ;=) !!!!!!!!!!!!!!

Laurent




> -----Message d'origine-----
> De : Brian Granger [mailto:ellisonbg.net at gmail.com]
> Envoyé : mardi 3 juin 2008 20:57
> À : Ville M. Vainio
> Cc : Laurent Dufrechou; Fernando Perez; ipython-dev Mailing list
> Objet : Re: [IPython-dev] Help! TR: TR: Ipython plugin
> 
> Another thing that we will have to move away from is having a Shell
> that talks to the GUI/frontend through callbacks that the frontend
> registers.  The reason is that the frontend could possibly be in a
> completely different process, or even a web browser.  In that type of
> setting, it is simply impossible for the Shell to call methods in the
> frontend.  Furthermore, it is too tight of a coupling to have in a
> distributed system - what happens if the frontend goes away but the
> Shell persists.
> 
> Instead, all the methods of the Shell will have to return Python
> objects (dicts, etcs) that contain the information that the frontend
> can use for its own purposes.
> 
> Brian
> 
> 
> On Mon, Jun 2, 2008 at 3:39 PM, Ville M. Vainio <vivainio at gmail.com>
> wrote:
> > On Mon, Jun 2, 2008 at 11:39 PM, Laurent Dufrechou
> > <laurent.dufrechou at gmail.com> wrote:
> >
> >> I mean we can stay with pyreadline for console based terminal but I
> think we
> >> need something simpler for "graphical" gui.
> >
> > I agree. However, this can be done as it is now in iplib.py
> > "interact_with_readline" method (which, admittedly, is not excercised
> > in current code but mostly server as proof that ipython can be easily
> > decoupled from raw_input.
> >
> >> (Another time, this is my point of view, some other devs will say
> that this
> >> is the job of a readline object: I'm not ok with that because I want
> to be
> >> free and I need something flexible. "Keep it simple" philosophy)
> >
> > I agree with you here. All the direct references to readline should
> > factored out of the logic-running classes.
> >
> >> - Completer API.
> >> Sometihng like:
> >> IP.Completer.getCompletion(user_input_to_complete) -> return a list
> of
> >> completion :
> >>
> list([completion1,'function'],[completion2,'int'],[completion3,'private
> ']
> >> etc...
> >
> > This should be easy. test_completer.py introduces how to "hack" your
> > way aroud the lack of API (so far).
> >
> > --
> > Ville M. Vainio - vivainio.googlepages.com
> > blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
> >