Notes re files not being updated

30 views

Skip to first unread message

Edward K. Ream

unread,

Dec 8, 2019, 7:23:30 AM12/8/19

to leo-editor

I have just revised code in the "bug-1451". Some cruft is gone, and several docstring improved.

I can find nothing seriously amiss. Indeed, several messy methods look completely innocent. Even if they were buggy they could not cause files to be skipped.

I have just updated the first comment of #1451. This comment summarizes what I did and my present thinking.

Please do continue to use the "bug-1451" branch and report any problems.

Summary

The code looks rock solid to me. I'll be merging the new code into devel sometime in the next few days.

Edward

Edward K. Ream

unread,

Dec 9, 2019, 6:44:04 AM12/9/19

to leo-editor

On Sun, Dec 8, 2019 at 6:23 AM Edward K. Ream <edre...@gmail.com> wrote:

I have just revised code in the "bug-1451". Some cruft is gone, and several docstring improved.

I can find nothing seriously amiss.

Doh! I was looking in the wrong place! The culprit is likely to be the code that calculates which @<file> nodes are dirty, not the code that writes those files!

Indeed, p.setAllAncestorAtFileNodesDirty changed for Leo 6.1. It's elegant, but I think it may be the culprit. There are subtleties involved. Next I'll compare the old and new versions

Reverting to the old code isn't straightforward, because the new code base assumes that p.setAllAncestorAtFileNodesDirty is fast.

My sincere apologies, once again, for this screw up. Clearly, a new unit test is needed. I'll attempt a fix asap.