The joys of coming back to Leo

[Offray Vladimir Luna Cárdenas]

Hi,

Leo has a special place in my heart and also the community around of it, and has been and important source of inspiration in the creation of my own outliner, Grafoscopio, which is Pharo based instead of using Python. As I drifted away from Python and started to immerse myself into live coding and Pharo and Grafoscopio, I explored other outliners (Doom Emacs) and decreased my usage of Leo, mainly because of my interest in live coding and self-referential meta-systems is better reflected in the Pharo ecosystem. But that doesn't change I think that Leo is a superb piece of inspiring software with practical consequences.

For example, when I need to write something quick, deconstruct complex/interesting source code files, Leo is always my place to go. Its shortcuts/GUI are ingrained in me. They fit the way I like to approach complex text and to see it unfold its complexity as I de/re-construct it. Recently, for example, I needed to to a 3000 words proposal in short time. And with Leo's help, I have it done in almost all 2 days. Even the proposal showcased Leo as it was used to write the proposal to illustrate "the fractality of writing" when tools like Leo are used to blur the distinction between prose/code and document/program. Here it is:

It's good to know that Leo keeps evolving and it's being maintain and also the explorations coming with the VS code interface.

By the way I have seen some comments about Rust and how it over emphasizes security and I thought about Nim, which, in my early explorations so far, seems a good balance between speed, meta programming and easiness, with ideas taken from Python, Anda and Modula. Maybe Nim would inspire aldo explorations to come.

Cheers,

Offray

[Edward K. Ream]

On Wed, Feb 23, 2022 at 7:40 AM Offray Vladimir Luna Cárdenas <off...@riseup.net> wrote:

Leo has a special place in my heart and also the community around of it, and has been and important source of inspiration in the creation of my own outliner, Grafoscopio, which is Pharo based instead of using Python. As I drifted away from Python and started to immerse myself into live coding and Pharo and Grafoscopio, I explored other outliners (Doom Emacs) and decreased my usage of Leo, mainly because of my interest in live coding and self-referential meta-systems is better reflected in the Pharo ecosystem. But that doesn't change I think that Leo is a superb piece of inspiring software with practical consequences.

Thanks for these kind words. In your opinion, what would it take to add live coding and better self-referencial features to python?

Edward

[Edward K. Ream]

On Wednesday, February 23, 2022 at 12:14:18 PM UTC-6 Edward K. Ream wrote:

> what would it take to add live coding and better self-referential features to python?

pylivecodingis one answer. I am going to take a look.

Edward

[Edward K. Ream]

On Wednesday, February 23, 2022 at 12:42:02 PM UTC-6 Edward K. Ream wrote:

>> what would it take to add live coding and better self-referential features to python?

> pylivecoding is one answer. I am going to take a look.

pylivecoding uses reload, which imo has no chance of working in general. Instead, live code almost surely must be done at the byte-code/interpreter/gc level.

Years ago, I remember reading about a fundamental smalltalk interpreter opcode that makes live coding possible, but a brief google search hasn't turned up anything. Offray, can you point me in the right direction?

Edward

[Offray Vladimir Luna Cárdenas]

Hi Edward,

I don't know abut pylivecoding until now, but I can tell you that  its author was a pretty active member of the Pharo community and made some introductory tutorials to it and projects bridging Pharo, Blender and Python[1], so I can see the traces of a Smalltalk inspired live coding environment.

[1] https://github.com/kilon

Neither I know about the internals of Python enough to advice a possible route, but I have experience that a good introduction to live coding for the general population is through its uses in music performances. And I like a lot FoxDot, made in Python [1a][1b][1c]. If I would to approach to live coding from a Python perspective, the programs that have been done to music performance would be my first place, and also they would give a playful moment to make some noise.

[1a]  https://foxdot.org/
[1b]  https://youtu.be/XRNFBZlBeuI
[1c] https://dev.viewtube.io/watch?v=xXNB1BbKY8A

The big difference in experience when live coding is having this engaging and rewarding conversation with dynamic representation of data/code instead of with some memory address or "printed" variable. I think that is something that must have experience first hand, as is difficult to convey such experience in words. I remember you tested Grafoscopio before and Pharo and made some feedback about both (Grafoscopio is still pretty raw, as it was my first "serious program" ever and was a bootstrapper of other parallel researches) and Pharo has not yet a prime documentation experience. But that is changing with the Glamorous Toolkit (GT)[2] and there are a series on it[2a], where Tudor Girba introduce the ideas and toolkit to several individuals (so many of such videos can serve as an starting point). I would particularly advice video #11 as a conversation with a Emacs user/dev and stablish the differences between Emacs and GT and can be also an entry point for those who have worked with self referential outliners (like Leo). Also I have recently published a data story[2c] using Lepiter[2d] notebooks that could help in some way as we have talked before about Leo becoming some kind of data narrative environment for Python (maybe providing outlining functionality beyond what is possible with Jupyter).

[2] https://gtoolkit.com/
[2a] https://invidious.snopyta.org/channel/UClLZHVq_-2D2-iI4rA2O8Ug
[2b] https://invidious.snopyta.org/watch?v=ndUpEq3Jcxs
[2c] https://mutabit.com/repos.fossil/malleable-systems/doc/trunk/wiki/en/malleable-systems-wiki--23fm1.md.html
[2d] https://lepiter.io/feenk/introducing-lepiter--knowledge-management--e2p6apqsz5npq7m4xte0kkywn/

So, just a lot of places to browse, without specific Python implementation advice. But hopefully live coding for music and data storytelling can serve as use cases and/or starting points about the kind of experience that a Leo Powered lived coding environment could provide.

Hope this helps,

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 view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/26a571c3-9ada-4d6d-bcc2-f03f548bc280n%40googlegroups.com.

[tbp1...@gmail.com]

This is all very interesting.  One of the first programming language I worked with (after some Focal, Basic and a bit of PDP-8 asm), a long time ago, was Forth.  Forth's commands are all defined in Forth except for a few primitives and the little Forth VM, including conditionals and loops.  You are always live with the Forth interpreter, so in some ways it's live programming.

Coming back to Leo, I'm working on an application that displays its UI in a log tab.  I've devised a way to re-import all the imports after I make a change to the source code.  So with one button, I can close the tab, reload the imports and changed code, and re-open the tab.  Very fast, that is.  Almost like live programming, although without the ability to inspect variables and have breakpoints (maybe I could use pdb here, but I haven't tried that so far).  Before this, I had to close and restart Leo for any code change, and this reload technique makes developing the code very feasible.