Re: Leo and Jupyter

On Tue, Mar 31, 2020 at 1:03 PM Thomas Passin wrote: I don't see the point of working with Jupyter/ipython in Leo unless we can > actually make use of Leo's strengths. > I agree. Last year we reached consensus that embedding Leo into emacs or vim is a bad idea. Similar logic applie

Re: Leo and Jupyter

On Tue, Mar 31, 2020 at 10:44 AM 'tfer' via leo-editor < leo-editor@googlegroups.com> wrote: > There is another option we could consider, rather than full juypter stuff, > just add an Ipython console tab to the log pane. Though not as sexy as > Juypter, it has most of its guts, is embed-able,

Re: Leo and Jupyter

e > version. > The thing is, I don't see the point of working with Jupyter/ipython in Leo unless we can actually make use of Leo's strengths. Otherwise, Jupyter notebooks are very good, highly developed, and have many features (like their kernels for other languages and widgets) that we

Re: Leo and Jupyter

There is another option we could consider, rather than full juypter stuff, just add an Ipython console tab to the log pane. Though not as sexy as Juypter, it has most of its guts, is embed-able, and has a qt-console version. -- You received this message because you are subscribed to the

Re: Leo and Jupyter

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

Re: Leo and Jupyter

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 > <https://docs.bokeh.org/en/latest/docs/user_guide/jupyter.html&

Re: Leo and Jupyter

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 *o

Re: Leo and Jupyter

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 plot

Re: Leo and Jupyter

act >>> 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 J

Re: Leo and Jupyter

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

Re: Leo and Jupyter

y 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

Leo and Jupyter

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

Re: The design of Leo+Ipython+Jupyter+Lit-computing

Looks like it works pretty much as expected, if you know the right classes to use. I inserted a QML view into a regular PyQt container, no problem. The view was a QDeclarativeView imported from PyQt4.QtDeclarative. I don't know if they have all the widgets we'd want to use as QDeclaratives

Re: The design of Leo+Ipython+Jupyter+Lit-computing

