Rev a54f6662b fixes a mysterious bug that seemingly affected only python 2. The real mystery was why the previous code worked with python 3! I've filed this under "One of life's mysteries". It is unlikely ever to be solved.
The new code properly uses the existing root vnode, rather than creating a copy. The new code is much like the old, and simpler in a few places. For the first time, it might actually support @first and @last properly, though I haven't tested this yet. *Aside*: while investigating the mystery, I replaced defaultdict with plain dict. (At one time I mistakenly blamed defaultdict for the differences between 2 and 3). I've retained this change. For this code, using plain dicts is just a bit clearer. Differences in speed are irrelevant here. *Theory of operation* The essence of fast_at.scan_lines is exactly as Vitalije first presented it. I have only "curated" it. This includes supporting all of Leo's existing directives, including @delims, @comment, etc. The << init scan_lines >> section contains a few more local vars, but nothing difficult. My test script runs exactly as quickly as before, taking 0.09 seconds to handle all the .py files in leo/core. The actual read code must be slower, because creating "real" vnodes involves allocating gnx's. The test script uses a TestVNode class to ensure that the test doesn't corrupt the outline in which the script is running. I would like to make this script an official part of Leo, maybe as a unit test... *The entire project succeeds or fails based on the << handle node_start >> section in scan_lines*. I have spent two full days revising it. There are three cases, marked as such in the code: Case 1. The root vnode. This is straightforward. Case 2. Scanning the descendants of a clone. The clone itself, clone_v, has *cleared* its children array, thereby ensuring that existing clones (perhaps arising from the .leo file) can not possibly "pollute" the nodes presently being scanned. The "inner" code must *not* update structure links, that is parent_v.children or v.parents, *except* that the direct children of the clone must add themselves to parent_v.children, that is, clone_v.children. However, body text *is* updated within the descendants of a clone, again ensuring that there can be no unwanted pollution of the clones. As a side effect, the last node with the given gnx "wins" (in the external file). This handles what should be an extremely rare situation, namely that somebody has changed one cloned node (in the external file), but not the other. No check is made for this situation at present. It could be done, but it doesn't seem worth doing at present. Case 3: Not scanning the descendants of a clone. The new node, v, is a clone *if and only if* it already exists in the *global* gnx2vnode dictionary. In that case, we set clone_v = v, clear v.children and body (the list of body lines of the presently scanned node) and continue. Otherwise, v has never been seen before, so we must allocate a vnode for it. Either way, we *do* link the node into the parent vnode, appending to parent_v.children and adding parent_v to v.parents. *Summary* The present fast-read branch appears sound. In particular, the << handle node_start >> section in scan_lines now works as expected. Yes, << handle node_start >> is difficult, but it replaces *much *more difficult legacy code.* We aren't going back*. One way or another I *will* make scan_lines work. The new code will be part of the next official release. It may be months, however, before that happens. Much more testing is needed. The next step will be to merge the fast-read branch into the no-sax branch. The bugs that the fast-read branch now fixes might complicate the merge. Think about that for a moment. Once the merge *does *complete successfully the no-sax branch should also be immune from update problems. 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
