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. > Having compatibility to import and export Jupyter notebooks is important, > but the core concerns should be interactivity "inside" Leo, by making code > nodes behave like code cells. > Yes. A conversation with Rebecca clarified my thinking and allowed this design to flow. The main idea is that I can't change either Jupyter or IPython, so I have to focus on what Leo can do. Import/export is an afterthought. In fact, the proper strategy is to support cells even better than pyzo does. > I imagine some kind of default behavior that keeps you in the flow. 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 will change the kernel for the proper language). > Yes. This behavior is implicit in how Leo handles @language. At any node, there is a default @language in effect, which the @icell (@cell for short) will use. Having this @icell talking with the python/ipython kernel, will bring the > core of live coding experience, > I agree. Part of this "talk" will be receiving results *and* rendering them, pretty much exactly as is done in a Jupyter notebook. This means rendering them in the *same* @icell in such a way that the @icell remains "live". In other words, the user must be able to re-execute the @icell. > even if we use the Leo tree for making other experiments, that are not > properly exported to the jupyter format. > Yes. > For example, I have some Leo scripts to traverse a Leo tree, ignore > "invisible" nodes and export all that to markdown (that was before the > markdown support) to create PDFs with pandoc, all that without referring to > the Jupyter format, just from Leo -> pandoc -> LaTeX -> PDF, but what I was > missing was interactivity on the Leo nodes, that I have with > IPython/Jupyter notebooks. > That is surely the key feature. Interaction with one or more Jupyter kernels is the heart of this feature. In summary: > > The core experience of Jupyter's literate computing is on weaving, in a > document, prose with "live coding", by providing interactive cells. Such > core experience can be bring to Leo by supporting @icell that, with proper > defaults, would made the content of such Leo node behave like an > IPython/Python "code cell", that can talk with a python kernel (or others) > and import the result back to the node. This open a lot of possibilities to > Leo in the scenario of literate computing, to go even beyond of what is > possible with Jupyter now (without damaging compatibility with it), using > Leo's superior programmable tree format and capabilities: You can have > complete books inside a single tree (instead of split in several ipynb > files and directories), you can export directly to PDF/LaTeX/HTML, just by > traversing the tree with your own @directives, or you can go back to > jupyter notebook format when needed. For this, what is needed is to give > priority to @icell and its behavior, to combine the best of both worlds: > interactivity and a self referential programmable tree. > I agree completely. Making @icell work is a major endeavor. It's worth any amount of work. Perhaps yoton will help, but this project must succeed whatever the cost. 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 [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.
