Leo + PlantUML workflow

[Satish Goda]

Hello Folks.

Once in a while I rely on UML diagrams to document existing software systems and/or create pictures from loads of technical texts.

http://plantuml.com/

Before Leo, I used to use PyCharm's plantuml plugin (It is a very nice tool built on top of plantuml)

https://plugins.jetbrains.com/idea/plugin/7017-plantuml-integration

But today, I have started using Leo+PlantUML UI to generate my diagrams. Please find the attached image for an example.

I have added some notes and a link to the MIT licensed version of the PlantUml binary at the link below

https://github.com/satishgoda/leo-editor-tutorial/tree/master/workflows/plantuml

Thank you!
Satish.

[Edward K. Ream]

On Wed, Jan 4, 2017 at 11:20 PM, Satish Goda <satis...@gmail.com> wrote:

today, I have started using Leo+PlantUML UI to generate my diagrams. Please find the attached image for an example.

​An excellent integration of @file nodes, PlantUML, a node containing an rst image reference, and the viewrendered plugin.

It should also be possible to use @images node directly. The choice is yours. 

I have added some notes and a link to the MIT licensed version of the PlantUml binary at the link below

https://github.com/satishgoda/leo-editor-tutorial/tree/master/workflows/plantuml

Thank you!

​And many thanks to you for sharing this excellent work flow.

Edward

[Edward K. Ream]

On Wednesday, January 4, 2017 at 11:20:43 PM UTC-5, Satish Goda wrote:

> I have started using Leo+PlantUML UI to generate my diagrams.

I have been thinking of Jupyter Notebooks lately, because they are often used in Deep learning.

By analogy with your UML workflow, I am thinking that there should be an easy way of having Leo support notebooks. Maybe something like @jupyter or @notebook.

The Jupyter Notebook Viewer uses nbconvert, as standard part of the Anaconda distro.  So it should be straightforward to duplicate what the notebook viewer does.

Not sure how this will work out...

EKR

[Satish Goda]

Hello Edward.

I have used Jupyter notebooks sparingly, but I do like their utility and interactivity.

At my workplace last year, I have successfully integrated Pyzo in my team for interactive python debugging and testing workflows.

http://www.pyzo.org/features.html

pyzo is being developed for scientific computing and has borrowed a lot of ideas from Jypyter and other sources. I particularly like the cell based execution (A pyzo editor document can be split up into cells) where you can only execute the cell under cursor. No need to select the text.

As you said, a Leo @jupyter node's children could be executable cells!

[Offray Vladimir Luna Cárdenas]

Hi,

I think that the proper level of granularity for integration between the ideas of Leo and IPython would be at cell level, not at document level. Something like making a cell in IPython become a node in Leo. I have proposed the idea of using services to make the Leo nodes to talk with a Jupyter kernel, to bring live coding to Leo self referential documents. With such integration you could have the best of the both worlds: interactivity of IPython and the self-referential emergent and programmable tree of Leo. I have made an app to explore such ideas (documents as interactive self referential trees) called Grafoscopio (using Pharo instead of Python).

So is nice to see this exploration taking form (interactive IPython cells as Leo nodes, finally!). Hopefully machine learning would be the context to bootstrap such integration.

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 leo-editor+...@googlegroups.com.
To post to this group, send email to leo-e...@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

[Edward K. Ream]

​On Thu, Jan 5, 2017 at 8:48 PM,

​​

Satish Goda <satis...@gmail.com> wrote:

​​I have used Jupyter notebooks sparingly, but I do like their utility and interactivity.

At my workplace last year, I have successfully integrated Pyzo in my team for interactive python debugging and testing workflows.

​I am studying Pyzo right now.  I am super impressed with their python parser and syntax highlighter. The code is brilliantly simple.  Leo has to use this approach. It's much, much faster than Leo's.

Cells are also cool, as is IPython integration.   It should be easy to have Pyzo recognize Leo nodes as cells.  Just treat #+node like ##.

Pyzo is a serious competitor to Leo, and is also an inspiration for Leo.  Indeed, Leo can now longer settle for wimpy IPython integration.  Leo must have an IPython pane, as in Pyzo.  This requires heavy lifting, with yoton, kernels, etc. The details are complex, and I don't understand them yet.

​> ​

As you said, a Leo @jupyter node's children could be executable cells!

​There is a lot going on in my mind about this.  It's not entirely clear what Leo's new gui is going to be like.  This is the important thing at the design level.  If Leo is going to supplement either IPython or Pyzo, it must, in some sense, be as easy to use as they are.

The technical side is also going to be interesting/challenging.  I'm not sure how to proceed. One possibility would be to add some prototyping code to Pyzo.  Or vice versa: add some prototyping code to Leo.

In my mind, this is a super important project.  For me, Leo must support IPython and Jupyter.  Otherwise, Leo can never be main stream.  As a result, this project is worth any amount of work.

