leo-editor/leo-editor — pull request #71 by SegundoBob (2014-10-09 22:56:10+00:00)
Title: Issues/35 - Strictly increasing time stamp fix to Duplicate GNX bug

# The Problem

Whenever two Leo-Editor "sessions" on the same computer with same user have the same gnx "time stamp" duplicate node GNX's can occur.

I have demonstrated that this occurs when using leoBridge. But this demonstration requires many things to happen in a one-second window. Hence, it does not show that the "duplicate time stamp" (and hence, duplicate GNX) problem can occur when using the Leo-Editor GUI.

Now, consider what happens when local time is not strictly increasing--and the local time is sometimes predictably and sometimes not strictly increasing. For example, it is predictably decreasing every year when local time goes off daylight savings time and local time goes back a full hour. This creates a huge window and allows Leo-Editor GUI to encounter the duplicate "time stamp" problem.

Local time is unpredictably not strictly increasing because almost everyone sync's their computer's time with an atomic clock accessed over the Internet. Most people do this syncing automatically in the background. Hence, it occurs unpredictably. The number of seconds the clock is set back is also unpredictable. It depends on how fast the computer's clock is and how long since the last sych. When someone returns from a vacation, the correction is probably larger than usual.

I believe that both the predictable and the unpredictable "setting back" of local time could cause both leoBridge and Leo-Editor GUI to encounter the duplicate time stamp problem. Demonstrating my claims is beyond my abilities. I admit the likelihood of encountering the problem due to not strictly increasing local time is very, very small.

# The Fix

The problem can be fixed by forcing the time stamp to be strictly increasing--even when local time is not. I implemented this with about ten lines of code in leo-editor/leo/core/LeoPyRef.leo#Code-->Core classes-->@file leoNodes.py-->class NodeIndices-->ni.setTimeStamp. My fix communicates the last time stamp from one Leo-Editor process to the next Leo-Editor process by putting the last time stamp in the Leo-Editor "globals" cache. I hope this is an allowed use of the cache and that I did it in a correct, or nearly-correct, way.

# Demonstrating the Fix

To demonstrate that the fix really works, in setTimeStamp() set trace=False and prtF=True, then run my bug demonstration program (hrngpM2.py) till you see this console output:
```
$ ./hrngpM2.py
lastTimeStamp=20141008161341
newTimeStamp=20141008161511
file not found: /home/ldi/git/leo_experiments/hidden_root_tsts/test1.leo. creating new window
lastTimeStamp=20141008161511
Time in Past=20141008161511
newTimeStamp=20141008161512

** isPython3: False
Leo 4.11 final, build 20141007141947, Tue Oct 7 14:19:47 CDT 2014
Git repo info: branch = 35, commit = e0e8d22fb52a
Python 2.7.6, LeoGui: dummy version
linux2
reading settings in /home/ldi/git/leo_experiments/hidden_root_tsts/test1.leo
wrote recent file: /home/bob06/.leo/.leoRecentFiles.txt
2014-10-08 16:15:12 /home/ldi/git/leo_experiments
$
```
The "Time in Past" line shows that the fix code was executed.

I don't use trace to demonstrate the fix because trace does not produce any output from the hrngpS2.py process. *Could someone explain to me why this is so?*

I have made minor improvments to hrngpM2.py and hrngpS2.py. These changes are available on github, but they are unimportant.

# The Fix and Going off Daylight Savings Time

During the repeated hour after going off daylight savings time, each new Leo-Editor session gets a time stamp one second later than the last session's. After the repeated hour, the time stamp becomes the true local time again.

# LeoBridge Sometimes Leaves the Leo-Editor file "open" when it should not

The demonstration of this bug also demonstrates that LeoBridge can leave the Leo-Editor file "open". For a simpler demonstration of this problem see Issue #69.