>
>
> YEEEHAAA!, we are on!
>
> Curious, what happens to speed of operations like searching nodes for
> strings?
>
> Thanks for the enthusiasm. Searching for strings might or might not get
faster, but I am 100% sure leoFind will become much simpler and shorter
because nodes are accessible as a
On Wed, Jul 11, 2018 at 9:38 AM, vitalije wrote:
>
>> I have lost patience with this discussion. If you want to convince me,
>> change leoNodes.py in a git branch and create show how the qt redraw code
>> can be improved.
>>
>> The ball is in your your court. I'm done reading dissertations.
>>
On Wed, Jul 11, 2018 at 9:38 AM, vitalije wrote:
But on second thought I will accept the challenge. Only I am not going to
> play according to the rule "change only leoNodes.py". Instead I will to try
> to change as little as possible in whatever module I find necessary. All
> that in a separate
>
>
> I have lost patience with this discussion. If you want to convince me,
> change leoNodes.py in a git branch and create show how the qt redraw code
> can be improved.
>
> The ball is in your your court. I'm done reading dissertations.
>
> Edward
>
My first response was:
It is not fair.
On Wed, Jul 11, 2018 at 6:55 AM, vitalije wrote:
>
>
>> Leo's existing data model is completely straightforward,
>>
>
> The main problem as I see it is that Edward (and I guess only Edward)
> firmly believes that this claim is true.
>
I'm was talking about the Position and VNode classes. Many
On Wed, Jul 11, 2018 at 9:02 AM, Kent Tenney wrote:
Increased speed offers the potential for working at larger scale,
> waiting 10s for anything means it's broken, millisecond execution
> means more potential use cases.
>
Sure, but is a new data model required?
Edward
--
You received this
Increased speed offers the potential for working at larger scale,
waiting 10s for anything means it's broken, millisecond execution
means more potential use cases.
The difference in speed says to me that the execution path is
orders of magnitude simpler in the new code = better chance of
>
>
> - The proposal asks me to consider rewriting Leo's essential code.
>
> Why should I want to do that?
Because right now with the present Leo code alone, best that Leo can do is
1300 times slower than present Leo code with the new model.
Vitalije
--
You received this message because you
For those who watch the video, please note the end result in lower left
corner in Log pane:
Leo's present code takes 10s to expand fully tree, and 1.7s to perform
promote/demote cycle on one node.
The same Leo instance with the help of new data model, expands tree
immediately and performs
> Leo's existing data model is completely straightforward,
>
The main problem as I see it is that Edward (and I guess only Edward)
firmly believes that this claim is true. If there is anyone anywhere that
would like to support this claim, please go ahead and tell me that I am
wrong. I
On Wednesday, July 11, 2018 at 4:29:29 AM UTC-5, Edward K. Ream wrote:
> I seen no reason to consider the new data model further, for the reasons
just stated.
Here is what might change my mind:
1. A git branch that changes implements the new data model, changing only
leoNodes.py.
The code
On Tue, Jul 10, 2018 at 11:49 AM, Terry Brown
wrote:
>
> The big issue - what is the future of the Leo code base?
>
> Many people have contributed code
> where the code is reasonably easy to contri
>
> bute - plugins an obvious
> example. Very few people, that I recall, have made
12 matches
Mail list logo