Naturally, I won't just start hacking away on code (except for minor prototypes).  The main goal is to support Jupyter notebooks as well as humanly possible.  This goal isn't about code, it's about design.

Many thanks, ​Satish, for this post.  It seems to have come at the perfect time to inspire me, both at the code level and the design level.

All comments welcome, Amigos.

Edward

[Edward K. Ream]

On Thu, Jan 5, 2017 at 9:12 PM, Offray Vladimir Luna Cárdenas <off...@riseup.net> wrote:

I think that the proper level of granularity for integration between the ideas of Leo and IPython would be at cell level, not at document level. Something like making a cell in IPython become a node in Leo.

​Yes, I agree, so far as I understand the implications.​

 

I have proposed the idea of using services to make the Leo nodes to talk with a Jupyter kernel, to bring live coding to Leo self referential documents.

​Perhaps I will be able to understand your idea more fully now that I see that Pyzo already does this, as far as I can tell.​

With such integration you could have the best of the both worlds: interactivity of IPython and the self-referential emergent and programmable tree of Leo.

​This is a good statement of intent.  I don't understand it in detail, but as I have said in another reply, this project is worth any amount of work.

Given the state of Pyzo, it's entirely reasonable, imo, to target something spectacular for Leo in 2017.  And not just a prototype or two.  They should only take a few days/week.  I mean something that will be truly useful for IPython/Jupyter users, without changing either IPython or Jupyter in any way.​

 

I have made an app to explore such ideas (documents as interactive self referential trees) called Grafoscopio (using Pharo instead of Python).

​I am very interested in what you have found.  I understand you prefer Pharo, but any advice you can give that pertains to Python or Pyzo will be most welcome.  In fact, it may be that the design of Grafoscopio will provide import clues/insights into this project.​

So is nice to see this exploration taking form (interactive IPython cells as Leo nodes, finally!). Hopefully machine learning would be the context to bootstrap such integration.

​Heh. I already know enough about machine learning to know that Leo will remain my life's work.  I'm a tool guy, not an entrepreneur.

Having said that, Jupyter notebooks seem to be the Lingua Franca of the academic/scientific world.  This is the world I admire most, and the world in which I am most comfortable.  Leo simply must be a player in that world.

Edward

[Offray Vladimir Luna Cárdenas]

Hi,

Well... My answer went longer that I expected. Fortunately this list is a place for deep/long talk and thought. I tried to provide general ideas to more detailed links on history and demos of the implementation I have now with Grafoscopio. As I said at the end, I hope some crosspollination between projects and ideas. (Longer) Details below :-).

On 06/01/17 12:27, Edward K. Ream wrote:

On Thu, Jan 5, 2017 at 9:12 PM, Offray Vladimir Luna Cárdenas <off...@riseup.net> wrote:

I think that the proper level of granularity for integration between the ideas of Leo and IPython would be at cell level, not at document level. Something like making a cell in IPython become a node in Leo.

​Yes, I agree, so far as I understand the implications.​

 

I have proposed the idea of using services to make the Leo nodes to talk with a Jupyter kernel, to bring live coding to Leo self referential documents.

​Perhaps I will be able to understand your idea more fully now that I see that Pyzo already does this, as far as I can tell.​

I have seen some Pyzo videos and browse the documentation of Yoton and the idea of IDE/Kernel to provide stuff like auto-completion [1] and interactive  "code nodes" in a Leo document would be my first exploration. Can we made a Leo node with python code talk with such kernels via yoton in a similar way to what Pyzo does?

[1] http://yoton.readthedocs.io/en/latest/examples.html#ide-kernel

With such integration you could have the best of the both worlds: interactivity of IPython and the self-referential emergent and programmable tree of Leo.

​This is a good statement of intent.  I don't understand it in detail, but as I have said in another reply, this project is worth any amount of work.

Given the state of Pyzo, it's entirely reasonable, imo, to target something spectacular for Leo in 2017.  And not just a prototype or two.  They should only take a few days/week.  I mean something that will be truly useful for IPython/Jupyter users, without changing either IPython or Jupyter in any way.​

 

For me the key issue of Jupyter is providing a language neutral architecture to build interactive notebooks. That's made by allowing 40+ languages to communicate via ZeroMQ (kind of yoton) with several (language) kernels and render the results in a nice way. This architecture gives you  basically these things: a) code completion (tab with steroids) b) (HTML) rendering of the code/markup cells c) a global namespace of variables usable along the notebook d) dual communications between the cell and the kernel(s): any code cell can send a command to the kernel a get an output cell into the notebook as a result.

