This thread could be called a continuation of "Leo 4.7 delayed until critical issues fixed". I'm starting a new thread to concentrate on code-level issues.
Rev 2751 of the trunk contains a major refactoring of atFile.read and related logic. See the checkin log for details. This refactoring allows Leo to determine whether an @file node uses file-like (old-style) or thin-like (new-style) sentinels. The old code used the presence or absence of a tnodeList in the root node **in the .leo file** to "guess" the kind of sentinels used. This is unsafe because it assumes that the .leo file and external file are always in sync. This may have been a component of the data problems I experienced a week ago. Last night I began a new task, namely using the presence of an @all directive in the (root node of) and external file to control whether clones in the external file should override clones in other files. This is not a simple project, for the following reasons: 1. It took me several hours(!) to discover how to recognize @all directives. The proper place is the atFile.readStartAll method. I had been thinking that the the leoFileCommands logic would be the place, but that is wrong for two reasons. First, Leo doesn't write the body text of @file or @thin nodes to the .leo file. That's actually fortunate, because second, we want to use the data in the external file to avoid the same syncing problem as that fixed in rev 2751. 2. readStartAll can set a flag indicating that cloned nodes should not override existing nodes. Presumably, createThinChild4 will use this flag, but details are not clear yet. 3. While looking at the code, I discovered what looks like a significant performance hit. The read code opens and reads the file twice: once to determine the caching key, and once to handle each line of the file. at.readLine does the actual line-by-line read, and converts to unicode using the proper encoding, that is, at.encoding. It should be possible to avoid the second open and read by creating a StringIO file for the line-by-line read logic. In particular, the new scheme will continue to use at.readLine, so unicode issues will be handled exactly as before. However, great care will be needed because atFile.read handles lots of complications related to @shadow, etc. 4. For testing, I had to disable caching by setting enableDB = False at the start of leoGlobals.py. Otherwise the read logic almost never gets used :-) This was another happy "accident" because it called my attention to v.createOutlineFromCacheList. The caching logic, now encapsulated in at.readFromCache, calls this vnode method to recreate (quickly!) the outline from the cached data. The question arises whether v.createOutlineFromCacheList will have to become aware of @all sentinels. If so, the logic that *writes* the cache will have to be aware of the @all sentinels: at.readFromCache does not examine the cached data in any way. In short, this is turning into quite a project. Imo, there is no alternative but to complete it: leaving things as they are ignores the critical data error. I hope to complete steps 2, 3 and 4 today or tomorrow. I'd like to create new unit tests, and the refactoring of the code into smaller, self-contained pieces helps, but there is no way to remove completely the risks inherent in this project. So the next release might better be called b2 rather rc1. We shall see... Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
