Re: Leo and the Best of the Rest

[Thomas Passin]

On Tuesday, January 7, 2020 at 5:35:22 AM UTC-5, Edward K. Ream wrote:
>
> ...
> Iirc, my conclusion is that a more rigid tree view has advantages over 
> graphical views.
>
> Having said that, Leo got its start because I had trouble understanding 
> complex programs isn't easy. Just yesterday I thought again about this 
> problem. The task before me is to explain all the new code in leoAst.py.
>
> Neither words, words, words, nor outlines, nor pretty graphs seem like the 
> solution. Hmm. What else is there, except for experience? Ah, I'm 
> forgetting How-To's. That's the way to encourage people to get their own 
> experiences.
>
>
> That's because many different aspects of a piece of code are needed, and 
one kind of view can't cover all of them.  For example, you need an API 
view of each class or module, a sequence view to depict the flow through 
modules, instances, and functions as one processing task is processed, a 
lifecycle view, etc., etc.

One of Leo's strong points for me has been that you can break up a module 
into nodes that don't have to correspond to functions and classes.  This 
capability lets us have much larger program files(and function/method 
bodies) than anyone should have otherwise, yet still have the bits and 
pieces be manageable, and to do it without needing to insert a lot of 
distracting comments in the code itself.  For example, a good guideline is 
that one bit of functionality shouldn't take more than a screen, so you can 
take the whole thing in easily.  With Leo you can come close to that, and 
without needing to create a blizzard of little functions or classes.

One of the weaknesses has been that it's hard to see the code from such 
nodes in sequence with its neighboring nodes. Viewrendered3 will be able to 
do this (with some limitations), which is one reason I've been plugging 
away at it.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/3111e4fd-db49-4889-ad61-8d62b013668d%40googlegroups.com.

Re: Matt: distribute leoAst separately?

[Matt Wilkie]

Can we drop the "and" ?

Project: ast-token-tools 
Library: ast_token_tools

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/4e9fa4be-dc71-4a24-9eb3-2dedd3ed93fa%40googlegroups.com.

Re: #1467: Use traditional unit test (almost?) everywhere

[Brian Theado]

On Fri, Jan 10, 2020 at 8:33 AM Edward K. Ream  wrote:

> > I still think full line-by-line coverage analysis will be very valuable.
>>
>> I agree. I have just created #1474
>>  for this.
>>
>
> Many thanks for suggesting this. `pytest --cov` has quickly become one of
> my favorite tools, on a par with pyflakes and pylint.
>

Excellent. I'm glad it is helpful.

pytest is easy to configure, and it's easy to suppress coverage test within
> the code itself. leo-editor/.coveragerc now contains the default settings.
>

I was unaware of that feature. Looks useful.

I have doubts about the following entries you are suppressing: assert,
except, raise.

For all 3, it seems like a case-by-case "pragma: no cover" is better than
wholesale suppression.

Especially assert. In general, an assert will precede other code you will
already want cover with tests, so why suppress the coverage report from the
assert statement itself?

With except and raise there might be some cases in which the code can't be
hit unless there is a bug in your library code. Since you can't anticipate
your bugs, you would want to suppress those from the coverage report. But
in most cases, I expect the exception catching and raising will be for
cases in which the user passes in bad data. It would be valuable to
exercise that code in unit tests to ensure it works the way you expect if a
user encounters it.

So my 2 cents says it would be better to have case-by-case suppression for
the exceptions catching and raising whose purpose is to alert you to bugs
in your own code.

Brian

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAO5X8CzCwRF2%3DsiiXOGBJ8F_tgGHEnSnY3DXbz2GA9h2KQEBYg%40mail.gmail.com.

Status report: the fstrings branch

[Edward K. Ream]

I have just completed a spectacular simplification of the 
TokenOrderGenerator class.

The tog.advance_str and and tog.advance_if machinery is gone. These methods 
"polluted" all visitors involving "else" tokens.  No more.

This would never have happened were it not for a hole I found yesterday.  
Once again, the parse tree can not distinguish between two different sets 
of tokens. The following generate exactly the same parse trees:

a = [ b : ]
a = [ b : : ]

My first thought was to implement tog.advance_slice, but then, Aha!, I saw 
that a *single *pointer suffices to sync tokens with parse tree nodes.  
This pointer is tog.px, set *only* by tog.sync_tokens.

It's just a bit tricky to use tog.px to look ahead in the token list. 
That's what tog.find_next_significant_token and 
tog.get_concatenated_string_tokens do.

*Details*

Instead of three or four indices that step through the token list, a single 
index, tog.px suffices. Multiple indices suffered from theoretical as well 
as practical problems. It was hardly obvious that the various pointers 
would play well together.

Only visitors for ast.Bytes, ast.If, ast.JoinedStr, ast.Slice and ast.Str 
ever need to look ahead in the token list.  This simplifies several other 
visitors.

*Summary*

The fstringify branch now converts all Leo files to f-strings without 
obvious problems.

The new code should be much easier to understand and maintain.

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/58ad92f6-6553-4e4d-b000-34dd6a081e0e%40googlegroups.com.

Re: On topic: Quanta magazine and today's links

[Edward K. Ream]

On Thursday, January 9, 2020 at 2:24:02 PM UTC-5, Edward K. Ream wrote:
>
> If I had to recommend one web site on the web, it would be Quanta Magazine 
> .  It's free, its articles are superb 
> and filled with endless links to explore.
>

Don't miss the superb "year in review" articles.  I've bookmarked the 
following:

The year in biology. 

The year in math and computer science 

.
The year in physics 
.

Imo, these give more of a flavor of the excitement and energy in science 
than do the year-end reviews in Science and Nature magazines.  And they're 
free.

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/8adc9b6d-c883-4ae3-8fe4-0e6219d8b92d%40googlegroups.com.

Re: Matt: distribute leoAst separately?

[Edward K. Ream]

On Fri, Jan 10, 2020 at 3:19 PM Matt Wilkie  wrote:

> Let's give the project a name like ast_and_tokens_tools.
>>
>
> I was thinking more about when it's used.
>
> import ast_and_tokens_tools
> ast_and_tokens_tools.some_func(arg1, arg2)
>
> ...is a bit much ;-)
>

import ast_and_token_tools as tools.

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS3Y-G2v07TiwVvBdg-Cb8Jiwp29NWKuz6MHrVnEw6w1ow%40mail.gmail.com.

Re: Looking at Viktor's key traces

[Viktor Ransmayr]

Hello Edward,

Am Do., 9. Jan. 2020 um 11:33 Uhr schrieb Edward K. Ream <
edream...@gmail.com>:

> On Tue, Jan 7, 2020 at 2:38 PM Viktor Ransmayr 
> wrote:
>
> *> @data   globalabbreviations =  [...]* is the only configuration
> variable, where the values looks slightly different than yours ...
>
> > Any feedback/ ideas?
>
> Insert a call to g.pdb() in AbbrevCommands.expandAbbrev or one of its
> helpers.
>
> Run Leo with --trace=keys to provide context.
>

I did as you recommended. - I inserted the call to g.pdb(), started Leo -
and - entered the simple abbreviation (myabrv) that works - plus - the more
complex abbreviation (ts~~) that does not work.

Here are the traces as a file attachement.

Thanks already in advance for looking into this further!

With kind regards,

Viktor

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAAeSrGLujSMZb%3DE5P9gHwpEvYYvX4JmAC8YBemO7YiedJR1h1A%40mail.gmail.com.


leo-abbreviation-trace.rtf
Description: RTF file