On Sun, 11 Mar 2018 07:05:54 -0700 (PDT) Thomas Passin wrote: > I haven't worked on anything much in-browser since before html5 came > out. So I didn't know anything about "~=", for example. Even then I > tried to only work with the simpler constructs (both javascript and >

Re: The design of Leo+Ipython+Jupyter+Lit-computing

I haven't worked on anything much in-browser since before html5 came out. So I didn't know anything about "~=", for example. Even then I tried to only work with the simpler constructs (both javascript and css), so I probably wouldn't have used that particular construct anyway. On Saturday,

Re: The design of Leo+Ipython+Jupyter+Lit-computing

On Sat, 10 Mar 2018 18:46:12 -0800 (PST) Thomas Passin wrote: > Do you happen to know if it's feasible to use QML widgets in Leo? I > don't know either Qt or QML, but much of the PyQt code I see in Leo > looks very painful, a steep learning curve to climb. I remember when

Re: The design of Leo+Ipython+Jupyter+Lit-computing

Do you happen to know if it's feasible to use QML widgets in Leo? I don't know either Qt or QML, but much of the PyQt code I see in Leo looks very painful, a steep learning curve to climb. I remember when I wrote my Matplotlib graphics plotting and calculator program, finding out how to do

Re: The design of Leo+Ipython+Jupyter+Lit-computing

On Sat, 10 Mar 2018 17:41:47 -0800 (PST) Thomas Passin wrote: > If I could step in here some months later, and move to a higher level > of conversation, I think that there are several levels of engagement > with Jupyter that we could contemplate. I have a long term goal of

Re: The design of Leo+Ipython+Jupyter+Lit-computing

is, we want to keep tree-to-notebooks process in > the back of our mind as we think about Leo trees. > > *The Jupyter design* > > The jupyter notebook handles cells in a simple, intuitive manner as > follows: > > 1. Running a code cell produces output *in that cell*.

Re: #561: Please explain why making Leo a jupyter client is important

On Tue, Oct 31, 2017 at 2:03 PM, David Szent-Györgyi wrote: > On Sunday, October 29, 2017 at 6:02:35 PM UTC-4, Offray Vladimir Luna > Cárdenas wrote: >> >> Collaboration could be done as a desktop app with the proper support for >> Jupyter kernels with ZeroMQ. As for the

Re: #561: Please explain why making Leo a jupyter client is important

On Sunday, October 29, 2017 at 6:02:35 PM UTC-4, Offray Vladimir Luna Cárdenas wrote: > > Collaboration could be done as a desktop app with the proper support for > Jupyter kernels with ZeroMQ. As for the Python/Web/Javascript > integration, Dash seems pretty interesting and Flask is a minimal

Re: #561: Please explain why making Leo a jupyter client is important

Reading your responses I noticed my own mistake: > - Separate code from outputs. One of the main strengths for Leo, combining code and results into the same document, is also one of its main limitations. ​ I meant " One of the main strengths for **Jupyter**, combining code and results into

Re: #561: Please explain why making Leo a jupyter client is important

. Leo could be a better Lab for Jupyter that JupyterLab. Leo has a superior DOM for exploratory computing [1]The main issue here is the use of widgets that are thought for the web/browser inside a desktop app. Anyway making the bridge with the Jupyter kernel seems the first step in such direction. >

Re: #561: Please explain why making Leo a jupyter client is important

store and refer to previous calculations. This is done know with the IPython kernel, but I don't mind if there is an alternative way. Other thing I would like to have is code completion a la IPython. > > 2. After their work is done, we provide a way of writing /the work > done in Leo/ to a

Re: #561: Please explain why making Leo a jupyter client is important

On Fri, Oct 27, 2017 at 2:35 PM, Jose Gonzalez wrote: > I think it's also about building on Jupyter concepts as reproducible > literate programming platform, not just cloning its current functionality > ​I agree. Imo, a complete script is the ultimate in "reproducible".

Re: #561: Please explain why making Leo a jupyter client is important

I think it's also about building on Jupyter concepts as reproducible literate programming platform, not just cloning its current functionality See it as an alternative to the JupyterLab application (https://channel9.msdn.com/Events/PyData/Seattle2017/BRK11), reusing the same capabilities from

Re: #561: Please explain why making Leo a jupyter client is important

On Thu, Oct 26, 2017 at 8:51 AM, Terry Brown wrote: > > > Does this vision match yours? Here are some initial thoughts. > > My thoughts, which include a lot of groundless assumptions about how > Jupyter works, would be that we have a new node type: > ​[big snip] Thanks

Re: #561: Please explain why making Leo a jupyter client is important

> Does this vision match yours? Here are some initial thoughts. My thoughts, which include a lot of groundless assumptions about how Jupyter works, would be that we have a new node type: @jupyter jupt://127.0.0.1:8123/some/jupyter/protocol/thing or possibly just @jupyter short_name with

Re: #561: Please explain why making Leo a jupyter client is important

t Jupyter advances will make embedding the Jupyter console into Leo more straightforward. The sources for the Qt Console are now at: https://github.com/jupyter/qtconsole. The organization is different from what I (dimly) remember, and at first glance it appears more flexible. It's easy to run a st

Re: #561: Please explain why making Leo a jupyter client is important

w directly in the body pane? Previous investigates indicate that that might be quite difficult, even given the source code for the console. Alternatively, the user could mark some body text (say @jupyter) as input to Jupyter. Leo would then direct the output to a "jupyter capable" vr-pane. But

Re: #561: Please explain why making Leo a jupyter client is important

d? >> >> ​More importantly, let's assume that the Jupyter server/kernels *do* >> provide great capabilities. I assume that the Jupyter notebook in the >> browser is only one way to access these capabilities. How would Leo >> as a Jupyter client work? > I think that's

Re: #561: Please explain why making Leo a jupyter client is important

t's assume that the Jupyter server/kernels *do* > provide great capabilities. I assume that the Jupyter notebook in the > browser is only one way to access these capabilities. How would Leo > as a Jupyter client work? I think that's where we were heading in this thread: https://groups.googl

Re: #561: Please explain why making Leo a jupyter client is important

to access these capabilities. How would Leo as a Jupyter client work? 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.

Re: #561: Please explain why making Leo a jupyter client is important

On Wed, Oct 25, 2017 at 8:57 AM, Terry Brown wrote: ​> ​ > So what, exactly, does dealing with the jupyter > ​ ​ > server add to Leo? > > ~100% of the computational power of Jupyter. > ​ [big snip] > ​Where are these capabilities summarized? ​ I wasn't really very

Re: #561: Please explain why making Leo a jupyter client is important

ever emulate a worthwhile amount of that though. The little I have used Jupyter though, I wasn't really very impressed with its interface. I think it has some limited support for hierarchy, but nothing like Leo. So the primary benefit of #561 is bringing all the power of Jupyter to Leo users, but

#561: Please explain why making Leo a jupyter client is important

I really don't understand the intent behind #561 . I've used the jupyter notebook enough to know that the server can show the notebook, and can evaluate expressions, in python, or other languages if "kernels" for those languages exist.

Re: The design of Leo+Ipython+Jupyter+Lit-computing

On Tuesday, January 10, 2017 at 12:14:44 PM UTC-5, Offray Vladimir Luna Cárdenas wrote: I would give priority to @cell directive and interaction with (I)python > kernels (maybe via yoton), even if other @-directives for the notebook are > not supported at the beginning. > I agree. >

Re: The design of Leo+Ipython+Jupyter+Lit-computing

Hi, Thanks Edward for your rational and calm answer, even when such attempts to diminish the quality of conversation or new directions arise. Cheers, Offray On 10/01/17 18:08, Edward K. Ream wrote: On Tue, Jan 10, 2017 at 1:23 PM, Mike Hodson >

Re: The design of Leo+Ipython+Jupyter+Lit-computing

On Tue, Jan 10, 2017 at 1:23 PM, Mike Hodson wrote: I must ask, with all this extending to great big new things, all I've > wanted from Leo for over a year now is the ability for it to save a file > without causing the entire user interface to redraw itself. > ​The redraw

Re: The design of Leo+Ipython+Jupyter+Lit-computing

for this?  https://github.com/leo-editor/leo-editor/issues Cheers -Terry From: Mike Hodson <myst...@gmail.com> To: leo-editor@googlegroups.com Sent: Tuesday, January 10, 2017 12:23 PM Subject: Re: The design of Leo+Ipython+Jupyter+Lit-computing I must ask, with all this ext

Re: The design of Leo+Ipython+Jupyter+Lit-computing

No idea. You could open a new thread on that one with specific details. See you there ;-). Cheers, Offray On 10/01/17 13:23, Mike Hodson wrote: I must ask, with all this extending to great big new things, all I've wanted from Leo for over a year now is the ability for it to save a file

