New dev version?

Greg_Nordin · December 21, 2015, 10:59pm

Is there going to be a new dev version of 0.11 before its formal release?

Thanks,
Greg

Bryan · December 21, 2015, 11:55pm

Hi Greg,

Probably at least two. I had hoped to have another one today, but it will be tomorrow morning before I can get it out.

Bryan

···

On Dec 21, 2015, at 4:59 PM, Greg Nordin <[email protected]> wrote:

Is there going to be a new dev version of 0.11 before its formal release?

Thanks,
Greg

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/f424de41-4f34-4460-ab34-0d32ae545b6d%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

Greg_Nordin · December 22, 2015, 12:02am

Ok, sounds good. I was able to build a new version from master late this afternoon that resolved the problem with the start and stop buttons not working for the line_animation_widget.py example. I’ll pull the new dev versions as they come out and in the meantime work with the version I built.

Thanks for you and your team’s hard work! It’s quite impressive what you are accomplishing

Greg

···

On Monday, December 21, 2015 at 4:55:40 PM UTC-7, Bryan Van de ven wrote:

Hi Greg,

Probably at least two. I had hoped to have another one today, but it will be tomorrow morning before I can get it out.

Bryan

On Dec 21, 2015, at 4:59 PM, Greg Nordin [email protected] wrote:

Is there going to be a new dev version of 0.11 before its formal release?

Thanks,

Greg

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/f424de41-4f34-4460-ab34-0d32ae545b6d%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

Bryan · December 22, 2015, 12:05am

Hi Greg,

Thanks for the kind words, I am also glad to hear you were able to build without much trouble. If there is anything missing or unclear in the build instructions, though, please let us know.

Bryan

···

On Dec 21, 2015, at 6:02 PM, Greg Nordin <[email protected]> wrote:

Ok, sounds good. I was able to build a new version from master late this afternoon that resolved the problem with the start and stop buttons not working for the line_animation_widget.py example. I'll pull the new dev versions as they come out and in the meantime work with the version I built.

Thanks for you and your team's hard work! It's quite impressive what you are accomplishing

Greg

On Monday, December 21, 2015 at 4:55:40 PM UTC-7, Bryan Van de ven wrote:
Hi Greg,

Probably at least two. I had hoped to have another one today, but it will be tomorrow morning before I can get it out.

Bryan

> On Dec 21, 2015, at 4:59 PM, Greg Nordin <[email protected]> wrote:
>
> Is there going to be a new dev version of 0.11 before its formal release?
>
> Thanks,
> Greg
>
> --
> You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
> To post to this group, send email to bo...@continuum.io.
> To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/f424de41-4f34-4460-ab34-0d32ae545b6d%40continuum.io\.
> For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/5c5756e9-3231-4ace-9049-c790f756281d%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

Greg_Nordin · December 23, 2015, 5:36am

Hi Bryan,

I installed v0.11.0dev 5 (conda install -c bokeh/channel/dev bokeh) and got the example files that go with this dev version. However when I run “bokeh serve” and then “python line_animate_widget.py” in examples/plotting/server, the animation that comes up in my browser is extremely jumpy. It just jitters around and there is nothing smooth about it. I think I saw something about this in a PR the other day from one of your fellow developers, but don’t remember which PR.

Greg

···

On Monday, December 21, 2015 at 5:05:29 PM UTC-7, Bryan Van de ven wrote:

Hi Greg,

Thanks for the kind words, I am also glad to hear you were able to build without much trouble. If there is anything missing or unclear in the build instructions, though, please let us know.

Bryan

On Dec 21, 2015, at 6:02 PM, Greg Nordin [email protected] wrote:

Ok, sounds good. I was able to build a new version from master late this afternoon that resolved the problem with the start and stop buttons not working for the line_animation_widget.py example. I’ll pull the new dev versions as they come out and in the meantime work with the version I built.

Thanks for you and your team’s hard work! It’s quite impressive what you are accomplishing

Greg

On Monday, December 21, 2015 at 4:55:40 PM UTC-7, Bryan Van de ven wrote:

Hi Greg,

Probably at least two. I had hoped to have another one today, but it will be tomorrow morning before I can get it out.

Bryan

On Dec 21, 2015, at 4:59 PM, Greg Nordin [email protected] wrote:

Is there going to be a new dev version of 0.11 before its formal release?

Thanks,
Greg

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/f424de41-4f34-4460-ab34-0d32ae545b6d%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/5c5756e9-3231-4ace-9049-c790f756281d%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

Bryan · December 23, 2015, 5:41am

Greg,

When I start it is is jumpy at first, and then settles down to a smooth animation within a few seconds. We have speculated this might be due to browser JITing on startup. But more investigation is required. Can you provide more information about your browser and platform (hw and software) so that we can try to reproduce what you are seeing? Can you experiment and see if different timeout intervals or data sizes result in the updates smoothing?

Thanks,

Bryan

···

On Dec 22, 2015, at 11:36 PM, Greg Nordin <[email protected]> wrote:

Hi Bryan,

I installed v0.11.0dev 5 (conda install -c bokeh/channel/dev bokeh) and got the example files that go with this dev version. However when I run "bokeh serve" and then "python line_animate_widget.py" in examples/plotting/server, the animation that comes up in my browser is extremely jumpy. It just jitters around and there is nothing smooth about it. I think I saw something about this in a PR the other day from one of your fellow developers, but don't remember which PR.

Greg

On Monday, December 21, 2015 at 5:05:29 PM UTC-7, Bryan Van de ven wrote:
Hi Greg,

Thanks for the kind words, I am also glad to hear you were able to build without much trouble. If there is anything missing or unclear in the build instructions, though, please let us know.

Bryan

> On Dec 21, 2015, at 6:02 PM, Greg Nordin <[email protected]> wrote:
>
> Ok, sounds good. I was able to build a new version from master late this afternoon that resolved the problem with the start and stop buttons not working for the line_animation_widget.py example. I'll pull the new dev versions as they come out and in the meantime work with the version I built.
>
> Thanks for you and your team's hard work! It's quite impressive what you are accomplishing
>
> Greg
>
> On Monday, December 21, 2015 at 4:55:40 PM UTC-7, Bryan Van de ven wrote:
> Hi Greg,
>
> Probably at least two. I had hoped to have another one today, but it will be tomorrow morning before I can get it out.
>
> Bryan
>
>
> > On Dec 21, 2015, at 4:59 PM, Greg Nordin <[email protected]> wrote:
> >
> > Is there going to be a new dev version of 0.11 before its formal release?
> >
> > Thanks,
> > Greg
> >
> > --
> > You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
> > To post to this group, send email to bo...@continuum.io.
> > To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/f424de41-4f34-4460-ab34-0d32ae545b6d%40continuum.io\.
> > For more options, visit https://groups.google.com/a/continuum.io/d/optout\.
>
>
> --
> You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
> To post to this group, send email to bo...@continuum.io.
> To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/5c5756e9-3231-4ace-9049-c790f756281d%40continuum.io\.
> For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/c2ca5479-f503-456d-9f63-11193b14c07a%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

Greg_Nordin · December 23, 2015, 6:19am

Hi Bryan,

I’m on a MacBook Pro Retina (summer 2015 edition), 16 GB RAM, 1 TB SSD with Mac OS X 10.10.4 and Safari browser (8.0.7). The strange thing is that yesterday when I built Bokeh from a late afternoon version of master (not sure which commit), the animation was nice and smooth.

Ok, I just tried it again (re-ran python line_animate_widget.py; bokeh serve is still running from earlier today–i.e., I didn’t re-start it), and now the animation is very smooth, including right at start up. Not sure what’s going on. Earlier it was pretty bad.

Ok, I just stopped bokeh serve and re-started it and ran line_animate_widget.py. It stuttered for a brief fraction of a second and then ran smoothly.

By the way, I’m not sure what the correct way is to stop bokeh serve. I just use ^Z in terminal. If there is a better way, I’d be glad to find out what it is. Also, to stop running line_animate_widget.py I just ^C out of it in terminal.

I just changed the periodic callback parameter from 50 to 20 and now it stutters pretty badly, although at times it is smooth for a short time (~1 sec). Setting it to 10 it’s even worse. Back to 50 and it’s smooth except for the first fraction of a second, and at 100 it’s pretty smooth.

