Hi,
On 27/10/17 14:35, Jose Gonzalez wrote: > 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 Jupyter notebooks in terms of computing > power (multilanguage kernels), document integration (markdown + code > cells in the same entity), and ecosystem for all sort of data > visualization (ipywidgets) Agreed. 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. > > Things that "leopyter" could do better in my opinion would come from > better underlying data structures: > - Hierarchical document structure would result in more organized > notebooks (example https://app.notablemind.org/tutorial/) Another one, made in Leo was referred at [1]. Leo could hold book like complex documents. [1] http://mutabit.com/offray/static/blog/output/posts/on-deepness-and-complexity-of-ipython-documents.html > - Causality: Establishing dependencies between cells execution does > not come out of the box in Jupyter, it requires extensions > (https://github.com/stitchfix/nodebook or > https://www.youtube.com/watch?v=5MmXs6m3JcE) . This is essential for > repetitivity and maybe leo graph structure could accommodate this [...] > - Metadata associated with nodes can facilitate multiple views of the > same tree document. This is something I believe is in earlier stages > of use for Jupyter: e.g. offering multiple views of the same document > using cell annotations (e.g. cells as slides > https://github.com/damianavila/RISE) or filtering information > - Broader experience injecting different data-formats into the > document model (ReText, code, ...) than jupyter (with rare cases of > use outside its json format, like https://github.com/rossant/ipymd) > Thanks for the link. Interesting. I have talked about a "Data continuum environment: data <-> queries <-> code <-> visuals <-> docs"[2] where you can go from one to the other to track data provenance and manipulation. I think that the clones (or alike) can be used for this data provenance and to create views of the notebook for different audiences including data provenance. [2] http://mutabit.com/offray/blog/en/entry/panama-papers-1 > > - Links: being able to navigate across multiple notebooks in the same > leo document, which could be useful for keeping a knowledge base > within a notebook repository Something like the Org Mode links for notebooks seems appropriate here. > - 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. The workflow for many people like me is to use the > notebook first to "play with a problem" while documenting/visualizing > results and then mature the code, isolating it to a function/library > for broader use. Having results and code in the same json document > makes this process a little bit more complicated, in many cases > forcing the programmer to refactor the notebook to extract the code > (e.g. > http://opiateforthemass.es/articles/why-i-dont-like-jupyter-fka-ipython-notebook/) > Also, it you want to keep your code under version control, you need to > somehow strip out the results before committing it (e.g. > https://github.com/kynan/nbstripout). I believe leo cloning and three > way merging mechanism introduced for @clean could probably help in > separating notebooks into different physical store files that get > together in edition time My workflow in Grafoscopio is similar. I start with a notebook with some interactive script and when I have something valuable I reify it into a package or class in the System code browser, so my notebooks code become more small, using such recently created packages. Grafoscopio doesn't store any output by default (you need to use a header directive for that), so is more diff friendly according to [3]. Maybe some particular options in Leo could work the same by not storing every output and helping to package callable functionality into subtrees, using Leo's self referential DOM. Something like @button, let's call it "@package" that allows to name a subtree and make it callable inside the interactive document. [3] http://opiateforthemass.es/articles/why-i-dont-like-jupyter-fka-ipython-notebook/ > On the other side, while I certainly like python and use it for many > purposes, it has been a while since I gave up to the idea that python > interfaces would be more solid than web UIs (javascript,...) And I > think leo deep roots on python can be a factor slowing down the > adoption of some of these technologies for the front-end. For literate > programming interfaces there are things that modern javascript and web > technologies do very well: > * Moving to cooperative environments is relatively easier since you > can reuse much on the code in your desktop based application (e.g. > https://github.com/nteract/nteract) to deploy a multiuser server > application (https://github.com/nteract/commuter, https://cocalc.com/). [...] > * Html rendering technologies really play well with advanced > visualization for all sort of multimedia information, from maps > (https://github.com/OpenGeoscience/geonotebook) to scientific data > plots (https://plot.ly/python/getting-started/) > * Web technologies favored frameworks with clear separation of > Model-View to facilitate content production (CSS, etc). This, although > being incorporated to desktop technologies like QML, can facilitate > offering multiple perspectives of the same document as mentioned > before (mindmap, slides, kanban board, etc e.g > https://jaredforsyth.com/treed/) > * Having its roots in the web, javascript has very interesting > capabilities for concurrency, asynchronous operation, etc. Its a good > playground for technologies like functional programming, reactive > interfaces, declarative interfaces, etc. And it keeps growing in > popularity, with many available libraries and potential contributors > > Fortunately, it seems python+javascript have the potential to coexist > and complement each other well, with some examples like dash > https://medium.com/@plotlygraphs/introducing-dash-5ecf7191b503 > 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 library, which should keep things tight. Some time ago I proposed to make the Leo nodes kind of a minimal browser. I don't know how difficult this is, but anyway here are some links for embedded/minimal web browsers and bridging Python with the web: - https://stackoverflow.com/questions/3032666/embedded-web-browser - https://www.fyears.org/2017/02/electron-as-gui-of-python-apps-updated.html - https://pawelmhm.github.io/python/pyqt/qt/webkit/2015/09/08/browser.html 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.
