I'm afraid this level of detail is beyond me.
I don't understand Leo looking for nodes, I would expect
the @auto parsing component to be asking if a node had
been seen previously, something like
prior = found_in_auto_node_UA(<parsed component of external file>):
if prior is not None:
restore_prior_attrs(prior)
else:
<generate a standard auto node>
reviewing the first post
> Leo will store the needed in a tree (in the Leo outline) as follows
So Leo is persisting the tree of the @auto file? Doesn't that set the
stage for conflicts between the @auto parsing machinery and the
persisted tree?
I've been thinking along simpler lines, only persisting key/value
pairs like
{hash_contents:[uA, gnx], hash_contents:[uA, gnx] ...}
or
{hash_uri:[uA, gnx], hash_uri:[uA, gnx] ... }
if the parser comes across a node which matches one seen before, fine,
if it's new create a new gnx and empty uA, leaving all the tree management
work to the @auto parser.
Evidently I don't appreciate the complexities involved.
On Mon, Jul 14, 2014 at 7:23 AM, Edward K. Ream <[email protected]> wrote:
> On Sun, Jul 13, 2014 at 5:55 AM, Edward K. Ream <[email protected]> wrote:
>
>> Yesterday I started work on leoPersistence.py. It is a re-imagining of
>> leoViews.py.
>
> Work is going well: leoPersistence.py is a big collapse in complexity
> compared with leoViews.py.
>
> gnx's can now be restored in the easy case. The **hard case** arises
> when the structure of the imported file has been changed outside of
> Leo.
>
> Restoring uA's should be straightforward: the write logic saves
> pickled uA's in @ua nodes in the @uas tree. I'll add the code to
> restore uA's later today. This code uses restored gnx's and will work
> better when the restoration of gnx's becomes more reliable, as
> discussed below.
>
> I expect to enable the new code for general consumption later today by
> setting new_auto to True at the start of leoAtFile.py. I don't expect
> major problems, but if there are, you can just set this switch to
> False.
>
> ===== Associating unl's with gnx's
>
>> The only real difficulty is associating the unl's saved in @gnxs [nodes]
>> with the [imported] nodes. This will done
>> using...pd.find_position_for_relative_unl.
>
> As mentioned above, this works, provided that the relative unl's in
> the imported nodes haven't changed.
>
>> More in another thread.
>
> Rather than start another thread, I'll discuss
> pd.find_position_for_relative_unl here. Terry, Fidel, Kent, I
> especially look forward to your comments.
>
> It seems to me, that in *this* context, we don't particularly want
> unls that specify sibling position using the <headline>:M:N notation
> within parts of unls, as in g.recursiveUNLFind. Indeed, we don't care
> about sibling position when trying to associated gnx's with nodes.
> More importantly, perhaps, we do not expect two sibling nodes to have
> the same (imported) name, because that would mean we have a duplicate
> definition of the imported symbol!
>
> I *do* think that we need a way to expand the search for nodes if
> there is no exact match for the relative (to the root node) unl fails
> to match any imported node. However, I don't expect to use the
> <headline>:M:N notation.
>
> The general strategy will be to have a dictionary, say d, that
> associates headlines with lists of (copies of) positions. This will
> avoid scanning the entire outline repeatedly. If no exact match is
> found for a unl, the algorithm will use d to find the list of all the
> nodes corresponding to the *last* headline in the unl. For each
> position in the list, we can compute it's parents, and thus compute
> the longest unl that matches the to-be-matched unl. We pick the
> position in the list with the longest matching unl. This algorithm
> should be straightforward and very fast.
>
> ===== Summary
>
> I'll enable the new code later today by setting new_auto = True in
> leoAtFile.py. If there are problems, you can set this switch back to
> False. I'll enable the new code when restoring uA's works for the easy
> cases.
>
> The **hard case** arises when the structure of the imported file has
> been changed outside of Leo. In that case, a relative unls stored in
> the @persistence tree may not match any incoming node. I'll rewrite
> pd.find_position_for_relative_unl to find as many *reasonable* matches
> as possible.
>
> Your comments please, Amigos.
>
> 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 [email protected].
> To post to this group, send email to [email protected].
> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