Changing the number of data points from 100 to 1000 for a periodic callback time parameter of 50 results in severe stuttering. Here are some more results:

200 data points: smooth animation

500 data points: stutters for about a second, and then smooth animation

2000 data points: terrible stuttering

I should also note that when the animation stutters the start and stop buttons either don’t work, or take a long time to respond (5-10 sec).

Greg

···

On Tuesday, December 22, 2015 at 10:41:16 PM UTC-7, Bryan Van de ven wrote:

Greg,

When I start it is is jumpy at first, and then settles down to a smooth animation within a few seconds. We have speculated this might be due to browser JITing on startup. But more investigation is required. Can you provide more information about your browser and platform (hw and software) so that we can try to reproduce what you are seeing? Can you experiment and see if different timeout intervals or data sizes result in the updates smoothing?

Thanks,

Bryan

On Dec 22, 2015, at 11:36 PM, Greg Nordin [email protected] wrote:

Hi Bryan,

I installed v0.11.0dev 5 (conda install -c bokeh/channel/dev bokeh) and got the example files that go with this dev version. However when I run “bokeh serve” and then “python line_animate_widget.py” in examples/plotting/server, the animation that comes up in my browser is extremely jumpy. It just jitters around and there is nothing smooth about it. I think I saw something about this in a PR the other day from one of your fellow developers, but don’t remember which PR.

Greg

On Monday, December 21, 2015 at 5:05:29 PM UTC-7, Bryan Van de ven wrote:

Hi Greg,

Thanks for the kind words, I am also glad to hear you were able to build without much trouble. If there is anything missing or unclear in the build instructions, though, please let us know.

Bryan

On Dec 21, 2015, at 6:02 PM, Greg Nordin [email protected] wrote:

Ok, sounds good. I was able to build a new version from master late this afternoon that resolved the problem with the start and stop buttons not working for the line_animation_widget.py example. I’ll pull the new dev versions as they come out and in the meantime work with the version I built.

Thanks for you and your team’s hard work! It’s quite impressive what you are accomplishing

Greg

On Monday, December 21, 2015 at 4:55:40 PM UTC-7, Bryan Van de ven wrote:
Hi Greg,

Probably at least two. I had hoped to have another one today, but it will be tomorrow morning before I can get it out.

Bryan

On Dec 21, 2015, at 4:59 PM, Greg Nordin [email protected] wrote:

Is there going to be a new dev version of 0.11 before its formal release?

Thanks,
Greg

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/f424de41-4f34-4460-ab34-0d32ae545b6d%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/5c5756e9-3231-4ace-9049-c790f756281d%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/c2ca5479-f503-456d-9f63-11193b14c07a%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

Bryan · December 23, 2015, 7:01am

Hi Greg, I have two interesting and hopefully useful things to share.

First, one of the things about the new server is that it has uncovered some areas where for client-only properties might need to be made more explicit. After a little investigation, I discovered what was causing the spurious updates back to the server (which is what is causing the problems): It is the auto-ranging functionality of DataRange1d. It is trying to recompute new bounds on every render, and this is triggering update messages back to the server (and there should really be none). We will have to investigate the best way to handle DataRanges in the context of the server. In the immediate term, just setting explicit ranges yields a dramatic improvement:

p = figure(x_range=(-1,15), y_range=(-1.5, 1.5))

Second, we have some messaging to do around the different ways to use the server. While it is possible to use the python websocket client in scripts, as is demonstrated in the line_animate_widget.py script, for single-user, temporary, local experimentation, that is really not the optimal way to load applications in the new Bokeh server. The most efficient way to use the bokeh server is to serve an app directly, e.g.:

bokeh serve line_animate_widget.py --show

If you intend to "deploy" the app, or need to scale it to accommodate high loads, this is absolutely the way you should go (you can just run multiple copies of the above command behind a load balancer e.g). And the reason simple: when using the python websocket client, there is basically double the communication overhead (python <-> server <-> browser) instead of just (server <-> browser) as you get when you run an app as I displayed above. I have attached a slightly modified (trimmed down) version of line_animate_widget.py at the bottom of this email. I encourage you to run it as an app as I have shown above. On similar hardware I can run 1000pts / 20ms smoothly.

Thanks,

Bryan

# line_animate_widget.py (app version)

import numpy as np
from numpy import pi

from bokeh.models.widgets import Button
from bokeh.plotting import figure, vplot, curdoc, hplot
from bokeh.driving import cosine

x = np.linspace(0, 4*pi, 1000)
y = np.sin(x)

p = figure(x_range=(-1,15), y_range=(-1.5, 1.5))
r1 = p.line([0, 4*pi], [-1, 1], color="firebrick")
r2 = p.line(x, y, color="navy", line_width=4)

def start_handler():
    global playing
    if not playing:
        curdoc().add_periodic_callback(update, 20)
        playing = True

def stop_handler():
    global playing
    if playing:
        curdoc().remove_periodic_callback(update)
        playing = False

button_start = Button(label="Start", type="success")
button_start.on_click(start_handler)

button_stop = Button(label="Stop", type="danger")
button_stop.on_click(stop_handler)

controls = hplot(button_start, button_stop)
layout = vplot(controls, p)

@cosine(w=0.03)
def update(step):
    if playing:
        r2.data_source.data["y"] = y * step
        r2.glyph.line_alpha = 1 - 0.8 * abs(step)

playing = True

curdoc().add_periodic_callback(update, 20)

···

On Dec 23, 2015, at 12:19 AM, Greg Nordin <[email protected]> wrote:

Hi Bryan,

I'm on a MacBook Pro Retina (summer 2015 edition), 16 GB RAM, 1 TB SSD with Mac OS X 10.10.4 and Safari browser (8.0.7). The strange thing is that yesterday when I built Bokeh from a late afternoon version of master (not sure which commit), the animation was nice and smooth.

