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. On Thursday, February 24, 2022 at 9:53:34 AM UTC-5 off...@riseup.net wrote: > 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 > > > On 24/02/22 7:52, Edward K. Ream wrote: > > 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 <https://github.com/kilon/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 > > -- > 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 > > <https://groups.google.com/d/msgid/leo-editor/26a571c3-9ada-4d6d-bcc2-f03f548bc280n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/dbe2489b-fa1a-47ad-b9c8-415681981d31n%40googlegroups.com.
