Re: Leo 6.2.1 released

[Matt Wilkie]

Thanks Edward

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/0a2fcc0a-a6e5-4ff3-957f-bbc4a2aac0d4%40googlegroups.com.

Re: Leo's legacy layout is now the default in version 6.2

[Viktor Ransmayr]

Hello Chris,

Am Sonntag, 29. März 2020 22:55:15 UTC+2 schrieb Chris George:
>
> Here is my recipe for the dock layout that I like. It lets me use a two 
> pane, three pane or even four pane layout that is consistent.
>
> I use KDE NEON which is based on Ubuntu 18.04. I always use the git 
> version and run devel.
>
> 1. cd ~/.leo
> 2. rm -rf db
> 3. rm leo.session
> 4. cd ~/leo-editor
> 5. ./launchLeo.py --global-docks
>
> In myLeoSettings.leo:
>
> @bool minibuffer-find-mode = True
> @bool dockable-log-tabs = True
> @string central-dock-widget = body
> @bool use-vr-dock = True
> @string theme-name = ZephyrDarkThemeLocal
>
> Attached is a screenshot of workbook.leo after arranging how I like, 
> saving the file, and restarting using the recipe above.
>

Thanks a lot for sharing your recipe & settings.

There are a lot of different options to try our in order to re-create the 
default layout of 6.1 in a 6.2 instance of Leo ...

So far I'm still holding back to upgrade my main Leo instance to 6.2!

With kind regards,

Viktor

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/f0917cf6-611c-48a4-a8a5-5e868f1deb47%40googlegroups.com.

Re: Leo and Jupyter

[Edward K. Ream]

On Mon, Mar 30, 2020 at 12:33 PM Thomas Passin  wrote:

>...I don't see a strong reason why better import/export wouldn't be enough
for almost all needs.

This is the kind of thing I'd like to discuss on zoom.

Edward

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS1M3haKus8z7yh0%2BNmGrDarkiYkr9xuUUdLRBsqyrQBxw%40mail.gmail.com.

Re: Leo and Jupyter

[Thomas Passin]

On Monday, March 30, 2020 at 1:04:12 PM UTC-4, Edward K. Ream wrote:
>
> On Mon, Mar 30, 2020 at 11:08 AM Thomas Passin wrote:
>
> > There are at least four ways that Leo could be used with Jupyter:
>
> All four look like the hard way. I tried the hard way several times last 
> year and I'm not eager for more :-)
>
> I am interested in a Jupyter plugin for Leo *only *if it leverages 
> another project's bridge code. Bokeh *might* provide the necessary 
> leverage.  See this page 
> . I'll be 
> investigating this topic next.
>

Well, here's the thing.  How would someone use a Jupyter Notebook with Leo?

1. To look at someone else's notebook.  A notebook viewer would do this job 
at least as well as Leo.
2. To create a notebook in Leo for someone else to look at.  It they don't 
need to be able to execute the code, we could probably serialize VR3's 
output to a notebook as things stand.  No server needed.
3.  To let someone else view and execute the code.  We could probably still 
serialize VR3 subtrees to do this, but it would be harder.  Note that if we 
create the notebook, we don't have to understand or execute the %-magic 
expressions.  They are a convenience, not an essential.  Once it's been 
executed and the notebook saved, it's a tricky question whether or not we 
could use it again in Leo.  For that, we would need a much better importer 
than we have now.
4. To be able to execute code in some language we don't support, like R or 
Stata, but Jupyter has a kernel for.  It would probably be easier to get 
VR3 working with this other language instead.
5.  To be able to execute the code in someone else's notebook.  To do this, 
we would need to be able to handle the %-magic expressions.  Obviously that 
could be done, but I fancy it will take a lot of doing.
6. To work collaboratively with others.  This is one benefit of using a 
Jupyter server, but it would be the hardest to achieve in Leo.  And I don't 
think many of us need to do in very often.

Feel free to add to this list, but so far I don't see a strong reason why 
better import/export wouldn't be enough for almost all needs.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/82cf0079-294f-4fa0-9c25-00d57cd3e06b%40googlegroups.com.

