Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Comms to allow updating plots dynamically #838

Merged
merged 20 commits into from Aug 31, 2016
Merged

Add Comms to allow updating plots dynamically #838

merged 20 commits into from Aug 31, 2016

Conversation

@philippjfr
Copy link
Member

@philippjfr philippjfr commented Aug 30, 2016

This PR introduces Comms classes which allow bidirectionally communicating between the python process and a frontend. Additionally it gives Plot instances access to the current renderer and instantiates a Comms class, allowing updates to plots to be pushed to the frontend using the new refresh and push methods. Supports updating regular matplotlib plots, nbagg plots, mpld3 plots and bokeh plots.

@jbednar
Copy link
Member

@jbednar jbednar commented Aug 30, 2016

Can you briefly summarize what new functionality this will support, and/or what types of simplifications to the codebase will be possible, depending on your motivation here?

@philippjfr
Copy link
Member Author

@philippjfr philippjfr commented Aug 30, 2016

Sure, probably the right place to put this even though it's only a first step in that direction.

Eventually the aim of Comms is to allow any bidirectional communication between a Python process, whether that is a webserver or a Jupyter kernel, and a frontend. This will allow defining complex interactions using the upcoming Streams interface but should also eventually replace the existing mechanisms on our widgets to communicate widget state to python and update a plot on the frontend. One remaining obstacle will be to appropriately throttle events sent from the frontend to the python process.

@jlstevens
Copy link
Contributor

@jlstevens jlstevens commented Aug 30, 2016

At a higher level, I think of comms as offering a way to standardize communication with HoloViews visualizations that live in the browser (not necessarily the notebook). This should help simplify things and make it easier to implement new functionality whereby plots get updated over some communication channel (Jupyter Comms, websockets, some raw TCP socket, pipes, RPC etc).

@jbednar
Copy link
Member

@jbednar jbednar commented Aug 30, 2016

And Bokeh server?

@jlstevens
Copy link
Contributor

@jlstevens jlstevens commented Aug 30, 2016

And Bokeh server?

Most probably! We will definitely find a way to communicate with Bokeh visualizations without relying on Jupyter comms (i.e outside of notebooks).

@@ -135,6 +141,19 @@ def get_size(self_or_cls, plot):
return (w*dpi, h*dpi)


def patch(self, plot):
Copy link
Contributor

@jlstevens jlstevens Aug 30, 2016

I think diff would be a clearer name.

@jlstevens
Copy link
Contributor

@jlstevens jlstevens commented Aug 30, 2016

Made a couple of comments regarding naming.

Overall, I'm very pleased! This looks a lot clearer to me, the APIs look clean and I feel that I understand how it all works.

I realize it is still work-in-progress but it is already looking good!

A CustomCommSocket is required to delay communication
between the kernel and the canvas element until the widget
has been rendered in the notebook.
"""
Copy link
Contributor

@jlstevens jlstevens Aug 30, 2016

I believe CustomCommSocket must be an outdated name. This docstring should mention that CommSocket is a matplotlib concept that you are customizing to support NbAgg.



class SimpleJupyterComm(Comm):
"""
Copy link
Contributor

@jlstevens jlstevens Aug 31, 2016

How about calling it JupyterPushComm? From the sound of it, we may not need it in future one bokeh works with bi-directional comms.

for h in handles]
msg = compute_static_patch(doc, plotobjects)
handle.comms.send(json.dumps(msg))
return 'Complete'
Copy link
Contributor

@jlstevens jlstevens Aug 31, 2016

I would consider a better name than 'Complete'. Maybe 'Transferred', 'Transfer Complete' or maybe just 'Sent'. Not too important though...

# Define comm targets by mode
comms = {'default': (JupyterComm, mpl_msg_handler),
'nbagg': (NbAggJupyterComm, None),
'mpld3': (JupyterComm, mpld3_msg_handler)}
Copy link
Contributor

@jlstevens jlstevens Aug 31, 2016

In a later PR it would be good to have a nice way for the user to select the appropriate comms. E.g using WebsocketComms if not using the notebook.

@jlstevens
Copy link
Contributor

@jlstevens jlstevens commented Aug 31, 2016

I've now reviewed this PR and made all the comments I want to make. Overall, I'm really pleased with all of this! Once these comments are addressed, I am happy to merge.

@jlstevens jlstevens merged commit fac38de into master Aug 31, 2016
2 of 4 checks passed
@philippjfr philippjfr deleted the comms branch Sep 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants