Re: ENB: Fixing gnx collisions without a post scan

2014-10-15 Thread Segundo Bob
On 10/15/2014 03:57 AM, Edward K. Ream wrote: This is an Engineering Notebook post. Feel free to ignore it unless you have a deep interest in bug #69. You mean Issue #35, not Issue #69. Issue #69 is "leoBridge leaves .leo open" Issue #35 is "leoBridge sometimes assigns the same GNX to two dis

Re: ENB: Fixing gnx collisions without a post scan

2014-10-15 Thread 'Terry Brown' via leo-editor
On Wed, 15 Oct 2014 11:43:59 -0500 "Edward K. Ream" wrote: [snip] > > But, perhaps the above is naively simplistic. > > It seems rock solid to me. The post pass frees us from *any* > assumptions about ids and timestamps. I meant simplistic in terms of my thought that maybe the scanning-for-

Re: ENB: Fixing gnx collisions without a post scan

2014-10-15 Thread Edward K. Ream
On Wed, Oct 15, 2014 at 11:07 AM, 'Terry Brown' via leo-editor wrote: > My brother Tim in New Zealand sends me a .leo file. Current time > comparison: > >Chicago 10:48 am Wednesday > Auckland 4:48 am Thursday > > Depending on daylight savings time, there's a 17-18 hour window in > which I

Re: ENB: Fixing gnx collisions without a post scan

2014-10-15 Thread 'Terry Brown' via leo-editor
On Wed, 15 Oct 2014 11:08:54 -0500 Kent Tenney wrote: > > perhaps not standards-friendly enough for Kent > :-] > > now, I don't want to be the standard-bearer for standards if alone. > Does everyone else prefer an evolved gnx over uuid? :-) I'm still not convinced there's any need to change th

Re: ENB: Fixing gnx collisions without a post scan

2014-10-15 Thread Kent Tenney
> perhaps not standards-friendly enough for Kent :-] now, I don't want to be the standard-bearer for standards if alone. Does everyone else prefer an evolved gnx over uuid? On Wed, Oct 15, 2014 at 10:35 AM, Edward K. Ream wrote: > On Wed, Oct 15, 2014 at 10:29 AM, Zoltan Benedek wrote: > >> I d

Re: ENB: Fixing gnx collisions without a post scan

2014-10-15 Thread 'Terry Brown' via leo-editor
On Wed, 15 Oct 2014 10:21:37 -0500 "Edward K. Ream" wrote: > On Wed, Oct 15, 2014 at 9:18 AM, 'Terry Brown' wrote: > > >> > So for maximum code cleanliness Bob's fix could be removed. > > >> I don't see how that statement can be correct. Each invocation of > >> Leo must be based on a unique ti

Re: ENB: Fixing gnx collisions without a post scan

2014-10-15 Thread Edward K. Ream
On Wed, Oct 15, 2014 at 10:54 AM, Zoltan Benedek wrote: > :-) It was only an idea. > > Many thanks for the English correction. It wasn't a correction. I often shorten or edit comments when replying to them. EKR -- You received this message because you are subscribed to the Google Groups "leo

Re: ENB: Fixing gnx collisions without a post scan

2014-10-15 Thread Zoltan Benedek
:-) It was only an idea. Many thanks for the English correction. -- 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 leo-editor+unsubscr...@googlegroups.com. To post

Re: ENB: Fixing gnx collisions without a post scan

2014-10-15 Thread Edward K. Ream
On Wed, Oct 15, 2014 at 10:29 AM, Zoltan Benedek wrote: > I don't understand much of the topic, but I know a way to reduce the length > of an uuid, if it helps...In this way we get [a length] near to the current > 18-19 character length [of] timestamp.n Oh, the power of collaboration. Many th

Re: ENB: Fixing gnx collisions without a post scan

2014-10-15 Thread Zoltan Benedek
Hi, I don't understand much of the topic, but I know a way to reduce the length of an uuid, if it helps. The result of transformation is a string id of 22 character length, containing only the characters: 0123456789abcdefghijklmnopqrstuvwxyABCDEFGHIJKLMNOPQRSTUVWXY The result is a unique id a

Re: ENB: Fixing gnx collisions without a post scan

2014-10-15 Thread Edward K. Ream
On Wed, Oct 15, 2014 at 9:09 AM, Kent Tenney wrote: > Ah, sentinels! I live in an @auto only world, I forget about sentinels, > can't comment on the aesthetic importance of their format. > > I would see no reason for the . component, would prefer a canonical > uuid from which I can pull date and s

