Two outliners with live coding support

[Offray Vladimir Luna Cárdenas]

Hi,

I found this two videos that I think could bring some ideas on the
support for live coding inside Leo, by supporting @cell, and importing
results:

[1] https://youtu.be/dljNabciEGg
[2] http://xiki.org/screencasts/

Cheers,

Offray

[Satish Goda]

xiki looks interesting. Will try it out on the weekend.

[Edward K. Ream]

Two superb demos. Many thanks for sharing them. I love the light-weight, nimble approach in each.

Imo, these kinds of "workarounds" (to not using Leo) probably explain why Leo isn't used more.

I'll study both demos thoroughly. It's been a long time since I saw something that showed features not easily duplicated in Leo.  Now we all have many to chew on.

Edward

[Edward K. Ream]

On Tue, Jan 17, 2017 at 4:21 AM, Edward K. Ream <edre...@gmail.com> wrote:
 

It's been a long time since I saw something that showed features not easily duplicated in Leo.  Now we all have many to chew on.

​The emacs demo is the first time I have seen org-mode headlines​

 

​"properly" used as functional meta-data as in Leo's @x conventions. Furthermore, the hidden "properties" section seems more flexible/nimble that Leo's directives.

Both demos are first real challenge to Leo's capabilities I have ever seen. No, they don't have clones, but they aren't essential, are they?  One can imagine a literate devops script that would simulate the cff command.

I am happy about all this.  It means that Leo has serious competition. This kind of competition is healthy.  It should spur us all on.

Edward

[Offray Vladimir Luna Cárdenas]

Hi,

Now that I'm making my own prototypes, I try to bring inspiration for several places. Firsts inspiration sources for my prototypes were mind mapping, Leo, IPython and Smalltalk as apps and Yaml, markdown, txt2tags, dokuwiki as markups/formats. These days I found particularly good inspiration on Strange Loop conferences (mostly on functional programming and technologies), in video games[1][2][2a] (despite of not being a gamer myself, but I'm starting to play more as a result) and Live coding [3][4] and strangely... movies and video essays.

[1] https://duckduckgo.com/?q=game+makers+toolkit+blow&t=ffsb&atb=v47-3__&ia=videos&iax=1&iai=2zK8ItePe3Y
[2] https://duckduckgo.com/?q=Jonathan+blow+deep+work&t=ffsb&atb=v47-3__&ia=videos&iax=1&iai=d0m0jIzJfiQ
[2a] https://www.youtube.com/watch?v=Fy0aCDmgnxg&feature=youtu.be
[3] https://duckduckgo.com/?q=sonic+pi+live+coding&t=ffsb&atb=v47-3__&ia=videos&iax=1&iai=J8Dd2SIAWJw
[4] https://duckduckgo.com/?q=sonic+pi+live+coding&t=ffsb&atb=v47-3__&ia=videos&iax=1&iai=rnCE7hxNGXw

I think that all this different sources for inspiration on digital artifacts can help in the crosspollination of ideas and hopefully some of them will be back onto Leo. In my case, there is still a long path to walk to express my ideas in digital artifacts and, of course, inspiration doesn't mean implementation, but these sources start to be part of some subliminal aesthetic and "ideas' attic" for the future.

These are interesting times and is nice to see the this vitality on Leo.

Cheers,

Offray

[Offray Vladimir Luna Cárdenas]

Hi,

On 17/01/17 05:57, Edward K. Ream wrote:

On Tue, Jan 17, 2017 at 4:21 AM, Edward K. Ream <edre...@gmail.com> wrote:
 

It's been a long time since I saw something that showed features not easily duplicated in Leo.  Now we all have many to chew on.

​The emacs demo is the first time I have seen org-mode headlines​

 

​"properly" used as functional meta-data as in Leo's @x conventions. Furthermore, the hidden "properties" section seems more flexible/nimble that Leo's directives.

I think so. @-directives were my inspiration for Grafoscopio "node tags", with let me to easy embed live coding playgrounds inside the notebook. The implementation is clumsy in my case, but I have found that having a different place for such tags and properties (like node links) decreased the code complexity that trying to search for @ in the headers, or in the body and interface looks better: the presence of a particular tag/meta-data could be illustrated with a particular icon or visual remark.  (I still use "%keywords" for extending markdown with my own emergent markup).

