On Sunday, January 12, 2014 6:38:40 AM UTC-6, Edward K. Ream wrote:
> 1. Nested and intermediate organizer nodes must be handled correctly
before doing anything else.
I fixed the "last" major bug just a few hours ago, in the middle of the
night. Significant unit tests of the new @auto now pass.
As discussed below, considerable work remains, but imo the new @auto
project is now a demonstrated success! All the hard work is complete!
===== What I did
I spent about 8 hours yesterday, in four different sessions, working up to
fixing problems that *seemed* to come from how organizer nodes were
handled. In some cases, children of organizers were in the wrong places.
Before tackling the bug head on I did the following:
- Added numerous traces to show in detail exactly what was happening.
- Rewrote vc.compute_descendants so it runs in O(N) time using a
straightforward recursive algorithm.
- Added vc.trail_write. This is an essential part of unit tests that had
gone missing until yesterday. Eventually, it probably should do a "real"
trial write, using at.writeOneAtAutoNode. However, the following works
well enough, and produces easier-to-understand dumps. It simply
concatenates the body text of all nodes::
def trial_write(self,p)
return ''.join([p.b for p in root.self_and_subtree()])
===== Fixing the bug
After several hours staring at traces, I realized that *all* the problems
were in vc.move_nodes_to_organizers. That is, vc.global_moved_node_list,
the global move node list, was completely correct! This was not obvious,
because that trace in vc.move_nodes_to_organizers reported the *sorted*
version of the global move list. Bad idea: it was the sorting itself that
was causing all the problems!
Recall that I thought sorting the list was required to keep positions
unchanged until they are moved. But an hour or so of experimentation (at
3am) convinced me that there is *no way* to move items from sorted lists
into the correct positions.
After a few minutes of noodling, the solution finally appeared. Rather
than *moving* nodes by moving positions, the *only* way that leaves
to-be-considered positions intact is to *copy* all the nodes of a
position's tree to the correct place. Eureka! A new method,
vc.copy_tree_to_last_child_of does the actual copying. A final phase in
vc.move_nodes_to_organizers deletes all positions in reverse outline
order. So yes, sorting *is* essential, but only at the very end.
Note: these difficulties do not apply to bare organizer nodes, because each
is placed in its own holding cell. But it's not possible to create holding
cells for non-bare organizers.
===== Still to do
Some relatively minor testing remains.The present unit tests probably do
not test whether "extra" nodes (not in the lists of unl's in the organizer
nodes, but newly-created by the importer) are placed in the proper places
(in organizer nodes if possible).
Several relatively minor projects remain:
1. Support @existing-organizer nodes.
Recall that *existing* organizer nodes are organizer nodes that the
importer will have created. Last night, after everything worked, I
reconsidered the design of existing organizer nodes in the light of the new
code. I wondered whether the existing code would correctly move such nodes
into their correct final positions.
The short answer is yes, because the importer will *not* have created any
children for existing organizer nodes. That being so, everything is
*exactly* as it is for organizer nodes, except that demote_helper and its
helpers never need to create the organizer. Some complications may arise,
but I expect them all to be minor.
2. Better vc.trial write
As noted above, the production version of the code should use the official
@auto write logic, rather than simply concatenating the body text of all
nodes.
3. Support for custom headlines (@headlines)
This is important. In a previous post I wrote the new @auto write code
could just warn if a headline has changed since the @auto file was read.
Wrong, wrong, wrong! It would be *unbearable* to have to lose custom
headlines. The new code must save and restore headlines that don't match
the **standard headlines**, the headlines that the importer will give the
node the *next* time the importer reads the @auto file.
A new @headlines node (a child of the @auto-view node for the @auto file)
will contain the required data. It will contain pairs of lines, much like
@clones::
unl: <a unl>
head: <the custom headline>
The unls in the @headlines node must use standard headlines! The "links"
created by @headlines node will break if the body text of a node changes so
as to change its standard headline. That is, @headlines links will break
when class, method or function names change.
To combat such breakage, whenever the body text of a node changes the code
that writes the @headlines node should *recompute* the unl using a
to-be-written convenience method in leoImport.py. The convenience method
will return the new standard headline.
4. Automatic conversion of @file to @auto
When converting an @file node to @auto *every* body text must be considered
changed. All unls in the @headlines node must be set using the headline
that the importer will create for the corresponding node.
===== Summary
The new @auto project has passed a crucial milestone. Except for existing
organizer nodes, all essential aspects of the project work reliably.
Supporting existing organizer nodes should be straightforward, but that is
not guaranteed. Maybe today.
The new @auto code must preserve custom headlines! A single @headlines
node will contain the required data. When both headline and body text have
changed (or when converting @file to @auto), the write code will call a new
convenience method in leoImport.py to recompute the node's new standard
headline.
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.
