What's next, continued

[Edward K. Ream]

I have been working on this post for about a week. The way forward has just become clear:

The work in 2019 will be the foundation for this year's work.

The work in 2020 will focus on bridges between programs.

2019 Retrospective

6.0 Completed the switchover to Python 3. This is a happy development.

6.0 also added support for Qt docks, a prerequisite for several planned projects.

6.1 completed the pyzo_in_leo plugin. I can't recommend this plugin, but it may become valuable this year.

6.2 fixes all serious known bugs. It also uses fstrings throughout Leo's code base, which I think is worth the work.

2020: The year of the bridge

The focus this year will be on relatively simple bridges between various apps and tools.

1. Thomas's recent post re graaljs is a great example. A few lines of code allows Leo to run javascript code from any Leo node.

2. A few days ago I discovered Bokeh. This was an important discovery:

- Bokeh's graphics libraries offer d3 capabilities in python.

The VR (and VR3?) plugins should be able to support Bokeh fairly easily.

- Bokeh's client/server architecture should provide a ready-made bridge to the Jupyter world.

I'll be studying Bokeh in detail.

3. #1235 (neovim) will depend on a bridge between neovim (a neovim plugin) and Leo.

4. #1384 (pyzo) will depend on a bridge between pyzo and Leo.

The pyzo_in_leo plugin should allow Leo to inject bridge code into pyzo itself. Alternatively, the pyzo_in_leo plugin could inject a full plugin architecture into pyzo. We'll see what's better...

Summary

This week I have been wrestling with a sense that last year's work was not particularly valuable. Now I see it will be a firm foundation for this year's work.

The focus of Leo 6.3 will be on relatively simple bridges between Leo and other apps or libraries.

graaljs makes Leo a better platform for javascript development.

Bokeh may be the long-sought bridge between Leo and Jupyter.

Bokeh is built on Tornado. I'll be studying Bokeh, Tornado, yoton and other client/server tools, looking for the best way forward.

This new focus came from becoming clear about what I won't do.  See the Post Script for details.

There are other items on the 6.3 list. #1269 (Improve key handling) is the most ambitious. For now I shall focus on building bridges.

All comments welcome.

Edward

P.S. This new focus is a result of becoming clear about what I won't do:

1. Last year we reached consensus that Leo will remain a desktop app.

2. Rust will remain an interesting sideline. The leo-in-rust branch will contain experiments with the rust language. I have no plans to contribute to this branch at this time.

3. Imo, live coding is a dead end. The cool demos are toys which can not be scaled up:

A: Graphics: Any graphics-based demo could be more easily recreated with a slider that changes the graphics values.

Alternatively, you could just put your graphics code into a Leo node and hit Ctrl-B when you are ready for a new run.

You could create an @button node to rerun the graphics code on every Leo keystroke, but that's just silly. Most of the time you would either get a syntax error or a graph using an intermediate value.

B: Music.  Similarly, a "live" music app would be more usefully coded with sliders.

C. Apps. Changing a large app on the fly is either silly, or dangerous, or both.

I am not going to invest in learning the tools of the Pharo world. Otoh, browsing such tools lead me to Bokeh, so the time was well spent :-)

4. Yesterday I reviewed some of Offray's links re Pharo. The Hyperscope screencast shows how far ahead of its time Hyperscope was.

There are obvious parallels between Leo and Hyperscope.  The Hyperscope links are basically gnx's. Showing them on-screen is pretty geeky. Adding view options to links is even more geeky. Leo's clones are far superior.

Hyperscope's transclusion of links would be one way to do #946. Also, the Hyperscope way is much like #1279. It's not a high priority.

EKR

[Thomas Passin]

On Monday, March 23, 2020 at 9:11:04 AM UTC-4, Edward K. Ream wrote:

I have been working on this post for about a week. The way forward has just become clear:

The work in 2019 will be the foundation for this year's work.

The work in 2020 will focus on bridges between programs.

2. A few days ago I discovered Bokeh. This was an important discovery:

- Bokeh's graphics libraries offer d3 capabilities in python.

The VR (and VR3?) plugins should be able to support Bokeh fairly easily.

VR3 already does in this in a sense - you can run a node with a Bokeh program and output a plot that will render in the system browser.   If you want to embed the graph into a Leo node, a la Jupyter notebooks, that will take some thought to work out.  I have been mulling this over for a while, but not very seriously as yet.

There's also Holoviews, which can use Matplotlib or Bokeh back ends.  It might turn out to be the best way to go, though I don't know anything much about how they accomplish their magic:

