On Mon, Jul 9, 2018 at 1:45 PM, vitalije wrote:
>
>
> On Monday, July 9, 2018 at 6:22:52 PM UTC+2, Edward K. Ream wrote:
>>
>> I have not yet studied Vitalije's new data model in detail, being
>> immersed in fixing bugs in the new read code. It's next on the list. Here,
>> I'll discuss why Leo's
On Mon, Jul 9, 2018 at 11:59 AM, Terry Brown wrote:
A more clever, more useful, representation of positions may be possible. If
>> so, it will, perforce, be less intuitive than Leo's present positions.
>>
>
> It seems though that any loss of intuitiveness would only impact Leo
> devs., and only w
On Monday, July 9, 2018 at 6:22:52 PM UTC+2, Edward K. Ream wrote:
>
> I have not yet studied Vitalije's new data model in detail, being immersed
> in fixing bugs in the new read code. It's next on the list. Here, I'll
> discuss why Leo's present positions were designed as they are.
>
> Perhap
On Mon, Jul 9, 2018 at 11:22 AM Edward K. Ream wrote:
>
> A more clever, more useful, representation of positions may be possible.
> If so, it will, perforce, be less intuitive than Leo's present positions.
>
> Edward
>
It seems though that any loss of intuitiveness would only impact Leo devs.,
I have not yet studied Vitalije's new data model in detail, being immersed
in fixing bugs in the new read code. It's next on the list. Here, I'll
discuss why Leo's present positions were designed as they are.
Positions are essential. Given a vnode only, or even a vnode and a list of
it's pare