Re: ENB: Fixing gnx collisions without a post scan

2014-10-15 Thread Edward K. Ream
On Wed, Oct 15, 2014 at 9:18 AM, 'Terry Brown' wrote: >> > So for maximum code cleanliness Bob's fix could be removed. >> I don't see how that statement can be correct. Each invocation of Leo must >> be based on a unique timestamp. > That's not really an absolute...Having a system that generat

Re: ENB: Fixing gnx collisions without a post scan

2014-10-15 Thread 'Terry Brown' via leo-editor
On Wed, 15 Oct 2014 06:47:25 -0700 (PDT) "Edward K. Ream" wrote: > On Wednesday, October 15, 2014 8:28:05 AM UTC-5, Terry Brown wrote: > > > I don't think the post-scan does require Bob's always incrementing > timestamp fix, I think the post-scan is a more general solution which > addresses th

Re: ENB: Fixing gnx collisions without a post scan

2014-10-15 Thread Kent Tenney
Ah, sentinels! I live in an @auto only world, I forget about sentinels, can't comment on the aesthetic importance of their format. I would see no reason for the . component, would prefer a canonical uuid from which I can pull date and source machine. Although automation via LeoBridge may currentl

Re: ENB: Fixing gnx collisions without a post scan

2014-10-15 Thread Edward K. Ream
On Wednesday, October 15, 2014 8:28:05 AM UTC-5, Terry Brown wrote: > I don't think the post-scan does require Bob's always incrementing timestamp fix, I think the post-scan is a more general solution which addresses the ".leo files from other sources" aspect of the duplicated gnx problem, as w

Re: ENB: Fixing gnx collisions without a post scan

2014-10-15 Thread Edward K. Ream
On Wednesday, October 15, 2014 8:13:25 AM UTC-5, Kent Tenney wrote: > > (I'll let go of this soon, I promise) > > > not visually acceptable > > Who sees them when? > My understanding is that they are only visible when looking > at the xml in a Leo file, am I missing a usage which directly > in

Re: ENB: Fixing gnx collisions without a post scan

2014-10-15 Thread 'Terry Brown' via leo-editor
On Wed, 15 Oct 2014 03:57:00 -0700 (PDT) "Edward K. Ream" wrote: > This is an Engineering Notebook post. Feel free to ignore it unless > you have a deep interest in bug #69. > > Bob has just reported that the post scan works for him. That's > great, but I would like to eliminate the post scan:

Re: ENB: Fixing gnx collisions without a post scan

2014-10-15 Thread Edward K. Ream
On Wednesday, October 15, 2014 5:57:00 AM UTC-5, Edward K. Ream wrote: > Evidently, ni.toString is more complex than it needs to be...we could eliminate ni.toString entirely, and replace it with ni.tupleToString:: Without committing myself to eliminating the post pass, I have replaced ni.toStri

Re: ENB: Fixing gnx collisions without a post scan

2014-10-15 Thread Kent Tenney
(I'll let go of this soon, I promise) > not visually acceptable Who sees them when? My understanding is that they are only visible when looking at the xml in a Leo file, am I missing a usage which directly involves people? My impression is that the xml file hasn't had people friendliness as a pri

Re: ENB: Fixing gnx collisions without a post scan

2014-10-15 Thread Edward K. Ream
On Wed, Oct 15, 2014 at 6:04 AM, Kent Tenney wrote: > You're sure this level of complexity is required ... > timestamped uuids won't work? Yes, uuids would work, but they are not visually acceptable, imo. BTW, we must ensure that context (commander) is never None in the vnode ctor: otherwise pot

Re: ENB: Fixing gnx collisions without a post scan

2014-10-15 Thread Kent Tenney
You're sure this level of complexity is required ... timestamped uuids won't work? On Wed, Oct 15, 2014 at 5:57 AM, Edward K. Ream wrote: > This is an Engineering Notebook post. Feel free to ignore it unless you > have a deep interest in bug #69. > > Bob has just reported that the post scan work

ENB: Fixing gnx collisions without a post scan

2014-10-15 Thread Edward K. Ream
This is an Engineering Notebook post. Feel free to ignore it unless you have a deep interest in bug #69. Bob has just reported that the post scan works for him. That's great, but I would like to eliminate the post scan: it is *almost* never needed and it slows down *every* load of a .leo file