Ok, I just tried it again (re-ran python line_animate_widget.py; bokeh serve is still running from earlier today--i.e., I didn't re-start it), and now the animation is very smooth, including right at start up. Not sure what's going on. Earlier it was pretty bad.

Ok, I just stopped bokeh serve and re-started it and ran line_animate_widget.py. It stuttered for a brief fraction of a second and then ran smoothly.

By the way, I'm not sure what the correct way is to stop bokeh serve. I just use ^Z in terminal. If there is a better way, I'd be glad to find out what it is. Also, to stop running line_animate_widget.py I just ^C out of it in terminal.

I just changed the periodic callback parameter from 50 to 20 and now it stutters pretty badly, although at times it is smooth for a short time (~1 sec). Setting it to 10 it's even worse. Back to 50 and it's smooth except for the first fraction of a second, and at 100 it's pretty smooth.

Changing the number of data points from 100 to 1000 for a periodic callback time parameter of 50 results in severe stuttering. Here are some more results:

200 data points: smooth animation
500 data points: stutters for about a second, and then smooth animation
2000 data points: terrible stuttering

I should also note that when the animation stutters the start and stop buttons either don't work, or take a long time to respond (5-10 sec).

Greg

On Tuesday, December 22, 2015 at 10:41:16 PM UTC-7, Bryan Van de ven wrote:

Greg,

When I start it is is jumpy at first, and then settles down to a smooth animation within a few seconds. We have speculated this might be due to browser JITing on startup. But more investigation is required. Can you provide more information about your browser and platform (hw and software) so that we can try to reproduce what you are seeing? Can you experiment and see if different timeout intervals or data sizes result in the updates smoothing?

Thanks,

Bryan

> On Dec 22, 2015, at 11:36 PM, Greg Nordin <[email protected]> wrote:
>
> Hi Bryan,
>
> I installed v0.11.0dev 5 (conda install -c bokeh/channel/dev bokeh) and got the example files that go with this dev version. However when I run "bokeh serve" and then "python line_animate_widget.py" in examples/plotting/server, the animation that comes up in my browser is extremely jumpy. It just jitters around and there is nothing smooth about it. I think I saw something about this in a PR the other day from one of your fellow developers, but don't remember which PR.
>
> Greg
>
> On Monday, December 21, 2015 at 5:05:29 PM UTC-7, Bryan Van de ven wrote:
> Hi Greg,
>
> Thanks for the kind words, I am also glad to hear you were able to build without much trouble. If there is anything missing or unclear in the build instructions, though, please let us know.
>
> Bryan
>
> > On Dec 21, 2015, at 6:02 PM, Greg Nordin <[email protected]> wrote:
> >
> > Ok, sounds good. I was able to build a new version from master late this afternoon that resolved the problem with the start and stop buttons not working for the line_animation_widget.py example. I'll pull the new dev versions as they come out and in the meantime work with the version I built.
> >
> > Thanks for you and your team's hard work! It's quite impressive what you are accomplishing
> >
> > Greg
> >
> > On Monday, December 21, 2015 at 4:55:40 PM UTC-7, Bryan Van de ven wrote:
> > Hi Greg,
> >
> > Probably at least two. I had hoped to have another one today, but it will be tomorrow morning before I can get it out.
> >
> > Bryan
> >
> >
> > > On Dec 21, 2015, at 4:59 PM, Greg Nordin <[email protected]> wrote:
> > >
> > > Is there going to be a new dev version of 0.11 before its formal release?
> > >
> > > Thanks,
> > > Greg
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
> > > To post to this group, send email to bo...@continuum.io.
> > > To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/f424de41-4f34-4460-ab34-0d32ae545b6d%40continuum.io\.
> > > For more options, visit https://groups.google.com/a/continuum.io/d/optout\.
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
> > To post to this group, send email to bo...@continuum.io.
> > To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/5c5756e9-3231-4ace-9049-c790f756281d%40continuum.io\.
> > For more options, visit https://groups.google.com/a/continuum.io/d/optout\.
>
>
> --
> You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
> To post to this group, send email to bo...@continuum.io.
> To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/c2ca5479-f503-456d-9f63-11193b14c07a%40continuum.io\.
> For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/e9357872-b80a-4269-a11d-44a7b2475b49%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

Bryan · December 23, 2015, 7:06am

I should add, we still have yet to add the feature to transmit arrays as binary frames directly into JavaScript typed arrays (although we have demonstrated a proof of concept). Right now arrays are encoded to JSON and then decoded again then copied into typed arrays, all of which which adds a considerable amount of overhead. I'm excited because enabling binary transport should offer a substantial performance increase, transparently to users. I doubt this will be ready for 0.11 (slight possibility) but if not, it will be in a 0.11.1 release early in 2016.

Thanks,

Bryan

···

On Dec 23, 2015, at 1:01 AM, Bryan Van de Ven <[email protected]> wrote:

Hi Greg, I have two interesting and hopefully useful things to share.

First, one of the things about the new server is that it has uncovered some areas where for client-only properties might need to be made more explicit. After a little investigation, I discovered what was causing the spurious updates back to the server (which is what is causing the problems): It is the auto-ranging functionality of DataRange1d. It is trying to recompute new bounds on every render, and this is triggering update messages back to the server (and there should really be none). We will have to investigate the best way to handle DataRanges in the context of the server. In the immediate term, just setting explicit ranges yields a dramatic improvement:

  p = figure(x_range=(-1,15), y_range=(-1.5, 1.5))

Second, we have some messaging to do around the different ways to use the server. While it is possible to use the python websocket client in scripts, as is demonstrated in the line_animate_widget.py script, for single-user, temporary, local experimentation, that is really not the optimal way to load applications in the new Bokeh server. The most efficient way to use the bokeh server is to serve an app directly, e.g.:

  bokeh serve line_animate_widget.py --show

If you intend to "deploy" the app, or need to scale it to accommodate high loads, this is absolutely the way you should go (you can just run multiple copies of the above command behind a load balancer e.g). And the reason simple: when using the python websocket client, there is basically double the communication overhead (python <-> server <-> browser) instead of just (server <-> browser) as you get when you run an app as I displayed above. I have attached a slightly modified (trimmed down) version of line_animate_widget.py at the bottom of this email. I encourage you to run it as an app as I have shown above. On similar hardware I can run 1000pts / 20ms smoothly.

Thanks,

Bryan

# line_animate_widget.py (app version)

import numpy as np
from numpy import pi

from bokeh.models.widgets import Button
from bokeh.plotting import figure, vplot, curdoc, hplot
from bokeh.driving import cosine

x = np.linspace(0, 4*pi, 1000)
y = np.sin(x)

p = figure(x_range=(-1,15), y_range=(-1.5, 1.5))
r1 = p.line([0, 4*pi], [-1, 1], color="firebrick")
r2 = p.line(x, y, color="navy", line_width=4)

def start_handler():
   global playing
   if not playing:
       curdoc().add_periodic_callback(update, 20)
       playing = True

def stop_handler():
   global playing
   if playing:
       curdoc().remove_periodic_callback(update)
       playing = False

button_start = Button(label="Start", type="success")
button_start.on_click(start_handler)

button_stop = Button(label="Stop", type="danger")
button_stop.on_click(stop_handler)

controls = hplot(button_start, button_stop)
layout = vplot(controls, p)

@cosine(w=0.03)
def update(step):
   if playing:
       r2.data_source.data["y"] = y * step
       r2.glyph.line_alpha = 1 - 0.8 * abs(step)

playing = True

curdoc().add_periodic_callback(update, 20)

On Dec 23, 2015, at 12:19 AM, Greg Nordin <[email protected]> wrote:

Hi Bryan,

I'm on a MacBook Pro Retina (summer 2015 edition), 16 GB RAM, 1 TB SSD with Mac OS X 10.10.4 and Safari browser (8.0.7). The strange thing is that yesterday when I built Bokeh from a late afternoon version of master (not sure which commit), the animation was nice and smooth.

Ok, I just tried it again (re-ran python line_animate_widget.py; bokeh serve is still running from earlier today--i.e., I didn't re-start it), and now the animation is very smooth, including right at start up. Not sure what's going on. Earlier it was pretty bad.

Ok, I just stopped bokeh serve and re-started it and ran line_animate_widget.py. It stuttered for a brief fraction of a second and then ran smoothly.

By the way, I'm not sure what the correct way is to stop bokeh serve. I just use ^Z in terminal. If there is a better way, I'd be glad to find out what it is. Also, to stop running line_animate_widget.py I just ^C out of it in terminal.

I just changed the periodic callback parameter from 50 to 20 and now it stutters pretty badly, although at times it is smooth for a short time (~1 sec). Setting it to 10 it's even worse. Back to 50 and it's smooth except for the first fraction of a second, and at 100 it's pretty smooth.

Changing the number of data points from 100 to 1000 for a periodic callback time parameter of 50 results in severe stuttering. Here are some more results:

200 data points: smooth animation
500 data points: stutters for about a second, and then smooth animation
2000 data points: terrible stuttering

I should also note that when the animation stutters the start and stop buttons either don't work, or take a long time to respond (5-10 sec).

Greg

On Tuesday, December 22, 2015 at 10:41:16 PM UTC-7, Bryan Van de ven wrote:

Greg,

When I start it is is jumpy at first, and then settles down to a smooth animation within a few seconds. We have speculated this might be due to browser JITing on startup. But more investigation is required. Can you provide more information about your browser and platform (hw and software) so that we can try to reproduce what you are seeing? Can you experiment and see if different timeout intervals or data sizes result in the updates smoothing?

Thanks,

Bryan

On Dec 22, 2015, at 11:36 PM, Greg Nordin <[email protected]> wrote:

Hi Bryan,

I installed v0.11.0dev 5 (conda install -c bokeh/channel/dev bokeh) and got the example files that go with this dev version. However when I run "bokeh serve" and then "python line_animate_widget.py" in examples/plotting/server, the animation that comes up in my browser is extremely jumpy. It just jitters around and there is nothing smooth about it. I think I saw something about this in a PR the other day from one of your fellow developers, but don't remember which PR.

Greg

On Monday, December 21, 2015 at 5:05:29 PM UTC-7, Bryan Van de ven wrote:
Hi Greg,

Thanks for the kind words, I am also glad to hear you were able to build without much trouble. If there is anything missing or unclear in the build instructions, though, please let us know.

Bryan

On Dec 21, 2015, at 6:02 PM, Greg Nordin <[email protected]> wrote:

Ok, sounds good. I was able to build a new version from master late this afternoon that resolved the problem with the start and stop buttons not working for the line_animation_widget.py example. I'll pull the new dev versions as they come out and in the meantime work with the version I built.

Thanks for you and your team's hard work! It's quite impressive what you are accomplishing

Greg

On Monday, December 21, 2015 at 4:55:40 PM UTC-7, Bryan Van de ven wrote:
Hi Greg,

Probably at least two. I had hoped to have another one today, but it will be tomorrow morning before I can get it out.

Bryan

On Dec 21, 2015, at 4:59 PM, Greg Nordin <[email protected]> wrote:

Is there going to be a new dev version of 0.11 before its formal release?

Thanks,
Greg

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
To post to this group, send email to bo...@continuum.io.
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/f424de41-4f34-4460-ab34-0d32ae545b6d%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
To post to this group, send email to bo...@continuum.io.
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/5c5756e9-3231-4ace-9049-c790f756281d%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
To post to this group, send email to bo...@continuum.io.
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/c2ca5479-f503-456d-9f63-11193b14c07a%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/e9357872-b80a-4269-a11d-44a7b2475b49%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

Greg_Nordin · December 23, 2015, 7:14am

Very interesting–thanks for letting me know. I’ll try this out tomorrow. I’m also excited for the binary transport!

In the next few days I plan to start writing a simple animation I will use in class the first week of the semester. I plan to do some performance testing with it prior to writing some animations I’ll be using in subsequent weeks.

Greg

···

On Wednesday, December 23, 2015 at 12:01:05 AM UTC-7, Bryan Van de ven wrote:

Hi Greg, I have two interesting and hopefully useful things to share.

First, one of the things about the new server is that it has uncovered some areas where for client-only properties might need to be made more explicit. After a little investigation, I discovered what was causing the spurious updates back to the server (which is what is causing the problems): It is the auto-ranging functionality of DataRange1d. It is trying to recompute new bounds on every render, and this is triggering update messages back to the server (and there should really be none). We will have to investigate the best way to handle DataRanges in the context of the server. In the immediate term, just setting explicit ranges yields a dramatic improvement:
    p = figure(x_range=(-1,15), y_range=(-1.5, 1.5))
Second, we have some messaging to do around the different ways to use the server. While it is possible to use the python websocket client in scripts, as is demonstrated in the line_animate_widget.py script, for single-user, temporary, local experimentation, that is really not the optimal way to load applications in the new Bokeh server. The most efficient way to use the bokeh server is to serve an app directly, e.g.:
    bokeh serve line_animate_widget.py --show
If you intend to “deploy” the app, or need to scale it to accommodate high loads, this is absolutely the way you should go (you can just run multiple copies of the above command behind a load balancer e.g). And the reason simple: when using the python websocket client, there is basically double the communication overhead (python ↔ server ↔ browser) instead of just (server ↔ browser) as you get when you run an app as I displayed above. I have attached a slightly modified (trimmed down) version of line_animate_widget.py at the bottom of this email. I encourage you to run it as an app as I have shown above. On similar hardware I can run 1000pts / 20ms smoothly.

Thanks,

Bryan

line_animate_widget.py (app version)

import numpy as np

from numpy import pi

from bokeh.models.widgets import Button

from bokeh.plotting import figure, vplot, curdoc, hplot

from bokeh.driving import cosine

x = np.linspace(0, 4*pi, 1000)

y = np.sin(x)

p = figure(x_range=(-1,15), y_range=(-1.5, 1.5))

r1 = p.line([0, 4*pi], [-1, 1], color=“firebrick”)

r2 = p.line(x, y, color=“navy”, line_width=4)

def start_handler():
global playing

if not playing:

    curdoc().add_periodic_callback(update, 20)

    playing = True
def stop_handler():
global playing

if playing:

    curdoc().remove_periodic_callback(update)

    playing = False
button_start = Button(label=“Start”, type=“success”)

button_start.on_click(start_handler)

button_stop = Button(label=“Stop”, type=“danger”)

button_stop.on_click(stop_handler)

controls = hplot(button_start, button_stop)

layout = vplot(controls, p)

@cosine(w=0.03)

def update(step):
if playing:

    r2.data_source.data["y"] = y * step

    r2.glyph.line_alpha = 1 - 0.8 * abs(step)
playing = True

curdoc().add_periodic_callback(update, 20)

On Dec 23, 2015, at 12:19 AM, Greg Nordin [email protected] wrote:

Hi Bryan,

I’m on a MacBook Pro Retina (summer 2015 edition), 16 GB RAM, 1 TB SSD with Mac OS X 10.10.4 and Safari browser (8.0.7). The strange thing is that yesterday when I built Bokeh from a late afternoon version of master (not sure which commit), the animation was nice and smooth.

Ok, I just tried it again (re-ran python line_animate_widget.py; bokeh serve is still running from earlier today–i.e., I didn’t re-start it), and now the animation is very smooth, including right at start up. Not sure what’s going on. Earlier it was pretty bad.

Ok, I just stopped bokeh serve and re-started it and ran line_animate_widget.py. It stuttered for a brief fraction of a second and then ran smoothly.

By the way, I’m not sure what the correct way is to stop bokeh serve. I just use ^Z in terminal. If there is a better way, I’d be glad to find out what it is. Also, to stop running line_animate_widget.py I just ^C out of it in terminal.

I just changed the periodic callback parameter from 50 to 20 and now it stutters pretty badly, although at times it is smooth for a short time (~1 sec). Setting it to 10 it’s even worse. Back to 50 and it’s smooth except for the first fraction of a second, and at 100 it’s pretty smooth.

Changing the number of data points from 100 to 1000 for a periodic callback time parameter of 50 results in severe stuttering. Here are some more results:

200 data points: smooth animation

500 data points: stutters for about a second, and then smooth animation

2000 data points: terrible stuttering

I should also note that when the animation stutters the start and stop buttons either don’t work, or take a long time to respond (5-10 sec).

Greg

On Tuesday, December 22, 2015 at 10:41:16 PM UTC-7, Bryan Van de ven wrote:

Greg,

When I start it is is jumpy at first, and then settles down to a smooth animation within a few seconds. We have speculated this might be due to browser JITing on startup. But more investigation is required. Can you provide more information about your browser and platform (hw and software) so that we can try to reproduce what you are seeing? Can you experiment and see if different timeout intervals or data sizes result in the updates smoothing?

Thanks,

Bryan

On Dec 22, 2015, at 11:36 PM, Greg Nordin [email protected] wrote:

Hi Bryan,

I installed v0.11.0dev 5 (conda install -c bokeh/channel/dev bokeh) and got the example files that go with this dev version. However when I run “bokeh serve” and then “python line_animate_widget.py” in examples/plotting/server, the animation that comes up in my browser is extremely jumpy. It just jitters around and there is nothing smooth about it. I think I saw something about this in a PR the other day from one of your fellow developers, but don’t remember which PR.

Greg

On Monday, December 21, 2015 at 5:05:29 PM UTC-7, Bryan Van de ven wrote:
Hi Greg,

Thanks for the kind words, I am also glad to hear you were able to build without much trouble. If there is anything missing or unclear in the build instructions, though, please let us know.

Bryan

On Dec 21, 2015, at 6:02 PM, Greg Nordin [email protected] wrote:

Ok, sounds good. I was able to build a new version from master late this afternoon that resolved the problem with the start and stop buttons not working for the line_animation_widget.py example. I’ll pull the new dev versions as they come out and in the meantime work with the version I built.

Thanks for you and your team’s hard work! It’s quite impressive what you are accomplishing

Greg

On Monday, December 21, 2015 at 4:55:40 PM UTC-7, Bryan Van de ven wrote:
Hi Greg,

Probably at least two. I had hoped to have another one today, but it will be tomorrow morning before I can get it out.

Bryan

On Dec 21, 2015, at 4:59 PM, Greg Nordin [email protected] wrote:

Is there going to be a new dev version of 0.11 before its formal release?

Thanks,
Greg

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/f424de41-4f34-4460-ab34-0d32ae545b6d%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/5c5756e9-3231-4ace-9049-c790f756281d%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/c2ca5479-f503-456d-9f63-11193b14c07a%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/e9357872-b80a-4269-a11d-44a7b2475b49%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

Havoc_Pennington · December 23, 2015, 2:30pm

Hi,

I think our Tornado setup might have limitations when there's so much data
that the client or server gets backlogged - I've been looking at Tornado
docs to see if there's some way to control buffering or apply backpressure,
and it doesn't seem like there's much available on the Tornado level. If
one side doesn't keep up there's going to be a long backlog buffered
somewhere, which is going to create a lot of latency (if there's a new
event like a button click, we have to chew threw that backlog before we see
it).

In the Java world there's this recent effort, which shows one kind of thing
that could work:

http://www.reactive-streams.org/

There are probably some hacks you could do. For example, you could add a
custom model with a "server counter" and "client counter," the server
increments its counter in every periodic callback, the client sets its
counter to the server counter value when it gets a change notification on
the server counter... if the server sees the client counter too far behind
it makes the periodic callback do nothing for a while until the client
catches up... I don't know, something like that could limit the backlog
size.

The good news is that in practice one can often get away without this
stuff... after all Tornado doesn't seem to have it, and Java hasn't
traditionally had it. It's probably possible to be OK by simply tuning down
the amount of data (either frame-rate or amount of data per frame) until
things scale to the degree needed for a particular app. This is simple for
a single-machine local animation as you both were just playing with, and
should be possible for apps with a small number of people viewing them. For
apps that really need to scale out to hundreds or more users, server-driven
animation probably isn't a great approach, since it's quite a lot of CPU
and bandwidth so you'd be throwing a lot of cash at servers if nothing else.

In the long run we could probably implement some kind of special-case
mechanism for streaming data, that would include smarts around throttling,
buffering, etc. and avoid the backlog problem semi-magically behind the
scenes, at least for data arrays.

Also thinking, for animation, consistent smoothness requires a bit more
cleverness than a simple timeout. It's necessary to have a mechanism for
dropping frames and/or interpolating based on wall clock time, probably,
for example. However the simple approach works as long as your CPU is
easily keeping up with the framerate.

I don't think this kind of issue will arise for apps that aren't
continuously streaming, for example callbacks that only happen when the
user clicks something, though there are probably some scenarios like it
with interactive sliders for example (user continuously scrubs slider back
and forth, creating a backlog of events).

One way to avoid backlog in the slider scenario without a fancy new
approach is to have change events on the slider add a timeout on the server
side, if none has already been added, and update the data in the timeout;
that would throttle updates to the timeout frequency.

Havoc

Bryan · December 23, 2015, 2:51pm

FYI, just as a very rough "signpost" benchmark, I ran line_update_widget.py with 1000 points and a 20ms update overnight. It ran smoothly and without any big CPU spikes (fan, e.g). I will be *extremely* interested to see how much this might be improved by sending the arrays as binary frames. I also want to investigate if there are other inadvertent browser->server updates happening that might be affecting performance.

I agree that there is a "# of users" / "amount of data" tradefoff curve, and that server side streaming absolutely does not make sense for every combination.

I also agree that easing/tweening functions for scheduling animations purely browser-side, debouncing and buffering widget updates (e.g. scrubbing a slider shouldn't necesssarily trigger 100 callbacks along the way) will go a long way in many use-cases.

For true streaming, are still different use use-cases with different optimizations. I'd like to add protocol messages for incremental or "random access" updates to arrays. For "appending" streaming, this should make a huge difference. For cases like line_update_widget.py where all the data changes on every update, we might finally need to look into the buffering/backlog measures, but I don't think that is the most common case.

I actually find it quite encouraging that things are already where they are, yet there is still low hanging fruit left to make more improvements.

Bryan

···

On Dec 23, 2015, at 8:30 AM, Havoc Pennington <[email protected]> wrote:

Hi,

I think our Tornado setup might have limitations when there's so much data that the client or server gets backlogged - I've been looking at Tornado docs to see if there's some way to control buffering or apply backpressure, and it doesn't seem like there's much available on the Tornado level. If one side doesn't keep up there's going to be a long backlog buffered somewhere, which is going to create a lot of latency (if there's a new event like a button click, we have to chew threw that backlog before we see it).

In the Java world there's this recent effort, which shows one kind of thing that could work:
GitHub - reactive-streams/reactive-streams-jvm: Reactive Streams Specification for the JVM
http://www.reactive-streams.org/

There are probably some hacks you could do. For example, you could add a custom model with a "server counter" and "client counter," the server increments its counter in every periodic callback, the client sets its counter to the server counter value when it gets a change notification on the server counter... if the server sees the client counter too far behind it makes the periodic callback do nothing for a while until the client catches up... I don't know, something like that could limit the backlog size.

The good news is that in practice one can often get away without this stuff... after all Tornado doesn't seem to have it, and Java hasn't traditionally had it. It's probably possible to be OK by simply tuning down the amount of data (either frame-rate or amount of data per frame) until things scale to the degree needed for a particular app. This is simple for a single-machine local animation as you both were just playing with, and should be possible for apps with a small number of people viewing them. For apps that really need to scale out to hundreds or more users, server-driven animation probably isn't a great approach, since it's quite a lot of CPU and bandwidth so you'd be throwing a lot of cash at servers if nothing else.

In the long run we could probably implement some kind of special-case mechanism for streaming data, that would include smarts around throttling, buffering, etc. and avoid the backlog problem semi-magically behind the scenes, at least for data arrays.

Also thinking, for animation, consistent smoothness requires a bit more cleverness than a simple timeout. It's necessary to have a mechanism for dropping frames and/or interpolating based on wall clock time, probably, for example. However the simple approach works as long as your CPU is easily keeping up with the framerate.

I don't think this kind of issue will arise for apps that aren't continuously streaming, for example callbacks that only happen when the user clicks something, though there are probably some scenarios like it with interactive sliders for example (user continuously scrubs slider back and forth, creating a backlog of events).

One way to avoid backlog in the slider scenario without a fancy new approach is to have change events on the slider add a timeout on the server side, if none has already been added, and update the data in the timeout; that would throttle updates to the timeout frequency.

Havoc

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/CAC%2B_nE3iAsVCDPY7c0qY9PUYh8_01MF10e%2B-auXrR6rMXEL3fw%40mail.gmail.com\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

Greg_Nordin · December 23, 2015, 10:35pm

Great information–thanks!

A couple of quick follow-ups:

When I run line_animate_widget.py with 1000 points and 20 ms update rate the animation is smooth but the stop button is not very responsive. When I click on the stop button it can take several seconds before the animation stops. If I decrease the update rate to 35 ms, clicking on the stop button immediately stops the animation. (Note: I’m using Brian’s updated “p = figure(x_range=(-1,15), y_range=(-1.5, 1.5)) " in line_animate_widget.py”.)
When I run “bokeh serve line_animate_widget.py” I get the following error: CRITICAL:bokeh.server.server:Cannot start Bokeh server, port 5006 is already in use. However if I use “html” or “json” instead of “serve” in the command, a window immediately opens up in my browser with the animation and runs just fine. I thought the html and json options would just create an html or json file. In the case of html, I do get an html file in addition to an animation in the browser. In the case of json there is no json file in addition to the browser animation. I don’t really care about the html and json files. It’s just not doing what I would have expected so I thought I’d pass it along.

Greg

···

On Wednesday, December 23, 2015 at 7:51:14 AM UTC-7, Bryan Van de ven wrote:

FYI, just as a very rough “signpost” benchmark, I ran line_update_widget.py with 1000 points and a 20ms update overnight. It ran smoothly and without any big CPU spikes (fan, e.g). I will be extremely interested to see how much this might be improved by sending the arrays as binary frames. I also want to investigate if there are other inadvertent browser->server updates happening that might be affecting performance.

I agree that there is a “# of users” / “amount of data” tradefoff curve, and that server side streaming absolutely does not make sense for every combination.

I also agree that easing/tweening functions for scheduling animations purely browser-side, debouncing and buffering widget updates (e.g. scrubbing a slider shouldn’t necesssarily trigger 100 callbacks along the way) will go a long way in many use-cases.

For true streaming, are still different use use-cases with different optimizations. I’d like to add protocol messages for incremental or “random access” updates to arrays. For “appending” streaming, this should make a huge difference. For cases like line_update_widget.py where all the data changes on every update, we might finally need to look into the buffering/backlog measures, but I don’t think that is the most common case.

I actually find it quite encouraging that things are already where they are, yet there is still low hanging fruit left to make more improvements.

Bryan

On Dec 23, 2015, at 8:30 AM, Havoc Pennington [email protected] wrote:

Hi,

I think our Tornado setup might have limitations when there’s so much data that the client or server gets backlogged - I’ve been looking at Tornado docs to see if there’s some way to control buffering or apply backpressure, and it doesn’t seem like there’s much available on the Tornado level. If one side doesn’t keep up there’s going to be a long backlog buffered somewhere, which is going to create a lot of latency (if there’s a new event like a button click, we have to chew threw that backlog before we see it).

In the Java world there’s this recent effort, which shows one kind of thing that could work:

https://github.com/reactive-streams/reactive-streams-jvm/tree/master

http://www.reactive-streams.org/

There are probably some hacks you could do. For example, you could add a custom model with a “server counter” and “client counter,” the server increments its counter in every periodic callback, the client sets its counter to the server counter value when it gets a change notification on the server counter… if the server sees the client counter too far behind it makes the periodic callback do nothing for a while until the client catches up… I don’t know, something like that could limit the backlog size.

The good news is that in practice one can often get away without this stuff… after all Tornado doesn’t seem to have it, and Java hasn’t traditionally had it. It’s probably possible to be OK by simply tuning down the amount of data (either frame-rate or amount of data per frame) until things scale to the degree needed for a particular app. This is simple for a single-machine local animation as you both were just playing with, and should be possible for apps with a small number of people viewing them. For apps that really need to scale out to hundreds or more users, server-driven animation probably isn’t a great approach, since it’s quite a lot of CPU and bandwidth so you’d be throwing a lot of cash at servers if nothing else.

In the long run we could probably implement some kind of special-case mechanism for streaming data, that would include smarts around throttling, buffering, etc. and avoid the backlog problem semi-magically behind the scenes, at least for data arrays.

Also thinking, for animation, consistent smoothness requires a bit more cleverness than a simple timeout. It’s necessary to have a mechanism for dropping frames and/or interpolating based on wall clock time, probably, for example. However the simple approach works as long as your CPU is easily keeping up with the framerate.

I don’t think this kind of issue will arise for apps that aren’t continuously streaming, for example callbacks that only happen when the user clicks something, though there are probably some scenarios like it with interactive sliders for example (user continuously scrubs slider back and forth, creating a backlog of events).

One way to avoid backlog in the slider scenario without a fancy new approach is to have change events on the slider add a timeout on the server side, if none has already been added, and update the data in the timeout; that would throttle updates to the timeout frequency.

Havoc

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/CAC%2B_nE3iAsVCDPY7c0qY9PUYh8_01MF10e%2B-auXrR6rMXEL3fw%40mail.gmail.com.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

Bryan · December 23, 2015, 10:53pm

Greg,

You get the error about the port because you left the first "bokeh serve" running. You can stop it (Ctrl-C) or you can specify a different port with the --port option when you run, e.g.:

bokeh serve line_animate_widget.py --port=5010 --show

I'm not sure about the other behaviour with "html" or "json" that seems surprising to me too. My only thought offhand is that it is opening up the animation you left running from part 1. again.

Bryan

···

On Dec 23, 2015, at 4:35 PM, Greg Nordin <[email protected]> wrote:

Great information--thanks!

A couple of quick follow-ups:

1. When I run line_animate_widget.py with 1000 points and 20 ms update rate the animation is smooth but the stop button is not very responsive. When I click on the stop button it can take several seconds before the animation stops. If I decrease the update rate to 35 ms, clicking on the stop button immediately stops the animation. (Note: I'm using Brian's updated "p = figure(x_range=(-1,15), y_range=(-1.5, 1.5)) " in line_animate_widget.py".)

2. When I run "bokeh serve line_animate_widget.py" I get the following error: CRITICAL:bokeh.server.server:Cannot start Bokeh server, port 5006 is already in use. However if I use "html" or "json" instead of "serve" in the command, a window immediately opens up in my browser with the animation and runs just fine. I thought the html and json options would just create an html or json file. In the case of html, I do get an html file in addition to an animation in the browser. In the case of json there is no json file in addition to the browser animation. I don't really care about the html and json files. It's just not doing what I would have expected so I thought I'd pass it along.

Greg

On Wednesday, December 23, 2015 at 7:51:14 AM UTC-7, Bryan Van de ven wrote:
FYI, just as a very rough "signpost" benchmark, I ran line_update_widget.py with 1000 points and a 20ms update overnight. It ran smoothly and without any big CPU spikes (fan, e.g). I will be *extremely* interested to see how much this might be improved by sending the arrays as binary frames. I also want to investigate if there are other inadvertent browser->server updates happening that might be affecting performance.

I agree that there is a "# of users" / "amount of data" tradefoff curve, and that server side streaming absolutely does not make sense for every combination.

I also agree that easing/tweening functions for scheduling animations purely browser-side, debouncing and buffering widget updates (e.g. scrubbing a slider shouldn't necesssarily trigger 100 callbacks along the way) will go a long way in many use-cases.

For true streaming, are still different use use-cases with different optimizations. I'd like to add protocol messages for incremental or "random access" updates to arrays. For "appending" streaming, this should make a huge difference. For cases like line_update_widget.py where all the data changes on every update, we might finally need to look into the buffering/backlog measures, but I don't think that is the most common case.

I actually find it quite encouraging that things are already where they are, yet there is still low hanging fruit left to make more improvements.

Bryan

> On Dec 23, 2015, at 8:30 AM, Havoc Pennington <[email protected]> wrote:
>
> Hi,
>
> I think our Tornado setup might have limitations when there's so much data that the client or server gets backlogged - I've been looking at Tornado docs to see if there's some way to control buffering or apply backpressure, and it doesn't seem like there's much available on the Tornado level. If one side doesn't keep up there's going to be a long backlog buffered somewhere, which is going to create a lot of latency (if there's a new event like a button click, we have to chew threw that backlog before we see it).
>
> In the Java world there's this recent effort, which shows one kind of thing that could work:
> GitHub - reactive-streams/reactive-streams-jvm: Reactive Streams Specification for the JVM
> http://www.reactive-streams.org/
>
> There are probably some hacks you could do. For example, you could add a custom model with a "server counter" and "client counter," the server increments its counter in every periodic callback, the client sets its counter to the server counter value when it gets a change notification on the server counter... if the server sees the client counter too far behind it makes the periodic callback do nothing for a while until the client catches up... I don't know, something like that could limit the backlog size.
>
> The good news is that in practice one can often get away without this stuff... after all Tornado doesn't seem to have it, and Java hasn't traditionally had it. It's probably possible to be OK by simply tuning down the amount of data (either frame-rate or amount of data per frame) until things scale to the degree needed for a particular app. This is simple for a single-machine local animation as you both were just playing with, and should be possible for apps with a small number of people viewing them. For apps that really need to scale out to hundreds or more users, server-driven animation probably isn't a great approach, since it's quite a lot of CPU and bandwidth so you'd be throwing a lot of cash at servers if nothing else.
>
> In the long run we could probably implement some kind of special-case mechanism for streaming data, that would include smarts around throttling, buffering, etc. and avoid the backlog problem semi-magically behind the scenes, at least for data arrays.
>
> Also thinking, for animation, consistent smoothness requires a bit more cleverness than a simple timeout. It's necessary to have a mechanism for dropping frames and/or interpolating based on wall clock time, probably, for example. However the simple approach works as long as your CPU is easily keeping up with the framerate.
>
> I don't think this kind of issue will arise for apps that aren't continuously streaming, for example callbacks that only happen when the user clicks something, though there are probably some scenarios like it with interactive sliders for example (user continuously scrubs slider back and forth, creating a backlog of events).
>
> One way to avoid backlog in the slider scenario without a fancy new approach is to have change events on the slider add a timeout on the server side, if none has already been added, and update the data in the timeout; that would throttle updates to the timeout frequency.
>
> Havoc
>
>
> --
> You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
> To post to this group, send email to bo...@continuum.io.
> To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/CAC%2B_nE3iAsVCDPY7c0qY9PUYh8_01MF10e%2B-auXrR6rMXEL3fw%40mail.gmail.com\.
> For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/6f7c4076-5779-4ec1-915f-ca6191e643fd%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

Greg_Nordin · December 23, 2015, 11:27pm

Hi Bryan,

I found my problem for #2: I inadvertentlyh ad “bokeh serve” running in another terminal window. Also, I was mistakenly stopping “bokeh serve” with ^Z which does not properly shut it down, whereas ^C does do a full shut down.

Ok, this leads to two more things:

If I do “bokeh serve line_animate_widget.py --port=5010 --show”, the plot is opened immediately in a browser window but there are no start and stop buttons and the line plot is static. The same happens when I do “bokeh serve line_animate_widget.py --show” except it takes 5-10 seconds for the browser window to show up. If I do “bokeh serve line_animate_widget.py” and then manually open localhost:5006/line_animate_widget in my browser, it again takes 5-10 seconds to show up with no buttons or animation.
On the other hand, if I do “bokeh serve” in one terminal window and “python line_animate_widget.py” in another, the plot shows up immediately with working buttons and an animated line.

Greg

···

On Wednesday, December 23, 2015 at 3:53:05 PM UTC-7, Bryan Van de ven wrote:

Greg,

You get the error about the port because you left the first “bokeh serve” running. You can stop it (Ctrl-C) or you can specify a different port with the --port option when you run, e.g.:
    bokeh serve line_animate_widget.py --port=5010 --show
I’m not sure about the other behaviour with “html” or “json” that seems surprising to me too. My only thought offhand is that it is opening up the animation you left running from part 1. again.

Bryan

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/CAC%2B_nE3iAsVCDPY7c0qY9PUYh8_01MF10e%2B-auXrR6rMXEL3fw%40mail.gmail.com.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/6f7c4076-5779-4ec1-915f-ca6191e643fd%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

Bryan · December 24, 2015, 12:19am

Greg,

That's very bizarre, "bokeh server foo.py" should be much more efficient (and definitely is for me). There is also "line_animate.py" with no widgets, just double checking perhaps you ran that one by accident? Are you running from master, or a dev build? If from master, you need to set BOKEH_RESOURCES=inline to use locally built JS. Otherwise I wonder about some installation or configuration issue. Can you verify that when you run "bokeh server foo.py" it's actually running the expected bokeh command (i.e not some different one earlier in your path). Failing all that I would suggest cleaning out your site-packages, or making a fresh clean environment.

···

On Dec 23, 2015, at 5:27 PM, Greg Nordin <[email protected]> wrote:

Hi Bryan,

I found my problem for #2: I inadvertentlyh ad "bokeh serve" running in another terminal window. Also, I was mistakenly stopping "bokeh serve" with ^Z which does not properly shut it down, whereas ^C does do a full shut down.

Ok, this leads to two more things:

1. If I do "bokeh serve line_animate_widget.py --port=5010 --show", the plot is opened immediately in a browser window but there are no start and stop buttons and the line plot is static. The same happens when I do "bokeh serve line_animate_widget.py --show" except it takes 5-10 seconds for the browser window to show up. If I do "bokeh serve line_animate_widget.py" and then manually open localhost:5006/line_animate_widget in my browser, it again takes 5-10 seconds to show up with no buttons or animation.

2. On the other hand, if I do "bokeh serve" in one terminal window and "python line_animate_widget.py" in another, the plot shows up immediately with working buttons and an animated line.

Greg

On Wednesday, December 23, 2015 at 3:53:05 PM UTC-7, Bryan Van de ven wrote:
Greg,

You get the error about the port because you left the first "bokeh serve" running. You can stop it (Ctrl-C) or you can specify a different port with the --port option when you run, e.g.:

bokeh serve line_animate_widget.py --port=5010 --show

I'm not sure about the other behaviour with "html" or "json" that seems surprising to me too. My only thought offhand is that it is opening up the animation you left running from part 1. again.

Bryan

> >
> > --
> > You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
> > To post to this group, send email to bo...@continuum.io.
> > To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/CAC%2B_nE3iAsVCDPY7c0qY9PUYh8_01MF10e%2B-auXrR6rMXEL3fw%40mail.gmail.com\.
> > For more options, visit https://groups.google.com/a/continuum.io/d/optout\.
>
>
> --
> You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
> To post to this group, send email to bo...@continuum.io.
> To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/6f7c4076-5779-4ec1-915f-ca6191e643fd%40continuum.io\.
> For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/a0402f4f-349c-4195-8000-45197a8ce9d3%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

Greg_Nordin · December 24, 2015, 1:28am

Bryan,

I created a fresh clean environment (conda create -n py35bokeh python=3.5 anaconda), activated it, and installed the latest bokeh dev version (conda install -c bokeh/channel/dev bokeh). I then execute “bokeh serve line_animate_widget.py”, go to my browser and open localhost:5006/line_animate_widget (because the bokeh server does not automatically open a window in my browser), and it still takes 5-10 seconds to load and just presents a static graph with no buttons.

If I then start “bokeh serve” in one terminal window and “bokeh html line_animate_widget.py” in another, a browser window immediately pops up with animated graph and buttons. Examining the html file that’s created, the linked css and script files are https://cdn.pydata.org/bokeh/dev/bokeh-0.11.0dev5.min.[css,js]. Likewise for the widgets links: https://cdn.pydata.org/bokeh/dev/bokeh-widgets-0.11.0dev5.min.[css,js]. I assume these are the correct dev5 links.

Not sure what’s going on.

Greg

···

On Wednesday, December 23, 2015 at 5:19:51 PM UTC-7, Bryan Van de ven wrote:

Greg,

That’s very bizarre, “bokeh server foo.py” should be much more efficient (and definitely is for me). There is also “line_animate.py” with no widgets, just double checking perhaps you ran that one by accident? Are you running from master, or a dev build? If from master, you need to set BOKEH_RESOURCES=inline to use locally built JS. Otherwise I wonder about some installation or configuration issue. Can you verify that when you run “bokeh server foo.py” it’s actually running the expected bokeh command (i.e not some different one earlier in your path). Failing all that I would suggest cleaning out your site-packages, or making a fresh clean environment.

On Dec 23, 2015, at 5:27 PM, Greg Nordin [email protected] wrote:

Hi Bryan,

I found my problem for #2: I inadvertentlyh ad “bokeh serve” running in another terminal window. Also, I was mistakenly stopping “bokeh serve” with ^Z which does not properly shut it down, whereas ^C does do a full shut down.

Ok, this leads to two more things:

If I do “bokeh serve line_animate_widget.py --port=5010 --show”, the plot is opened immediately in a browser window but there are no start and stop buttons and the line plot is static. The same happens when I do “bokeh serve line_animate_widget.py --show” except it takes 5-10 seconds for the browser window to show up. If I do “bokeh serve line_animate_widget.py” and then manually open localhost:5006/line_animate_widget in my browser, it again takes 5-10 seconds to show up with no buttons or animation.

On the other hand, if I do “bokeh serve” in one terminal window and “python line_animate_widget.py” in another, the plot shows up immediately with working buttons and an animated line.

Greg

On Wednesday, December 23, 2015 at 3:53:05 PM UTC-7, Bryan Van de ven wrote:
Greg,

You get the error about the port because you left the first “bokeh serve” running. You can stop it (Ctrl-C) or you can specify a different port with the --port option when you run, e.g.:
    bokeh serve line_animate_widget.py --port=5010 --show
I’m not sure about the other behaviour with “html” or “json” that seems surprising to me too. My only thought offhand is that it is opening up the animation you left running from part 1. again.

Bryan

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/CAC%2B_nE3iAsVCDPY7c0qY9PUYh8_01MF10e%2B-auXrR6rMXEL3fw%40mail.gmail.com.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/6f7c4076-5779-4ec1-915f-ca6191e643fd%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/a0402f4f-349c-4195-8000-45197a8ce9d3%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

Bryan · December 24, 2015, 3:50am

I use py34 normally perhaps there is a py35 issue. Will investigate soon.

···

On Dec 23, 2015, at 19:28, Greg Nordin [email protected] wrote:

Bryan,

I created a fresh clean environment (conda create -n py35bokeh python=3.5 anaconda), activated it, and installed the latest bokeh dev version (conda install -c bokeh/channel/dev bokeh). I then execute “bokeh serve line_animate_widget.py”, go to my browser and open localhost:5006/line_animate_widget (because the bokeh server does not automatically open a window in my browser), and it still takes 5-10 seconds to load and just presents a static graph with no buttons.

If I then start “bokeh serve” in one terminal window and “bokeh html line_animate_widget.py” in another, a browser window immediately pops up with animated graph and buttons. Examining the html file that’s created, the linked css and script files are https://cdn.pydata.org/bokeh/dev/bokeh-0.11.0dev5.min.[css,js]. Likewise for the widgets links: https://cdn.pydata.org/bokeh/dev/bokeh-widgets-0.11.0dev5.min.[css,js]. I assume these are the correct dev5 links.

Not sure what’s going on.

Greg

On Wednesday, December 23, 2015 at 5:19:51 PM UTC-7, Bryan Van de ven wrote:
Greg,

That’s very bizarre, “bokeh server foo.py” should be much more efficient (and definitely is for me). There is also “line_animate.py” with no widgets, just double checking perhaps you ran that one by accident? Are you running from master, or a dev build? If from master, you need to set BOKEH_RESOURCES=inline to use locally built JS. Otherwise I wonder about some installation or configuration issue. Can you verify that when you run “bokeh server foo.py” it’s actually running the expected bokeh command (i.e not some different one earlier in your path). Failing all that I would suggest cleaning out your site-packages, or making a fresh clean environment.

On Dec 23, 2015, at 5:27 PM, Greg Nordin [email protected] wrote:

Hi Bryan,

I found my problem for #2: I inadvertentlyh ad “bokeh serve” running in another terminal window. Also, I was mistakenly stopping “bokeh serve” with ^Z which does not properly shut it down, whereas ^C does do a full shut down.

Ok, this leads to two more things:

If I do “bokeh serve line_animate_widget.py --port=5010 --show”, the plot is opened immediately in a browser window but there are no start and stop buttons and the line plot is static. The same happens when I do “bokeh serve line_animate_widget.py --show” except it takes 5-10 seconds for the browser window to show up. If I do “bokeh serve line_animate_widget.py” and then manually open localhost:5006/line_animate_widget in my browser, it again takes 5-10 seconds to show up with no buttons or animation.

On the other hand, if I do “bokeh serve” in one terminal window and “python line_animate_widget.py” in another, the plot shows up immediately with working buttons and an animated line.

Greg

On Wednesday, December 23, 2015 at 3:53:05 PM UTC-7, Bryan Van de ven wrote:
Greg,

You get the error about the port because you left the first “bokeh serve” running. You can stop it (Ctrl-C) or you can specify a different port with the --port option when you run, e.g.:
    bokeh serve line_animate_widget.py --port=5010 --show
I’m not sure about the other behaviour with “html” or “json” that seems surprising to me too. My only thought offhand is that it is opening up the animation you left running from part 1. again.

Bryan

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/CAC%2B_nE3iAsVCDPY7c0qY9PUYh8_01MF10e%2B-auXrR6rMXEL3fw%40mail.gmail.com.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/6f7c4076-5779-4ec1-915f-ca6191e643fd%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/a0402f4f-349c-4195-8000-45197a8ce9d3%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–

You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/06a6d8f7-9406-4b41-a825-dc85c858cdf8%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

Havoc_Pennington · December 24, 2015, 4:20am

Don’t know if this is your issue, but the same script can’t be used in both ways.

If the script has output_server() and push() or show() in it, or push_session() or pull_session() in it, it’s intended to be run outside the server and push a document to the server from outside.

If the script only modifies curdoc() with no explicit output/push/show then it’s intended to be run inside the server by passing it to bokeh serve.

push_session and pull_session should be added to this list to give an error in this case:

https://github.com/bokeh/bokeh/blob/master/bokeh/application/handlers/script.py#L15

Havoc

···

On Dec 23, 2015, at 6:27 PM, Greg Nordin [email protected] wrote:

Hi Bryan,

I found my problem for #2: I inadvertentlyh ad “bokeh serve” running in another terminal window. Also, I was mistakenly stopping “bokeh serve” with ^Z which does not properly shut it down, whereas ^C does do a full shut down.

Ok, this leads to two more things:

If I do “bokeh serve line_animate_widget.py --port=5010 --show”, the plot is opened immediately in a browser window but there are no start and stop buttons and the line plot is static. The same happens when I do “bokeh serve line_animate_widget.py --show” except it takes 5-10 seconds for the browser window to show up. If I do “bokeh serve line_animate_widget.py” and then manually open localhost:5006/line_animate_widget in my browser, it again takes 5-10 seconds to show up with no buttons or animation.

On the other hand, if I do “bokeh serve” in one terminal window and “python line_animate_widget.py” in another, the plot shows up immediately with working buttons and an animated line.

Greg

On Wednesday, December 23, 2015 at 3:53:05 PM UTC-7, Bryan Van de ven wrote:
Greg,

You get the error about the port because you left the first “bokeh serve” running. You can stop it (Ctrl-C) or you can specify a different port with the --port option when you run, e.g.:
    bokeh serve line_animate_widget.py --port=5010 --show
I’m not sure about the other behaviour with “html” or “json” that seems surprising to me too. My only thought offhand is that it is opening up the animation you left running from part 1. again.

Bryan

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/CAC%2B_nE3iAsVCDPY7c0qY9PUYh8_01MF10e%2B-auXrR6rMXEL3fw%40mail.gmail.com.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/6f7c4076-5779-4ec1-915f-ca6191e643fd%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–

You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/a0402f4f-349c-4195-8000-45197a8ce9d3%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

Bryan · December 24, 2015, 5:06am

Oh! Right, Greg, are you running the modified version of line_animate_widget.py that I included in my response a few messages back? It had all of the things Havoc mentioned (output_server, push_session, etc) stripped out. That is what you need to be using. The new server command is actually very nice in that you can write scripts without having to choose and output method -- you just run "bokeh serve" or "bokeh html" or "bokeh json" on the exact same script and it does the right thing. But you have to explicitly not choose, i.e., not have output_server, etc in the script.

Bryan

···

On Dec 23, 2015, at 10:20 PM, Havoc Pennington <[email protected]> wrote:

Don't know if this is your issue, but the same script can't be used in both ways.
If the script has output_server() and push() or show() in it, or push_session() or pull_session() in it, it's intended to be run outside the server and push a document to the server from outside.

If the script only modifies curdoc() with no explicit output/push/show then it's intended to be run inside the server by passing it to bokeh serve.

push_session and pull_session should be added to this list to give an error in this case:
https://github.com/bokeh/bokeh/blob/master/bokeh/application/handlers/script.py#L15

Havoc

On Dec 23, 2015, at 6:27 PM, Greg Nordin <[email protected]> wrote:

Hi Bryan,

I found my problem for #2: I inadvertentlyh ad "bokeh serve" running in another terminal window. Also, I was mistakenly stopping "bokeh serve" with ^Z which does not properly shut it down, whereas ^C does do a full shut down.

Ok, this leads to two more things:

1. If I do "bokeh serve line_animate_widget.py --port=5010 --show", the plot is opened immediately in a browser window but there are no start and stop buttons and the line plot is static. The same happens when I do "bokeh serve line_animate_widget.py --show" except it takes 5-10 seconds for the browser window to show up. If I do "bokeh serve line_animate_widget.py" and then manually open localhost:5006/line_animate_widget in my browser, it again takes 5-10 seconds to show up with no buttons or animation.

2. On the other hand, if I do "bokeh serve" in one terminal window and "python line_animate_widget.py" in another, the plot shows up immediately with working buttons and an animated line.

Greg

On Wednesday, December 23, 2015 at 3:53:05 PM UTC-7, Bryan Van de ven wrote:
Greg,

You get the error about the port because you left the first "bokeh serve" running. You can stop it (Ctrl-C) or you can specify a different port with the --port option when you run, e.g.:

bokeh serve line_animate_widget.py --port=5010 --show

I'm not sure about the other behaviour with "html" or "json" that seems surprising to me too. My only thought offhand is that it is opening up the animation you left running from part 1. again.

Bryan

> >
> > --
> > You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
> > To post to this group, send email to bo...@continuum.io.
> > To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/CAC%2B_nE3iAsVCDPY7c0qY9PUYh8_01MF10e%2B-auXrR6rMXEL3fw%40mail.gmail.com\.
> > For more options, visit https://groups.google.com/a/continuum.io/d/optout\.
>
>
> --
> You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
> To post to this group, send email to bo...@continuum.io.
> To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/6f7c4076-5779-4ec1-915f-ca6191e643fd%40continuum.io\.
> For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/a0402f4f-349c-4195-8000-45197a8ce9d3%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/21415F08-0721-49AD-9DBA-9B1CE3E23958%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.