Do you think it would be feasible to simply copy the root of the tree to be operated on? Then the undo would entail pointing the tree's original parent to the copy and then redrawing. I don't know about copy performance (I suppose that a deep copy would be needed) on Leo nodes, but as a naive idea it seems simple.
On Thursday, May 7, 2020 at 2:42:24 PM UTC-4, vitalije wrote: > > In last few days I've been working on tests to be sure that all commands > in new prototype are working correctly and that no crash will ever occur. I > am pretty sure now that the implementation is correct and there are no > remaining bugs in the prototype. > > First of all I must say that testing with hypothesis is really great way > to discover hidden bugs. Several bugs were found in the previous > implementation that are very hard to imagine as a possible scenario. Of > course most of these bugs were related to clones. Hypothesis did find them > really quickly and I had to think hard how to solve them. After several > iterations of running hypothesis and solving found bugs, prototype is now > able to survive 5000 test sessions. At first I have started each test with > the complete LeoPyRef.leo outline, test would choose and select a random > position in this outline, and then it would perform a random sequence of > commands, checking after each command that both models (v-nodes and tree > widget items) are in sync. It used to take several minutes for a series of > 500 tests. > To speed up tests, I have changed test to use a smaller outline as > starting position. At start it inserts just five ordinary nodes > interspersed with five cloned nodes (total of 15 node). Now hypothesis runs > 5000 tests in about minute. After several executions no bug has been found. > > It is highly unlikely that a new bug will be discovered using this test. > That means we can be pretty sure that no matter what operations and in > whichever order user executes both models: v-nodes and tree widget items > will always remain in sync. The outline represented by each of them is > exactly the same. > > *Now the question of executing scripts* > > How should we re-synchronize tree widget with the possible changes in the > outline made by user script? The more I think about this problem, the more > I am sure that my initial plan of using diff algorithm won't work. It would > mess up with the undo system. Undo operations rely on the stability of tree > widget items. If any of items is destroyed and replaced with the new one, > undo blocks containing this item will be broken. But not all hope is lost. > It is possible to execute full redraw after executing any script. The > prototype contains now the `performance` command. This command measures the > time required for full redraw and storing all the information necessary to > undo the execute script command. On my computer this takes about 80ms for > LeoPyRef.db. On little older computers it may take even 200-300ms. That > means that every execute script command will take that much time longer to > execute. This is the worst case scenario. Usually outlines are smaller than > LeoPyRef.leo and this time delay will be much smaller in most cases. In > return we gain something that we didn't have before: the executeScript > command now becomes undoable as any other command. > > I can't speak for everyone else but I would gladly accept this delay on > each executeScript command and in return have an insurance that no error in > my script will destroy my outline irrecoverably. I would like to be sure > that in case of an error in script I still can undo the whole operation and > return to the previous state. I know for certain that on more than one > occasion I've missed this undo ability very much. > > Your comments please. > > Vitalije > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/97a43fe8-1bfe-436d-b8fa-542bab60a0a7%40googlegroups.com.
