On Wednesday, January 15, 2014 11:53:46 AM UTC-6, Edward K. Ream wrote:
>>> All the hard work is complete!
This post will be pre-writing for the theory of operation. The project is,
truly, moving ever closer to completion.
Earlier last evening I spent several hours improving traces, refactoring
code, eliminating special cases and fixing small bugs with large impacts.
As a result, a new, interesting, easily solved problem arose. This looks
like the last significant problem in this project. I'll discuss this "last
problem" and it's solution below.
===== Refactoring & eliminating special cases
There is a new method: vc.precompute_all_data, that calls 5 helpers to init
all data before any call to demote_helper happens. There was no reason to
do any of this initing in demote_helper itself: it's much clearer to do it
in a separate init phase.
One of these helpers, vc.compute_organized_positions, will be involved to
the solution to the last problem, as discussed below.
vc.create_organizer_data (a helper of the main line, vc.demote_helper) now
sets od.parent = od.p for existing organizer nodes (nodes in
existing_organizer_data_list). As a result, vc.find_all_organizer_nodes is
now::
def find_all_organizer_nodes(self,od):
'''Return all OrganizerData instances organizing the same imported
source node as od.'''
# Because of existing organizers, we can't compare source_unl's.
# Instead just create the list using the od.parent field.
aList = [z for z in self.all_organizers_list if z.parent ==
od.parent]
return aList
I'm not entirely sure that od.p is correctly set for organizer nodes, but
however it is eventually inited, it must be inited so that
vc.find_all_organizer_nodes works as shown.
===== Small bugs with big impacts
I fixed a bug vc.switch_active_organizer, another helper of the main line,
vc.demote_helper. It must return (active,n) instead of (None,n) if
active.moved is True. In other words, it is emphatically *not* an error to
re-enter an organizer node multiple times. This bug caused nested
organizer nodes to terminate their parent organizer prematurely.
===== The "last problem" and its solution
As the result of the changes discussed above (and better traces), it became
clear that existing organizer nodes are not handled properly.
The symptom of the problem is a "not found" trace in
vc.compute_organized_position. For example, suppose that Y is to become a
child of an existing organizer node X. The trace says that the node
corresponding to the unl X-->Y can not be found. This lead to several
head-slapping moments:
1. Of course the node X-->Y can't be found--the importer will *not* have
created Y as a child of X!
2. Well, where *will* Y be found? After a bit of thought, the answer is
clear: Y must be a following sibling of X!
Proof: Y must have been a following child of X **when the
@existing-organizer: node was written**. Otherwise, the order of nodes in
the imported file would be different from the order of nodes in the
imported file. This is true even if other organizer nodes (existing or not)
are children of X.
This order-preserving requirement eliminated a lot of confusion. Because Y
must be a following sib of X, vc.compute_organized_positions can easily
compute the unl of where Y will be found. If od.exists, just remove the
penultimate part of the unl!
This simple change *might* suffice to handle existing organizer nodes. We
shall see, but not just yet. It's after 3 a.m. and time for a bit more
sleep...
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/groups/opt_out.