I'd like some zoom tutoring re Bokeh + Jupyter

[Edward K. Ream]

This page  
discusses using Bokeh and Jupyter. I've started Jupyter and worked through 
some examples.

However, the statement show(bkapp) does not seem to do anything. 

I'd like to discuss this page on zoom with whoever might be willing to 
tutor me.

Let's see who might be interested before setting up a meeting.

Edward

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/9b0666b1-a543-4a37-8dd5-7adb0e3aea5e%40googlegroups.com.

Re: Leo and Jupyter

[Edward K. Ream]

On Mon, Mar 30, 2020 at 11:08 AM Thomas Passin wrote:

> There are at least four ways that Leo could be used with Jupyter:

All four look like the hard way. I tried the hard way several times last
year and I'm not eager for more :-)

I am interested in a Jupyter plugin for Leo *only *if it leverages another
project's bridge code. Bokeh *might* provide the necessary leverage.  See this
page . I'll
be investigating this topic next.

Edward

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS0D_O5%2BX%3DHBZaDAeLpCRTgiKJG3XcDkrFRZy3EcCTx%3DkA%40mail.gmail.com.

Re: Leo and Jupyter

[Thomas Passin]

On Monday, March 30, 2020 at 12:15:44 PM UTC-4, Thomas Passin wrote:
>
>
> The questions are: what benefit could be gotten by interfacing Leo and 
> Jupyter, and how complicated would it be? 
>

It seems to me that it would be essential to be able to embed images, 
interactive plots, and the like that are the result of executing the code 
in code cells.  For working with notebooks from Jupyter users, and 
especially if they are to be executed inside Leo, the most apparent matters 
that would need to be dealt with are the following.

1. **Correct handling of Jupyter's "Magic" %-expressions.** Notebooks that 
were started in Leo would not necessarily need to include them, but 
imported notebooks are likely to use them.  This would matter if the 
notebook were re-executed in Leo.

2. **Bundling of execution output data**. Images, interactive graphs, etc.  
These would need to be put into a location, and into a form that Leo's 
renderer can work with.
 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/1599b3e8-fa74-470b-8aa7-ecfb6acde43d%40googlegroups.com.

Re: Leo and Jupyter

[Thomas Passin]

Leo Notebooks are easy to imagine, but they would never gain traction 
because Jupyter is too widespread already.

On Monday, March 30, 2020 at 12:13:04 PM UTC-4, Thomas Passin wrote:

> On Monday, March 30, 2020 at 12:08:15 PM UTC-4, Thomas Passin wrote:
>>
>> On Monday, March 30, 2020 at 12:06:47 PM UTC-4, Thomas Passin wrote:
>>>
>>>
>>> This thread is for discussion about how or whether Leo might be able to 
>>> play with Jupyter.
>>>
>>> I think there are basically four general ways that Leo could interact 
>>> with Leo.  I'll put them in my next post. See what you think.
>>>
>>
>>  There are at least four ways that Leo could be used with Jupyter:
>>
> [snip] 
>
> Since Leo outlines consist of a graph of nodes, it seems likely that the 
nodes could be mapped to Jupyter cells in some manner.  The nodes in a 
subtree could be rendered, for example by Viewrendered3 or a similar but  
specialized plugin.

There is no reason to try to duplicate Jupyter Notebook capabilities as Leo 
outlines, because Leo-format notebooks would never gain traction.  Jupyter 
notebooks are already too widespread.

The questions are: what benefit could be gotten by interfacing Leo and 
Jupyter, and how complicated would it be? 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/3ff81d41-1c39-48fd-a1a6-d67ed5e61df0%40googlegroups.com.

Re: Leo and Jupyter

[Thomas Passin]

On Monday, March 30, 2020 at 12:08:15 PM UTC-4, Thomas Passin wrote:
>
> On Monday, March 30, 2020 at 12:06:47 PM UTC-4, Thomas Passin wrote:
>>
>>
>> This thread is for discussion about how or whether Leo might be able to 
>> play with Jupyter.
>>
>> I think there are basically four general ways that Leo could interact 
>> with Leo.  I'll put them in my next post. See what you think.
>>
>
>  There are at least four ways that Leo could be used with Jupyter:
>
[snip] 