http://holoviews.org

Holoviews can already work with Jupyter.  VR3 can execute Holoviews programs that are asked to show the graphic output in a browser.

[Thomas Passin]

On Monday, March 23, 2020 at 8:50:16 PM UTC-4, Thomas Passin wrote:

On Monday, March 23, 2020 at 9:11:04 AM UTC-4, Edward K. Ream wrote:

The VR (and VR3?) plugins should be able to support Bokeh fairly easily.

VR3 already does in this in a sense - you can run a node with a Bokeh program and output a plot that will render in the system browser.   If you want to embed the graph into a Leo node, a la Jupyter notebooks, that will take some thought to work out.  I have been mulling this over for a while, but not very seriously as yet.

Here is a simple Bokeh program that renders the plot in the system browser:

from bokeh.plotting import figure, output_file, show, save

# prepare some data
x = [1, 2, 3, 4, 5]
y = [6, 7, 2, 4, 5]

# create a new plot with a title and axis labels
p = figure(title="simple line example", x_axis_label='x', y_axis_label='y')

# add a line renderer with legend and line thickness
p.line(x, y, legend_label="Temp.", line_width=2)

# Optional - save data to file
# save(p)

# show the results
show(p)

And here's a simple Holoviews program that VR3 executes:

# Following https://github.com/pyviz/holoviews/issues/1819 for how to plot
# without using ipython/Jupyter

import holoviews as hv
hv.extension('bokeh')

# hv.extension('matplotlib') # Alternate back end

# from bokeh.io import output_file, save  # Could save to a file,

# then load into a node.

from bokeh.io import show

xs = range(-10,11)
ys = [100-el**2 for el in xs]

curve = hv.Curve((xs, ys))

renderer = hv.renderer('bokeh')

# For saving to a file:

#renderer.save(curve, 'h1')

plot = renderer.get_plot(curve).state
show(plot)

[Edward K. Ream]

On Mon, Mar 23, 2020 at 7:56 PM Thomas Passin <tbp1...@gmail.com> wrote:

> Here's a simple Bokeh program that VR3 executes: [snip]

Thanks for this. Looks like holoviews/bokeh are just what we need.

I'll be studying them both.

Edward

[Thomas Passin]

On Tuesday, March 24, 2020 at 2:12:39 AM UTC-4, Edward K. Ream wrote:

On Mon, Mar 23, 2020 at 7:56 PM Thomas Passin <tbp1...@gmail.com> wrote:

> Here's a simple Bokeh program that VR3 executes: [snip]

Thanks for this. Looks like holoviews/bokeh are just what we need.

I've been looking at them a little more.  It turns out that using Holoviews with the matplotlib back end, it is easy to save a plot image and show it in a Leo Restructured Text (@rst) node.  Using the Bokeh backend, or using Bokeh itself, you can actually embed the entire interactive plot, using the .. raw directive:

@language rest
.. raw:: html
    :file: lines.html

The first attached png file is a screen capture showing my little Holoview program creating an image and embedding it in the rendered result.  The rendering is by the Viewrendered3 plugin.

You can also embed an interactive Bokeh plot in a Markdown document using an iframe.  The second attached screen capture file shows an example.

[Edward K. Ream]

On Tue, Mar 24, 2020 at 6:20 PM Thomas Passin <tbp1...@gmail.com> wrote:

> ...using Holoviews with the matplotlib back end, it is easy to save a plot and show in in a Leo node.  Using the Bokeh backend, or using Bokeh itself, it's nearly impossible.

> The attached png file is a screen shot showing my little Holoview program creating an image and embedding it in the rendered result.

Thanks!

> The reason it's very hard to do with the Bokeh back end is that Bokeh never actually creates an image file.  It creates an HTML file with javascript instructions for drawing the images.

The VR plugin typically renders by calling w.setHtml(text). Why won't that work with the html file created by Bokeh?

> In Holoview, doing your calculations and making the plot can use either Matplotlib or Bokeh back ends interchangeably, so just use matplotlib and everything will be way easier.

Sounds great. Thanks for your researches.

Edward

[Edward K. Ream]

On Tuesday, March 24, 2020 at 6:20:15 PM UTC-5, Thomas Passin wrote:

It turns out that using Holoviews with the matplotlib back end, it is easy to save a plot image and show it in a Leo Restructured Text (@rst) node.  Using the Bokeh backend, or using Bokeh itself, you can actually embed the entire interactive plot, using the .. raw directive:

@language rest
.. raw:: html
    :file: lines.html

This was a bit confusing for me at first.  lines.html comes from Bokeh's getting started example.

This is also shown in bokeh_in_md.png.

So to make this work, do the following:

1. Copy the example to any Leo node.

    Add the @language and @md section as shown.

2. Open vr3 with the vr3 command.

3. Choose MD from the Default Kind dropdown.

4. Choose Reload.

This executes the code, creates lines.html and shows the plot. Very cool.

After that, a node containing just:

@language rest
.. raw:: html
    :file: lines.html

will show you just the graph, without the code. It's super cool.

I haven't yet figure out how to use holoviews. I copied the code shown, namely:

import holoviews as hv
import holviews.util
hv.extension('matplotlib')
xs = range(-10, 11)
ys = [100-z**2 for z in xs]

curve = hv.Curve((xs, ys))
plot = renderer.get_plot(curve).state
hv.save(curve, 'curve.png')

Now I'm stuck. Neither reload nor execute creates curve.png.

What should I do?

Edward

[Edward K. Ream]

On Wednesday, March 25, 2020 at 6:33:23 AM UTC-5, Edward K. Ream wrote:

I haven't yet figure out how to use holoviews. I copied the code shown, namely:

import holoviews as hv
import holviews.util
hv.extension('matplotlib')
xs = range(-10, 11)
ys = [100-z**2 for z in xs]

curve = hv.Curve((xs, ys))
plot = renderer.get_plot(curve).state
hv.save(curve, 'curve.png')

Now I'm stuck. Neither reload nor execute creates curve.png.

To answer my own question, I should just execute this script, with Ctrl-B.  However, renderer isn't defined, and isn't needed, so I just deleted the line `plot = renderer.get_plot(curve).state`.




But I'm still having troubles. Importing matplotlib directly does work, but the last line here throws an exception:





import holoviews as hv
import holoviews.util
hv.extension('matplotlib')

Here is the exception:





WARNING:param.notebook_extension: Holoviews matplotlib extension could not be imported, it raised the following exception: FileNotFoundError('[WinError 2] The system cannot find the file specified')
exception executing script


Traceback (most recent call last):

  File "c:\leo.repo\leo-editor\leo\core\leoCommands.py", line 633, in executeScript
    c.executeScriptHelper(args, define_g, define_name, namespace, script)

  File "c:\leo.repo\leo-editor\leo\core\leoCommands.py", line 672, in executeScriptHelper
    exec(compile(script, scriptFile, 'exec'), d)

  File "C:/leo.repo/leo-editor/leo/test/scriptFile.py", line 6, in <module>
    hv.extension('matplotlib')

  File "C:\Users\edreamleo\Anaconda3\Lib\site-packages\param\parameterized.py", line 2812, in __new__
    return inst.__call__(*args,**params)

  File "C:\Users\edreamleo\Anaconda3\Lib\site-packages\holoviews\ipython\__init__.py", line 116, in __call__
    super(notebook_extension, self).__call__(*args, **params)

  File "C:\Users\edreamleo\Anaconda3\Lib\site-packages\holoviews\util\__init__.py", line 710, in __call__
    raise ImportError('None of the backends could be imported')

ImportError: None of the backends could be imported




Edward


[Thomas Passin]

That's funny.  I edited my post twice, but it seems that the original unedited version hung around.  I don't know how that happened, but I'm sorry for the confusion.

[Thomas Passin]

On Wednesday, March 25, 2020 at 7:49:47 AM UTC-4, Edward K. Ream wrote:




But I'm still having troubles. Importing matplotlib directly does work, but the last line here throws an exception:





import holoviews as hv
import holoviews.util
hv.extension('matplotlib')

Here is the exception:





WARNING:param.notebook_extension: Holoviews matplotlib extension could not be imported, it raised the following exception: FileNotFoundError('[WinError 2] The system cannot find the file specified')
exception executing script

This is one of those "I dunno, it works on my machine" things. I do not recall installing anything besides matplotlib - i mean, I just installed HV itself, and not any extension.  I'll set up a virtual environment and see what happens.

[Edward K. Ream]

On Wed, Mar 25, 2020 at 9:29 AM Thomas Passin <tbp1...@gmail.com> wrote:

> This is one of those "I dunno, it works on my machine" things. I do not recall installing anything besides matplotlib - i mean, I just installed HV itself, and not any extension.  I'll set up a virtual environment and see what happens.

Thanks. This is all expected growing pains.

Edward

[Thomas Passin]

OK, I set up a virtual environment, and installed packages in this order:

matplotlib

bokeh

leo

holoviews

The program worked as expected.  But I see that the code I posted above was missing one line.  It didn't affect you, based on your error message.  Here is the program as it worked for me a few minutes ago:

@language python

# Following https://github.com/pyviz/holoviews/issues/1819 for how to plot
# without using ipython/Jupyter

import holoviews as hv
import holoviews.util

#hv.extension('bokeh')
hv.extension('matplotlib')

#from bokeh.io import save
#from bokeh.io import show

xs = range(-10,11)
ys = [100-el**2 for el in xs]

curve = hv.Curve((xs, ys))

#renderer = hv.renderer('bokeh')
renderer = hv.renderer('matplotlib')

plot = renderer.get_plot(curve).state
#show(plot)

hv.save(curve, 'curve.png')

@language rest
Here is the resulting graph:

.. image:: curve.png

NOTE that there is a package named "hv" and this is *NOT* the same as the one we want here, which is "holoviews".

[Edward K. Ream]

On Wed, Mar 25, 2020 at 3:27 PM Thomas Passin <tbp1...@gmail.com> wrote:

> OK, I set up a virtual environment, and installed packages in this order:

matplotlib

bokeh

leo

holoviews

> The program worked as expected. 

I ended up completely reinstalling Anaconda. That cleared up some problems with weird environments. The base environment uses python 3.7.6 and all is well.

I then created a new holo environment. In this environment I installed holoviews and matplotlib and plotly.

The exact packages that get installed probably doesn't matter. What does matter is that python gets upgraded to 3.8 whenever I install holoviews, and this causes Qt to fail!  I'll investigate further.

This is all to the good, as I am getting more comfortable with conda environments.

Edward

[Thomas Passin]

On Wednesday, March 25, 2020 at 4:56:34 PM UTC-4, Edward K. Ream wrote:

On Wed, Mar 25, 2020 at 3:27 PM Thomas Passin <tbp1...@gmail.com> wrote:

The exact packages that get installed probably doesn't matter. What does matter is that python gets upgraded to 3.8 whenever I install holoviews, and this causes Qt to fail!  I'll investigate further.

How strange.  I wouldn't have noticed, because I started with 3.8 -  and QT is working when originally installed by 3.8.  I should try it on my Linux VMs, which have a lower version of Python.  I didn't know that a package could cause Python itself to get upgraded.  Or is that a Anaconda thing ans not a pip thing?

[Thomas Passin]

I installed Holoviews with pip on my Python 3.6 installation on a Linux Mint VM.  After installation, the code above worked, and so did the bokeh example.  Python was not upgraded to 3.8.  So that must be an Anaconda thing.

[Edward K. Ream]

On Wed, Mar 25, 2020 at 6:12 PM Thomas Passin <tbp1...@gmail.com> wrote:

I installed Holoviews with pip on my Python 3.6 installation on a Linux Mint VM.  After installation, the code above worked, and so did the bokeh example.  Python was not upgraded to 3.8.  So that must be an Anaconda thing.

Thanks. You have suggested several ways forward. I'll be working on this today.

Edward

[Edward K. Ream]

On Tuesday, March 24, 2020 at 6:20:15 PM UTC-5, Thomas Passin wrote:

You can also embed an interactive Bokeh plot in a Markdown document using an iframe.  The second attached screen capture file shows an example.

A nit: You can replace `></iframe>` with just `/>`. Like this:

<iframe title="Bokeh Rendering" width="700" height="600"
src="lines.html" frameborder="0" allowfullscreen />

Edward

[Thomas Passin]

As an old XML hand (going back to 1998), I do know that.  But I am under the impression that there are some non-XHTML situations where the processor still wants to use the long form.  I think that the script element used to be one of them (maybe the only one), and strictly speaking, the short form isn't legal HTML (though the processors out there are awfully tolerant).  So I tend to use the long form just to be on the safe side, even though it bugs me to see the long form for an empty element.  It's probably not needed these days.

Hmm, I should look and see if Docutils and MD are putting out HTML or XHTML.,,,[checks] Docutils is putting out XHTML, MD isn't specifying.  That would mean the it's effectively HTML, though I'm not sure if the browser is calling it HTML 5 or not.

I suppose I should check and see if MD can be persuaded to be more definite about it.

[Later] According to https://github.com/Python-Markdown/markdown/issues/492, Python MD produces XHTML fragments.  I should add an XHTML DOCTYPE to the document header, then.  I'll do that.

[Thomas Passin]

All right, I've added the XHML DOCTYPE, the namespace declarations to the html element, and enclosed the body in <body></body> tags.  I also added a closing </html> tag.  These tags weren't really needed for HTML - an HTML processor is required to infer them if missing - but for XHTML, you should be complete.

And yes, this version does work with the short form version of an <iframe> element.

These changes to viewrendered3.py are available in the VR3 branch of my repo at

https://github.com/tbpassin/leo-editor

[Edward K. Ream]

On Thu, Mar 26, 2020 at 4:36 PM Thomas Passin <tbp1...@gmail.com> wrote:

These changes to viewrendered3.py are available in the VR3 branch of my repo at

https://github.com/tbpassin/leo-editor

Thanks for the continued work. I'd like to get you commit access so you can work on vr3 directly in devel.

Edward

[Offray Vladimir Luna Cárdenas]

Hi,

Is good to see the path ahead and the upcoming focus.

On 23/03/20 8:11 a. m., Edward K. Ream wrote:

3. Imo, live coding is a dead end. The cool demos are toys which can not be scaled up:

A: Graphics: Any graphics-based demo could be more easily recreated with a slider that changes the graphics values.

Alternatively, you could just put your graphics code into a Leo node and hit Ctrl-B when you are ready for a new run.

You could create an @button node to rerun the graphics code on every Leo keystroke, but that's just silly. Most of the time you would either get a syntax error or a graph using an intermediate value.

B: Music.  Similarly, a "live" music app would be more usefully coded with sliders.

C. Apps. Changing a large app on the fly is either silly, or dangerous, or both.

I am not going to invest in learning the tools of the Pharo world. Otoh, browsing such tools lead me to Bokeh, so the time was well spent :-)

Live Coding has been a "dead end" full of "toys" for non-live coders since about 40 years when file based editing, compiling, interpreting, realoading programming style (Unix, C and friends) took over programmers imagination and over live coding systems (Lisp Symbolic Machines and Smalltalk Dynabook ones). Fortunately live coding is being alive and kicking since its beginnings without the pressure of main stream programming paradigms and languages.

Sliders could help here and there, but no amount of icons and sliders will replace the power of symbolic programming. I would like to see sliders based code editing for Leo sources, and just being able to express code manipulation that someone already pre-programed in a slider as a replace of direct textual manipulation. I can't imagine how software as a graph[1], (Python powered) music[2][2a] or the idea of programming as performance[3] can be expressed only via sliders and I can't imagine neither any creative endeavors advised to not do changes on the fly because of the previous conception of live coding (for example don't do your live coding is Jupyter, it's just a toy that can be scaled up or don't do data manipulation on the fly because of the silliness and danger of such approach).

[1] https://vimeo.com/94724841
[2] https://www.youtube.com/watch?v=xXNB1BbKY8A
[2a] https://foxdot.org/
[3] https://www.youtube.com/watch?v=0lTZ8Tuyu5I

Of course different readings of diverse tech ecosystems are important and anyone can choose to explore (or not) some particular stack(s). In my case, as a non-professional coder, as live coding and moldability became more and more important I saw that Python was not the path to follow, but that path (which has its value despite not being the one I would stay) let me to Leo and this community and after that to Pharo, Roassal, etc. So despite not being an active user of Python or Leo, because they don't provide the live coding + moldability I want/need, it has been time well spent/invested and still is to be around in this community.

Cheers,

Offray

[Edward K. Ream]

On Wednesday, April 1, 2020 at 2:48:31 PM UTC-5, Offray Vladimir Luna Cárdenas wrote:

Live Coding has been a "dead end" full of "toys" for non-live coders since about 40 years.

I'm glad you are pushing back a bit. It's a useful discussion. I've just at all your references.

Sliders could help here and there, but no amount of icons and sliders will replace the power of symbolic programming.

Symbolic programming, as illustrated in your demos, depends on libraries. So libraries are a middle ground between rigid sliders and arbitrary computation.

Given the music libraries shown in you demos, it seems VR3 could duplicate the demos.

 

I would like to see sliders based code editing for Leo sources

And I would like to see live coding for Leo. I just don't how that's going to happen.

Edward

[Offray Vladimir Luna Cárdenas]

On 2/04/20 5:14 a. m., Edward K. Ream wrote:

On Wednesday, April 1, 2020 at 2:48:31 PM UTC-5, Offray Vladimir Luna Cárdenas wrote:

Live Coding has been a "dead end" full of "toys" for non-live coders since about 40 years.

I'm glad you are pushing back a bit. It's a useful discussion. I've just at all your references.

:-), I enjoy these useful discussions

Sliders could help here and there, but no amount of icons and sliders will replace the power of symbolic programming.

Symbolic programming, as illustrated in your demos, depends on libraries. So libraries are a middle ground between rigid sliders and arbitrary computation.

For me the issue is how you get feedback? What is like the feedback cycle in your computing environment? Coding will be really useful if we get it outside of coding for making software and goes to software for understanding and expressing the world (scientist, musicians, journalist, teachers, researchers...). The feedback cycle for everyone else is different that the one for software programmers. As Fernando Pérez (Jupyter co-lead) said: scientist don't have a set of predefined output conditions as engineers do. They need to explore and make changes on the fly to understand phenomena (as musicians and pretty much everybody else... maybe except for software engineers, but I don't think so). That's why Jupyter delivers live coding as a core feature (not as a "toy" that doesn't scale up).

What should be the feedback cycle for live coding in Leo? How should the VR3 be reloaded when code changes? Maybe that could bring light on what the libraries should do.

Given the music libraries shown in you demos, it seems VR3 could duplicate the demos.

 

I would like to see sliders based code editing for Leo sources

And I would like to see live coding for Leo. I just don't how that's going to happen.

Maybe Leo should think in kind of a minimal server or something that tracks code changes and updates accordingly... I don't know if Yoton could provide that. In Smalltalk/Lisp systems is kind of a given. I presume that is related with the metaprogramming capabilities of such systems, but I don't know the underlying details.

Cheers,

Offray

[Thomas Passin]

On Thursday, April 2, 2020 at 12:36:33 PM UTC-4, Offray Vladimir Luna Cárdenas wrote:

And I would like to see live coding for Leo. I just don't how that's going to happen.

Maybe Leo should think in kind of a minimal server or something that tracks code changes and updates accordingly... I don't know if Yoton could provide that. In Smalltalk/Lisp systems is kind of a given. I presume that is related with the metaprogramming capabilities of such systems, but I don't know the underlying details.

Really, you don't want live coding.  Every character you type would give a syntax error until you complete a line or block.  Thar is awfully annoying.  What you need is the ability to easily rerun code once it's modified.  But you already get that with Python.  Within Leo, for a single node, CTRL-B gives you that, or for a node or subtree, Viewrendered3 has an execute button for the same purpose.

[Offray Vladimir Luna Cárdenas]

I for sure want live coding. It is not a theoretical desire. I have experience it in Pharo and recently in (Python's powered music system) FoxDot. They operate similar to Crtl+B and not as you describe. But what you can have is running objects that react with each Ctrl+B alike keystroke and is some/most cases give information back while running. See the inventing in principle video[1] which have inspired a lot of tools (i.e Light Table[2]). They are pretty powerful and fluent in terms of code writing and systems/problems explorations.

[1] https://vimeo.com/36579366
[2] http://lighttable.com/

I find strong reactions against some (prejudiced) version of live coding, particularly from those who have little or no experience on it (I'm not saying is the case here, and hopefully it will not). Maybe is some kind of humane bias against the unknown, as I have found it in many other places, for example in users of Git who don't know Fossil (just to point another tech community).

Cheers,

Offray

[Thomas Passin]

On Thursday, April 2, 2020 at 2:27:42 PM UTC-4, Offray Vladimir Luna Cárdenas wrote:

I for sure want live coding. It is not a theoretical desire. I have experience it in Pharo and recently in (Python's powered music system) FoxDot. They operate similar to Crtl+B and not as you describe. But what you can have is running objects that react with each Ctrl+B alike keystroke and is some/most cases give information back while running. See the inventing in principle video[1] which have inspired a lot of tools (i.e Light Table[2]). They are pretty powerful and fluent in terms of code writing and systems/problems explorations.

All right, now I think I have a better example of what you are thinking about.  I suppose one of the things is keeping the execution context between the invocations.  I wouldn't want to go creating a system like this from scratch, but if we can find one that already integrates with QT, or even with a separate viewing pane such as a browser, then it might not be too hard to get going.  Otherwise, I imagine we'd have to go through a server as you were speculating.

[Edward K. Ream]

On Thu, Apr 2, 2020 at 2:12 PM Thomas Passin <tbp1...@gmail.com> wrote:

All right, now I think I have a better example of what you are thinking about.  I suppose one of the things is keeping the execution context between the invocations.

Don't forget the livecode.py plugin.

Edward