On Jan 10, 9:09 pm, William Stein <wst...@gmail.com> wrote: > On Sun, Jan 10, 2010 at 8:56 PM, ghtdak <gl...@tarbox.org> wrote: > > > On Jan 9, 7:50 pm, ghtdak <gl...@tarbox.org> wrote: > >> On Jan 9, 2:20 am, Alejandro Serrano <trup...@gmail.com> wrote: > > >> > Hi,
> > > I should say that my primary interest in having the notebook be > > asynchronous was to interact with external systems. This is a > > requirement which isn't shared by many in the Sage community so it > > hasn't been a priority. It is also a non-trivial adjustment to the > > notebook itself... the combination may preclude its development. > > > -glenn > > Are you putting the notebook, GUI, and Sage compute all in the same > process? How many processes do you have and how do they communicate? All the same process which is the trick which makes everything "easy". The core idea is that the notebook would provide the foundation for interaction with the machine state and has all the bells and whistles which makes life good. Currently I do this with ipython instead of the notebook because ipython supports a general event loop (specifically PyQt's event loop) so I have interpretive interaction with the machine through ipython as well as Qt GUI code. This was "easy" because PyQt wraps Qt and ipython already knew how to do its interactions alongside PyQt and, hence, is integrated with the Qt event loop. Qt always has a main (singleton) event loop for the GUI.... so with a little Cython magic, I was able to take C++ Qt code invoked through a Cython shim (the reason for the shim is Qt compilation and might be unnecessary). Widgets and other Qt "thingies" are automagically added to the main event loop cuz thats how Qt works. The Qt code does asynchronous GUI / timer / communication functions alongside sage while providing an ipython shell with access to Qt subsystem. I don't currently have Qt events calling back into python although I think this is straightforward... it just hasn't been necessary yet as all my "real time" stuff stays on the Qt side. I bring this up because I've been considering some live Mayavi2 displays but processing considerations might require multiple threads / processes and I haven't really thought through all the issues. In my perfect world, I would replace ipython with the notebook server process. The QtWebKit is one option but isn't required because the browser itself could be in a separate process and be firefox or whatever (and is probably a better approach anyways cuz the browser activities are easily segmented into a separate process which is almost certainly better on a multicore machine). The essential element, however, is that the notebook process be asynchronous and hooked into Qt's event loop. As I said in a previous post, this is the basis of the Twisted QtReactor I built a while ago and, for the most part, would work the same way the current ipython-Qt integration works. At the end of the day, though, this is merely a specific case and a continuation of the asynchronous notebook server saga which may be part of the notebook rewrite. If not... well... ipython it is. -glenn > > William
-- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
