On 26/10/17 05:45, Edward K. Ream wrote:
> On Wed, Oct 25, 2017 at 12:06 PM, Offray Vladimir Luna Cárdenas
> <[email protected] <mailto:[email protected]>> wrote:
>
>
> I have updated #561 to clarify the rationale behind this proposal and
> include some links.
>
>
> Thanks for this. The link to the Jupyter messaging protocol
> <https://jupyter-client.readthedocs.io/en/latest/> was most helpful.
Yes. It was there originally, but I think that with other links it gets
more context.
> As I understand it, you idea is quite simple. It has two parts:
>
> 1. Using the Jupyter kernel, we allow people /to do in Leo/ what they
> might otherwise do in the Jupyter notebook itself.
Yes. What I want to bring to Leo is interactivity. The ability to do
calculations on the fly and to have a persistent place where I can 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 Jupyter notebook (.ipynb) file. This is similar,
> but not the same as, using Leo's existing .ipynb writer.
I really don't care that much about .ipynb export, as I have said, Leo
has a pretty more powerful DOM and import/export to .ipynb could be
regarded as support for popular (but inferior, ;-)) DOM formats. As said
in the notebook format link on #561:
"""
Notebooks consist of a *linear sequence of cells*. There are four basic
cell types:
* *Code cells:* Input and output of live code that is run in the kernel
* *Markdown cells:* Narrative text with embedded LaTeX equations
* *Heading cells:* 6 levels of hierarchical organization and formatting
* *Raw cells:* Unformatted text that is included, without
modification, when notebooks are converted to different formats
using nbconvert
"""
Leo already surpassed that, since its conception. A whole book and other
complex works can be hold inside a single Leo tree. You can't do that
with a single ipynb file. I have made my own exploration of this with
Grafoscopio ( http://mutabit.com/repos.fossil/mapeda/ ) and such
features were inspired by Leo DOM. I think is time to make the
advantages of Leo more prominent by bridging the advantages of such DOM
with the advantages of interactive computing.
>
> Does this vision match yours?
Mostly ;-).
> Here are some initial thoughts.
>
> #1 above is non-trivial. As I understand it, the most important part
> of the messaging protocol, as far as Leo is concerned, is the client -
> communicating with kernels
> <https://jupyter-client.readthedocs.io/en/latest/api/client.html>
> part. The execute, execute_interactive, complete, inspect and history
> messages have implications for users' work flow.
>
> Must Leo emulate Jupyter's QtConsole window 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 perhaps direct emulation of Jupyter's QtConsole
> in the body pane might be preferable, no matter what the
> implementation cost.
>
I don't know if 1 can be implemented in another simpler way (you told in
another thread that 20 lines of code will bring interactive computation
capabilities to Leo). What I'm advocating is a way of making Leo more
interactive. Seems that bridging with Jupyter/Ipython kernel is the way
to go. I wonder which is the minimal experiment that can be deliver
*soon* into that front.
Cheers,
Offray
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
