The @settings trees themselves will be small, but the tree in which
they are (potentially) embedded is large. So let me change my
proposal: could we change from c.allNodes_iter to
c.all_positions_with_unique_tnodes_iter to find the @settings node?
It would mean skipping further occurrences of a cloned @settings node
(or a clone of a parent that contained an @settings node).
Leaving @settings aside, what do you think of ignoring all but the
first of cloned @button nodes?
Now that I've identified c.allNodes_iter as my nemesis, I've got a few
other changes to try, many of which shouldn't change the semantics.
- Stephen
On Mar 27, 7:22 am, "Edward K. Ream" <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 26, 2008 at 3:23 PM, thyrsus <[EMAIL PROTECTED]> wrote:
>
> > In my prior speedups, I replace c.allNodes_iter with something like
> > c.all_nodes_with_unique_tnodes and I believe I have not changed the
> > results generated. I see two more opportunities, but this *would*
> > change the Leo semantics. c.allNodes_iter is used to look for both
> > @settings and for @button nodes.
>
> > If I were to make this change, it would affect situations where you
> > had
>
> > @settings
> > @bool foo False # tx="sps.20080202000824"
> > @bool foo True # tx="sps.20080202000825"
> > @bool foo False # tx="sps.20080202000824"
>
> > E.g., the first and third foo are clone; we currently get a foo value
> > of False; the change would generate a foo value of True. Similarly:
>
> > @button do nothing # tx="sps.20080202000826"
> > @button do nothing # tx="sps.20080202000826"
>
> > E.g., a button has a clone, and generates two buttons. Under the
> > change only one button would get generated.
>
> > I very much doubt the above scenarios currently occur on purpose.
> > Would the proposed change to the semantics be acceptable?
>
> I find it hard to believe that processing an @settings tree will be
> materially improved by changing the iterator: the trees are not that large.
> Do you know for sure that changing the iterator would make any difference?
>
> As for the potential change in semantics, I don't care much, for the
> following reasons:
>
> 1. The example you give is bad style: it is good style to use clones to
> organize settings in more than one way. IMO, Leo is under no particular
> obligation to make sense of multiple conflicting settings.
>
> 2. The config code might possibly warn about duplicate settings in the same
> file, so I don't know what the present semantics are :-)
>
> Edward
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en
-~----------~----~----~----~------~----~------~--~---