Both demos are first real challenge to Leo's capabilities I have ever seen. No, they don't have clones, but they aren't essential, are they?  One can imagine a literate devops script that would simulate the cff command.

I haven't used clones in my own Grafoscopio notebooks, despite of using them widely in Leo (mostly because they're not yet implemented! :-P). But for live coding, they don't seem a first necessity.

I am happy about all this.  It means that Leo has serious competition. This kind of competition is healthy.  It should spur us all on.

Edward

I share your happiness. Interesting times ahead!

Cheers,

Offray

[Edward K. Ream]

On Tuesday, January 17, 2017 at 4:57:22 AM UTC-6, Edward K. Ream wrote:

It's been a long time since I saw something that showed features not easily duplicated in Leo.  Now we all have many to chew on.

​The emacs demo is the first time I have seen org-mode headlines​

 

​"properly" used as functional meta-data as in Leo's @x conventions. Furthermore, the hidden "properties" section seems more flexible/nimble that Leo's directives.

I am just beginning to study all this.  Here are some preliminary notes and ideas:

tl;dr: Leo must support Emacs Babel concepts. Leo could use org-mode file format in .org.leo files.

1. The really cool scripting features in the first demo arise from Emacs Babel. These concepts are entwined with IPython/Jupyter concepts.

A: Feeding the results of one computation to another, possibly with a name.  Similar to @button, but perhaps more flexible.

B: Passing arguments to code blocks.

It will be relatively straightforward to represent and support these in Leo.  One can imagine several possibilities:

- @language name, args  OR
- @args args

2. Visible, usually hidden, properties.

Almost identical to Leo's uA's, but in plain text and more easily accessed, via org-mode drawers. Leo should support something like this. 

The format of drawers suggests that Leo's uA's are over-designed.  As Kent has been suggesting for a long time, uA keys should be plain text.  And uA's should be one-level dicts, not two-level.

3. Putting this together suggests that Leo could use org-mode format for .leo files!  Such files could have the extension .org.leo.  In particular, each node could have a :leo-gnx: drawer.

We could pre-define a ":leo-uas:" drawer, which might suffice to keep uA's unchanged.  But we might prefer to insert uA's into a standard ":properties" drawer instead.  To do this we would have to flatten nested uA dicts into a single set of key/value pairs.

Imo, all these ideas dovetail with the design work related to putting Jupyter cells in Leo.  In fact, I suspect that the Jupyter design itself was influenced by Babel.

Your comments, please.

Edward

[john lunzer]

I only watched the first demo. As you alluded to, I was struck by how similar that workflow looked to Jupyter. It is certainly awesome. 

Edward, I'm glad you are gaining inspiration from it. 

Offray, thank you for sharing! Outliners (mainly Leo) have become essential to my productivity and I feel fortunate having a small community to discuss them with. That type of Live coding inside of an outliner looks like a productivity booster as well.

[Offray Vladimir Luna Cárdenas]

Hi all,

Edward and John is nice to see this crosspollination of ideas and renewed inspiration. Thank you both for the responses.

I think that the core idea of live coding is talking back and forth to computing engines/languages, using ZeroMQ, Babel, Yoton, or similars (I don't know if Babel is based on something that is emacs exclusive). With Grafoscopio, my computing engine is the same available to build and run the outliner (Pharo Smalltalk), so I don't know if the first try should be to make live coding possible, by enabling interactive python nodes inside Leo (which is already running and build on python) and then abstract it for more diverse computing engines/languages.

On simplifying Leo format, I'm all for it. As I said, I have problems remembering what acronyms like gnx, uA p, g, c mean, so I can not go into implementation details here. But org mode, YAML and STON have shown that is possible to have complex outliners with a simple storage format and dedicated, but simple, objects to store node metadata.

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 Thursday, January 19, 2017 at 5:31:41 AM UTC-6, Edward K. Ream wrote:

tl;dr: Leo must support Emacs Babel concepts.

Heh. Thinking about org-mode had me wondering about nodes containing both @language rest and @language python.  What happens if we try execute-script on such nodes?

Oops: #371: execute-script fails when a node contains multiple @language directives.

So org-mode is (temporarily) more capable than Leo in this regard.  Otoh, org-mode does not support @others (it does support noweb section refs.)  More importantly, org-mode does not support automatic untangling.  That is, org-mode can not update an .org file using changes in corresponding "external" files. In effect, everything in an org-mode file works like @nosent.  No @auto, @clean, @file, etc.

EKR