On Thu, Jun 11, 2009 at 2:55 PM, Edward K. Ream<[email protected]> wrote:
>> This should be easy to fix - we just shouldn't enter the read() code >> if we are in a clone & have already read in the contents. This could >> probably also be fixed in the read() method, but that's the wrong >> place for it > > I agree. There are too many permutations and combinations of read code for > this to be a good solution. > > I assume the fix would be to g.create_tree_at_vnode (that's the only "real" > code that gets executed in the cashed-read logic). I would probably add a The problem is that I don't think we should ever enter create_tree_at_vnode in the first place. The clean way is to not come to read() at all, because all the work regarding that vnode is already done. >> >> (I think there is some workaround for this problem in the >> "slow" read code now, but that workaround should not be necessary). > > Yes. createThinChild4 and findFind4 are were the bodies are buried. I > don't remember the details, but you can see the code is ugly. Yeah, g.fast_add_last_child is my crystallization of createThinChild4 that only does the stuff I understand, and the stuff that is necessary IMO. I'd rather not complicate it with workarounds for problem at upper level of stack... I'll try to see what I can do this evening. -- Ville M. Vainio http://tinyurl.com/vainio --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