>
> 4. **Build a Jupyter front end client for Leo**.  Presumably this would be 
> in the form of a Leo plugin.  This would have the advantage that the plugin 
> could make use of Jupyter kernels developed for other languages.  Leo would 
> not need to re-invent that wheel. A Jupyter client would not necessarily 
> duplicate everything provided by other clients, such as JupyterLab or the 
> QTConsole.
>

A Jupyter server handles just one kind of cell - those that want code 
executed.  The server executes that code and sends it back to the client.  
The client figures out how to display and persist it.  A server runs a 
"kernel", and different kernels can handle different languages.  If you 
want Python, you use a Python kernel.  If you want R, you use an R kernel.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/00ad3d9f-d28a-4461-b62f-3f9335944515%40googlegroups.com.

Re: Leo and Jupyter

[Thomas Passin]

On Monday, March 30, 2020 at 12:06:47 PM UTC-4, Thomas Passin wrote:
>
>
> This thread is for discussion about how or whether Leo might be able to 
> play with Jupyter.
>
> I think there are basically four general ways that Leo could interact with 
> Leo.  I'll put them in my next post. See what you think.
>

 There are at least four ways that Leo could be used with Jupyter:

1. **Import a Jupyter notebook into Leo**.  A notebook could be viewed and 
rendered in Leo.  It is not clear why this would be better than using a 
notebook viewer program, although Leo might make navigation between cells 
easier than with most other programs.  Rendering these notebooks in Leo 
would be desirable for good readability.  It could be done with a 
modification to Viewrendered 3, or something similar.

2. **Export a Leo tree to a Jupyter notebook**.  If Leo could export a tree 
to a Jupyter-compatible notebook, then work that was done in Leo could be 
shared with others, and the well-developed software that already exists to 
view and author notebooks could be used with these Leo-originated 
notebooks.  Exporting would play a role similar to creating Sphinx 
documents from a Leo tree - it would be a one-way sharing of the rendering 
and execution results with others.

3. **Combine importing and exporting**.

4. **Build a Jupyter front end client for Leo**.  Presumably this would be 
in the form of a Leo plugin.  This would have the advantage that the plugin 
could make use of Jupyter kernels developed for other languages.  Leo would 
not need to re-invent that wheel. A Jupyter client would not necessarily 
duplicate everything provided by other clients, such as JupyterLab or the 
QTConsole.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/d387deab-4b78-4bb6-91a6-8fc3a8f9b353%40googlegroups.com.

Leo and Jupyter

[Thomas Passin]

Users of Leo who also know about Jupyter and Jupyter notebooks sometimes 
see a resemblance.  Now that the Viewrendered3 plugin is working (though 
still a beta version), it is possible to render code and the resulting text 
and plots in the same node, which looks even more like Jupyter.  Leo 
already has a limited ability to import and export in Juypter Notebook 
format.

Jupyter Notebooks have become a widespread way to share scientific work in 
a way that allows for immediate duplication of the calculations.  The 
Jupyter system is especially strong at creating graphical, even interactive 
plots that embed themselves right into the notebook.

This thread is for discussion about how or whether Leo might be able to 
play with Jupyter.

I think there are basically four general ways that Leo could interact with 
Leo.  I'll put them in my next post. See what you think.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/8b386c05-83d0-40b3-bcac-c2ab22b0442b%40googlegroups.com.

Re: About VR3, holoviews and bokeh

[Edward K. Ream]

On Mon, Mar 30, 2020 at 8:16 AM Thomas Passin  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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS2k8cL%3DMvsbrJGdtrDRgdZNo-tog%2BQ0BByt8-2STbfk7w%40mail.gmail.com.

Leo 6.2.1 released

[Edward K. Ream]

It's here on 
GitHub. This release adds the manifest needed for `pip install leo`.

I'll wait a day or three before announcing this release widely. Please 
report any problems.

Edward

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/e633004a-40a5-48a9-87ba-5756d0a0cd8b%40googlegroups.com.

Re: About VR3, holoviews and bokeh

