On Fri, Aug 28, 2009 at 2:38 AM, Ville M. Vainio <[email protected]> wrote:
> > On Fri, Aug 28, 2009 at 5:00 AM, Edward K. Ream<[email protected]> > wrote: > > > My present opinion is that caching should be disabled for all nodes > except > > @thin nodes. The read logic for the various kinds of @<file> nodes is > > And @auto, @auto-rst. What other types of @<file> nodes do we have > that are round-tripped? @edit, @noref, @shadow, @root @edit, @auto and @auto-rst should be safe because no sentinels are involved: the read code imports the file every time. @shadow should be safe because it uses @thin technology. @noref is similar to @file: I had to look at leo\test\unittest\at-noref-test.py to know for sure. So caching for @noref should be disabled. @root files are unlikely to be cached at present, unless you went out of your way to do so. > > subtly different, and I am far from convinced that caching has been > > thoroughly tested. > > > Presumably uA's survive in @thin trees because of the the so-called > "hidden > > machinery" in @thin files, that is, the descendentTnodeUnknownAttribute > in > > the <v> element in the @thin node. The hidden machinery exists only for > > @thin trees. > > Yes, because only @thin files have uAs (because they have persistent > gnx's). The problem with @file may arise because sentinels in files derived from @file trees use file indices rather than gnx's, and these file indices are not cached. But I'm guessing, and Leo plays some tricky games with file indices and gnx's. > > in the "helpful" conversion code. So I think we should just advise > people > > not to use them in cooperative environments and leave it at that. > > Yes, that's the best plan for now. g.es a brief warning about them though. I agree. > > The problems happen in the trunk, so I don't see how we can pretend there > > are no problems. It may be that the problems are confined to @file nodes, > > and that we can solve those problems simply by never caching @file nodes, > > but I'm having troubles with the trunk, and I know of no changes that > would > > have broken the trunk. In other words, I think the problems existed in > Leo > > 4.6.2. > > Yeah, I do believe the problem is confined to the @file nodes. When > you disable the caching for @file nodes (I still think it's better to > leave it on for other file types), please do it in 46-maint branch > first so that we can have it in 4.6.3. I agree. A good first step will be to disable caching only for @file. I'll disable caching for @noref nodes if indeed they are ever cached. I'll do this immediately in the trunk, 46-maint and one-node branches. Edward P.S. An ironic question arises. If we deprecate @file nodes, shall we continue to unit test @file nodes? The problems with @file became apparent because of failed unit test in unitTest.leo, and that failed because an @file node in unitTest.leo did not read correctly. I want it both ways: I want to get rid of the @file node in unitTest.leo, and yet I want to continue to have unit tests for @file nodes! A possible solution would be to have a "virtual" @file node. Some unit tests already do that: you will see nodes that look like #...@file, #...@noref, etc. Perhaps similar tests can make the need for the actual @file nodes go away, but that is far from certain. EKR --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
