ipython plugin will always be on

[Edward K. Ream]

In practice, the separation of code between the ipython.py plugin and
leo/external/ipy_leo.py is inconvenient for me and a bit confusing for
users. Indeed, Leo's --ipython command-line arg should be all that is
needed to create the ILeo bridge.

I plan to fold the code in ipython.py and ipy_leo.py into a single
file. There seems to be no reason why this file should not be part of
Leo's core, say leoIPython.py.

Ville, do have any comments?

Edward

[Ville M. Vainio]

Iirc, ipy_leo is leo 'helpers' that you load from ipython (as ipython plugin), and ipython.py is a leo plugin that enables the ipython bridge. Having them be separate seems natural to me, and users only know about ipython.py.

--
You received this message because you are subscribed to the Google Groups "leo-editor" group.
To post to this group, send email to leo-e...@googlegroups.com.
To unsubscribe from this group, send email to leo-editor+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.

[Viktor Ransmayr]

Hello Edward,

This question reminds me a bit of the times when the GUI-Issue was
discussed. - Tk vs. Qt vs. ...

Is it possible that this question could/ should be answered in the larger
context of

* what goes/ should go into Leo's core,
* what is/ should always be a Leo plugin?

With kind regards,

Viktor

[Edward K. Ream]

On Sun, Apr 1, 2012 at 12:31 AM, Ville M. Vainio <viva...@gmail.com> wrote:

> Iirc, ipy_leo is leo 'helpers' that you load from ipython (as ipython
> plugin), and ipython.py is a leo plugin that enables the ipython bridge.
> Having them be separate seems natural to me, and users only know about
> ipython.py.

Thanks for this. I would like users to know only about the --ipython
option. My original question was intended to discover if there was
any technical reason why the two files could not be merged. Unless
there is, my plan is to merge both into Leo's core.

To answer Viktor, I think IPython support is natural for Leo's core,
for two related reasons:

1. It seems natural to support the --ipython option at all times.

2. Given the --ipython option, forcing users *also* to enable the
ipython plugin seems clumsy.

The case could be made for as much to be moved out of the core as
possible, but that's not the direction that we have been following
recently. For example, the rst3 command is now part of Leo's core.

Any other comments?

Edward

[Edward K. Ream]

On Apr 1, 6:34 am, "Edward K. Ream" <edream...@gmail.com> wrote:

> Unless [there are technical objections] my plan is to merge both into Leo's core.

Creating a new core file, say leoIPython.py will allow us to keep
ipy_leo.py and ipython.py unchanged during development of the new
IPython support code. The old code will continue to work with legacy
versions of IPython. That's likely to be useful.

So the plan is to move the new code into leoIPython.py, and then
revert ipy_leo.py and ipython.py before pushing the new code.

Hmm. Perhaps Leo will need a --legacy_ipython command-line arg to
make this scheme work...I'm not sure that's going to be useful, but
for now I do want to keep the old support files unchanged.

Edward

[Edward K. Ream]

On Sun, Apr 1, 2012 at 7:31 AM, Edward K. Ream <edre...@gmail.com> wrote:

> Hmm.  Perhaps Leo will need a --legacy_ipython command-line arg.

A ridiculously bad idea ;-) The new IPython controller will determine
which version of IPython is in effect and act accordingly.

EKR

[tfer]

Forgive my imperfect understanding of this, but I think that the old
Leo-Ipython stuff worked by having the same python interpreter
instance running both leo and ipython shifting things of interest back
and forth through namespaces that either could look at.

While this still may be possible with the new Ipython, (and this may
be what you are working on?), the new model for this is to have two
interpreters running, one running Leo and one running Ipython and
handle the communications between the two through the zmq interchange
library, (via the python bindings provided by pyzmq). It is this sort
of thing that the Ipython notebook video was demonstrating.

I've felt that this zmq could be the thing that, if added to Leo and
utilized by a python program running inside of Vim, could make Vim
replace the editor component of Leo using IPC to send the opened
node(s) to vim instead of using temporary files.

Setting up zmq on a windows PC is so involved, that I have not done
anything with Ipython lately, however, the people at enthought have a
windows distribution package that includes it, plus a number of
scientific, mathematical, simulation goods that will work out of the
box. It runs Leo fine.

Tom

[Edward K. Ream]

On Apr 2, 9:21 am, tfer <tfethers...@aol.com> wrote:

> Forgive my imperfect understanding of this, but I think that the old
> Leo-Ipython stuff worked by having the same python interpreter
> instance running both leo and ipython shifting things of interest back
> and forth through namespaces that either could look at.

Actually, I'm not sure how it worked. It really was (and is) magic to
me.

I do know that the basics still does work in degraded (no zmq) mode.
My plan is to get *all* the features working in no-zmq mode.

> While this still may be possible with the new Ipython, (and this may
> be what you are working on?), the new model for this is to have two
> interpreters running, one running Leo and one running Ipython and
> handle the communications between the two through the zmq interchange
> library, (via the python bindings provided by pyzmq).  It is this sort
> of thing that the Ipython notebook video  was demonstrating.

Yes. zmq is exciting. Alas, I have not been able to build it either
on Windows or Ubuntu.

> I've felt that this zmq could be the thing that, if added to Leo and
> utilized by a python program running inside of Vim, could make Vim
> replace the editor component of Leo using IPC to send the opened
> node(s) to vim instead of using temporary files.

I hadn't thought of that. Clearly, something like zmq could solve a
lot of problems.

> Setting up zmq on a windows PC is so involved, that I have not  done
> anything with Ipython lately, however, the  people at enthought have a
> windows distribution package that includes it, plus a number of
> scientific, mathematical, simulation goods that will work out of the
> box.  It runs Leo fine.

Time to check into enthought. Thanks for this tip. I'd love to give
IPython notebooks try. And all the other goodies too.

Edward

[Terry Brown]

On Mon, 2 Apr 2012 08:32:40 -0700 (PDT)

"Edward K. Ream" <edre...@gmail.com> wrote:

> Yes. zmq is exciting. Alas, I have not been able to build it either
> on Windows or Ubuntu.

It's available as a package in the package management system for
Ubuntu. Unfortunately tfer said zmq in windows was hard, if that's
true, then that's a pain, because it sounds like zmq might be a well
rounded wheel that it would be nice to avoid re-inventing.

Cheers -Terry

[Matt Wilkie]

> Unfortunately tfer said zmq in windows was hard, if that's
> true, then that's a pain,

I have pyzmq working I think, or at least I was able to get ipython
notebook running on my computer last week (python 2.7). I believe I
just used `pip install pyzmq` and it was off to the races.

I was following the guide at
http://ipython.org/ipython-doc/dev/install/install.html#installnotebook

A week before that I installed pip using this recipe:
http://www.pip-installer.org/en/latest/installing.html

The whole process wasn't a push button affair, but no more difficult
than installing Leo by hand and manually setting the file assocations
and so on. I'll see if I can replicate the process at home and write
up a recipe.

--
-matt