Thoughts about the mvc prototype

48 views
Skip to first unread message

Edward K. Ream

unread,
May 5, 2020, 12:17:28 PM5/5/20
to leo-editor
First of all, this is a great prototype! A prototype like this is the essential first step if the qt code is to be changed.

In general, the code looks super elegant. Sometimes it's so elegant that it's a bit hard to know what is going on.

The QtPosition class looks like the heart of the code. It mirrors the corresponding position/vnode methods. I attempted something like this long ago, but I never got this far. I do remember that untangling the relationships between tree items and vnodes is much trickier than one might naively expect.

I just pushed code that increases the size of text. I hope you don't mind. It's much easier on my eyes. The new code also contracts all nodes initially.

Cloning appears to work, but not at the top level. At the top level the selected node changes after a clone, but nothing else happens, apparently. Sometimes the code crashes. The clone problems remains even if all nodes are expanded at first.

Cloning clearly is the heart of the matter. Somehow the qt items must remain in sync with vnodes. I suspect the top-level problems are nits.

The acid test would be clones of clones of clones...Presumably this would exponentially increase the number of qt tree items. Let me know if something more clever is going on.

That's all for now. This is a great start.

Edward

vitalije

unread,
May 5, 2020, 1:25:29 PM5/5/20
to leo-editor
I am glad you like it. The issue with cloning top levels is fixed in 1edad92fe9b8cd. It was caused by iter_all_v_items which didn't yield anything when v is c.hiddenRootNode. Now it checks for this condition and yields only rootItem.

The QtPosition class is not used yet in the prototype. I started to write it to see if it is feasible to make something to hold all traversal methods of p and generators. It is not finished yet (the generators are missing).

I think that the next step should be to make some tests for prototype to eliminate all crashes.

Manually I test it by running a serious of commands to create a complex trees with a lot of clones, inserting new nodes, demoting, moving right/left, especially right to get into the cloned node, or moving left from cloned node, ... then I undo each step, then redo all steps again, then I make series of undo/redo.

I thought I had eliminated crashes. Do you remember the steps that lead to crash?

Vitalije

Edward K. Ream

unread,
May 6, 2020, 6:40:23 AM5/6/20
to leo-editor
On Tue, May 5, 2020 at 12:25 PM vitalije <vita...@gmail.com> wrote:

I am glad you like it. The issue with cloning top levels is fixed in 1edad92fe9b8cd. It was caused by iter_all_v_items which didn't yield anything when v is c.hiddenRootNode. Now it checks for this condition and yields only rootItem.

Everything works for me now.

The QtPosition class is not used yet in the prototype. I started to write it to see if it is feasible to make something to hold all traversal methods of p and generators. It is not finished yet (the generators are missing).

Heh. I didn't realize that.

The QtPosition class is extremely clever. Implementing Position methods using Qt tree items rather than vnodes promises to break the Gordian Know of interactions between the gui code and Leo's core.

I think that the next step should be to make some tests for prototype to eliminate all crashes.

I would suggest creating unit tests that cover all the code. The test code in leoAst.py might be a template for such a project. I am willing to work on tests if you are willing to share the programming.
Manually I test it by running a serious of commands to create a complex trees with a lot of clones, inserting new nodes, demoting, moving right/left, especially right to get into the cloned node, or moving left from cloned node, ... then I undo each step, then redo all steps again, then I make series of undo/redo.

Creating full coverage unit tests might be easier if running the prototype without any arguments created an empty outline. The necessary changes are straightforward. I can push the changes I've made locally if you like.

I thought I had eliminated crashes. Do you remember the steps that lead to crash?

No, I don't. I'll let you know if the prototype crashes again.

Edward

vitalije

unread,
May 6, 2020, 7:50:49 AM5/6/20
to leo-editor
I am willing to work on tests if you are willing to share the programming.

Of course I am.

 
Creating full coverage unit tests might be easier if running the prototype without any arguments created an empty outline. The necessary changes are straightforward. I can push the changes I've made locally if you like.


  Feel free to do anything you want to the prototype. But I would like to at least have the ability to run it using an existing outline. It might be best if the filename is provided on the command line to open that filename and without arguments to create a new outline with the single node.
 
I am working on testing using hypothesis. I plan to open LeoPyRef.db, then hypothesis will randomly select items and perform random commands checking after each command that the resulting list of vnodes collected in the outline order by iterating v-nodes is exactly the same as the one collected by iterating tree items. Hypothesis is good at finding short sequence of operations that lead to error. If it doesn't find that sequence we may be pretty sure that code is correct.

Vitalije

Edward K. Ream

unread,
May 6, 2020, 9:10:52 AM5/6/20
to leo-editor
On Wed, May 6, 2020 at 6:50 AM vitalije <vita...@gmail.com> wrote:

>> I am willing to work on tests if you are willing to share the programming.
> Of course I am.

Thanks. First, it's time to fix #1563.
 
I would like to at least have the ability to run it using an existing outline. It might be best if the filename is provided on the command line to open that filename and without arguments to create a new outline with the single node.

That's what rev bce8dc123 does, which I have just pushed.

 I am working on testing using hypothesis. I plan to open LeoPyRef.db, then hypothesis will randomly select items and perform random commands checking after each command that the resulting list of vnodes collected in the outline order by iterating v-nodes is exactly the same as the one collected by iterating tree items. Hypothesis is good at finding short sequence of operations that lead to error. If it doesn't find that sequence we may be pretty sure that code is correct.

Let me know how it works out.

Edward
Reply all
Reply to author
Forward
0 new messages