[IPython-dev] ipython on google app engine

[Brian Granger]

> One of the things that's come up as I'm (very slowly) working on the
> cocoa frontend is that implementing something like Matlab's workspace
> (i.e. user namespace) browser requires that the frontend query the
> engine for the user namespace keys (and their values) after each
> operation that might affect the namespace. So, could the engineservice
> provide some hints about what keys in the user namespace were
> altered/added/removed as a result of execution of a block? Either way,
> if the frontend maintains this (flat) local copy of the user
> namespace, than many completions could be accomplished locally.

I don't think there is anyway of monitoring the user's namespace for
changes.  But, I can think of a couple different approaches that might
work:

1) Have an interface that allows the user to specify which variables
to monitor/browse in the frontend.

or

2) For in process engines, it really won't be a problem to get the
keys/values each time.

3) For an out of process engine, it is a bad idea to bring back all
the keys+values no matter how you approach it.  The chances for a user
to unknowingly create a bunch of large objects and bring the system to
a halt is too great.

4) A compromise, would be to bring back the values for only simple
scalar types (ints, floats, str?) and bring back the repr of all other
objects.  Then you could provide an interface to enable "actually
bring back the value of this object" for given keys.  This is probably
the best of both worlds.

>>
>> so, I guess I would say that both the frontend and backend work
>> together to do the tab completion.
>>
>> Brian
>>
>>
>> On Sun, May 25, 2008 at 10:49 AM, Barry Wark <barrywark at gmail.com> wrote:
>>> On Sat, May 24, 2008 at 1:50 AM, Ondrej Certik <ondrej at certik.cz> wrote:
>>>> Hi,
>>>>
>>>> I'd love to use ipython on the google app engine. Currently our shell
>>>> looks like this:
>>>>
>>>> http://live.sympy.org/
>>>>
>>>> But I just prefer the ipython style. What I use/like on ipython is just:
>>>>
>>>> 1) the look and feel (lines starting with [1] etc.)
>>>> 2) tab completion
>>>> 3) ? and ??
>>>> 4) inteligent up/down arrows history browsing
>>>>
>>>> and I think that's all (sometimes I use some other features, but very
>>>> rarely). So when thinking about it again,
>>>>
>>>> 1) should be easy to fix, or at least come to a very close look & feel,
>>>> 2) This will be hard, as it will require an interaction between the
>>>> webbrowser and the server. We may learn from Sage, ipython1 or
>>>> http://knoboo.com/
>>>
>>> It's my understanding that the current plan is for tab completion to
>>> be handled in the frontend, not at the engine level in ipython1.
>>> Mapping the ipython1 model directly to this situation, the tab
>>> completion would happen in the browser. Since this is a bit
>>> impractical, I'd suggest Ville's solution. The nature of the AppEngine
>>> will mitigate the risk that the server is slow to respond to the tab
>>> completion request (a possiblity in the ipython1 model if the
>>> controller or engine handled the completion request).
>>>
>>>> 3) this should be easy, it will simply copy the command to the server,
>>>> and in python we'll parse it and return some help
>>>> 4) will have to be implemented in javascript, but I could also live
>>>> without it quite well,
>>>>
>>>> Note, that the requirement is that it runs on the google app server.
>>>>
>>>>
>>>> What do you think? How does this fit into the ipython1 model? I'd like
>>>> to have something now, but also I'd prefer to work on one thing
>>>> ipython1, instead of doing things on my own. Also I probably won't
>>>> have much time either. But my motivation to run something like
>>>> ipython+sympy on google app engine is also big. :)
>>>>
>>>> Ondrej
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>>
>>
>