Rethinking Leo 6.1 and pyzo integration

[Edward K. Ream]

Leo 6.1 supposedly would integrate pyzo features into Leo. See this page.

In fact, doing so would be foolish and unnecessary, as I shall now explain.

Doh: Read the documentation, Luke

A few days ago I had a sickening Doh! moment.  I have done extensive code-level prototyping of pyzo integration without having a clear idea of what pyzo does!  I'm talking about the basics, covered in the pyzo intro, configuring shells and interactive vs script mode.

From the pyzo intro: "Shells run in a sub-process, such that when it is busy, Pyzo itself stays responsive, allowing you to keep coding and even run code in another shell."

This explains why pyzo uses yoton, and the related complexity.  yoton allows pyzo to show results in the "Workspace", "History Viewer" and "Shell" areas, while the actual computation happens in an external process.

So far, so good.  What are the implications?

My first thought was that Leo could easily adapt the Ctrl-B logic to run code in an external process.  But just a bit more thought shows that that won't work.  Scripts run in an external environment can't be Leonine. They could be given access to c, g and p, but they could not control Leo without heroic measures.

Doh: Pyzo can run alongside Leo

Yesterday I saw this clearly for the first time. It was another sickeningly obvious "revelation". 

Pyzo does a great job of showing and updating external files.  So anyone can get the benefits of both Leo and Pyzo right now as follows:

1. Use Leo to create and update external files, as usual.

2. Use pyzo to open files and run shells, as desired.

In short, adding pyzo's features to Leo would be really really stupid.

Summary

Anyone can get the benefits of Leo and pyzo by running them side by side.  Doh!

I shall not add pyzo's major features to Leo.  Not in 6.1.  Not ever.

Suddenly, Leo looks finished as well as complete :-)  It's time to investigate new directions for Leo with more playful prototypes.

All comments welcome and encouraged.

Edward

[Edward K. Ream]

On Tuesday, June 18, 2019 at 1:28:51 AM UTC-5, Edward K. Ream wrote:

> In short, adding pyzo's features to Leo would be really really stupid.

Port mortem

It hurts to have spent months on a fool's errand.  Otoh, the pyzo project did drive the two main features of Leo 6.0, namely moving to Python 3 and supporting Qt docks.  Both are important and useful.

Anyway, we can't change the past, and it's good to acknowledge our mistakes and move on.  The belated Aha's will prevent even more wasted effort in future.  It's good to see how easy it is for Leo and pyzo to work together.

So now I personally am at a big transition.  None of the items scheduled for 6.1 are urgent.  They could easily be postponed for months, or even to the end of this year. It's time for a big rethink of where I go next.  This should be exciting, if a bit daunting. It's been decades since I have been in this situation.

Edward

[john lunzer]

I dislike having multiple editors/IDEs open because it is often messy and the "integrated" component of IDE gets lost.

I'm not implying that you do more work; it is your Leo, we just use it. I'm not optimistic that users would see this as a "good" or "clean" solution to having shell and file browser features available to them.

I am, however, implying that your Doh/Aha moment might be a personal one and that the desire for the stated features to be integrated within Leo will not go away because of it.

That said thank you for the recent work, very much appreciated.

[Chris George]

The features from the file browser are nice but as you stated before you can include them in the Leo file browser easier than trying to integrate existing pyzo code.

Back when I started down the path of trying to learn python a couple of years ago, Leo's lack of an integrated shell drove me to pyzo. The python terminal plugin has never worked for me as it causes Leo to segfault every time I enabled it.

And would it not make sense to make the shell an iPython shell instead of just the regular one?

Chris

--
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 post to this group, send email to leo-e...@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/3faacace-ddbf-4f91-8c17-86fec0d0e196%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Edward K. Ream]

On Tue, Jun 18, 2019 at 10:05 AM Chris George <techn...@gmail.com> wrote:

The python terminal plugin has never worked for me as it causes Leo to segfault every time I enabled it.

I've just created #1212 for this. This should end the dithering about whether this plugin is worth resuscitating.  It is.

And would it not make sense to make the shell an iPython shell instead of just the regular one?

I don't think so.  If you want IPython, try --ipython.  This is a pretty nifty feature. It integrates Leo and IPython as much as possible.

Edward

[Edward K. Ream]

On Tue, Jun 18, 2019 at 9:49 AM john lunzer <lun...@gmail.com> wrote:

I dislike having multiple editors/IDEs open because it is often messy and the "integrated" component of IDE gets lost.

Imo, letting pyzo be pyzo and Leo be Leo is as clean a division of labor as can be imagined.  In practice, it would be rare to have both pyzo and Leo open at the same time.  But that would "just work" if you actually do that.

Integrating pyzo's shell (and related features) simply doesn't work.  Scripts run from the pyzo shell aren't (can't be) Leonine scripts.  That being so, it makes more sense to use pyzo if you you want pyzo's features.

I'm not optimistic that users would see this as a "good" or "clean" solution to having shell and file browser features available to them.

Then we'll have to educate them.  Or better, get the python_terminal plugin working.

...your Doh/Aha moment might be a personal one and that the desire for the stated features to be integrated within Leo will not go away because of it.

It's not going to happen.  Get used to it.

Life is too short to add mostly useless features.  It's time to do something interesting :-)

Edward

[Edward K. Ream]

On Tuesday, June 18, 2019 at 1:28:51 AM UTC-5, Edward K. Ream wrote:

I have revised several conclusions.  As usual, making a strong, pithy statement helps the mind engage and critique it. This reply contains quotes from this thread and "Leo's past and future".

> [Integrating pyzo features into Leo] would be foolish and unnecessary.

This is now debatable, as discussed below.

> I have done extensive code-level prototyping of pyzo integration without [considering] the basics, covered in the pyzo intro, configuring shells and interactive vs script mode.

That was being way too hard on myself.  I probably did read these pages, without realizing their significance at the time. That's hardly a crime. In all likelihood, I could not have truly understood their significance without having done the prototyping I did.

> Doh: Pyzo can run alongside Leo

True, but not conclusive. John Lunzer said:

"I'm not optimistic that users would see this as a "good" or "clean" solution to having shell and file browser features available to them."

Debaters take note: a pithy comment is way more effective than windy ones.

> Would I embed pyzo's docks into Leo if I could just wave a magic wand? Yes, probably. Alas, actually doing so would take a lot of work.

So what? The goal matters more than programming difficulties, provided that no heroic measures are needed.

> There are only two ways forward:

> 1. Import pyzo code and bend it to Leo's will.

> 2. Copy pyzo code into Leo and suffer all the ill effects of cut and paste.

> Each is ugly in its own way.

These are not necessarily gotchas.  Any "ugliness" would be confined to a plugin. It's too early to say.

There might be a third way: some kind of client/server interaction between Leo and pyzo/yoton.

Yoton, pyzo's communication infrastructure, is worth learning and playing with on its own. Communication between Leo and other programs will likely be a big part of Leo's future.

> Scripts run in an external environment can't be Leonine. They could be given access to c, g and p, but they could not control Leo without heroic measures.

Not a gotcha. Most people use scripts for purposes unrelated to Leo! Pyzo allows scripts to run in the background.  Leo could (and should) do this too.  Such Leonine background scripts would not be able to control Leo either.

Finally, pyzo's debugger and shell would replace Leo's python_console and xdb plugins.  If this can be done (a big question) it would be a major improvement to Leo.

Summary

> I shall not add pyzo's major features to Leo.  Not in 6.1.  Not ever.

I was way too harsh on myself and hasty in my conclusions.

I am now officially dithering regarding pyzo :-)  Time for more prototyping.

This is progress. The prototyping will happen in a wider context: interaction with other programs.

Edward

[Offray Vladimir Luna Cárdenas]

Hi,

On 21/06/19 11:53 a. m., Edward K. Ream wrote:

There might be a third way: some kind of client/server interaction between Leo and pyzo/yoton.

Yoton, pyzo's communication infrastructure, is worth learning and playing with on its own. Communication between Leo and other programs will likely be a big part of Leo's future.

> Scripts run in an external environment can't be Leonine. They could be given access to c, g and p, but they could not control Leo without heroic measures.

Not a gotcha. Most people use scripts for purposes unrelated to Leo! Pyzo allows scripts to run in the background.  Leo could (and should) do this too.  Such Leonine background scripts would not be able to control Leo either.

Happy to see this "Leo as a service" exploration. I have advocate for it since... well years... particularly to have an interactive outlining experience (at that time I compared interacting with the external world via files, versus interacting with it via services). But I think now is the time when such idea is coming more naturally here. Maybe a Yoton playful prototype that connects Leo with IPython or something like that will be soon on the horizon.

Congrats about 6.1 and the happy prototypes from this year.

Cheers,

Offray

[Edward K. Ream]

On Fri, Jun 21, 2019 at 7:17 PM Offray Vladimir Luna Cárdenas wrote:

Happy to see this "Leo as a service" exploration. I have advocate for it since... well years...Maybe a Yoton playful prototype that connects Leo with IPython or something like that will be soon on the horizon.

Yes.  That's the plan.

Congrats about 6.1 and the happy prototypes from this year.

Thank you.  I appreciate it.

Edward

[Matt Wilkie]

... Leo's lack of an integrated shell drove me to pyzo.

Ditto. That and being able to inspect variable contents at runtime by double-clicking on them.

it would be rare to have both pyzo and Leo open at the same time.  But that would "just work" if you actually do that.

Yup, it just works! And is my standard operating procedure when I'm working on pure python stuff, which is more often than Python + Leo stuff. So, normal and not rare (for me). There is some friction with it tho:

...multiple editors/IDEs open ... is often messy and the "integrated" component of IDE gets lost.

Which makes me somewhat sad, however, I too am not:

 ... implying that you do more work; it is your Leo, we just use it. ... thank you for the recent work, very much appreciated.

Absolutely!

Switching to a different thread-in-the-thread:

.... a pithy comment is way more effective than windy ones.

Yes. While being ware it's frightfully easy to intend pithy

and be heard pissy, which is how I first read:

...not going to happen. Get used to it.

Pissy was likely not the intended tone here. A dance where we all step and misstep on both sides of the line. ;-)

Anyway, back to the core: cutting down to python 3 and adding moveable docks are milestones to be celebrated. If thinking-via-code in pyzo integration experiments made that happen, then yay the experiments. (Sez me who didn't have skin in that game.)

-matt