Constant checking in, gnx caching out
32 views
Skip to first unread message
Edward K. Ream
Mar 21, 2015, 8:43:48 AM3/21/15
to leo-e...@googlegroups.com
Last night Leo reported duplicate gnx's after cutting an outline from leoSettings.leo to leoPy.leo. I reported the details here. This is an extremely serious bug. It's also perversely good news.
Here is the plan:
1. Discover why the gnx's collided. The gnx's report that the colliding vnodes were created yesterday, 20150320 at 233042. Folks, this makes no sense. Imo, a botch in gnx caching likely caused this collision. It's essential to find the cause of this bug before doing anything else.
2. Permanently activate all gnx checks, as discussed in this thread.
3. Get rid of the gnx caching scheme! It will no longer be needed when Leo calls check-outline regularly. Imo, gnx caching is dubious engineering. I am so looking forward to killing it.
Recall that gnx caching arose from a bizarre special case in which a Leo bridge opens several .leo files within the same second. check-outline can handle those special cases. The bridge won't mind the warnings -)
4. Fix paste-retaining-clones. It is fortunate that this issue has not yet been addressed.
Summary: We have come full circle. The problems with the bridge resulted in gnx caching. Problems with gnx caching prompted continuous checking of .leo files. Permanent, continuous checking will eliminate the need for gnx caching. The result will be a simpler, more robust Leo.
This work has top priority: we must test the resulting code for at least another work before releasing b1.
Edward
Here is the plan:
1. Discover why the gnx's collided. The gnx's report that the colliding vnodes were created yesterday, 20150320 at 233042. Folks, this makes no sense. Imo, a botch in gnx caching likely caused this collision. It's essential to find the cause of this bug before doing anything else.
2. Permanently activate all gnx checks, as discussed in this thread.
3. Get rid of the gnx caching scheme! It will no longer be needed when Leo calls check-outline regularly. Imo, gnx caching is dubious engineering. I am so looking forward to killing it.
Recall that gnx caching arose from a bizarre special case in which a Leo bridge opens several .leo files within the same second. check-outline can handle those special cases. The bridge won't mind the warnings -)
4. Fix paste-retaining-clones. It is fortunate that this issue has not yet been addressed.
Summary: We have come full circle. The problems with the bridge resulted in gnx caching. Problems with gnx caching prompted continuous checking of .leo files. Permanent, continuous checking will eliminate the need for gnx caching. The result will be a simpler, more robust Leo.
This work has top priority: we must test the resulting code for at least another work before releasing b1.
Edward
Edward K. Ream
Mar 21, 2015, 11:43:31 AM3/21/15
to leo-e...@googlegroups.com
On Saturday, March 21, 2015 at 7:43:48 AM UTC-5, Edward K. Ream wrote:
> 1. Discover why the gnx's collided.
> 1. Discover why the gnx's collided.
I have not been able to recreate this problem. Boo hoo.
Most gnx problems are intermittent. An unusual sequence of steps must happen for problems to manifest themselves. Bug #163 may be related. It (or something similar) exists Leo 5.0 final.
Lacking other ideas, I am going to move on to...
> 2. Permanently activate all gnx checks
Leo may as well get the best checks now.
> 3. Get rid of the gnx caching scheme
This will clarify the situation.
fc.gnxDict: This is the likely culprit if problems persist. Problems updating the gnxDict will create time bombs. I have initiated a thorough review of this dict using several sets of clone-find-all searches. The tempOutline keyword arg to c.pasteOutline stands out as highly dubious.
Improved consistency checking is revealing problems that have existed since 5.0 or even earlier. We shall deal with this systematically before 5.1 b1.
Edward
fc.gnxDict: This is the likely culprit if problems persist. Problems updating the gnxDict will create time bombs. I have initiated a thorough review of this dict using several sets of clone-find-all searches. The tempOutline keyword arg to c.pasteOutline stands out as highly dubious.
Improved consistency checking is revealing problems that have existed since 5.0 or even earlier. We shall deal with this systematically before 5.1 b1.
Edward
Edward K. Ream
Mar 21, 2015, 1:47:54 PM3/21/15
to leo-e...@googlegroups.com
On Saturday, March 21, 2015 at 10:43:31 AM UTC-5, Edward K. Ream wrote:
> fc.gnxDict: This is the likely culprit if problems persist.
The present code urgently needs revision. It's way too complex. Here are the principles:
1. Ever-increasing: No items will ever be deleted from this dict.
2. Limited setters: The read code adds entries when it sees <v> elements. Thereafter, only ni.getNewIndex should add new entries.
3. Constant checks: All setters will ensure that the to-be-created gnx is not already in fc.gnxDict. This check is super fast, and super important.
4. No ifs: Per #1 above, the dict will never be saved, restored or otherwise messed with. It must be obvious that gnxDict is always correct.
Edward
1. Ever-increasing: No items will ever be deleted from this dict.
2. Limited setters: The read code adds entries when it sees <v> elements. Thereafter, only ni.getNewIndex should add new entries.
3. Constant checks: All setters will ensure that the to-be-created gnx is not already in fc.gnxDict. This check is super fast, and super important.
4. No ifs: Per #1 above, the dict will never be saved, restored or otherwise messed with. It must be obvious that gnxDict is always correct.
Edward
Reply all
Reply to author
Forward
0 new messages