On Mon, Jun 8, 2009 at 9:47 PM, Ville M. Vainio<[email protected]> wrote:
> Actually, the way I implemented clone support for hash caching is > suggests that nodes that claim ownership of a tnode *first* take > precedence (and amazingly, it seems to work). That is, when you read > in a tree and see that this tnode already exists, you do not read in > the content but just create the clone to an already existing node to > that spot. That felt more intuitive to code than recreating the whole > tree and overriding previous clones. Apparently, that was wrong ;-). > I'll correct this. I'm not sure I was wrong, actually. Recreating the tree for cloned nodes every time you read it in would indicate that if you are using an already existing tnode, you would need to nuke all the children of the vnode when you hit a clone. I don't see this in createThinChild4. Also, I'm suspicious why my hashcache code seems to work correctly (i.e. I made a change in a node cloned both on qtNotes.txt and leoQtUi.py, saved, and reverted qtNotes.txt to a version without that change. Reload brought back that change, exactly as it should). Btw, I don't understand copies & cloneSibCount in createThinChild4. For reference, that function is here: http://pastebin.com/m7d9ca7c8 What's special about cloned siblings? My "read" (ok, cache import) code just takes the first instance of node (gnx) and uses that for all instances in the file (because the first time a node is created is always authoritative). -- 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 -~----------~----~----~----~------~----~------~--~---
