experiment - remote execution of jquery and d3 code into the browser via ipython
Locked
 
|
Thought you might be interested in something I've experimented with over the past few days. https://github.com/hhuuggoo/pushd3/blob/master/demopush.ogv I wanted to see how well this concept would work, I set up remote execution of code in the browser by creating an RPC interface around zeromq messages which get forwarded into websockets, and then I forwarded d3 and jquery operations to the browser. It works fine if your arguments are all json serializable, however d3 is heavily reliant on passing callbacks, and I don't have a good way to do that. Anyways, here it is. This is separate from the ipython notebook, I have a separate gevent based zeromq web socket forwarder that I've also been playing around with which I am using here. _______________________________________________ IPython-dev mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/ipython-dev |
Re: experiment - remote execution of jquery and d3 code into the browser via ipython
|
holy mackerel that's awesome!
Can you elaborate on the callback issue? Wondering why you can't pass in a callback that just makes a ws call internally. On Mar 19, 2012, at 8:13 AM, hugo wrote:
_______________________________________________ IPython-dev mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/ipython-dev |
|
|
On 03/19/2012 09:22 AM, fawce wrote: holy mackerel that's awesome! just that I serialize function names and the args they are called with via JSON so for d3, the normal way you would position points in a scatter plot is something like this d3.selectAll('circle').attr('cx', function(d){return axis(d['x'])}); I have no good way to pass function(d){return xaxis(d['x'])} I could pass it as a string, but then I would need some way to determine whether strings I pass should be eval-ed to retrieve callbacks or not also - you would have to write javascript callbacks in string form, which is ugly anyways. furthermore, in d3, it is common to define scaling axes objects, and use those in your callbacks - I don't have a good place to do that either.
_______________________________________________ IPython-dev mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/ipython-dev |
Re: experiment - remote execution of jquery and d3 code into the browser via ipython
|
On 3/19/12 9:32 AM, hugo wrote:
> > > On 03/19/2012 09:22 AM, fawce wrote: >> holy mackerel that's awesome! >> >> Can you elaborate on the callback issue? Wondering why you can't pass >> in a callback that just makes a ws call internally. > > just that I serialize function names and the args they are called with > via JSON > > so for d3, the normal way you would position points in a scatter plot is > something like this > > d3.selectAll('circle').attr('cx', function(d){return axis(d['x'])}); > > I have no good way to pass function(d){return xaxis(d['x'])} > > I could pass it as a string, but then I would need some way to determine > whether strings I pass should be eval-ed to retrieve callbacks or not > also - you would have to write javascript callbacks in string form, > which is ugly anyways. furthermore, in d3, it is common to define > scaling axes objects, and use those in your callbacks - I don't have a > good place to do that either. fawce's suggestion sounds very intriguing--make the websockets message passing two-way between python and javascript. The way I understand the suggestion, what about (in python): def mycallback(d): return d3.axis(d['x']) d3.selectAll('circle').attr('cx', callback(mycallback)); This gets translated to the javascript code: d3.selectAll('circle'.attr('cx', function(){ var results= send_message('mycallback', arguments); return interpret_results(results);}) send_message sends a message back through websockets to call the mycallback python function with some sort of proxy object d that knows how to generate json messages describing the attribute accesses, etc. In the python side, inside mycallback, d['x'] generates the javascript code to access arguments[0]['x'], so what is passed back is some sort of javascript code like 'd3.axis(arguments[0]['x'])'. interpret_results then runs this code and returns the result. Thanks, Jason _______________________________________________ IPython-dev mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/ipython-dev |
|
Hi All,
i found this new capabilities really really interesting! it is awesome!!! i've few questions .. i was tring to run the examples i found here : https://github.com/cschin/IPython-Notebook---d3.js-mashup i applied the changes in the ipython core files (adding the 2 methods) then i was able to run the first example (congrats! it's really cool) now going ahead i was really attracted by the other examples 2/3 in order to add a frame inside the notebook itself instead of a new page. in example 2 i changed the path to de.js to be : ./d3.js like in the first example then i add the import for the module 'math'. trying ti run example 2, i see a square empty box is loaded in the notebook (a string : 404: Not Found - inside it) then running the first lines of code a frame is added to the python notebook! :) in it i can still see the string : 404: Not Found the rest of the code seems to don't have effects on the frame. have you any clue on what i need to change in order to have it running ?\ thanks a lot for this, it is so cool! --Massimo. Il giorno Mar 19, 2012, alle ore 10:51 AM, Jason Grout ha scritto: > On 3/19/12 9:32 AM, hugo wrote: >> >> >> On 03/19/2012 09:22 AM, fawce wrote: >>> holy mackerel that's awesome! >>> >>> Can you elaborate on the callback issue? Wondering why you can't pass >>> in a callback that just makes a ws call internally. >> >> just that I serialize function names and the args they are called with >> via JSON >> >> so for d3, the normal way you would position points in a scatter plot is >> something like this >> >> d3.selectAll('circle').attr('cx', function(d){return axis(d['x'])}); >> >> I have no good way to pass function(d){return xaxis(d['x'])} >> >> I could pass it as a string, but then I would need some way to determine >> whether strings I pass should be eval-ed to retrieve callbacks or not >> also - you would have to write javascript callbacks in string form, >> which is ugly anyways. furthermore, in d3, it is common to define >> scaling axes objects, and use those in your callbacks - I don't have a >> good place to do that either. > > > fawce's suggestion sounds very intriguing--make the websockets message > passing two-way between python and javascript. The way I understand the > suggestion, what about (in python): > > def mycallback(d): > return d3.axis(d['x']) > > d3.selectAll('circle').attr('cx', callback(mycallback)); > > This gets translated to the javascript code: > > d3.selectAll('circle'.attr('cx', function(){ > var results= send_message('mycallback', arguments); > return interpret_results(results);}) > > send_message sends a message back through websockets to call the > mycallback python function with some sort of proxy object d that knows > how to generate json messages describing the attribute accesses, etc. > In the python side, inside mycallback, d['x'] generates the javascript > code to access arguments[0]['x'], so what is passed back is some sort of > javascript code like 'd3.axis(arguments[0]['x'])'. interpret_results > then runs this code and returns the result. > > Thanks, > > Jason > _______________________________________________ > IPython-dev mailing list > [hidden email] > http://mail.scipy.org/mailman/listinfo/ipython-dev _______________________________________________ IPython-dev mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/ipython-dev |
|
|
In reply to this post by Jason Grout-5
ah - interesting, I didn't quite understand it at first.
I think that would work, however in the d3 case, I think performance would be an issue, d3 uses callbacks for everything. for a scatter plot, each circle needs at least 2 callbacks, one for x coordinate, one for y coordinate, that would be one round trip communication per point! for local work, this might be ok, but it probably won't work in a traditional client server setup, especially if you get many points. I think for me - the complexity involved in this is enough to convince me that this is the wrong approach. It was an interesting experiment but I'm going to give up on this path, I think a preferable route is to implement higher level plots (scatter, lines, image plots, etc..) which only take json serialiseable data as args, and then just call those from ipython. > > fawce's suggestion sounds very intriguing--make the websockets message > passing two-way between python and javascript. The way I understand the > suggestion, what about (in python): > > def mycallback(d): > return d3.axis(d['x']) > > d3.selectAll('circle').attr('cx', callback(mycallback)); > > This gets translated to the javascript code: > > d3.selectAll('circle'.attr('cx', function(){ > var results= send_message('mycallback', arguments); > return interpret_results(results);}) > > send_message sends a message back through websockets to call the > mycallback python function with some sort of proxy object d that knows > how to generate json messages describing the attribute accesses, etc. > In the python side, inside mycallback, d['x'] generates the javascript > code to access arguments[0]['x'], so what is passed back is some sort of > javascript code like 'd3.axis(arguments[0]['x'])'. interpret_results > then runs this code and returns the result. > > Thanks, > > Jason > _______________________________________________ > IPython-dev mailing list > [hidden email] > http://mail.scipy.org/mailman/listinfo/ipython-dev _______________________________________________ IPython-dev mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/ipython-dev |
Re: experiment - remote execution of jquery and d3 code into the browser via ipython
|
On Mon, Mar 19, 2012 at 5:27 PM, hugo <[hidden email]> wrote:
> ah - interesting, I didn't quite understand it at first. > > I think that would work, however in the d3 case, I think performance > would be an issue, d3 uses callbacks for everything. for a scatter > plot, each circle needs at least 2 callbacks, one for x coordinate, one > for y coordinate, that would be one round trip communication per point! > for local work, this might be ok, but it probably won't work in a > traditional client server setup, especially if you get many points. > > I think for me - the complexity involved in this is enough to convince > me that this is the wrong approach. It was an interesting experiment > but I'm going to give up on this path, I think a preferable route is to > implement higher level plots (scatter, lines, image plots, etc..) which > only take json serialiseable data as args, and then just call those from > ipython. I strongly agree with this assessment. In general we are -1 on adding new web socket connections and trying to manage Javascript/Python communications at a fine grained level. Things like interactive plots should simply take JSON data at the beginning and they work with it on the client side. >> >> fawce's suggestion sounds very intriguing--make the websockets message >> passing two-way between python and javascript. The way I understand the >> suggestion, what about (in python): >> >> def mycallback(d): >> return d3.axis(d['x']) >> >> d3.selectAll('circle').attr('cx', callback(mycallback)); >> >> This gets translated to the javascript code: >> >> d3.selectAll('circle'.attr('cx', function(){ >> var results= send_message('mycallback', arguments); >> return interpret_results(results);}) >> >> send_message sends a message back through websockets to call the >> mycallback python function with some sort of proxy object d that knows >> how to generate json messages describing the attribute accesses, etc. >> In the python side, inside mycallback, d['x'] generates the javascript >> code to access arguments[0]['x'], so what is passed back is some sort of >> javascript code like 'd3.axis(arguments[0]['x'])'. interpret_results >> then runs this code and returns the result. >> >> Thanks, >> >> Jason >> _______________________________________________ >> IPython-dev mailing list >> [hidden email] >> http://mail.scipy.org/mailman/listinfo/ipython-dev > > _______________________________________________ > IPython-dev mailing list > [hidden email] > http://mail.scipy.org/mailman/listinfo/ipython-dev -- Brian E. Granger Cal Poly State University, San Luis Obispo [hidden email] and [hidden email] _______________________________________________ IPython-dev mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/ipython-dev |
Re: experiment - remote execution of jquery and d3 code into the browser via ipython
|
|
On Mar 19, 2012, at 8:51 PM, Brian Granger wrote: > On Mon, Mar 19, 2012 at 5:27 PM, hugo <[hidden email]> wrote: >> ah - interesting, I didn't quite understand it at first. >> >> I think that would work, however in the d3 case, I think performance >> would be an issue, d3 uses callbacks for everything. for a scatter >> plot, each circle needs at least 2 callbacks, one for x coordinate, one >> for y coordinate, that would be one round trip communication per point! >> for local work, this might be ok, but it probably won't work in a >> traditional client server setup, especially if you get many points. >> >> I think for me - the complexity involved in this is enough to convince >> me that this is the wrong approach. It was an interesting experiment >> but I'm going to give up on this path, I think a preferable route is to >> implement higher level plots (scatter, lines, image plots, etc..) which >> only take json serialiseable data as args, and then just call those from >> ipython. > > I strongly agree with this assessment. In general we are -1 on adding > new web socket connections and trying to manage Javascript/Python > communications at a fine grained level. Things like interactive plots > should simply take JSON data at the beginning and they work with it on > the client side. Sorry for the poor suggestion, I just didn't know d3 was so chatty. Highcharts works the way you're suggesting, and also has good support for incrementally adding data. It is a very nice library, and we're pushing a lot of updates to it via websockets. The tradeoff, which I think comes with the high-level chart design, is that you sacrifice flexibility in the rendering -- you can only use the chart types that exist in the library. > > >>> >>> fawce's suggestion sounds very intriguing--make the websockets message >>> passing two-way between python and javascript. The way I understand the >>> suggestion, what about (in python): >>> >>> def mycallback(d): >>> return d3.axis(d['x']) >>> >>> d3.selectAll('circle').attr('cx', callback(mycallback)); >>> >>> This gets translated to the javascript code: >>> >>> d3.selectAll('circle'.attr('cx', function(){ >>> var results= send_message('mycallback', arguments); >>> return interpret_results(results);}) >>> >>> send_message sends a message back through websockets to call the >>> mycallback python function with some sort of proxy object d that knows >>> how to generate json messages describing the attribute accesses, etc. >>> In the python side, inside mycallback, d['x'] generates the javascript >>> code to access arguments[0]['x'], so what is passed back is some sort of >>> javascript code like 'd3.axis(arguments[0]['x'])'. interpret_results >>> then runs this code and returns the result. >>> >>> Thanks, >>> >>> Jason >>> _______________________________________________ >>> IPython-dev mailing list >>> [hidden email] >>> http://mail.scipy.org/mailman/listinfo/ipython-dev >> >> _______________________________________________ >> IPython-dev mailing list >> [hidden email] >> http://mail.scipy.org/mailman/listinfo/ipython-dev > > > > -- > Brian E. Granger > Cal Poly State University, San Luis Obispo > [hidden email] and [hidden email] > _______________________________________________ > IPython-dev mailing list > [hidden email] > http://mail.scipy.org/mailman/listinfo/ipython-dev _______________________________________________ IPython-dev mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/ipython-dev |
Re: experiment - remote execution of jquery and d3 code into the browser via ipython
|
|
On Mon, Mar 19, 2012 at 6:23 PM, fawce <[hidden email]> wrote:
> > On Mar 19, 2012, at 8:51 PM, Brian Granger wrote: > >> On Mon, Mar 19, 2012 at 5:27 PM, hugo <[hidden email]> wrote: >>> ah - interesting, I didn't quite understand it at first. >>> >>> I think that would work, however in the d3 case, I think performance >>> would be an issue, d3 uses callbacks for everything. for a scatter >>> plot, each circle needs at least 2 callbacks, one for x coordinate, one >>> for y coordinate, that would be one round trip communication per point! >>> for local work, this might be ok, but it probably won't work in a >>> traditional client server setup, especially if you get many points. >>> >>> I think for me - the complexity involved in this is enough to convince >>> me that this is the wrong approach. It was an interesting experiment >>> but I'm going to give up on this path, I think a preferable route is to >>> implement higher level plots (scatter, lines, image plots, etc..) which >>> only take json serialiseable data as args, and then just call those from >>> ipython. >> >> I strongly agree with this assessment. In general we are -1 on adding >> new web socket connections and trying to manage Javascript/Python >> communications at a fine grained level. Things like interactive plots >> should simply take JSON data at the beginning and they work with it on >> the client side. > > Sorry for the poor suggestion, I just didn't know d3 was so chatty. > Highcharts works the way you're suggesting, and also has good support for incrementally adding data. It is a very nice library, and we're pushing a lot of updates to it via websockets. The tradeoff, which I think comes with the high-level chart design, is that you sacrifice flexibility in the rendering -- you can only use the chart types that exist in the library. I think we will (in the long run) be able to push/pull data to Javascript code like you are mentioning. But it will require some very careful design to do properly. We have started to think about these abstractions but have lots of work to go still. >> >> >>>> >>>> fawce's suggestion sounds very intriguing--make the websockets message >>>> passing two-way between python and javascript. The way I understand the >>>> suggestion, what about (in python): >>>> >>>> def mycallback(d): >>>> return d3.axis(d['x']) >>>> >>>> d3.selectAll('circle').attr('cx', callback(mycallback)); >>>> >>>> This gets translated to the javascript code: >>>> >>>> d3.selectAll('circle'.attr('cx', function(){ >>>> var results= send_message('mycallback', arguments); >>>> return interpret_results(results);}) >>>> >>>> send_message sends a message back through websockets to call the >>>> mycallback python function with some sort of proxy object d that knows >>>> how to generate json messages describing the attribute accesses, etc. >>>> In the python side, inside mycallback, d['x'] generates the javascript >>>> code to access arguments[0]['x'], so what is passed back is some sort of >>>> javascript code like 'd3.axis(arguments[0]['x'])'. interpret_results >>>> then runs this code and returns the result. >>>> >>>> Thanks, >>>> >>>> Jason >>>> _______________________________________________ >>>> IPython-dev mailing list >>>> [hidden email] >>>> http://mail.scipy.org/mailman/listinfo/ipython-dev >>> >>> _______________________________________________ >>> IPython-dev mailing list >>> [hidden email] >>> http://mail.scipy.org/mailman/listinfo/ipython-dev >> >> >> >> -- >> Brian E. Granger >> Cal Poly State University, San Luis Obispo >> [hidden email] and [hidden email] >> _______________________________________________ >> IPython-dev mailing list >> [hidden email] >> http://mail.scipy.org/mailman/listinfo/ipython-dev > > _______________________________________________ > IPython-dev mailing list > [hidden email] > http://mail.scipy.org/mailman/listinfo/ipython-dev -- Brian E. Granger Cal Poly State University, San Luis Obispo [hidden email] and [hidden email] _______________________________________________ IPython-dev mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/ipython-dev |
Re: experiment - remote execution of jquery and d3 code into the browser via ipython
|
In reply to this post by Brian Granger-3
On Mon, Mar 19, 2012 at 5:51 PM, Brian Granger <[hidden email]> wrote:
> On Mon, Mar 19, 2012 at 5:27 PM, hugo <[hidden email]> wrote: >> ah - interesting, I didn't quite understand it at first. >> >> I think that would work, however in the d3 case, I think performance >> would be an issue, d3 uses callbacks for everything. for a scatter >> plot, each circle needs at least 2 callbacks, one for x coordinate, one >> for y coordinate, that would be one round trip communication per point! >> for local work, this might be ok, but it probably won't work in a >> traditional client server setup, especially if you get many points. >> >> I think for me - the complexity involved in this is enough to convince >> me that this is the wrong approach. It was an interesting experiment >> but I'm going to give up on this path, I think a preferable route is to >> implement higher level plots (scatter, lines, image plots, etc..) which >> only take json serialiseable data as args, and then just call those from >> ipython. > > I strongly agree with this assessment. In general we are -1 on adding > new web socket connections and trying to manage Javascript/Python > communications at a fine grained level. Things like interactive plots > should simply take JSON data at the beginning and they work with it on > the client side. That's my take on it too, esp. given how intensely callback-based d3 seems to be. Even for localhost work, the fact that we'd be creating thousands of callbacks that become js-websockets-python-stringifiedjs-websocket-js monsters would probably make anything non-trivial unusably slow. But thanks Hugo for this experiment! It's great to start seeing with practical tests the boundaries of the problem, so that we can plan out what will be the most fruitful approaches to enable. We really want to simply refactor things in ipython so that *users* can start creating any kind of js-based interactive display they want, instead of us welding any specific approach to ipython itself. I think for now we've settled on the approach Brian outlines above as the most sensible path forward, eventually adding capabilities for incremental update of the data on the client. Clients would provide most interactivity with locally cached data, only requesting new information from the python process on an infrequent basis as thresholds of resolution or viewport are crossed. The one thing that will *not* be good for is real-time display of data, where you are actually pulling data as fast as it can be captured. Something like Peter Wang's Chaco demo with real time audio capture and spectrogram would require a ton of communication across the process boundary that I'm a bit doubtful will work well enough with that many layers in between... Cheers, f _______________________________________________ IPython-dev mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/ipython-dev |
Re: experiment - remote execution of jquery and d3 code into the browser via ipython
|
On Mar 20, 2012, at 10:08 PM, Fernando Perez wrote: > On Mon, Mar 19, 2012 at 5:51 PM, Brian Granger <[hidden email]> wrote: >> On Mon, Mar 19, 2012 at 5:27 PM, hugo <[hidden email]> wrote: >>> ah - interesting, I didn't quite understand it at first. >>> >>> I think that would work, however in the d3 case, I think performance >>> would be an issue, d3 uses callbacks for everything. for a scatter >>> plot, each circle needs at least 2 callbacks, one for x coordinate, one >>> for y coordinate, that would be one round trip communication per point! >>> for local work, this might be ok, but it probably won't work in a >>> traditional client server setup, especially if you get many points. >>> >>> I think for me - the complexity involved in this is enough to convince >>> me that this is the wrong approach. It was an interesting experiment >>> but I'm going to give up on this path, I think a preferable route is to >>> implement higher level plots (scatter, lines, image plots, etc..) which >>> only take json serialiseable data as args, and then just call those from >>> ipython. >> >> I strongly agree with this assessment. In general we are -1 on adding >> new web socket connections and trying to manage Javascript/Python >> communications at a fine grained level. Things like interactive plots >> should simply take JSON data at the beginning and they work with it on >> the client side. > > That's my take on it too, esp. given how intensely callback-based d3 > seems to be. Even for localhost work, the fact that we'd be creating > thousands of callbacks that become > js-websockets-python-stringifiedjs-websocket-js monsters would > probably make anything non-trivial unusably slow. > > But thanks Hugo for this experiment! It's great to start seeing with > practical tests the boundaries of the problem, so that we can plan out > what will be the most fruitful approaches to enable. We really want > to simply refactor things in ipython so that *users* can start > creating any kind of js-based interactive display they want, instead > of us welding any specific approach to ipython itself. > > I think for now we've settled on the approach Brian outlines above as > the most sensible path forward, eventually adding capabilities for > incremental update of the data on the client. Clients would provide > most interactivity with locally cached data, only requesting new > information from the python process on an infrequent basis as > thresholds of resolution or viewport are crossed. > > The one thing that will *not* be good for is real-time display of > data, where you are actually pulling data as fast as it can be > captured. Something like Peter Wang's Chaco demo with real time audio > capture and spectrogram would require a ton of communication across > the process boundary that I'm a bit doubtful will work well enough > with that many layers in between... > I think the html notebook can not currently support high through network traffic for large amount data transfer. And it is probably true for most web based visualization. What I think a general approach is to enable good API for two way communication to enable exchange information in the browser (javascript objects) and the ipython kernel (python objects), such a more convient way to develop interaction-rich visualization all within ipython notebook environment. For example, if I need a input-text box, I like to response the "on_change" javascript event with a python code. I will like to able to do something like this ## create a test input text box input_style = {"width":"240px"} i1 = vis.InputWidget(name = "input_1", parent = "plot_area", style = input_style, value = "try this out", vis = vis_display) def onchange(self, *argv, **kwargv): self.update_value() vis.set_action(i1, "onchange", onchange) And when the event "onchange" of the input-text html element is trigger, the "sefl.update_value()" python code is executed. It is totally possible to do such thing in the current 0.13-dev using the current ipython websocket/zmq channel. I have to monkey patched a numbers of thing on intercepting io_pub message that is not originally from a code_cell. With those patches, one can create any html based visualization with one's favorite javascript library. (A notebook that I am working on can be download from https://github.com/cschin/IPython-Notebook---d3.js-mashup/blob/master/inb_vis_widget_exp.ipynb , It has the instruction on how to monkey patch the 0.13-dev to make it work. I will write more about this later too.) _______________________________________________ IPython-dev mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/ipython-dev |
Re: experiment - remote execution of jquery and d3 code into the browser via ipython
|
|
Yet another demo, http://dl.dropbox.com/u/69208751/ipython_d3_word_ladder.mov I think it will be cool to be able to use ipython notebook to build such level of interactivity for some exploratory data analysis. (not data intensive, but interactive rich or 3D stuff) While most things that has been shown by some of us are currently d3.js centric, I think what we will like to see is to embrace as much as possible other cool javascript libs (e.g. http://mrdoob.github.com/three.js/ for 3D visualizations) . --Jason On Mar 21, 2012, at 12:04 PM, Chen-Shan Chin wrote: > > On Mar 20, 2012, at 10:08 PM, Fernando Perez wrote: > >> On Mon, Mar 19, 2012 at 5:51 PM, Brian Granger <[hidden email]> wrote: >>> On Mon, Mar 19, 2012 at 5:27 PM, hugo <[hidden email]> wrote: >>>> ah - interesting, I didn't quite understand it at first. >>>> >>>> I think that would work, however in the d3 case, I think performance >>>> would be an issue, d3 uses callbacks for everything. for a scatter >>>> plot, each circle needs at least 2 callbacks, one for x coordinate, one >>>> for y coordinate, that would be one round trip communication per point! >>>> for local work, this might be ok, but it probably won't work in a >>>> traditional client server setup, especially if you get many points. >>>> >>>> I think for me - the complexity involved in this is enough to convince >>>> me that this is the wrong approach. It was an interesting experiment >>>> but I'm going to give up on this path, I think a preferable route is to >>>> implement higher level plots (scatter, lines, image plots, etc..) which >>>> only take json serialiseable data as args, and then just call those from >>>> ipython. >>> >>> I strongly agree with this assessment. In general we are -1 on adding >>> new web socket connections and trying to manage Javascript/Python >>> communications at a fine grained level. Things like interactive plots >>> should simply take JSON data at the beginning and they work with it on >>> the client side. >> >> That's my take on it too, esp. given how intensely callback-based d3 >> seems to be. Even for localhost work, the fact that we'd be creating >> thousands of callbacks that become >> js-websockets-python-stringifiedjs-websocket-js monsters would >> probably make anything non-trivial unusably slow. >> >> But thanks Hugo for this experiment! It's great to start seeing with >> practical tests the boundaries of the problem, so that we can plan out >> what will be the most fruitful approaches to enable. We really want >> to simply refactor things in ipython so that *users* can start >> creating any kind of js-based interactive display they want, instead >> of us welding any specific approach to ipython itself. >> >> I think for now we've settled on the approach Brian outlines above as >> the most sensible path forward, eventually adding capabilities for >> incremental update of the data on the client. Clients would provide >> most interactivity with locally cached data, only requesting new >> information from the python process on an infrequent basis as >> thresholds of resolution or viewport are crossed. >> >> The one thing that will *not* be good for is real-time display of >> data, where you are actually pulling data as fast as it can be >> captured. Something like Peter Wang's Chaco demo with real time audio >> capture and spectrogram would require a ton of communication across >> the process boundary that I'm a bit doubtful will work well enough >> with that many layers in between... >> > > > I think the html notebook can not currently support high through network traffic for large > amount data transfer. And it is probably true for most web based visualization. What I > think a general approach is to enable good API for two way communication to enable exchange > information in the browser (javascript objects) and the ipython kernel (python objects), such > a more convient way to develop interaction-rich visualization all within ipython notebook > environment. > > For example, if I need a input-text box, I like to response the "on_change" javascript event > with a python code. I will like to able to do something like this > > > ## create a test input text box > input_style = {"width":"240px"} > i1 = vis.InputWidget(name = "input_1", > parent = "plot_area", > style = input_style, > value = "try this out", > vis = vis_display) > > def onchange(self, *argv, **kwargv): > self.update_value() > > vis.set_action(i1, "onchange", onchange) > > And when the event "onchange" of the input-text html element is trigger, the "sefl.update_value()" python code is executed. > > > It is totally possible to do such thing in the current 0.13-dev using the current ipython websocket/zmq channel. > I have to monkey patched a numbers of thing on intercepting io_pub message that is not originally from > a code_cell. With those patches, one can create any html based visualization with one's favorite > javascript library. > > (A notebook that I am working on can be download from https://github.com/cschin/IPython-Notebook---d3.js-mashup/blob/master/inb_vis_widget_exp.ipynb , It has the instruction on how to monkey patch the 0.13-dev to > make it work. I will write more about this later too.) > > > > > > > > > > > > > > > _______________________________________________ IPython-dev mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/ipython-dev |
|
I really like how flexible D3 can be, although it will take me a while to learn it. And the number one feature is that you can modify the graphics very easily in your browser. So today I started writing a module that would 'bring' D3 to IPython notebook, even though my experience with that is rather minimal. Surprisingly it goes well so far. I figured a way to insert multiple figures and update them between cells. The only problem now is that I cannot save the results. All HTML injections get saved, SVG objects are not. Any ideas how to circumvent that limitation?
Demo with three figures being populated with random dots. https://www.youtube.com/watch?v=IVlRT4wT7mM |
Re: experiment - remote execution of jquery and d3 code into the browser via ipython
|
|
On 5/5/12 6:28 PM, lecast wrote:
> I really like how flexible D3 can be, although it will take me a while to > learn it. And the number one feature is that you can modify the graphics > very easily in your browser. So today I started writing a module that would > 'bring' D3 to IPython notebook, even though my experience with that is > rather minimal. Surprisingly it goes well so far. I figured a way to insert > multiple figures and update them between cells. The only problem now is that > I cannot save the results. All HTML injections get saved, SVG objects are > not. Any ideas how to circumvent that limitation? > > Demo with three figures being populated with random dots. > https://www.youtube.com/watch?v=IVlRT4wT7mM I'm curious what you think of the recent pull request to refactor the javascript to make it easier for javascript to call back to python: https://github.com/ipython/ipython/pull/1697 Thanks, Jason _______________________________________________ IPython-dev mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/ipython-dev |
«
Return to IPython - Development
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |