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.
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.
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.
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
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')
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.
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
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
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.
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.
You can also embed an interactive Bokeh plot in a Markdown document using an iframe. The second attached screen capture file shows an example.
<iframe title="Bokeh Rendering" width="700" height="600"
src="lines.html" frameborder="0" allowfullscreen />
These changes to viewrendered3.py are available in the VR3 branch of my repo at
Hi,
Is good to see the path ahead and the upcoming focus.
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
Live Coding has been a "dead end" full of "toys" for non-live coders since about 40 years.
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
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
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.
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
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.