[IPython-dev] Efficient way to render Javascripts

Jason Moore moorepants at gmail.com
Mon Jun 17 02:15:30 EDT 2013 

Thanks Brian, the sketch gives us a good idea for our path.


Jason
moorepants.info
+01 530-601-9791


On Sun, Jun 16, 2013 at 9:51 PM, Brian Granger <ellisonbg at gmail.com> wrote:

> Jason,
>
> > That is exactly what I wanted to hear. I'm just looking for some clarity
> on
> > how IPython works, how our project can utilize it, and where our
> resources
> > can potentially help you all. I agree firmly with sound design before
> > writing code and am glad to here you all are committed to that. Thanks!
>
> Thanks for understanding, glad my comments helped you.
>
> > So the better question for you all may be this:
> >
> > We're developing some browser based visualizations that we will use a
> simple
> > web server, a socket, or writing js on the fly to communicate between our
> > Python packages and the JS libraries. We'd love to design this in a way
> that
> > we can display the same thing in a notebook cell. Right now we can do
> that
> > with the ipython Display mechanisms but the data flow is definitely a
> hack.
> > What would be your recommendation for our approach so that (1) we can
> > display our visualization in the notebook now but without investing tons
> of
> > time into code that will be useless once you all have the widget support
> and
> > (2) that our designs be intended to mesh with the future JS widget
> designs
> > for the notebook (i.e. that our design is agnostic to the display
> mechanism
> > in the browser)?
>
> Here is a sketch of the some of the major features of the new design:
>
> * We will create an API that allows Python and JS to communicate data
> back and forth using JSON.  The JSON data might be the data you want
> to visualize.
> * When data is sent back and forth, a handler will be declared for
> that data.  There will likely be handlers on both the JS and Python
> sides.  These handlers will consume the JSON data and do whatever
> needs to be done.
> * We want to move away from having to write "code in strings" that is
> passed to Kernel.execute or the Javascript object.  The handler names
> will be used instead.
> * We expect the current Javascript display object to continue to work
> though.
>
> So, if you can work to cleanly separate your JS code from the JSON
> data that goes back and forth, you should have a clean path for the
> transition.
>
> > And a secondary question, what's the best way for us to follow progress
> in
> > the ipython js developments. Is the roadmap wiki the best place for the
> > looking for sumarized info on these parts of the project?
>
> The roadmap is pretty good, but we will probably also have other
> design documents on the wiki just for the interactive widgets.  I
> would check back in early August and we will have a lot more to say.
> We will also send out requests for comments on ipython-dev during the
> design and implementation process.
>
> Looking forward to see what you are all up to...
>
> Cheers,
>
> Brian
>
> >
> > Jason
> > moorepants.info
> > +01 530-601-9791
> >
> >
> > On Sat, Jun 15, 2013 at 9:44 AM, Brian Granger <ellisonbg at gmail.com>
> wrote:
> >>
> >> I don't think you are going to like this, but I want to be honest
> >> about our situation wrt these things:
> >>
> >> * It is not supported to do direct calls from the browser to the
> >> kernel.  You can hack it, but in general there is no promise the
> >> kernel is even running on publicly visible host.  Personally I would
> >> not invest the time to do direct GET/POST to the kernel.
> >> * If you write the data to a file, you can load the data using URLs of
> >> the form "files/mydata.json".
> >> * There is no way for JS to directly write data to a file.  You will
> >> have to embed the data in the string passed to Kernel.execute.
> >> * If you really have to work on all of this during the summer, it is
> >> going to be somewhat painful and you will have to redo a good part of
> >> it once IPython's support improves later this year.  If it were me, I
> >> would focus on other things.  This type of thing should be *trivial*
> >> once we have done our work.
> >> * We will *start* on this in late summer, but the work will be done
> >> gradually between late summer and early next year.  But, the low level
> >> pieces that you probably need should be done by Fall.
> >> * We are committed to getting the design of these things right.
> >> Within the IPython code base we are strictly focused on our 1.0
> >> release and roadmap:
> >>
> >> https://github.com/ipython/ipython/wiki/Roadmap:-IPython
> >>
> >> * This means we are actually committed to *not* doing anything on the
> >> interactive widgets within IPython until late Fall.  Even if other
> >> people want to contribute to the code base for these things, it will
> >> be ignored.  It is not a matter of writing code - that is the easy
> >> part - the hard part is the design.  IPython is a big project and it
> >> is extremely important for us to be focused, otherwise the project
> >> starts to look like a random walk and progress on big things is
> >> difficult.  Until later summer our focus is on nbconvert,
> >> multidirectory support and the 1.0 release.
> >> * IPython has been in this situation multiple times before - IOW
> >> people waiting long periods of time for us to finish important work.
> >> In all cases, waiting and being patient has been the right thing to
> >> do.
> >>
> >> I know this is probably bad news, but in the end, if you simply wait
> >> you will be able to accomplish what you want with a smile on your face
> >> saying "wow, I can't believe how awesome and easy this is...just
> >> magic"
> >>
> >> Cheers,
> >>
> >> Brian
> >>
> >> On Sat, Jun 15, 2013 at 9:23 AM, Jason Moore <moorepants at gmail.com>
> wrote:
> >> > Brian,
> >> >
> >> > So it seems that for us to get some data from a python object into our
> >> > javascript, we write the data to file on the fly so that a js cell can
> >> > pull
> >> > it in from the filesystem or we hard code the data into the js string.
> >> > Is
> >> > that the way it should be done with the current setup?
> >> >
> >> > So we'd like the functionality for GET/POST in the notebook for our
> >> > project.
> >> > And I have one full time student that starts this week. What would be
> >> > the
> >> > best way for us to contribute some patches to jumpstart this on the
> >> > ipython
> >> > side?
> >> >
> >> >
> >> >
> >> > Jason
> >> > moorepants.info
> >> > +01 530-601-9791
> >> >
> >> >
> >> > On Sat, Jun 15, 2013 at 9:02 AM, Brian Granger <ellisonbg at gmail.com>
> >> > wrote:
> >> >>
> >> >> Right now it does not have any easy way of doing that.  For now you
> >> >> will have to encode your data into the call to kernel.execute, which
> >> >> is a completely pain. That is exactly what we will be tackling later
> >> >> in the summer...
> >> >>
> >> >> Cheers,
> >> >>
> >> >> Brian
> >> >>
> >> >> On Sat, Jun 15, 2013 at 8:54 AM, Jason Moore <moorepants at gmail.com>
> >> >> wrote:
> >> >> > Brian,
> >> >> >
> >> >> > In IPython, is there a standard mechanism to pass data from the
> >> >> > client
> >> >> > to
> >> >> > the server? We'd like to make some python calls that generate a
> data
> >> >> > stucture, jsonify it and then make it available to the javascript
> >> >> > that
> >> >> > is
> >> >> > running in a cell via a GET request. I assume the kernel
> architecture
> >> >> > has
> >> >> > this in place?
> >> >> >
> >> >> >
> >> >> > Jason
> >> >> > moorepants.info
> >> >> > +01 530-601-9791
> >> >> >
> >> >> >
> >> >> > On Sat, Jun 15, 2013 at 8:14 AM, Brian Granger <
> ellisonbg at gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> Right now (today) the best way is to use the Javascript object
> along
> >> >> >> with the display function.  However, starting in late summer we
> will
> >> >> >> be improving this API so it may change some, but all for the
> >> >> >> better...
> >> >> >>
> >> >> >> Cheers,
> >> >> >>
> >> >> >> Brian
> >> >> >>
> >> >> >> On Fri, Jun 14, 2013 at 11:33 PM, TARUN GABA <
> tarun.gaba7 at gmail.com>
> >> >> >> wrote:
> >> >> >> > Hi,
> >> >> >> >
> >> >> >> > I am wondering on what method would be more efficient to serve
> >> >> >> > Javascripts on IPython notebooks
> >> >> >> >
> >> >> >> > I need to visualize/simulate multibody dynamics, and there are
> two
> >> >> >> > methods which are in my mind.
> >> >> >> > The rough API of the project is being formed at ..
> >> >> >> >
> >> >> >> > http://pydy.org/visualization
> >> >> >> >
> >> >> >> > the two methods are:
> >> >> >> > 1) Via http requests:
> >> >> >> >
> >> >> >> >   on calling something like ..
> >> >> >> >
> >> >> >> > myobject.visualize(numerical_data)
> >> >> >> >
> >> >> >> > The browser sends a POST request to the kernel, and python
> methods
> >> >> >> > send a POST request to the required javascripts alongwith POST
> >> >> >> > parameters as the numerical data required for visualization,
> most
> >> >> >> > likely a 4*4 transformation matrix, and shape information.
> >> >> >> > the Javascripts recieves the post and then it is displayed in
> the
> >> >> >> > IPython output cell.
> >> >> >> >
> >> >> >> > 2) Another method can be to make Javascript objects and save
> them
> >> >> >> > as
> >> >> >> > text in the classes,
> >> >> >> > something like ..
> >> >> >> >
> >> >> >> > def MyClass():
> >> >> >> >
> >> >> >> >     def __init__(relevant,args):
> >> >> >> >         self.js_data = ''' A call to the Javascript functions,
> >> >> >> > alongwith arguments..
> >> >> >> >                              var myobject =
> >> >> >> > Shape_creating_function(%s)'''%(args)
> >> >> >> >
> >> >> >> > and then on calling ..
> >> >> >> > MyClass.visualize()
> >> >> >> >
> >> >> >> > from IPython notebook, first calling all the required
> >> >> >> > javascripts(files) via publish_javascript()/publish_html()
> display
> >> >> >> > methods and then
> >> >> >> >
> >> >> >> > display(Javascript(MyClass.js_data))
> >> >> >> >
> >> >> >> > Which of these would be more feasible and efficient..
> >> >> >> > _______________________________________________
> >> >> >> > IPython-dev mailing list
> >> >> >> > IPython-dev at scipy.org
> >> >> >> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Brian E. Granger
> >> >> >> Cal Poly State University, San Luis Obispo
> >> >> >> bgranger at calpoly.edu and ellisonbg at gmail.com
> >> >> >> _______________________________________________
> >> >> >> IPython-dev mailing list
> >> >> >> IPython-dev at scipy.org
> >> >> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >> >> >
> >> >> >
> >> >> >
> >> >> > _______________________________________________
> >> >> > IPython-dev mailing list
> >> >> > IPython-dev at scipy.org
> >> >> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Brian E. Granger
> >> >> Cal Poly State University, San Luis Obispo
> >> >> bgranger at calpoly.edu and ellisonbg at gmail.com
> >> >> _______________________________________________
> >> >> IPython-dev mailing list
> >> >> IPython-dev at scipy.org
> >> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > IPython-dev mailing list
> >> > IPython-dev at scipy.org
> >> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >> >
> >>
> >>
> >>
> >> --
> >> Brian E. Granger
> >> Cal Poly State University, San Luis Obispo
> >> bgranger at calpoly.edu and ellisonbg at gmail.com
> >> _______________________________________________
> >> IPython-dev mailing list
> >> IPython-dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
> >
> >
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20130616/ae40bfa2/attachment.html>

More information about the IPython-dev mailing list