Re: The design of Leo+Ipython+Jupyter+Lit-computing

I must ask, with all this extending to great big new things, all I've wanted from Leo for over a year now is the ability for it to save a file without causing the entire user interface to redraw itself. how hard is it to decouple the UI from the gears behind it, vs adding all this new cruft? --

Re: The design of Leo+Ipython+Jupyter+Lit-computing

Hi, On 10/01/17 12:14, Offray Vladimir Luna Cárdenas wrote: For example I have some @icell (for interactive cell) and Leo presumes that the contents are python and let them to be executed with a shortcut and to import the output into the cell (defining another @language inside the @icell

Re: The design of Leo+Ipython+Jupyter+Lit-computing

Hi, On 10/01/17 02:55, Edward K. Ream wrote: [...] *New directives* *@jupyter-notebook*: explicitly denotes a notebook. All descendants are IPython cells. Useful when converting a Leo outline to one or more Jupyter notebooks. *@cells*: All descendants are IPython cells. *@cell*: A

Re: The design of Leo+Ipython+Jupyter+Lit-computing

On Tuesday, January 10, 2017 at 9:56:48 AM UTC-5, Edward K. Ream wrote: Leo's existing infrastructure is already remarkably useful. > As a further example, Leo's uA's easily suffice to hold all data in .ipynb files, which have .json format. EKR -- You received this message because you are

Re: The design of Leo+Ipython+Jupyter+Lit-computing

On Tuesday, January 10, 2017 at 2:55:34 AM UTC-5, Edward K. Ream wrote: > *Summary* > 1. New Leo directives will designate subtrees as containing IPython > *cells*. > ... > > 2. Leo's existing @language directives will indicate the type of cell. > Leo's existing infrastructure is already

The design of Leo+Ipython+Jupyter+Lit-computing

. There must be some way of converting (parts of) Leo outlines to a *list* of .ipynb files. There is considerable room for creativity in this conversion process. That is, we want to keep tree-to-notebooks process in the back of our mind as we think about Leo trees. *The Jupyter design* The jupyter