Re: Documentation on new data model for Leo outlines

2018-05-21 Thread Edward K. Ream
On Sun, May 20, 2018 at 1:08 PM, vitalije wrote: > To be fair, I must point out that Leo is performing also undo/redo logic > which my prototype still doesn't. But taking a full snapshot of the tree in > the new model was measured before and it used to take about 20ms, for

Re: Documentation on new data model for Leo outlines

2018-05-20 Thread vitalije
On Thursday, May 17, 2018 at 9:20:33 PM UTC+2, Matt Wilkie wrote: > > I have just published first two articles about what I have done so far in >> this mini-project. Here are the links: >> > [...] > >> All comments are welcome. >> > > Vitalije, I'm working my through your posts on that site

Re: Documentation on new data model for Leo outlines

2018-05-17 Thread Matt Wilkie
> > > > col = (pos.x - grid.minx) / (grid.maxx - grid.minx) * grid.cols > > > > > +10! > > Given the +10 :) I should add I've been using this lib.: > > https://pypi.org/project/addict/#description > Thanks! -- You received this message because you are subscribed to the Google Groups

Re: Documentation on new data model for Leo outlines

2018-05-17 Thread Matt Wilkie
> > I have just published first two articles about what I have done so far in > this mini-project. Here are the links: > [...] > All comments are welcome. > Vitalije, I'm working my through your posts on that site from the beginning. It's slow because I understand little because of my

Re: Documentation on new data model for Leo outlines

2018-05-17 Thread Terry Brown
On Thu, 17 May 2018 12:00:30 -0700 (PDT) Matt Wilkie wrote: > > Veering off topic I wish there was a more general solution for dot > > access to dict members, I understand all the arguments against, but > > often writing mathematical expressions... > > > > col = (pos['x'] -

Re: Documentation on new data model for Leo outlines

2018-05-17 Thread Matt Wilkie
the rest of this thread is over my head, but: Veering off topic I wish there was a more general solution for dot > access to dict members, I understand all the arguments against, but > often writing mathematical expressions... > > col = (pos['x'] - grid['minx']) / (grid['maxx'] - grid['minx'])

Re: Documentation on new data model for Leo outlines

2018-05-16 Thread Edward K. Ream
On Tue, May 15, 2018 at 5:04 PM, vitalije wrote: About script compatibility and rewriting Position class, I was thinking > that it would be simplest thing to just let them be as they are now. > ​...​ Both models can easily coexist. We can advice all users to write their >

Re: Documentation on new data model for Leo outlines

2018-05-15 Thread vitalije
Thanks for all your comments and suggestions. I agree that using integers to access the elements of attrs list is not very readable. There will be time to discuss it further when whole model is settled down a bit. It is still evolving, so I haven't seen much point in polishing it yet. Today, I

Re: Documentation on new data model for Leo outlines

2018-05-15 Thread Edward K. Ream
On Tuesday, May 15, 2018 at 6:36:15 AM UTC-5, Edward K. Ream wrote: all existing Position methods and generators must have exactly the same > *effect* as before. Many (All?) Position methods and generators will > need to be rewritten. That's fine. The new code will be simpler than the > old

Re: Documentation on new data model for Leo outlines

2018-05-15 Thread Edward K. Ream
On Tue, May 15, 2018 at 8:53 AM, Terry Brown wrote: > > We've discussed this before I think, but returning tuples can be a real > pain for extensibility. ​I agree. I think Vitalije is aware of the trade-offs. For now, I'm happy to let him choose whatever style he likes.

Re: Documentation on new data model for Leo outlines

2018-05-15 Thread Terry Brown
On Tue, 15 May 2018 08:04:21 -0500 "Edward K. Ream" wrote: > On Tue, May 15, 2018 at 6:55 AM, Terry Brown > wrote: > > > What about a namedtuple? > > ​That or a bunch. Just to be clear, ​the code itself may change to > make this moot. Realized

Re: Documentation on new data model for Leo outlines

2018-05-15 Thread Edward K. Ream
On Tue, May 15, 2018 at 6:55 AM, Terry Brown wrote: What about a namedtuple? > ​That or a bunch. Just to be clear, ​the code itself may change to make this moot. Another possibility, which I often favor, is to unpack the tuple in place: item1, item2, ... itemN = aTuple

Re: Documentation on new data model for Leo outlines

2018-05-15 Thread Terry Brown
On Tue, 15 May 2018 04:36:15 -0700 (PDT) "Edward K. Ream" wrote: > *Readability will not affect performance* > > attrs[gnx] is a tuple [h, b, ps, chn, sz[0]]. The components should > be accessed via a bunch, or an enum, say, > > e_h = 0 > e_b = 1 > e_ps = 2 What about a

Re: Documentation on new data model for Leo outlines

2018-05-15 Thread Edward K. Ream
On Monday, May 14, 2018 at 9:44:11 AM UTC-5, Edward K. Ream wrote: > > > On Mon, May 14, 2018 at 8:02 AM, vitalije wrote: > >> I have just published first two articles about what I have done so far in >> this mini-project. Here are the links: >> >>1. Leo tree model - new

Re: Documentation on new data model for Leo outlines

2018-05-14 Thread Edward K. Ream
On Mon, May 14, 2018 at 8:02 AM, vitalije wrote: > I have just published first two articles about what I have done so far in > this mini-project. Here are the links: > >1. Leo tree model - new approach > >2. Leo