On Mon, Jun 11, 2018 at 10:45 AM, vitalije <[email protected]> wrote:
> I have written new data model several times, using several different languages and each time I wrote it I learned something new. Each model was better than the one before. > I would like to share what I have learned so far. Please do. I'm not sure why you think my reaction might be negative. Afaik, all I have said is that I would like Leo's primary scripting interface to remain (largely) unchanged. But compatibility is *not* a requirement for prototypes. They need only demonstrate that something is feasible. A new data model would be extremely interesting in its own right. > I feel that this new data model has great potential and that it can be used in many other fields as well. I am interested in anything you do, Vitalije. > I feel that it would be a great idea to rewrite it once again - this time completely in rust language and make it available as both the Python extension and Node extension. I have even installed a Windows 10 as a second OS on my new machine so that I can compile both for Windows and Linux. As the prototype shows new model is quite easily attached to any GUI. Cool! > Edward seems to be not very fond of this new model. It may seem odd or complicated at first, but it is not. Really, I have no idea why you say this. I have *no* opinion of the new model. In fact, I didn't understand it at all, until I read this letter. I am *completely* open to learning about it. > More than once in this forum it was pointed out that Leo's outline is like a database. Let us accept this analogy for now and let me use some database terminology. Sounds perfectly reasonable to me. > Currently Leo is like a database with no indexes at all. Very interesting change in point of view. > We can modify the outline very fast, but when we need to query tree we have no other choice but to go from the start to the end. That makes drawing slow and very dependent on the outline size and number of expanded nodes. To speed drawing we have to add some indexes to Leo. Good summary. > My new data-model is nothing more than a database with just enough indexes to make all outline operations fast enough and traversing, searching, drawing very fast. This is great stuff. Very clear. I never understood what you proposed doing until now. I'm all for exploring this. > Edward can come up with another set of indexes, to achieve same performance as the prototype demonstrates. Perhaps, he can find even better suited set of indexes so that Leo becomes even faster than my prototype. The one thing I am sure is that speed can't be improved without some kind of indexes. Are you talking about screen redraws? That might be made faster by drawing only the visible part of the screen. Anyway, the data model is interesting on its own. > And those indexes whatever they may be like, need to be updated every time outline changes. Yes. > Currently Leo's data is totally unprotected. There is no way to find out about a change in the outline unless it is explicitly reported. And many scripts do not report change. Another clear concept, and a big change in point of view. > The one possible solution is to replace both children and parents fields with user defined list instances that override all methods that modify list. Overridden methods should update both the list and indexes to keep them in sync. However, there may exist some scripts that set directly parents and children fields of vnode instances. Imo, we don't necessarily have to maintain compatibility with such low-level scripts. Certainly we can *imagine* excluding those scripts while discussing your ideas. > Those scripts would broke Leo. In that case it would be necessary to turn fields 'children' and 'parents' into properties, to protect Leo's data from this kind of scripts. Let's not worry about such things now. > There is a better solution. Let's use internally new data-model instead of vodes and positions. All of the operations that modify tree are already implemented in the prototype and all of them run at least ten times faster than current Leo commands. Undo/redo code can be substantially simpler and shorter, drawing can be very fast and the only thing that remain to be done is making scripts work as before. Sounds like an excellent plan. > The easiest thing to do is to change execute-script command so that it first sync data from new model to c.hiddenRootNode, then execute script, and after executing script, resync data from c.hiddenRootNode back to new model. With this approach all scripts will continue to work just as they used to, and Leo's internals can be greatly simplified. Very clever. I would never have thought of doing this. > I intend to write more about new model and to make some pictures to make it more understandable. That would also help me when (and if) I start rewriting it in Rust. Excellent! *Summary* This is outstanding work. I am eager to study it further. This letter is like a Rosetta stone. You have clearly summarized why a new data model might be useful. Perhaps now we can understand your prototype code. Please tell us where we can find the latest version. 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 https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
