Revised plans for 2017

[Edward K. Ream]

I don't think I have ever started a year with such excitement about Leo.

Just before Christmas I wrote the "Leo in 2017" post.  All good stuff.

Since then, two great new projects have emerged: #366: Jupyter cells in Leo and a new project, #370. The idea is to replace Leo's body text with pyzo's actual text widget, suitably modified for Leo. This will give Leo pyzo's autocompletion and debugging capabilities. It might also help integrate Leo with Jupyter.

It should be busy year.

Edward

[Offray Vladimir Luna Cárdenas]

Nice to see this plans taking form. Leo, live coding, pyzo and fossil integration will move the project to interesting directions.

Thanks for listening and the hard work that it implies.

Cheers and an interesting 2017 :-)

Offray

--
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.
For more options, visit https://groups.google.com/d/optout.

[Satish Goda]

Very nice Edward. 2017 is definitely going to be exciting.

[Edward K. Ream]

On Monday, January 16, 2017 at 5:06:19 AM UTC-6, Edward K. Ream wrote:

I don't think I have ever started a year with such excitement about Leo.

Just before Christmas I wrote the "Leo in 2017" post.  All good stuff.

Since then, two great new projects have emerged: #366: Jupyter cells in Leo and a new project, #370.

The 21 present issues are probably going to take most of this year, or perhaps even longer.  In this post, I'll list my present priorities.  This is middle-manager stuff.  Feel free to ignore.

With so much to do, planning is important.  Here are my present choices, in roughly the order that I plan to do them. However, I'll may do several in parallel.

1. Fix the various importer bugs. These have recently bit me. It would be unbearable to let them hang around. I am going to re-enable the old python importer code (using basescanner.py), to see whether the various recently-reported importer bugs apply to it. 

If necessary, I'll eventually rewrite the code one more time, after studying the pyzo code.  But the rewrite is not a big priority.  All that matters for now is that the python importer works, even if it means using the old code for awhile longer. 

2. Add org-mode capabilities to Leo, as described in this paper. Leo can not afford to lag behind org-mode.  Happily, this project should be straightforward. All changes will likely be confined to c.executeScript and its helpers.  This may involve some additional work to simulate emacs Babel, but that too should be straightforward.

3. Support .org.leo files. As always, writing such files is much easier than reading them.  There will be a bit of design work so that org-mode "drawers" (attributes) can round-trip properly with Leo uA's.  We may want to simplify uA's to make this simpler.

4. The big projects. This includes pyzo based auto-completion and debugging, and jupyter-like cells using the pyzo server architecture.  It may also involve fossil stuff.

Schedule

I typically use an "expansion factor" of 4.  If something seems like it might take a week, it may take up to a month.  Items 1, 2 and 3 look like a week each (or less), before expansion.  Item 4 is more open ended. It might take months.

All comments welcome.

Edward

[Offray Vladimir Luna Cárdenas]

Hi,

Is good to see this plans taking form. Literate computing, i.e. interactive exploratory computing intertwined with prose, in an outlining environment has been a long search/interest for me since years ago and is nice to see it happening in Leo. Grafoscopio is a prototype of the same ideas for the Pharo ecosystem (no multi language/computing support yet) and I'm glad in bringing some inspiration back to Leo. Prototyping has been a better way to express that ideas in this and other communities.

Thanks for the paper's link, surely it will help with the crosspollination on outlines for literate computing.

Cheers,

Offray

[Edward K. Ream]

On Sat, Jan 21, 2017 at 7:31 PM, Offray Vladimir Luna Cárdenas <off...@riseup.net> wrote:

Thanks for the paper's link, surely it will help with the cross

​ ​

pollination on outlines for literate computing.

​Someone else first offered the link.  Don't remember who just now.

EKR

[Edward K. Ream]

On Saturday, January 21, 2017 at 5:03:53 PM UTC-6, Edward K. Ream wrote:

1. Fix the various importer bugs. These have recently bit me. It would be unbearable to let them hang around. I am going to re-enable the old python importer code (using basescanner.py), to see whether the various recently-reported importer bugs apply to it. 

Actually, the new python importer is substantially better than the old importer. All old importers suffered from a major bug in the perfect-import logic. As a result, perfect import checks passed when they should have failed. The latest version of basescanner.py fixes this bug.

Notes

#357 (@auto whitespace sensitivity, nodes not generated) appears to work fine, regardless of importer. It has been closed. A new unit test has been added.

#260 (python import separates decorator from function) is minor for two reasons.  First, multi-line decorators are rare. Second, a new unit test verifies that perfect import tests actually pass. So this is mostly a cosmetic issue.

#364 (c.recursiveImport fails when generating @auto nodes) works much better with the new importers.  About 40 files fail with the old importers.  Only 5 files fail with the new importers.

I'll investigate #364 a bit further, but I do not expect to spend much more time on Leo's importers.

Edward

[Edward K. Ream]

On Sun, Jan 22, 2017 at 4:53 AM, Edward K. Ream <edre...@gmail.com> wrote:

the new python importer is substantially better than the old importer.

​...​

Notes

#364 (c.recursiveImport fails when generating @auto nodes) works much better with the new importers.

​Rev 440b5a5 closes this issue.

Only #374 (Leo can confuse directives with decorators)​

 

​is of serious concern. I'll attempt a fix today.

EKR

[Edward K. Ream]

On Sunday, January 22, 2017 at 4:34:39 PM UTC-6, Edward K. Ream wrote:

Only #374 (Leo can confuse directives with decorators

​is of serious concern. I'll attempt a fix today.

Rev 748101dc completes all work on importers.  Copies of the legacy basescanner.py and python.py files are now in the attic.

EKR

[Edward K. Ream]

On Saturday, January 21, 2017 at 5:03:53 PM UTC-6, Edward K. Ream wrote:

The 21 present issues are probably going to take most of this year, or perhaps even longer.  In this post, I'll list my present priorities...

 

1. Fix the various importer bugs.

Fully completed, without using any pyzo code.

4. The big projects. This includes pyzo based auto-completion...

Leo's auto-completer seems more capable than pyzo's.  It has exactly the same UI as pyzo's when @bool use_qcompleter is True.  Perhaps calltips could be improved, but this is not a high-priority item.

So far, we are ahead of schedule. The next step will be to add org-mode capabilities to Leo.

Edward