On Sat, May 24, 2008 at 10:44:19AM +0200, Ondrej Certik wrote: > > On Fri, May 23, 2008 at 6:21 PM, Kirill Smelkov > <[EMAIL PROTECTED]> wrote: > > > > On Fri, May 23, 2008 at 04:54:52PM +0200, Ondrej Certik wrote: > >> > >> On Fri, May 23, 2008 at 12:42 PM, Vinzent Steinberg > >> <[EMAIL PROTECTED]> wrote: > >> > > >> > On May 23, 3:46 am, Saroj Adhikari <[EMAIL PROTECTED]> wrote: > >> >> The draft looks great. Unlike Felix and Kirill, I like the idea of > >> >> having the shell on the homepage. We can have a two column webpage > >> >> design with one having general information and the other having the > >> >> shell with smaller width. > >> >> > >> >> Saroj > >> >> > >> > > >> > I agree with Saroj. Currently the shell alone is not that useful if > >> > you don't know sympy (imagine you'd visit this page the first time > >> > without knowing anything about sympy and it's syntax), but a two > >> > columns (or two rows) design would be great if you could browse > >> > documentation/examples while experimenting with the shell. I really > >> > like such an interactivity, it's imo much more interesting than a > >> > static page. > >> > > >> > I think that Felix's points about the design are valid, but if I got > >> > it right it's just a draft about the concept, not about the design. > >> > >> Thanks again for the feedback. Yes, it's just a quick draft of the concept. > >> > >> My motivation is to have a site, that would be useful both for the new > >> people and also for experienced people. > >> I don't like frames though. But let's just try couple more different > >> designs and we'll find some good balance. > > > > I'd like to say that I too would like to have a shell on start page. > > > > My initial reaction to lite.sympy.org was positive, but I though it > > would not serve as a start page, but now I've rethought it, and I too > > think that minimalistic, cool, pretty and hooking starting web page is > > good, and of course, having an isympy terminal right there would be > > cool. > > > > If we'd manage to get full isympy+ipython running inside, it would be > > great! > > > > > > Let's try it and see what happens. > > > > I'm not a web guy, nor I know javascript & friends, but we could use > > something like ajaxterm for colorful terminal emulation: > > > > http://antony.lesuisse.org/qweb/trac/wiki/AjaxTerm > > Yep, neither am I a web guy. One argument for not putting a shell on > our front page is that the current online shell experience is not as > good as running isympy on your computer (pretty printing, ipython, > ...). Something can be improved (pretty printing), but something will > be a lot of work (ipython). But maybe if we write very clearly, that > this is only to whet your appetite and you should download the sympy > and try it on your comp to get all the features of ipython, then it > may be ok. > > But maybe it won't be that hard. 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. So when thinking about it again,
And then you'll want - colors, - access to history (In[1], Out[2], etc...), - autocalls (one could write "sin x" instead of "sin(x)" or "dump smth" instead of "dump(smth)" - autoindenting when entering short loops or shot functions - %who, %whos - probably %time and %timeit - etc ... All the things ipython already provides. > 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/ > 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, I think this way we are going to duplicate the effort. Maybe it would be better to spend time and energy on web-porting ipython itself? > Note, that the requirement is that it runs on the google app server. Yes, it should run on restricted environment, for sure. But why we set "running on google app server" as a requirement? App server itself is very young and is moving target, and it is *app server* who should adapt to what people need, not the vice versa. So I think if it runs on google app server -- that would be good, but I think we should not put it on *that* high priority. For example here: http://groups.google.com/group/sympy-patches/msg/fe47f11fc20125c7 we reject common Python practice in favour of GAPPS As said before, I think we should not get this attitude: First, I believe this particular proble could be solved on GAPPS - you could install mpmath separately there, and Second, we are going to add troubles for "plain" distributions like Debian, where mpmath should be already there as a separate package, and distributors would have to change a lot of lines instead of only one line adding thirdpart modules to sys.path. > Anyone interested in implementing these? :) If time permits I'd be interested in helping preparing "restricted" Python interpreter build. -- Всего хорошего, Кирилл. P.S. Google says in GAPPS one does not have access to files. That's true - they removed it so a program could be run in cluster _somewhere_, and so it could be migrated freely, and also for security reasons. But I believe access to files could be emulated on top of the DB that GAPP engine provedes. Just a note. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sympy?hl=en -~----------~----~----~----~------~----~------~--~---
