[IPython-dev] shell command for ipython1 frontend

[Gael Varoquaux]

On Mon, Sep 08, 2008 at 10:42:12PM +0200, Laurent Dufrechou wrote:
> It is not working at all :(
> To be sure:
> I've created a new directory.
> Then:
> bzr branch lp:~gael-varoquaux/ipython/ipython-sync-frontend
> then launched ipythonx

> Is it tagged 0.9beta3 ? If yes then...there still an issue.

I don't think you are picking up the new code. You need to install it.
Just copying (or branching) the files and starting the ipythonx program
won't be enough.

> Moreover, the exception don't display anything... Is it working on your
> side?

If there is an exception in the display code, then indeed it won't
display. It is a pain, but that's the price to pay for having the display
code running in the same event loop as the code raising the eceptions.

> Do I need to do eggsetup develop?????

That's should get you going.

> I've worked a little on your widget:

> What I want is something that looks like to my widget (white on black) + one
> line next to other + prompt2:

> 1/I've seen that there is global value in underling classes that are used to
> change color of input/output and error.
> I couldn't manage to change them in the top level class. I'm not used to
> vars like
> Class toto:
> 	MYVAR = ...
> MYVAR is global to the class but is constant?

MYVAR is just a class variable. You can change it either by subclassing
the class and changing it in the subclass, or simply be assiging a value
to it:

t = toto()
t.MYVAR = "A different value"

> If yes can you change them to make me change the aspect of the widget?

I haven't focussed yet on this aspect. The code currently will not make
it easy for you to do that. This is low priority for me: I first want to
get the main frontend API right, and the event handling right. I need to
understand these problems well to get the right overall architecture
first.

> 2/Next I don't want a '\n' between each prompt (in and out too).
> I've tried different things
> #self.write('\n', refresh=False)
> self.write('', refresh=False)

> But it seems that the '\n' are used by the underlying classes to handle the
> line state, or something like this, so don't where to change this witout
> breaking your widget. Any idea?

The '\n' is necessary for the separation between input and output, indeed
at the frontend level. There sometimes is too much vertical space, but I
have not found a way to have less without breaking formatting on one
platform or the other. The stems from the horrible mix of the different
values for carriage return under the different platforms ('\n', '\r',
'\n\r') and with or without an UNicode build of Wx. I spent a while on
this, and then decided I would live with the extra vertical space.
Anybody is welcome to have a go at trying to fix this. Plan for having
many VMs.

> 3/ I've seen a little threading? Problem while pushing a lot of time
> a+enter...

> In [98]: 
> a
> In [99]: 

> In [100]: a

> Out[100]: 1

> Oups, look at line 99.(Had the same problem before too with my widget)

Well, that's not really a threading problem, that's just a buffering of
the input problem. I could indeed maybe be smarter with input buffering,
but that would make things more fragile. Right now the rule is that if
you enter keys outside of a prompt, the behavior is undefined.

> 4/? -> display long text, is there a way to overload help display to add
> input from user?
> I've done this in my widget, I display 10lines then used have to push 'space
> to display 10 next lines or 'q' to quit.

I don't plan on adding such a feature right now. Even in the long run, I
am not too sure it is a good idea. User interaction with the mainloop
while the user is executing code should be restricted as much as
possible. This is fragile, and will always be. You can use page up and
page down to navigate this output.

> 5/ You widget seems to react strangely (well not at all in fact ) but
> somewhat frustrating:

> IN: while(1):
> 	&
> 	print "coucou"
> and your widget don't execute the lines like ioython0 because he detects an
> error! It is REALLY frustrating because sometimes you don't see the error
> and would like to execute the line to make ipython shell show you the bug :)

> Can we change this behavior?

That should be fixed. Make sure you have the latest version.

> 6/ import htt+'tab' don't work at all, in fact completion on import don't
> works.

Indeed. That's interesting. Ipython0's complete method does not complete
imports:

In [1]: __IP.complete('import htt')
Out[1]: []

Anybody has a clue why, and what could be done to fix that?

Cheers,

Gaël