Getting Leo nodes communicated with kernels would give a) and d). After that I would address c) and leave the HTML rendering as the last part to perfect. That would give the Jupyter's "live coding" experience priority to bring it into the Leo world. I don't know about yoton's ability to communicate other languages besides Python (like Jupyter's ZeroMQ), but having live coding in Leo would bring the core feature of Jupyter to its users, with all the advantages of Leo, without changing IPython or Jupyter and with support to import notebooks to Leo and exporting it back by flatten the Leo's tree into a "plain" cell sequence of the jupyter's notebook format. I think that Leo documents format and tree metaphor is far superior for exploratory computing that a sequence of flat cells (as I said back on 2012/2013 [2]) and have experience this for myself: with Jupyer you end with the "split pile of files" to cope with emerging complexity or with a long complicated "roll" of input and output cells (kind of the HTML new version of the REPL log)[3]. In fact, Grafoscopio started, at 2014, because I was unable to get the advantages of Leo and IPython into a single/simple experience[4] that is interactive, emergent, structured, self-referential and unified. Now I'm getting closer[5] (demo video in Spanish).

[2] http://mutabit.com/offray/static/blog/output/posts/on-deepness-and-complexity-of-ipython-documents.html
[3] http://mutabit.com/repos.fossil/piamed/doc/tip/Afiche/narrativa.png
[4] http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-initial-progress.html
[5] https://archive.org/details/grafoscopio-demo-corto

I have made an app to explore such ideas (documents as interactive self referential trees) called Grafoscopio (using Pharo instead of Python).

​I am very interested in what you have found.  I understand you prefer Pharo, but any advice you can give that pertains to Python or Pyzo will be most welcome.  In fact, it may be that the design of Grafoscopio will provide import clues/insights into this project.​

In Pharo/Smalltalk programming is done by message passing between objects. So, in a sense I have something like a micro-services architecture granted as an starting point for Grafoscopio (yokon/ZeroMQ alike architecture is a given for all objects). The uniformity of the environment let me embed (compose) interactive playgrounds to support code snippets and live coding inside the document tree (the notebook). My next step is to make the tree exposed to the embedded playgrounds so I can make something like "thisNode chidren computeAll; exportAsHTML" and make the tree completely programmable from inside the tree, and create the global dictionary of notebook's variables. So, in a sense I was starting backwards: providing live coding first to a tree and then make that tree available to any of its code nodes. Leo has already a programmable tree and an excellent document format. What needs to bring is live coding via (yokon /ZeroMQ) services.

So is nice to see this exploration taking form (interactive IPython cells as Leo nodes, finally!). Hopefully machine learning would be the context to bootstrap such integration.

​Heh. I already know enough about machine learning to know that Leo will remain my life's work.  I'm a tool guy, not an entrepreneur.

I'm kind in the middle. I am an academic (in recovery :-P), that is making (digital) tools to understand theoretical stuff and thinks that such bridge can have open civic/social "entrepreneur" opportunities.

Having said that, Jupyter notebooks seem to be the Lingua Franca of the academic/scientific world.  This is the world I admire most, and the world in which I am most comfortable.  Leo simply must be a player in that world.

Edward

Jupyter is appealing to scientist/academics because its idea of computational narratives, ie: scientific prose backed by data+code. Leo can be an important player of the future scenarios Jupyter is looking for, as said in [6]:

"""
The problem the Jupyter project tackles is precisely this intersection:
creating tools to support in the best possible ways the computational
workflow of scientific inquiry, and providing the environment to
create the proper narrative around that central act of computation. We
refer to this as Literate Computing, in contrast to Knuth’s concept of
Literate Programming, where the emphasis is on narrating algorithms and programs. In a Literate Computing environment, the author weaves
human language with live code and the results of the code, and it is the
combination of all that produces a computational narrative.
"""

[6] http://blog.jupyter.org/2015/07/07/project-jupyter-computational-narratives-as-the-engine-of-collaborative-data-science/

Leo has departed critically long time ago from literate programming, and can be an integral part of literate computing. Having a single Leo notebook that contains literate computing for full books, courses, theories, presentations and so on would be a distinctive feature of Leo in the literate computing ecosystem. This is my search with Grafoscopio and hopefully some ideas crosspollination could be returned back to the Leo community.

Cheers,

Offray

[Satish Goda]

My pleasure Edward. I am exclusively using Leo since two months (not even Pyzo/PyCharm) as I am able to document my thoughts and move things around easily (non destructively via clone nodes). The executing of code and its output is something we could address in 2017 with a revised code/execution architecture.

I am also studying thoroughly jupyter/yoton and leo and hopefully I can bring more ideas to the table.

[Edward K. Ream]

On Mon, Jan 9, 2017 at 5:22 AM, Satish Goda <satis...@gmail.com> wrote:

 

I am exclusively using Leo since two months (not even Pyzo/PyCharm) as I am able to document my thoughts and move things around easily (non destructively via clone nodes).

​Glad to hear it!
​

 

The executing of code and its output is something we could address in 2017 with a revised code/execution architecture.

​Yes.  This will be my main focus this year, along with bringing pyzo's syntax coloring, code completion and maybe even debugging code into Leo.​

 

I am also studying thoroughly jupyter/yoton and leo and hopefully I can bring more ideas to the table.

​Excellent.  I too am studying jupyter/yoton.

Edward​