I think that a good approach would be to come up with several use-cases or scenarios of how someone would actually use a hybrid Leo-IPython system. It's no different that the case of Jupyter or sage. I stopped supporting Jupyter notebooks in VR3 for the reason that I couldn't come up with one, at least one that wouldn't take a huge amount of work.
In the case of Jupyter notebooks, it's obvious that the input and output blocks could become Leo nodes, and Leo would bring a superior way to work with, view, and and handle those nodes. There are two things that stand in the way: 1) code in each Jupyter input node has access to the variables computed by earlier nodes, and 2) the inline display of graphics. There is also trickiness that about recomputing when the code changes. I can live with the graphics by viewing the notebook with VR3, and I have made fairly extensive notebook-style outlines including code-generated graphics that way. Passing variables from one node to the next would require a serious rethink of how VR3 operates. Since Jupyter is in some sense an elaborate extension of IPython similar points should apply. I don't know about Sage but it too probably fits into that kind of picture. IPython clients communicate with a server process, isn't that right? I know it's that way with Jupyter. I don't know why there couldn't be a Leo client, but it wouldn't be VR3 (and there is no reason why it should be). Again, the most important starting point is to think through how a Leo client would work from the user's point of view. Once that is understood, we can come to grips with how to make it work. Trying to make something work before understanding a way or ways to make use of IPython support isn't likely to lead to helpful results, in my view. On Friday, October 18, 2024 at 9:42:14 AM UTC-4 Edward K. Ream wrote: > This Engineering Notebook post rethinks what Leo's IPython bridge (in > *leoIPython.py*) must be. > > Leo's IPython bridge has likely not worked for years. Imo, the bridge has > never been much more than a toy. As a result, I feel free to re-imagine > everything about Leo's relationship to IPython. > > > *Goals and requirements* > > *I'll retire leoIPython.py unless Leo can become an easy-to-use IPython > notebook. * > > - Leo and IPython must run without blocking each other. > - IPython must have access to c, g and p. > > *Managing event loops* > > As an experiment, I tried running this Leonine script: > > import IPython > IPython.embed() > > As expected, this script starts IPython in the console window from which > Leo launched. And IPython does have access to c, g and p! > > In [1]: c > Out[1]: Commander 1439643722256: 'c:/Repos/leo-editor/leo/core/leoPy.leo' > In [2]: g > Out[2]: <module 'leo.core.leoGlobals' from > 'C:\\Repos\\leo-editor\\leo\\core\\leoGlobals.py'> > In [3]: p > Out[3]: <pos 1439662055744 childIndex: 6 lvl: 0 key: 1439726600784:6 embed> > > Alas, Leo hangs until IPython quits. So more work is needed :-) > > *Managing namespaces* > > A new Leo command, *execute-ipython-script*, should execute p.b in a > namespace that includes all names known to the running IPython instance. > > Similarly, IPython must have access to c, g and p *without *using embed. > > *Packaging* > > Leo's present *--ipython* command-line arg starts Leo in a ipython > console window. I would like to retire this arg: it's clumsy and adds > nothing essential. > > Instead, a new Leo command, say *launch-ipython*, would: > > - Exit with a warning if importing ipython fails. > - Launch (once) IPython in the console from which Leo was launched. > > *Summary* > > Leo's IPython bridge is little more than a toy. Worse, leoIPython.py has > not worked for years. I shall retire leoIPython.py unless Leo can become a > straightforward, easy-to-use IPython notebook. This notebook must: > > - block neither IPython nor Leo. > - give IPython access to c, g and p. > - have an execute-ipython-script command. > > It remains an open question whether these goals are attainable. I have > hopes: IPython's API (fully accessible from Leo) has many features relating > to embedding IPython into applications. > > All comments and questions are welcome. > > Edward > > P.S. Running Leo from Leo's bridge is not the answer. We could avoid > clashing event loops by embedding Leo's bridge (in *leoBridge.leo*) into > IPython. But giving IPython access to Leo via Leo's bridge would add almost > nothing to IPython! > > EKR > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/877f9a98-5cb4-41da-a86f-83232099c815n%40googlegroups.com.
