Re: New persistence code ready for testing!
On Tue, 15 Jul 2014 17:50:21 -0500 "Edward K. Ream" 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 @ 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 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.
Rewrote pd.find_position_for_relative_unl
The repo now contains a rewritten, non-recursive, version of pd.find_position_for_relative_unl. Don't even *think* about replacing this code unless your code passes all the test cases in @test pd.find_position_for_relative_unl. Previous versions failed one or more parts of this test. The new code follows a strategy that is completely different from g.recursiveUNLSearch. Imo, this strategy is more appropriate for linking @auto imported nodes. It does not use sibling order in any way. As described in another thread, it first finds all nodes whose headline matches the tail of the unl. It then looks at the matching node's parents, and adds the parents' headlines if they match the expanding tail of the unl. If there are more than one matches, it picks the node with the longest match. 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 04:39:06 -0700 (PDT) "Edward K. Ream" 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 > > 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 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 > 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.
