About VR3, holoviews and bokeh

[Edward K. Ream]

Thomas Passin and I have been discussing his vr3 plugin in private. This is a great plugin. Our conversation deserves to be public.

Here I am going to discuss what I think I know about vr3 and its relationship with the holoviews and bokeh packages.  I'll keep this as short as possible.

vr3: the big picture

vr3 allows you to interleave python code with rst, such that both parts are shown in the vr3 pane. This is a great feature.  For example, given the following in the body pane:

@language python

import holoviews as hv
hv.extension('bokeh')
xs = range(-10,11)
ys = [100-el**2 for el in xs]
curve = hv.Curve((xs, ys))
curve.opts(width=350, height=300)
hv.save(curve, 'curve.html')

@language rest
Here is the resulting interactive graph:

.. raw:: html
   :file: curve.html

You will see something like the attached file in the vr3 pane.

I wonder, though, whether some of the rST code is necessary. Thomas, wouldn't it be simpler (for users) for vr3 to support something like:

@language rst
Here is the resulting interactive graph:
@image curve.html

Just a thought...

Holoview and bokeh

Holoviews and bokeh are both important projects. It's reasonable to use both.

For vr3, using holoviews might be the better starting point, as shown above. However, I personally am more more interested in the bokeh client server architecture as it relates to Jupyter. I'm not sure how this architecture relates to vr3.

Summary

Thomas is vr3's author. I'll stay out of his way.

In effect, vr3 makes every Leo node act like a Jupyter notebook cell.

I will be investigating bokeh's client/server architecture, independently of vr3.

Thomas, any comments or corrections will be appreciated.

Edward

[Edward K. Ream]

On Monday, March 30, 2020 at 5:48:29 AM UTC-5, Edward K. Ream wrote:

> You will see something like the attached file in the vr3 pane.

The attached file is (I hope) what you will see.

Edward

[Thomas Passin]

On Monday, March 30, 2020 at 6:48:29 AM UTC-4, Edward K. Ream wrote:

Thomas Passin and I have been discussing his vr3 plugin in private. This is a great plugin. Our conversation deserves to be public.

Here I am going to discuss what I think I know about vr3 and its relationship with the holoviews and bokeh packages.  I'll keep this as short as possible.

vr3: the big picture

vr3 allows you to interleave python code with rst, such that both parts are shown in the vr3 pane. This is a great feature.  For example, given the following in the body pane:

@language python

import holoviews as hv
hv.extension('bokeh')
xs = range(-10,11)
ys = [100-el**2 for el in xs]
curve = hv.Curve((xs, ys))
curve.opts(width=350, height=300)
hv.save(curve, 'curve.html')

@language rest
Here is the resulting interactive graph:

.. raw:: html
   :file: curve.html

You will see something like the attached file in the vr3 pane.

I wonder, though, whether some of the rST code is necessary. Thomas, wouldn't it be simpler (for users) for vr3 to support something like:

@language rst
Here is the resulting interactive graph:
@image curve.html

Not in this case, because the output is interactive javascript code, not just an image file.  Matplotlib will produce an image file, and then you could probably do it that way.




Also, for there to be an @image directive, we'd have to think it through carefully to understand what should happen if someone put one into the middle of a code block.  In principle, it would be a good thing to have a language-agnostic directive like this that you could use the same way with both MD and RsT, so the idea is attractive from that point of view.


[Thomas Passin]

On Monday, March 30, 2020 at 6:48:29 AM UTC-4, Edward K. Ream wrote:

Thomas Passin and I have been discussing his vr3 plugin in private. This is a great plugin. Our conversation deserves to be public.

Holoview and bokeh

Holoviews and bokeh are both important projects. It's reasonable to use both.

For vr3, using holoviews might be the better starting point, as shown above. However, I personally am more more interested in the bokeh client server architecture as it relates to Jupyter. I'm not sure how this architecture relates to vr3.

I've been thinking about Jupyter for some time, and I'd like to discuss how Leo and Jupyter could work together.  I wouldn't recommending jumping into working on client-server, though. I've feeling somewhat negative about that at the moment.  I think we can manage almost everything worth doing without it, as long as we can improve Jupyter import and export. And if we can't, then we won't be able to make client-server work well either.  Let's start up another thread on Leo-Jupyter, and I'll put my thoughts there. Would you like to open one up?

[Thomas Passin]

And it turns out that it's just as easy to work with Seaborn.

On Monday, March 30, 2020 at 6:48:29 AM UTC-4, Edward K. Ream wrote:

Thomas Passin and I have been discussing his vr3 plugin in private. This is a great plugin. Our conversation deserves to be public.

Here I am going to discuss what I think I know about vr3 and its relationship with the holoviews and bokeh packages.  I'll keep this as short as possible.

[snip]

[Edward K. Ream]

On Mon, Mar 30, 2020 at 7:34 AM Thomas Passin <tbp1...@gmail.com> wrote:

And it turns out that it's just as easy to work with Seaborn,

Excellent.

Edward

[Edward K. Ream]

On Mon, Mar 30, 2020 at 7:21 AM Thomas Passin <tbp1...@gmail.com> wrote:

> Let's start up another thread on Leo-Jupyter, and I'll put my thoughts there.

Feel free to start it now. I have to study bokeh before saying anything more.

Edward

[Thomas Passin]

On Monday, March 30, 2020 at 8:12:25 AM UTC-4, Thomas Passin wrote:

On Monday, March 30, 2020 at 6:48:29 AM UTC-4, Edward K. Ream wrote:

Thomas Passin and I have been discussing his vr3 plugin in private. This is a great plugin. Our conversation deserves to be public.

Here I am going to discuss what I think I know about vr3 and its relationship with the holoviews and bokeh packages.  I'll keep this as short as possible.

[snip]

 

I wonder, though, whether some of the rST code is necessary. Thomas, wouldn't it be simpler (for users) for vr3 to support something like:

@language rst
Here is the resulting interactive graph:
@image curve.html

Not in this case, because the output is interactive javascript code, not just an image file.  Matplotlib will produce an image file, and then you could probably do it that way.




Also, for there to be an @image directive, we'd have to think it through carefully to understand what should happen if someone put one into the middle of a code block.  In principle, it would be a good thing to have a language-agnostic directive like this that you could use the same way with both MD and RsT, so the idea is attractive from that point of view.


If we were to adopt an @image directive, then we ought to also adopt an @html-blob one.  This would be used for interactive plots from Bokeh, animations, etc.

[Edward K. Ream]

On Mon, Mar 30, 2020 at 8:16 AM Thomas Passin <tbp1...@gmail.com> wrote:

> If we were to adopt an @image directive, then we ought to also adopt an @html-blob one.  This would be used for interactive plots from Bokeh, animations, etc.

I do think @image is a good idea, and I'll take your word for it re @html-blob.

It's up to you whether you do either one.

Edward

[Offray Vladimir Luna Cárdenas]

This looks really cool! I was asking for a inspiring screenshot in other thread, unknowing that I would find them here.

Thanks a lot,

Offray

On 30/03/20 7:34 a. m., Thomas Passin wrote:

And it turns out that it's just as easy to work with Seaborn,

On Monday, March 30, 2020 at 6:48:29 AM UTC-4, Edward K. Ream wrote:

Thomas Passin and I have been discussing his vr3 plugin in private. This is a great plugin. Our conversation deserves to be public.

Here I am going to discuss what I think I know about vr3 and its relationship with the holoviews and bokeh packages.  I'll keep this as short as possible.

[snip]

--
You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/b3d7a8a2-2d53-4b8e-ac47-a09539dacc0a%40googlegroups.com.