Re: New persistence code ready for testing!
On Tue, Jul 15, 2014 at 8:17 PM, 'Terry Brown' via leo-editor leo-editor@googlegroups.com wrote: It seems that the uA persisting code really should try and save uA info on nodes it can't match... I agree. I guess it's a question of what the uA data is. No. It's simply a question of where to put restored nodes that contain the uA's. So just general interest, what happens when you delete __init__ from class A, do its uAs get assigned to __init__ in class B? And then where do B.__init__'s uAs get assigned? Good point. The code should warn if a node's uA's get assigned twice. Another warning I've been meaning to mention: pd.find_position_for_relative_unl should probably warn if two nodes match according the the new algorithm *and* both matches have the same length. The matches will *not* have the same length in the example you mention, so maybe that can be used to disambiguate what node is meant. Alternatively, it may be best simply to require an exact match, and fall back on creating nodes to hold uA's in case no match is found. I'll think about this. I really should try the code :-) Remember that the *only* way that problems can arise is if you (or someone else) modifies the @auto node outside Leo. 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
On Wednesday, July 16, 2014 2:16:45 AM UTC-5, Edward K. Ream wrote: On Tue, Jul 15, 2014 at 8:17 PM, 'Terry Brown' via leo-editor leo-editor@googlegroups.com wrote: ...it may be best simply to require an exact match, and fall back on creating nodes to hold uA's in case no match is found. As of the latest rev, pd.find_position_for_relative_unl contains this code. if 1: return pd.find_exact_match(root,unl_list) else: return pd.find_best_match(root,unl_list) Given our discussion of ambiguous unl's and restoring unmatched uA's, I think the simplest thing that could possibly work is to require exact matches, and to save unmatched uA's somewhere. So the first part of plan is in place... 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
On 7/16/2014 8:59 AM, Edward K. Ream wrote: the simplest thing that could possibly work Ockham's Razor at work! Good :) Nice work, Edward. Keep it up! --Jake -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
First impressions: - the @auto node icons indicate they are clones - I'm not sure why the @persistence tree is visible, can it be used for something? Maybe somehow useful in resolving issues? On Wed, Jul 16, 2014 at 8:29 AM, Jacob Peck gatesph...@gmail.com wrote: On 7/16/2014 8:59 AM, Edward K. Ream wrote: the simplest thing that could possibly work Ockham's Razor at work! Good :) Nice work, Edward. Keep it up! --Jake -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout. -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
On Wed, Jul 16, 2014 at 9:00 AM, Kent Tenney kten...@gmail.com wrote: First impressions: - the @auto node icons indicate they are clones Only if they are clones :-) - I'm not sure why the @persistence tree is visible, can it be used for something? Maybe somehow useful in resolving issues? @persistence trees contain all data used to restore gnx's and uA's in @auto nodes. So yes, they are used for something ;-) They are visible because all Leo nodes are visible, but the recommended place for them would be squirreled away in the @startup node. I just upped code that starts to support @recovery trees in each per-file @data tree: 1. pd.update_before_write_foreign_file now deletes all children of the corresponding @data node *except* the first @recovery node (and its subtree). 2. When an exact match for a unl isn't found, the read code calls pd.recover_ua_for_gnx. At present, this does nothing, but it will soon write a child of the @recovery node. Something like:: @recovered-ua gnx = unl It's body text will be the pickled ua. This is, I think, about all that can be done to preserve uA's when an url is not found. 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
On Wednesday, July 16, 2014 9:14:59 AM UTC-5, Edward K. Ream wrote: On Wed, Jul 16, 2014 at 9:00 AM, Kent Tenney kten...@gmail.com wrote: First impressions: - the @auto node icons indicate they are clones Only if they are clones :-) I do notice that the icon box has a black border, indicating that the @auto node is dirty. That's a recent problem. I'll fix it asap. EKR -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
On Wed, Jul 16, 2014 at 9:14 AM, Edward K. Ream edream...@gmail.com wrote: On Wed, Jul 16, 2014 at 9:00 AM, Kent Tenney kten...@gmail.com wrote: First impressions: - the @auto node icons indicate they are clones Only if they are clones :-) No, all of them, none are clones. Sounds like you're already on this. - I'm not sure why the @persistence tree is visible, can it be used for something? Maybe somehow useful in resolving issues? @persistence trees contain all data used to restore gnx's and uA's in @auto nodes. So yes, they are used for something ;-) I was wondering if they are useful in user space. They seem like Leo bookkeeping. Presumably the user can break persistence by editing in that tree? They are visible because all Leo nodes are visible, but the recommended place for them would be squirreled away in the @startup node. I just upped code that starts to support @recovery trees in each per-file @data tree: 1. pd.update_before_write_foreign_file now deletes all children of the corresponding @data node *except* the first @recovery node (and its subtree). 2. When an exact match for a unl isn't found, the read code calls pd.recover_ua_for_gnx. At present, this does nothing, but it will soon write a child of the @recovery node. Something like:: @recovered-ua gnx = unl It's body text will be the pickled ua. This is, I think, about all that can be done to preserve uA's when an url is not found. 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout. -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
On Wednesday, July 16, 2014 9:22:03 AM UTC-5, Edward K. Ream wrote: I do notice that the icon box has a black border, indicating that the @auto node is dirty. That's a recent problem. I'll fix it asap. This looks like an interaction problem with the bookmarks.py plugin. Not exactly sure it's fair to blame the plugin... Restoring an icon from a persisted uA has the unwanted side effect of setting the @auto file dirty. I spent some time tracking down this bug, but have no good idea about how to squash it. Terry, do you have any ideas? 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
On Wed, 16 Jul 2014 11:41:37 -0700 (PDT) Edward K. Ream edream...@gmail.com wrote: On Wednesday, July 16, 2014 9:22:03 AM UTC-5, Edward K. Ream wrote: I do notice that the icon box has a black border, indicating that the @auto node is dirty. That's a recent problem. I'll fix it asap. This looks like an interaction problem with the bookmarks.py plugin. Not exactly sure it's fair to blame the plugin... Restoring an icon from a persisted uA has the unwanted side effect of setting the @auto file dirty. I spent some time tracking down this bug, but have no good idea about how to squash it. Terry, do you have any ideas? You mean todo.py, not bookmarks.py, right? It's tricky, the file should definitely be marked dirty when the user manually changes the todo status. It probably shouldn't be marked dirty when the todo uAs change during load (this happens with the due date icon, which is updated to future / today / overdue during load). It probably should be marked dirty when things change programatically (i.e. not manually) at times other than during load. Is there something todo.py can call to see if Leo's currently loading the commander it's in, so not startup in general but loading specifically for this c? If not, todoController could maybe use hooks to get that info. itself, i.e. a .mark_dirty() method that uses an ivar which is initially false (don't mark dirty) but changes to true on `open2` hook perhaps, provided it's called late enough. Cheers -Terry -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
On Wed, Jul 16, 2014 at 9:14 AM, Edward K. Ream edream...@gmail.com wrote: I just upped code that starts to support @recovery trees in each per-file @data tree: Rev 9a082a8... fixes several problems. All tests pass, including some by-hand tests of real-world scenarios. The only remaining items with this project are clearing the dirty marker and adding a clean-persistence command. 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
On Monday, July 14, 2014 2:00:48 PM UTC-5, Edward K. Ream wrote: On Mon, Jul 14, 2014 at 11:49 AM, 'Terry Brown' via leo-editor leo-editor@googlegroups.com wrote: I asked a vague question about the status of vc.find_absolute_unl_node and vc.find_position_for_relative_unl the other day, what I meant was, what do they do that g.recursiveUNLFind doesn't? Thanks for this reminder. I'll look into g.recursiveUNLFind. As an exercise, I am going to try to find something simpler pd.find_position_for_relative_unl. I don't believe child indices have much hope of improving matches during @auto: I would rather have links break than link to the wrong node. Edward EKR -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
On Tue, 15 Jul 2014 04:39:06 -0700 (PDT) Edward K. Ream edream...@gmail.com wrote: On Monday, July 14, 2014 2:00:48 PM UTC-5, Edward K. Ream wrote: On Mon, Jul 14, 2014 at 11:49 AM, 'Terry Brown' via leo-editor leo-editor@googlegroups.com wrote: I asked a vague question about the status of vc.find_absolute_unl_node and vc.find_position_for_relative_unl the other day, what I meant was, what do they do that g.recursiveUNLFind doesn't? Thanks for this reminder. I'll look into g.recursiveUNLFind. As an exercise, I am going to try to find something simpler pd.find_position_for_relative_unl. I don't believe child indices have much hope of improving matches during @auto: I would rather have links break than link to the wrong node. Use of indices by g.recursiveUNLFind is optional though, so there may still be duplicated functionality. I won't have time today, but I can try and make g.recursiveUNLFind a bit clearer, if that helps. On a different topic, somewhat. It seems that the uA persisting code really should try and save uA info. on nodes it can't match, otherwise you're making an assumption the uA info. isn't really valuable. In some cases it may not be, but you can't assume that's always true. So what I was thinking was that the orphan nodes could have an UNL (in their uAs :-) which points to the best guess imported node, perhaps with a couple of helper commands `orphan-node-goto-best-guess`, `orphan-node-copy-uA`, and `orphan-node-paste-uA` Not that this needs to be done immediately or anything, I haven't even played with the new code yet. It seems to me that the biggest payoff may be the persisting gnxs, really. Cheers -Terry Edward EKR -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
On Tue, Jul 15, 2014 at 7:04 AM, 'Terry Brown' via leo-editor It seems that the uA persisting code really should try and save uA info on nodes it can't match... So what I was thinking was that the orphan nodes could have an UNL (in their uAs :-) which points to the best guess imported node, perhaps with a couple of helper commands... There is no such thing as a best guess. The present code will use any unl whose tail matches any node in the @auto tree. If that doesn't work, Leo could create such a node, and put the uA in it. I suppose one could then have a copy uA command. Not very exciting, imo, but it might be useful in some situations. 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
On Tue, 15 Jul 2014 17:50:21 -0500 Edward K. Ream edream...@gmail.com wrote: On Tue, Jul 15, 2014 at 7:04 AM, 'Terry Brown' via leo-editor It seems that the uA persisting code really should try and save uA info on nodes it can't match... So what I was thinking was that the orphan nodes could have an UNL (in their uAs :-) which points to the best guess imported node, perhaps with a couple of helper commands... There is no such thing as a best guess. The present code will use any unl whose tail matches any node in the @auto tree. If that doesn't work, Leo could create such a node, and put the uA in it. I suppose one could then have a copy uA command. Not very exciting, imo, but it might be useful in some situations. I guess it's a question of what the uA data is - I sometimes store very valuable data in uAs, but of course up until now never on an @auto file, in fact typically not in any @file type. So I'm not sure what people would store on nodes in @auto files, but if for example it was notes on things that need to be done to the code, and if for example one off the notes was remember to replace my google password with prompt for user input before release, and if the note vanished and you subsequently forgot, you might be saddened by that :-) Silly example, but it seems in general people won't want data to only persist sometimes. Of course you did have to make uAs persistent :-) I think persistent gnxs would have done it for Kent. So just general interest, what happens when you delete __init__ from class A, do its uAs get assigned to __init__ in class B? And then where do B.__init__'s uAs get assigned? I really should try the code :-) Cheers -Terry -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
On Mon, Jul 14, 2014 at 8:48 AM, Edward K. Ream edream...@gmail.com wrote: As of rev 25101ddf3b0c... Leo now saves and restores clone links and uA's in @auto trees! For example, use the todo plugin to add an icon to a node in an @auto file. Save the file and reload. The icon will still be there. Ditto for clones links for between node a node C inside an @auto file and a cloned node C outside the @auto file. Such links should persist *provided* you don't change the outline structure (including headlines) of the @auto file outside of Leo. This is a show-stopper for me, and probably evidence of my outlier status. I'm as likely to work in vim as Leo, on-the-run work done in vim, more formal sessions from Leo. If changes outside Leo break @auto, it's no longer @auto in my book. The question seems to be: 'which is canonical, myfile.py, or myfile.leo' for true leonistas, the latter is fine, I need the former. All this means is that you are solving a problem that I don't have, but one that presumably, many others do. From the next message But how often do you, in fact, change outline structure outside of Leo? And how often do you change the *names* of imported things outside of Leo? Not all that often, I'm guessing. BZT wrong guess, as described above. (and, evidenced by the recurring mention of the 'refresh from disk' bug) I'll continue looking at @auto persistence via back-end db. Thanks, Kent All changes are *lightly* tested. Please report any problems immediately. To disable the new code, set new_auto = False at the start of leoAtFile.py. 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout. -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
On Mon, Jul 14, 2014 at 9:22 AM, Kent Tenney kten...@gmail.com wrote: Such links should persist *provided* you don't change the outline structure (including headlines) of the @auto file outside of Leo. This is a show-stopper for me, and probably evidence of my outlier status. I'm as likely to work in vim as Leo, on-the-run work done in vim, more formal sessions from Leo. If changes outside Leo break @auto, it's no longer @auto in my book. I think you will find that the present scheme will work well for you. Please try it. The question seems to be: 'which is canonical, myfile.py, or myfile.leo' for true leonistas, the latter is fine, I need the former. myfile.py *is* canonical, if I understand you correctly. The new @auto is exactly the same as the old @auto in this regard. The parser hasn't changed: you *always* get the outline structure of the imported file. Period. Persisted data have got to be stored somewhere. In the present scheme, they are stored in the @persistence tree, but it really doesn't matter where the data are stored. Putting them in a db changes nothing. The question isn't which data is canonical, the question is how to link data with incoming nodes. All this means is that you are solving a problem that I don't have, but one that presumably, many others do. I have solved the one and only problem that we have been talking about for these many years: how to associate uA's and clone links with imported outlines. You are asking for the impossible if you demand that the links between persisted data and incoming nodes *never* break. Only sentinels with gnx's provide truly unbreakable links. Bookmarks (unl's) along with a flexible (but not perfect) algorithm that associates the unl's of incoming nodes with gnx's (and hence, persisted data) seem like the only possible approach. If you want something better than bookmarks, please explain how it might possibly work. 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
On Mon, Jul 14, 2014 at 9:52 AM, Edward K. Ream edream...@gmail.com wrote: On Mon, Jul 14, 2014 at 9:22 AM, Kent Tenney kten...@gmail.com wrote: Such links should persist *provided* you don't change the outline structure (including headlines) of the @auto file outside of Leo. This is a show-stopper for me, and probably evidence of my outlier status. I'm as likely to work in vim as Leo, on-the-run work done in vim, more formal sessions from Leo. If changes outside Leo break @auto, it's no longer @auto in my book. I think you will find that the present scheme will work well for you. Please try it. The question seems to be: 'which is canonical, myfile.py, or myfile.leo' for true leonistas, the latter is fine, I need the former. myfile.py *is* canonical, if I understand you correctly. The new @auto is exactly the same as the old @auto in this regard. The parser hasn't changed: you *always* get the outline structure of the imported file. Period. Persisted data have got to be stored somewhere. In the present scheme, they are stored in the @persistence tree, but it really doesn't matter where the data are stored. Putting them in a db changes nothing. The question isn't which data is canonical, the question is how to link data with incoming nodes. All this means is that you are solving a problem that I don't have, but one that presumably, many others do. I have solved the one and only problem that we have been talking about for these many years: how to associate uA's and clone links with imported outlines. You are asking for the impossible if you demand that the links between persisted data and incoming nodes *never* break. Only sentinels with gnx's provide truly unbreakable links. I think I see the problem. Such links should persist *provided* you don't change the outline structure (including headlines) of the @auto file outside of Leo. I read this as changing outside Leo breaking the import, not just the inevitable issue of 'here's an unknown node'. I bet the changed nodes get a fresh gnx and a blank uA correct? As you say, that's all that is possible. Sorry for the noise. Bookmarks (unl's) along with a flexible (but not perfect) algorithm that associates the unl's of incoming nodes with gnx's (and hence, persisted data) seem like the only possible approach. If you want something better than bookmarks, please explain how it might possibly work. 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout. -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
On Mon, Jul 14, 2014 at 10:06 AM, Kent Tenney kten...@gmail.com wrote: I think I see the problem. Such links should persist *provided* you don't change the outline structure (including headlines) of the @auto file outside of Leo. I read this as changing outside Leo breaking the import, not just the inevitable issue of 'here's an unknown node'. The import will be fine. I bet the changed nodes get a fresh gnx and a blank uA correct? As you say, that's all that is possible. Exactly. Sorry for the noise. Whew! I'm glad we're on the same page now :-) 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
On Mon, 14 Jul 2014 06:48:18 -0700 (PDT) Edward K. Ream edream...@gmail.com wrote: As of rev 25101ddf3b0c... Leo now saves and restores clone links and uA's in @auto trees! For example, use the todo plugin to add an icon to a node in an @auto file. Save the file and reload. The icon will still be there. Ditto for clones links for between node a node C inside an @auto file and a cloned node C outside the @auto file. Such links should persist *provided* you don't change the outline structure (including headlines) of the @auto file outside of Leo. Ok, this took me a while to parse (haha), but Kent's got it well clarified now :-) So how hard does the new code try to recover from breakage? Does it use the new indexed UNLs to fall-back on position index when headlines fail? I guess it's a more sensitive case than bookmarks, where Leo can basically say I can't find that, but it used to be here, if that helps, and let the user decide. In the import case you could only fall back on the position index when the matched node was not also matched by a headline list. I.e. class Foo def __init__ def otters def recieve_data def send_data if it's simply a change from recieve_data to receive_data, falling back on position index would be great. But if the change was to class Foo def __init__ def otters def send_data def receive_data then headline search would fail and index search should fail because of the competing headline search match for send_data. Also, does the new code use the new UNL's repeated headline count to match the right headline when headlines are repeated? Repeated headlines in python code would be contrived, e.g. def fooble(arg1): this doesn't work, retained for historical interest code code def fooble(arg1): working version code code although this is dumb but valid: PROCESSORS = [] def processor(args, args): code PROCESSORS.append(processor) def processor(args, args): different code PROCESSORS.append(processor) but repeated headlines in other languages might be entirely reasonable, div in parsed HTML being a trivial example. So when breakage does occur, does the new code make a list of nodes not found with their uA data still attached? Because that could be really useful when valuable uA data was involved. Final questions: Are gnxs persisted? What are the differences between this and @shadow? Cheers -Terry All changes are *lightly* tested. Please report any problems immediately. To disable the new code, set new_auto = False at the start of leoAtFile.py. 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
On Mon, Jul 14, 2014 at 10:11 AM, Edward K. Ream edream...@gmail.com wrote: On Mon, Jul 14, 2014 at 10:06 AM, Kent Tenney kten...@gmail.com wrote: I think I see the problem. Such links should persist *provided* you don't change the outline structure (including headlines) of the @auto file outside of Leo. I read this as changing outside Leo breaking the import, not just the inevitable issue of 'here's an unknown node'. The import will be fine. I bet the changed nodes get a fresh gnx and a blank uA correct? As you say, that's all that is possible. Exactly. Sorry for the noise. Whew! I'm glad we're on the same page now :-) Indeed, hate to see fisticuffs on this list [-; Initial test is REALLY exciting, in addition to complete support for the 'choices' stuff, the timestamps in uA are persistent ... Amazing stuff Edward. Thanks, Kent 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout. -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
On Mon, Jul 14, 2014 at 10:41 AM, 'Terry Brown' via leo-editor leo-editor@googlegroups.com wrote: So how hard does the new code try to recover from breakage? At present, Leo attempts no error recovery. Does it use the new indexed UNLs to fall-back on position index when headlines fail? I have no idea what you mean by this. If a bookmark (unl) can't be associated with a node (headline) then the node's gnx doesn't change: it won't be a clone of any node an it won't have any uA. I guess it's a more sensitive case than bookmarks, where Leo can basically say I can't find that, but it used to be here, if that helps, and let the user decide. That might happen later. In the import case you could only fall back on the position index when the matched node was not also matched by a headline list. I.e. class Foo def __init__ def otters def recieve_data def send_data if it's simply a change from recieve_data to receive_data, falling back on position index would be great. But if the change was to class Foo def __init__ def otters def send_data def receive_data then headline search would fail and index search should fail because of the competing headline search match for send_data. All of this is what I am calling AI. I would prefer not to do anything in such cases. At what point does an (obvious???) misspelling turn into a real change. Rather than try to answer such deep questions, I would prefer to accept the inevitable: some links to gnx's will break. It would be easy to report such breaks, as you suggest. In fact, pd.restore_gnx will do this if the trace var is True. Also, does the new code use the new UNL's repeated headline count to match the right headline when headlines are repeated? No. That's on purpose. Repeated headlines in python code would be contrived, e.g. [snip] I agree. Pylint will report duplicate function/method in such cases. but repeated headlines in other languages might be entirely reasonable, div in parsed HTML being a trivial example. Interesting. Imo, the solution for html would be to add more to the imported headline :-) So when breakage does occur, does the new code make a list of nodes not found with their uA data still attached? Because that could be really useful when valuable uA data was involved. Interesting idea. pd.update_after_read_foreign_file could easily create a list/tree of nodes with potentially valuable uA's, with headlines derived from the unmatched corresponding unl in the @gnxs node. This would work much like the recovered nodes nodes that Leo creates when reading @file nodes. Having said that, my experience is that such recovered data are rarely used, even when the data are text. I suspect recovered uA's would hardly ever be used. Are gnxs persisted? Yes. The @gnxs node contains pairs of lines associated the (persisted) gnx's with unl's. If the match is made, pd.pd.restore_gnx restores the gnx of the imported node by calling p2._relinkAsCloneOf(p1). It's slick. If the match can't be made, the node retains the (new) gnx given to it by the importer, with a timestamp that reflects the time that the node was imported. What are the differences between this and @shadow? Good question. @shadow recreates the outline using the Leo sentinels in the so-called private file. All gnx's (and so clone links and uA's) are preserved. @shadow works by diffing text, namely the diffs between the public file and the private file (stripped of sentinels). The public file never has any sentinels, so all changes to the public file get translated into text in the original nodes in the private file. With @shadow, all changes to the outline structure, **no matter how big**, are shoe-horned into the outline structure of the private file. In contrast, the @auto importers have no access to any sentinels. They create a tree based solely on the logical structure of the imported file. In particular, headlines in @auto files can only come from the names of functions, classes and methods. Aside: The old new @auto code tried to rename/retain headlines, but that created way too many complications. I have no plans to bring that scheme back. In short: @auto always give you the correct structure of the imported file. The @auto importers know nothing of gnx's. @shadow always preserves the structure of the outline when it was last written, including gnx's. That may not be great when big changes have been made. 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
On Mon, Jul 14, 2014 at 10:46 AM, Kent Tenney kten...@gmail.com wrote: Whew! I'm glad we're on the same page now :-) Indeed, hate to see fisticuffs on this list [-; Yeah, I was about to give you a phone call ;-) Initial test is REALLY exciting, in addition to complete support for the 'choices' stuff, the timestamps in uA are persistent ... Excellent. What do you mean by choices stuff? Amazing stuff Edward. Thanks. *That's* the response I was expecting. Hehe. It's very satisfying that the code is so much simpler than before. At present, I plan only two more changes: 1. As discussed previously, pd.find_position_for_relative_unl will be rewritten to be more flexible when searching for matches between unl's and the incoming imported outline. This will reduce broken links. 2. The clean-persistence-tree command will remove @data nodes that do not correspond to any existing foreign file (for now, read @auto tree). 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
On Mon, Jul 14, 2014 at 11:29 AM, Edward K. Ream edream...@gmail.com wrote: On Mon, Jul 14, 2014 at 10:46 AM, Kent Tenney kten...@gmail.com wrote: Whew! I'm glad we're on the same page now :-) Indeed, hate to see fisticuffs on this list [-; Yeah, I was about to give you a phone call ;-) Initial test is REALLY exciting, in addition to complete support for the 'choices' stuff, the timestamps in uA are persistent ... Excellent. What do you mean by choices stuff? The 'left' and 'right' buttons which offer multiple node contents to be available from the back end db, was posted as lndb.py plugin. Amazing stuff Edward. Thanks. *That's* the response I was expecting. Hehe. It's very satisfying that the code is so much simpler than before. At present, I plan only two more changes: 1. As discussed previously, pd.find_position_for_relative_unl will be rewritten to be more flexible when searching for matches between unl's and the incoming imported outline. This will reduce broken links. 2. The clean-persistence-tree command will remove @data nodes that do not correspond to any existing foreign file (for now, read @auto tree). 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout. -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
On Mon, 14 Jul 2014 11:29:19 -0500 Edward K. Ream edream...@gmail.com wrote: On Mon, Jul 14, 2014 at 10:46 AM, Kent Tenney kten...@gmail.com wrote: Whew! I'm glad we're on the same page now :-) Indeed, hate to see fisticuffs on this list [-; Yeah, I was about to give you a phone call ;-) Initial test is REALLY exciting, in addition to complete support for the 'choices' stuff, the timestamps in uA are persistent ... Excellent. What do you mean by choices stuff? Amazing stuff Edward. Thanks. *That's* the response I was expecting. Hehe. It's very satisfying that the code is so much simpler than before. At present, I plan only two more changes: 1. As discussed previously, pd.find_position_for_relative_unl will be rewritten to be more flexible when searching for matches between unl's and the incoming imported outline. This will reduce broken links. I asked a vague question about the status of vc.find_absolute_unl_node and vc.find_position_for_relative_unl the other day, what I meant was, what do they do that g.recursiveUNLFind doesn't? It seems like we have two methods to do the same thing, and I think it's already caused confusion dev. wise, when the smarter bookmarks were being developed and the vc.* commands were updated even though they weren't relevant. Cheers -Terry 2. The clean-persistence-tree command will remove @data nodes that do not correspond to any existing foreign file (for now, read @auto tree). 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: New persistence code ready for testing!
On Mon, Jul 14, 2014 at 11:49 AM, 'Terry Brown' via leo-editor leo-editor@googlegroups.com wrote: I asked a vague question about the status of vc.find_absolute_unl_node and vc.find_position_for_relative_unl the other day, what I meant was, what do they do that g.recursiveUNLFind doesn't? Thanks for this reminder. I'll look into g.recursiveUNLFind. EKR -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