[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.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/e12c1d17-8e2c-4289-b592-077e62d8c9f1%40googlegroups.com.

Re: About VR3, holoviews and bokeh

[Edward K. Ream]

On Mon, Mar 30, 2020 at 7:21 AM Thomas Passin  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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS0uCq2bJHsieGg29eLc7foDqEq0Qzn%3D4qqj5bPqhd_JUQ%40mail.gmail.com.

Re: About VR3, holoviews and bokeh

[Edward K. Ream]

On Mon, Mar 30, 2020 at 7:34 AM Thomas Passin  wrote:

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

Excellent.

Edward

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS3Ya714yR%2BKNn8POJ%2BgLtszz7EFTR30oT6f0-PDGgtP-A%40mail.gmail.com.

Re: About VR3, holoviews and bokeh

[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]
>

-- 
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+unsubscr...@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.

Re: About VR3, holoviews and bokeh

[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?

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/9adaa5ed-5dfb-489a-b95a-2642b2dbc7f2%40googlegroups.com.

Re: About VR3, holoviews and bokeh

[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.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/1aae8960-ccd2-4853-94a8-3f7adfb1d105%40googlegroups.com.

Re: Proposed change to setup.py

[Thomas Passin]

On Sunday, March 29, 2020 at 10:29:36 PM UTC-4, Matt Wilkie wrote:
>
>
> b) merge early, merge often: as in daily. This way any given upstream 
> change can (usually) be inspected and accepted/changed in small easy to 
> understand pieces. Use an interactice tool like WinMerge or Kmeld to do the 
> merging. (WinMerge has been easiest for me to understand, the keyboard 
> shortcuts make sense to me.)
>

Thanks for your advice, Matt.  I really don't want to spend time doing 
daily merges if I can avoid it.  And I'll look at Winmerge.  I think my 
ideal would be to create a branch in my fork that would only contain the 
files I'm working on.  But Git (or at least Github desktop) doesn't seem to 
work that way.  Otherwise I suppose that frequent updates from upstream 
would be the best way to go.
 

> Really though if what you're doing now is successful keep doing it! VR3 is 
> awesome. Better you spend your precious attention on building cool things 
> like that than figuring out git arcana. ;-)
>

Well, thanks!  Though I feel that I'm just resurrecting Peter Mills's work 
and giving it a few tweaks.
 

>
> -matt
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/5fad1849-6dc6-4a3c-a467-35bb2ec38b0b%40googlegroups.com.

Re: New installation log

[Thomas Passin]

On Sunday, March 29, 2020 at 10:07:37 PM UTC-4, Matt Wilkie wrote:
>
>
> OTOH, I have installed as a user on Linux distros many times using pip 
>> install, and never had a problem. Never needed to consider using sudo.
>>
>
> Did/do you need to pass `--user` flag? 
>
> pip install --user foobaz
>

I don't think I ever used it. For sure I didn't use it when I have 
installed Leo and its dependencies.  I always used the python installations 
that came system-installed.  The systems were usually Mint and Ubuntu.   
Maybe that's a good reason for using the system-installed Python and not 
Python you installed outside of the system packaging mechanism.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/23a612df-9d35-44ae-b5a6-87ae84e51293%40googlegroups.com.

Re: About VR3, holoviews and bokeh

[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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/b04baec3-5935-4488-bdff-9b705fb36d87%40googlegroups.com.

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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/d473e49b-6a9e-4739-a39e-76ade32aacbc%40googlegroups.com.
Title: With VR3




  
  
  

  

  
  

  

  

  
  



  
  

Re: New installation log

[Edward K. Ream]

On Sunday, March 29, 2020 at 5:09:38 AM UTC-5, Edward K. Ream wrote:

> I am seriously considering ignoring Anaconda and miniconda in Leo's 
installation instructions:

Belay that. 

Your comments have convinced me that there is no reason to endorse pip, 
Anaconda or miniconda. In effect, these are preferences.

Leo's installation instructions are neutral about these options. I see no 
reason to change them.

Edward

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/fe7e24e6-6d23-44ba-8ad1-6380f80f8851%40googlegroups.com.