TL;DR: re-instate Bob's timestamp fix in core, doesn't make sense to be an off-by-default plug-in. UUID gnxs: wishlist priority, current time vs. session start time timestamps would be nice though.
On Wed, 22 Oct 2014 08:46:32 -0500 "Edward K. Ream" <[email protected]> wrote: [snip] > The fundamental problem is that two different invocations of Leo can > clash, which can lead to two *different* vnodes (different purposes) > getting assigned the same gnx. Like this: Ok, so your different invocations just refers to the fact that the current gnx is not guaranteed to be universally unique, and in the extremely rare case where it clashes *and* someone uses paste retaining clones, stuff breaks. I think Leo should be around for a long time to come, but I'm not sure it will be around for the length of time it will take that to happen in the wild :-) Although P1, same user id, could be higher than you think, if say one person's using Leo on machines running in different time zones... unlikely, but so is P1*P2*P3*P4 :-) [snip] > We must solve Bob's problem, but the present "solution" is not good. > The post-pass is a ticking time bomb because it's implications are so > subtle. I'm confused, and every other Leo developer will be too. > Hacking on ni.getNewIndex would be a band-aid. Imo, the post pass > must go. So the post-past adds complexity and fails in the P1*P2*P3*P4 (paste retaining clones) case. Also, Bob's always increasing timestamp solution is a sufficient remedy for Bob's twice in one second problem. I'm trying to mentally weight the cost benefit of removing the post-past. I guess it fails to solve a problem we'll probably never see, and is not needed for the problem that has been encountered, if we re-instate the increasing timestamp fix. I can't see a strong argument for not removing it. > If comments are favorable, I'll write a unique_timestamps plugin. This > plugin will repackage Bob's original timestamp adjustment. See the > post script for details. > > Yes, Bob will have to enable this plugin when running his automated > unit tests. How is having to enable a plugin better than having to use a '--no-duplicate-gnx' command line parameter? I think Bob's increasing timestamp fix should just be re-instated in core, I can't see how it has any negative impact on anything. > #@+node:<gnx>:<headline> > > Instead, they could have the form:: > > #@+node::<headline>:<gnx> I think this problem is unimportant, because I think that the increasing timestamp is the smart way to fix the collisions that are actually likely, that I'm not convinced uuid in gnxs need higher than 'wishlist' priority. The above seems reasonable if they are being implemented. Also a get_gnx_timestamp() method to get the timestamp from old user.timestamp.seq and new gnxs would be good. Also take the opportunity to switch to a current time, rather than session start time, timestamp, that would be nice. I'm still not sure exposing people's network addresses in Leo files is ideal https://groups.google.com/d/msg/leo-editor/7HNA2mOqpJU/goulrkknvgwJ but UUID version 1 is the only UUID that records timestamps and it also records mac addresses. Of course, you can just give it a bogus MAC address. So... ha, funny thing, UUIDs... not necessarily unique? http://en.wikipedia.org/wiki/Universally_unique_identifier#Version_1_.28MAC_address_.26_date-time.29 That wikipedia page says Python's implementation follows http://tools.ietf.org/html/rfc4122 ... I assume that means it's (a) fast and efficient, and (b) guaranteed to be unique on a particular machine. I'm not sure what impact a bogus MAC address would have on the uniqueness guarantee, if Leo used say 0x123456789abc always, then it would be degrading the uniqueness perhaps, but we could still avoid exposing the real MAC by using g.app.db['fakemac'], which is set to random.randint(0,0xffffffffffff) if it doesn't exist. Cheers -Terry > The second form is better because the headline is first, which is what > humans want to see. The opening :: distinguishes the second form from > the first. The trailing gnx will be scanned *backward*, starting from > the end of the line. This ensures that headlines may contain any text > whatever. > > Lengthening sentinel comments is not pleasant, but using uuid's in > sentinels appears to be inevitable at some point. > > ===== Solution 2: Create a plugin that ensures unique timestamps. > > This plugin would repackage Bob's timestamp hack. Unless I am > severely mistaken, ensuring that all invocations of Leo are based on > separate timestamps will solve all the present gnx problems. > > I like this solution: > > 1. It requires no nerdy command-line option. > 2. Only those who have Bob's particular use-case need activate the > plugin. 3. It simplifies Leo's code and *much more importantly* > simplifies the underlying assumptions behind Leo's code. > > Otoh, this solution resuscitates but #35 > > Happily, I still have the tests lying around. I spent enough time with > those tests that I should be able to tell whether they fail or not. > It's a statistical thing whether the two invocations actually share > the same timestamp: one must run the test until they do. > > EKR > -- 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 http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
