On Fri, Oct 18, 2024 at 10:00 AM Thomas Passin <[email protected]> wrote:
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. > Thanks for this excellent analysis. I was just going to create an ENB on this topic. I agree: plausible use cases must come first. See below for further discussion. My only firm conclusion: it's time to retire leoIPython.py. The present code doesn't work and IPython's server has been deprecated and will be retired in a future release. 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. > I agree. Otoh, I would be willing to live with some scheme that uses IPython to display graphics results. 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 handle those nodes. > That's the idea. 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 may be other issues standing in the way :-) 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. > I think of VR/VR3 support as optional. I'm having a devil of a time wrapping my head around all the possibilities as it is. 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. > Last night I realized that a client/server architecture might be essential. Jupyter provides such an architecture, but is way heavy. Embedding a server into IPython (customized to Leo, when IPython starts) is possible. Such an architecture would be similar to LeoInteg's architecture. Leo would be a client of that server. IPython clients communicate with a server process, isn't that right? > I'm not sure. Anyway, the existing IPython server has been deprecated. I know it's that way with Jupyter. I don't know why there couldn't be a > Leo client > Yes, Leo could be a client, but the Jupyter server is obsessed (as it must be) with security. A local, bespoke, server would be much easier to create and use. 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. > I agree completely, and it has taken days of exploration to come around to the Aha! Previously, I assumed that Leo's IPython bridge was something more than a toy, so I didn't look for use cases! *Summary* Many thanks for your analysis. Finding a plausible use case for using Leo in the SageMath, IPython or Jupyter worlds will drive all my explorations. Otoh, this is a speculative, open-ended project. The only goal is vague: finding *some* way to incorporate IPython's many powers into Leo. I'm spending a lot of time googling and noodling. Edward My only firm conclusion: it's time to retire leoIPython.py. 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS0ETP82O7a-9_GqDaJVWPwNS%2B8a%2B481PrEZ1z%3DFvxfhuQ%40mail.gmail.com.
