Quantcast

experiment - remote execution of jquery and d3 code into the browser via ipython

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

experiment - remote execution of jquery and d3 code into the browser via ipython

hugo

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: experiment - remote execution of jquery and d3 code into the browser via ipython

John Fawcett
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:


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


_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: experiment - remote execution of jquery and d3 code into the browser via ipython

hugo


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.


On Mar 19, 2012, at 8:13 AM, hugo wrote:


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



_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: experiment - remote execution of jquery and d3 code into the browser via ipython

Jason Grout-5
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
epi
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: experiment - remote execution of jquery and d3 code into the browser via ipython

epi
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: experiment - remote execution of jquery and d3 code into the browser via ipython

hugo
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: experiment - remote execution of jquery and d3 code into the browser via ipython

Brian Granger-3
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: experiment - remote execution of jquery and d3 code into the browser via ipython

John Fawcett

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: experiment - remote execution of jquery and d3 code into the browser via ipython

Brian Granger-3
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: experiment - remote execution of jquery and d3 code into the browser via ipython

Fernando Perez
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: experiment - remote execution of jquery and d3 code into the browser via ipython

Chen-Shan Chin

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: experiment - remote execution of jquery and d3 code into the browser via ipython

Chen-Shan Chin

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: experiment - remote execution of jquery and d3 code into the browser via ipython

lecast
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: experiment - remote execution of jquery and d3 code into the browser via ipython

Jason Grout-5
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
Loading...