Re: leo4sqlite: table imports/exports ready for testing

+1 AsciiDoc! I still prefer reST, though. On Tue, Dec 12, 2017 at 1:56 PM, Matt Wilkie wrote: > > Feature wise I prefer restructured text, but unfortunately I feel it's >> lost the race in too many widespread tools. > > > Faint voice from back of theater "AsciiDoc!" >

Re: 90f9865: the NewShowData class

On Wednesday, December 13, 2017 at 6:03:07 PM UTC-6, Edward K. Ream wrote: > Here are the good parts. Actually we can make analyze much faster by not using any generator at all: def analyze(self, fn, root): ast_d = { ast.Assign: self.assigns_d, ast.AugAssign: self.assigns_d,

Re: 90f9865: the NewShowData class

On Wednesday, December 13, 2017 at 6:11:15 PM UTC-6, Edward K. Ream wrote: > g.printDict({key: sorted(set(d.get(key) for key in d}) A last-minute edit went bad. This should be: g.printDict({key: sorted(set(d.get(key))) for key in d}) Edward -- You received this message because you are

Re: 90f9865: the NewShowData class

On Wednesday, December 13, 2017 at 6:03:07 PM UTC-6, Edward K. Ream wrote: > The new class uses Vitalije's suggested patterns. show_results can be simplified with a dict comprehension: def show_results(self): ... for (name, d) in table: print('%s...' % name)

90f9865: the NewShowData class

The new class uses Vitalije's suggested patterns. This @button node tests the code: import imp import leo.core.leoCheck as leoCheck imp.reload(leoCheck) files = leoCheck.ProjectUtils().leo_core_files() leoCheck.NewShowData().run(files[:2]) Here are the good parts: def analyze(self, fn, root):

Re: What I've just learned from Vitalije

On Wednesday, December 13, 2017 at 3:28:50 PM UTC-6, Edward K. Ream wrote: There are several coding patterns in Vitalije's prototype that deserve > mention. > *Generators as predicates* > > Vitalije's prototype (as modified in leoCheck.py) contains this: > > for node in ast.walk(root): >

Re: ENB: What's next for check-conventions

On Wed, Dec 13, 2017 at 12:32 PM, Edward K. Ream wrote: ​I was going out the door when I wrote my first brief replies. Several questions deserve longer answers.​ I don't like too many tracing code to be left inside code. >> > > ​I understand, but ​for now it helps me

What I've just learned from Vitalije

There are several coding patterns in Vitalije's prototype that deserve mention. *Generators* ['abc'].extend(None) throws a TypeError. However, the following works: def a_generator(): if 0: yield 'abc' # Makes the function a generator return None aList = ['abc']

Re: ENB: What's next for check-conventions

On Wed, Dec 13, 2017 at 2:03 PM, vitalije wrote: > You can start by studying the resolve methods. >> > > Ok, I am studying it and have a question. In resolve_ivar method if > ivar=='self' it returns ('class', class_name). Shouldn't it return > ('instance', class_name)? >

Re: ENB: What's next for check-conventions

I see you have added doc strings in c/self_assign functions that says they yield for each assignment node. Actually they yield single value if input node is assignment of correct type or don't yield at all. They expect to be called once for each node, they do not traverse tree. Perhaps it

Re: ENB: What's next for check-conventions

> > You can start by studying the resolve methods. > Ok, I am studying it and have a question. In resolve_ivar method if ivar=='self' it returns ('class', class_name). Shouldn't it return ('instance', class_name)? Little bit further in same method it checks if ivar is among special_names

Re: ENB: What's next for check-conventions

On Wed, Dec 13, 2017 at 11:50 AM, vitalije wrote: I didn't like the Type class. It can be replaced with named or even > ordinary tuple. > ​We'll see... ​ > I couldn't find that you have instantiated it anywhere with last two > optional arguments. > ​Old cruft. ​ > Also

Re: ENB: What's next for check-conventions

> > P.S. A nit. I dislike "ok and" pattern. For example, I would rewrite > is_assign_to this way: I don't mind your way of rewriting it. I used it just because I didn't know in advance all checks that need to be fulfilled, and `ok = ok and ...` gave me opportunity to put trace between any

Re: ENB: What's next for check-conventions

On Wed, Dec 13, 2017 at 7:44 AM, vitalije wrote: > Here is my attempt to show in code what I couldn't explain with the words. > It looks like you forgot these lines in my_check_func: for x in self_assign(_n): s_assigns.append(x)​ As you can see, I am studying

Re: ENB: What's next for check-conventions

On Wednesday, December 13, 2017 at 7:44:57 AM UTC-6, vitalije wrote: Here is my attempt to show in code what I couldn't explain with the words. > ... > current version successfully adds entries to map of known_classes. In > particular it adds injected theTagController to the Command class

Re: ENB: What's next for check-conventions

Here is my attempt to show in code what I couldn't explain with the words. Attached to this message you can find Leo document with script node that analyzes little bit modified your test example which demonstrates wrong method call. My code in the current version successfully adds entries to

Re: ENB: What's next for check-conventions

On Tuesday, December 12, 2017 at 1:06:50 PM UTC-6, Edward K. Ream wrote: As you can see from my lack of comments on other matters, this project requires my undivided attention. Recent work: 1. The "kind" switch in checker.check is one of those small things that makes a surprisingly big

Re: Installing Pyenchant

On Tue, Dec 12, 2017 at 3:52 PM, Matt Wilkie wrote: > > This probably merits an issue in the tracker. I'll go start one. >> > > https://github.com/leo-editor/leo-editor/issues/636 > ​Thanks for this. I've learned not to worry about the number of outstanding issues ;-) Edward

Re: Summary of installation discussions

Hi Matt, I'm testing the pip3 install leo process. I prepared my system, simulating a new system with a pip uninstall for both PyQt5 and docutils from my python folder, then: > pip3 install leo It seems to be a developers version of Leo and certainly installed all the required packages. Here