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'm currently developing something very similar as the thing you are > > proposing. I sent it to the list about two months ago > > (http://groups.google.com/group/sage-devel/browse_thread/thread/53b3d6...
I took a look and its interesting. But I have some questions. Perhaps, though, it might be easier to describe what I was trying and why so you could contrast your approach. First, it seemed that exploiting the existing notebook capabilities was going to yield the best reward / effort. Knowing that QtWebKit and the browser demo which comes with the Qt distro works with Sage, I figured that the easiest first cut would be to build a simple application with an embedded browser window and hook into the underlying Sage Notebook server process. This way, all the notebook code could be exploited and I could focus on whatever specific weirdness I wanted without needing to do major surgery. Unfortunately, this approach wasn't possible with the Sage Notebook process as it existed primarily because it wasn't an asynchronous process. It blocks on the pipe to the main Twisted Server process. I had some luck using Python threads for some workarounds but, unfortunately, this made nailing the Qt main loop tricky because Qt really wants a single thread for gui applications... Since I was using PyQt I didn't know what tricks I would need to try when integrating with Cython etc... so I kinda punted. Some things have changed. First, it is more straightforward to create a custom python process using Cython. While I haven't tried it, it seems that one could start up all the Qt stuff before invoking the notebook process code... this approach requires understanding how the Twisted server worked and getting in the middle of the notebook process launch... I don't think its very hard but the few times I poked around didn't yield much success. Even with this approach, however, threads would be needed meaning synchronization etc and I think it would be architecturally incorrect. There was occasional back and forth on making the notebook process asynchronous. I haven't been following so don't know if asynchronous is part of the current notebook rewrite effort. In my perfect world, I would have an asynchronous sage notebook process supporting the browser window... which would require no code change to Sage, and I would simply add components to the event loop to support other activities. For example, Mayavi2 could work alongside the notebook sharing the underlying data structures with no concern for synchronization which could get tricky. Extensions could be written to support notebook invocations of Mayavi2 but they could come in time... custom widgets would initially be used that would have no impact on the Sage baseline code. I previously built a Twisted Qt Reactor to do this for PyQt but it requires that the supported processes be asynchronous... which the sage notebook wasn't and may still not be (again haven't been following) In looking at your code, it "appears" that you're providing some capabilities which might be more easily handled in the notebook. I really liked the variables being shown and I believe you're thinking along some of the lines I was originally. But you mentioned you were using threads and I wonder why and what kind... this will require more looking on my part. 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
-- 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
