Re: tip wanted: faster git clone

[Kent Tenney]

Below demonstrates the difference between clone and clone --depth=1
When git trunk is recommended as a good way for users to install and run,
I think --depth=1 would be good to mention, pretty dramatic difference.

ktenney@delly:/tmp$ time git clone --depth=1
https://github.com/leo-editor/leo-editor
Cloning into 'leo-editor'...
remote: Counting objects: 3503, done.
remote: Compressing objects: 100% (3113/3113), done.
remote: Total 3503 (delta 410), reused 2670 (delta 319), pack-reused 0
Receiving objects: 100% (3503/3503), 9.10 MiB | 154.00 KiB/s, done.
Resolving deltas: 100% (410/410), done.

real1m3.407s
user0m2.092s
sys0m0.940s


ktenney@delly:/tmp$ time git clone https://github.com/leo-editor/leo-editor
Cloning into 'leo-editor'...
remote: Counting objects: 121841, done.
remote: Compressing objects: 100% (340/340), done.
remote: Total 121841 (delta 245), reused 203 (delta 69), pack-reused 121432
Receiving objects: 100% (121841/121841), 140.73 MiB | 170.00 KiB/s, done.
Resolving deltas: 100% (94862/94862), done.

real14m24.684s
user1m12.704s
sys0m12.904s


On Thu, Dec 7, 2017 at 10:51 PM, Matt Wilkie  wrote:

> Somebody (Kent?) posted a git clone command that was faster than the
> typical:
>
>  git clone https://github.com/leo-editor/leo-editor.git
>
> I think it involved telling git there was no need to go back to the
> beginning of time, just the previous N months. Or something?
>
> matt
>
> --
> 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 post to this group, send email to leo-editor@googlegroups.com.
> Visit this group at https://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: tip wanted: faster git clone

[Jacob MacDonald]

Oh, I didn't realize unshallowing was added! I retract my statement.
Without that feature I find that a repository without history is bad for
development because of the lack of bisect.

On Fri, Dec 8, 2017, 12:50 Matt Wilkie  wrote:

> Thanks Jacob!
>
> It seems that --depth=x  a.k.a. Shallow Clones used to be a problem prior
> to Git v1.9 but are now more fully featured. They're still downplayed in
> "merge-based workflows" but not an actual problem anymore:
> https://stackoverflow.com/questions/6941889/is-it-safe-to-shallow-clone-with-depth-1-create-commits-and-pull-updates-aga
>
> A repo can be started with a shallow clone and full history pulled later
> if needed with (Git 2.8+):
> *git pull --unshallow*
>
> So for Leo's current commit rate a shallow clone with a history of
> ~3-4months would be:
>
> git clone --depth=500
>
> To go back to the last tagged release ask someone who has a clone to
> report result of `git rev-list HEAD ^5.6 --count` (412 at present moment or
> maybe https://github.com/cjlarose/github-rev-list. You could also look at
> the dev*NNN* at https://pypi.python.org/pypi/leo and hazard an estimate.
>
> matt
>
> On Thu, Dec 7, 2017 at 9:01 PM, Jacob MacDonald 
> wrote:
>
>> Check out the documentation for the `--depth` flag to `git-clone`. It
>> will pull only the selected number of commits from a single branch, which
>> means your initial clone is far smaller. However, it makes it very
>> difficult to do development later, so make sure the clone will only be used
>> for reading!
>>
>> Jacob.
>>
>> On Thu, Dec 7, 2017 at 10:51 PM Matt Wilkie  wrote:
>>
>>> Somebody (Kent?) posted a git clone command that was faster than the
>>> typical:
>>>
>>>  git clone https://github.com/leo-editor/leo-editor.git
>>>
>>> I think it involved telling git there was no need to go back to the
>>> beginning of time, just the previous N months. Or something?
>>>
>>> matt
>>>
>>> --
>>> 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 post to this group, send email to leo-editor@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/leo-editor.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> 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 post to this group, send email to leo-editor@googlegroups.com.
>> Visit this group at https://groups.google.com/group/leo-editor.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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 post to this group, send email to leo-editor@googlegroups.com.
> Visit this group at https://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: tip wanted: faster git clone

[Matt Wilkie]

Thanks Jacob!

It seems that --depth=x  a.k.a. Shallow Clones used to be a problem prior
to Git v1.9 but are now more fully featured. They're still downplayed in
"merge-based workflows" but not an actual problem anymore:
https://stackoverflow.com/questions/6941889/is-it-safe-to-shallow-clone-with-depth-1-create-commits-and-pull-updates-aga

A repo can be started with a shallow clone and full history pulled later if
needed with (Git 2.8+):
*git pull --unshallow*

So for Leo's current commit rate a shallow clone with a history of
~3-4months would be:

git clone --depth=500

To go back to the last tagged release ask someone who has a clone to report
result of `git rev-list HEAD ^5.6 --count` (412 at present moment or maybe
https://github.com/cjlarose/github-rev-list. You could also look at the dev
*NNN* at https://pypi.python.org/pypi/leo and hazard an estimate.

matt

On Thu, Dec 7, 2017 at 9:01 PM, Jacob MacDonald  wrote:

> Check out the documentation for the `--depth` flag to `git-clone`. It will
> pull only the selected number of commits from a single branch, which means
> your initial clone is far smaller. However, it makes it very difficult to
> do development later, so make sure the clone will only be used for reading!
>
> Jacob.
>
> On Thu, Dec 7, 2017 at 10:51 PM Matt Wilkie  wrote:
>
>> Somebody (Kent?) posted a git clone command that was faster than the
>> typical:
>>
>>  git clone https://github.com/leo-editor/leo-editor.git
>>
>> I think it involved telling git there was no need to go back to the
>> beginning of time, just the previous N months. Or something?
>>
>> matt
>>
>> --
>> 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 post to this group, send email to leo-editor@googlegroups.com.
>> Visit this group at https://groups.google.com/group/leo-editor.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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 post to this group, send email to leo-editor@googlegroups.com.
> Visit this group at https://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: ENB: Prototype of convention checker

[Edward K. Ream]

This continues an Engineering Notebook entry.  Feel free to ignore.

The string-oriented prototype is 100x faster than previous prototyping 
attempts. This makes a huge difference.

To repeat, this project will be worthwhile if it can find *even one bug* 
that pylint and pyflakes can't.  I'm closing in on success at breakneck 
speed.  Here is my present test string:

class TagController:

def __init__(self, c):
self.c = c
c.theTagController = self

def add_tag(self, p, tag):
# Will fail if p is a vnode
tags = set(p.v.u.get('__node_tags', set([])))

class LeoTagWidget(QtWidgets.QWidget):

def __init__(self,c,parent=None):
self.c = c
self.tc = self.c.theTagController

def add_tag(self, event=None):
p = self.c.p
self.tc.add_tag(p.v,tag) # WRONG: should be p.

And here is the output of the present prototype:

class TagController:

def TagController.def __init__(self,c):

self.x= .c=c
   c.x= c.theTagController=self

def TagController.def add_tag(self,p,tag):

end_class  END OF CLASS TagController
end_class IVARS
{
  c:'self.c=c'
}
end_class METHODS
{
  __init__:'def __init__(self,c):',
   add_tag:'def add_tag(self,p,tag):'
}

class LeoTagWidget(QtWidgets.QWidget):

def LeoTagWidget.def __init__(self,c,parent=None):

self.x= .c=c
self.x= .tc=.c.theTagController

def LeoTagWidget.def add_tag(self,event=None):

   call .tc.add_tag(p.v,tag)

end_class  END OF CLASS LeoTagWidget
end_class IVARS
{
   c:'self.c=c',
  tc:'self.tc=self.c.theTagController'
}
end_class METHODS
{
  __init__:'def __init__(self,c,parent=None):',
   add_tag:'def add_tag(self,event=None):'
}

show C CLASSES
{
  theTagController:'c.theTagController=self'
}

As you can see, the prototype creates "symbol tables" for each class, plus 
a symbol table for 'c'. These are complete hacks, but they should be enough 
to find the bug.

A new, crucial,  "resolve" method will resolve chains like a.b.c to class 
(name). Resolve will work on strings, like everything else in this 
prototype.

A new design principle has emerged:  *check known chains and report unknown 
chains*. This will instantly give us a sense of how useful this tool might 
be.

I'll give myself a day or two to have the code find the bug.  If unforeseen 
problems arise I'll document them and (maybe) move on, putting this project 
(really) on the back burner.

Edward

P.S. *Important*: there are clear analogs between the string hacking of the 
prototype and corresponding (more complicated) ast-related code. So 
"cheats" in the prototype are perfectly admissible.

Building Leo-specific knowledge into the prototype does *not* mean that the 
tool will be Leo-specific. Later, we can build in generalized 
(non-Leo-specific) hints. But I won't even think of doing that until the 
prototype finds the first bug.

EKR

-- 
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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: tip wanted: faster git clone

[Zoom.Quiet]

if just want pull lasted code
we can base svn got them from githu

On Fri, Dec 8, 2017 at 10:34 PM, Terry Brown  wrote:
> On Fri, 08 Dec 2017 05:01:29 +
> Jacob MacDonald  wrote:
>
>> Check out the documentation for the `--depth` flag to `git-clone`. It
>> will pull only the selected number of commits from a single branch,
>> which means your initial clone is far smaller. However, it makes it
>> very difficult to do development later, so make sure the clone will
>> only be used for reading!
>>
>> Jacob.
>
> Just out of interest, why is it harder to do development later?
> Obviously you don't have the history to inspect, but other than that,
> you can still add commits and, I would assume, push back to the origin?
> Just curious.
>
> Cheers -Terry
>
> --
> 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 post to this group, send email to leo-editor@googlegroups.com.
> Visit this group at https://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.



-- 
life is pathetic, go Pythonic! 人生苦短, Python当歌!
俺: http://zoomquiet.io
授: http://creativecommons.org/licenses/by-sa/2.5/cn/
怒: 冗余不做,日子甭过!备份不做,十恶不赦!
KM keep growing environment culture which promoting organization learning!

-- 
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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: How big is Leo on disk?

[Offray Vladimir Luna Cárdenas]

Hi,

I coined the term "pocket infrastructures" for the ones which are
self-contained, simple and can run from USB drives to humble laptops and
anything in between and beyond. Now my combination includes:

- Pandoc: ~ 15 Mb, For markup processing and conversion.
- Fossil; ~ 3 Mb, kind of a "GitHub in a box" and totally distributed,
providing DVCS, tickets (issues), wiki and embedded web server.
- Sqlite: ~1 Mb, for data manipulation and spreadsheet related task.
- Grafoscopio / Pharo: 164 Mb  Development environment including live
coding, source code manager, data visualization & interactive
notebooks/outlines.

So, is nice to have such set of well diverse but coupled tasks covered
under 200 Mb, compared with the alternatives these days. Even, complex
data intensive research, like the Panama Papers, can be approached by
these "pocket infrastructures" as shown in [1].

BTW, Leo Editor was recently mentioned in a talk about metasystems for
reproducible research [2]

[1] http://mutabit.com/offray/blog/en/entry/panama-papers-1
[2] https://twitter.com/khinsen/status/938834204892254208

Cheers,

Offray

On 07/12/17 20:22, Zoom.Quiet wrote:
> 42M Leo-5.4
> not include Py 2.7.10 + PyQt ...ect.
>
>
> On Fri, Dec 8, 2017 at 8:46 AM, Matt Wilkie  wrote:
>>> For anyone wondering what you could possibly do with a 20 Mb drive,
>>> apps. and games were all much less than 1 Mb back then, so it was quite
>>> useful.
>> The most amazing program under 1mb I ever encountered was World Construction
>> Set. At a time when the expensive GIS software used to make our daily bread
>> came on 20 to 30 floppy disks (~1995), depending on extensions, it showed up
>> in a measly cardboard envelope, and blew my socks off. It could render a 3D
>> perspective view of rocks, trees, clouds, distance haze and more from
>> real-world spatial data while said expensive GIS software could only draw
>> wire frames.
>> http://www.maphew.com/archive/patawi/matt/polargeo/gallery/3D/Minto_View2.htm
>>
>>
>> --
>> 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 post to this group, send email to leo-editor@googlegroups.com.
>> Visit this group at https://groups.google.com/group/leo-editor.
>> For more options, visit https://groups.google.com/d/optout.
>
>


-- 
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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: The cft crash: understanding vs type checking

[Terry Brown]

On Fri, 8 Dec 2017 04:37:01 -0800 (PST)
"Edward K. Ream"  wrote:

> 3. The nodetags.py plugins caches vnodes.  This is fine as long the
> plugin (in effect) recreates the cache when the outline changes.

Short version: in what way must the plugin "recreate" vnode data when
the outline changes, assuming it's using c.vnode2position() when
appropriate?

Long version:

My understanding, and it's worked for me so far ;-) is that you can
"cache" (keep references to) vnodes without much worry - as long as you
check the results of c.vnode2position() to make sure the vnode is
still in the outline when you come to work on it.  You could of course
cache gnxs instead, with basically the same pattern.  You certainly
can't cache positions, seeing they become invalid very quickly.

I only recently appreciated the coolness of weakrefs, as used in
https://pythonhosted.org/blinker/ ... although I guess that wouldn't be
as rigorous a check as c.vnode2position() - something else could be
holding a regular reference.

I don't know if there's a cheaper way to check that a vnode is still in
an outline than c.vnode2position() - some ivar of the vnode that's
always cleared when a vnode's removed from the outline.

In practice even the check to see that the vnode is still in the
outline is sometimes unnecessary, if the fact that your function was
called on a particular vnode requires that it's still in the outline.

Cheers -Terry

-- 
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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: tip wanted: faster git clone

[Terry Brown]

On Fri, 08 Dec 2017 05:01:29 +
Jacob MacDonald  wrote:

> Check out the documentation for the `--depth` flag to `git-clone`. It
> will pull only the selected number of commits from a single branch,
> which means your initial clone is far smaller. However, it makes it
> very difficult to do development later, so make sure the clone will
> only be used for reading!
> 
> Jacob.

Just out of interest, why is it harder to do development later?
Obviously you don't have the history to inspect, but other than that,
you can still add commits and, I would assume, push back to the origin?
Just curious.

Cheers -Terry

-- 
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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: ENB: Prototype of convention checker

[Edward K. Ream]

On Friday, December 8, 2017 at 7:58:36 AM UTC-6, Edward K. Ream wrote:
>
>
> Otoh, the process of resolving chains like x.y.z.func(...) remains murky.  
> For example:
>
> # [In LeoTagWidget.__init__]
> self.tc = self.c.theTagController
> # [In LeoTagWidget.update_current_tags]
> tc = c.theTagController
> tc.remove_tag(p,tag) # [should be p.v]
>
 
> The problem seems mysterious, after all these years.

Oops.  I omitted a piece of the puzzle:

# In TagController.__init__
c.theTagController = self​

All parts of the puzzle reside in a single file, so there *must* be a way 
of detecting the error.

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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: ENB: Prototype of convention checker

[Edward K. Ream]

On Friday, December 8, 2017 at 4:59:32 AM UTC-6, Edward K. Ream wrote:

*tl;dr:* Read the summary

*> I am now in the process of putting this project on the back burner*

Like the process of ending a project, deferring a project may be a 
protracted process, not a milestone or instant in time.

Here are some additional thoughts, some to be transferred to #632 

.

1. To *kill* this project I would have to prove that a convention checker 
could *never* find bugs that pylint or pyflakes miss.  That assertion is 
simply false, as discussed below.  So the project remains "alive".

2. Would I use such a checker if it existed?  You bet I would!  I would run 
it automatically whenever saving an external files, provided the pyflakes 
checks pass.

3. Is this project worthwhile? That's a much harder question! Here are some 
additional thoughts...

*Using ast's*

Previously I said, "Translating the prototype into ast-based code would 
instantly embroil me in all the old complexities."  This statement is 
somewhat  misleading.

The regex patterns in the prototype detect class statements, def 
statements, and two kinds of assignments.  Recognizing classes and defs in 
the ast tree happens automatically.  Otoh, recognizing specific kinds of 
assignments using the ast is indeed clumsy.  But for prototypes one could 
actually use the regex patterns *applied to the "dump" of the statement.  *So 
this problem isn't a gotcha.

*Computing known objects*

The million-dollar question is: how many known types (of objects) can the 
checker compute *easily?*

Well, some types *can* be computed easily.  "self" is an instance of the 
class in which it appears. So for instance, if the bug fixed by #627 

 
where confined to a single class, a convention checker would have known 
what self.remove_tag refers to and thus could have detected that the p.v 
argument in the call does not match the p argument in the signature.

Imo, this refutes the assertion that the checker could *never* find 
mistakes not found by pyflakes or pylint.  

Otoh, the process of resolving chains like x.y.z.func(...) remains murky.  
For example:

# In the ctor
self.tc = self.c.theTagController
# In another method
tc = c.theTagController
tc.remove_tag(p,tag)

The problem seems mysterious, after all these years.

*Summary*

This project will remain on the back burner unless I have some new insights 
into computing known objects.

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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Searching on LeoEditor site is broken

[Largo84]

Try doing a search for any topic on Leo's main web site and you will likely 
get something like this (searched for 'mark'):



-- 
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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

The cft crash: understanding vs type checking

[Edward K. Ream]

I'd like to say a few words relating to the crash that #627 
 fixes.

*Prefer positions to vnode in calling conventions*

The reason is straightforward.  Positions contain more information than 
vnodes.

Given a position p, p.v is its unique vnode.  But given a node v, there may 
be several positions p with v == p.v.

*The crash was more than botched call*

1. In several places, I replaced code like:

for v in self.c.all_unique_nodes():
p = self.c.vnode2position(v)

with:

for p in self.c.all_unique_positions():

This is a direct application of the principle that positions carry more 
data than vnodes.

2. If I have recreated the diffs properly, the old version of item_selected 
was:

def item_selected(self):
c = self.c
key = id(self.listWidget.currentItem())
v = self.mapping[key]
pos = c.vnode2position(v)
self.update_current_tags(pos)
c.selectPosition(pos)
c.redraw()

The corrected version of item_selected method is:

def item_selected(self):
c = self.c
key = id(self.listWidget.currentItem())
v = self.mapping[key]
if isinstance(v, leoNodes.VNode):
p = c.vnode2position(v)
assert isinstance(p, leoNodes.Position), repr(p)
self.update_current_tags(p)
c.selectPosition(p)
c.redraw()

self.mapping can contain either vnodes or positions, so the new code is 
more robust and more explicit.

Neither type checking nor convention checking would be able to create the 
improved code. Neither type checking nor convention checking would be able 
to detect any problem at all without lots of help.

3. The nodetags.py plugins caches vnodes.  This is fine as long the plugin 
(in effect) recreates the cache when the outline changes.

*Summary*

#632  (convention 
checking) envisages a tool that would not have completely fixed #627 
.

Rather than relying on a non-existent tool to distinguish vnodes from 
positions, devs should use positions wherever possible.

In any case, devs must remember that positions *will* become invalid when 
the outline changes.

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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: ENB: Prototype of convention checker

[Edward K. Ream]

On Thursday, December 7, 2017 at 12:53:59 PM UTC-6, Edward K. Ream wrote:

Furthermore, the "deductions" involved in:
>
> self.x= self.c=c
> self.x= self.tc=self.c.theTagController
>
> are non-trivial for programs. 
>

I have given this matter considerable thought over the last 24 hours. Here 
is the summary:

- The regex-based prototype was a success only because it was completed 
quickly ;-)

- I am no longer sure that this project is feasible, or  valuable in 
practice.

- Translating the prototype into ast-based code would instantly embroil me 
in all the old complexities.

- If I were to restart this project, I would likely used a text-based 
approach for prototypes rather than ast's.

*I am now in the process of putting this project on the back burner*

- I have rewritten the first comment of #632 
. They are now more 
guarded in their outlook.

- Added the BackBurner label.

- Rev fa40b3c encapsulates yesterday's work as the ConventionChecker class 
in leoCheck.py. Its docstring shows a simplified @button node that tests 
the code.

- I will soon write a post discussing the type problems in #627 
, the issue that 
prompted me to create #632.

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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.