Bob H: would distinct Leo IDs help with #1348?

60 views
Skip to first unread message

Edward K. Ream

unread,
Oct 18, 2019, 11:10:55 AM10/18/19
to leo-editor
#1348 has been closed, but I'm not sure of its status.

gnx clashes are a recurring theme when using Leo (or the bridge) to spawn many other copies of Leo quickly.

I am wondering whether these clashes might be avoided if Leo would use a separate user id for each spawned copy.  This might be done either with a --id=x command-line option or with a kwarg to runLeo.py.

What are your thoughts?

Edward

Segundo Bob

unread,
Nov 7, 2019, 6:08:32 PM11/7/19
to leo-e...@googlegroups.com
On 10/18/19 8:10 AM, Edward K. Ream wrote:
> #1348 <https://github.com/leo-editor/leo-editor/issues/1348> has been
I think changing the user id is a bad solution. It would make a mockery
of what the user thinks the user id is. Besides, I doubt that a new
user id can be generated in a way that guarantees no conflicts.

The fix should not require the user to do anything because depending on
unreliable users is no fix at all.

My preferences are as follows from most preferable to least preferable.
My preferences are, of course, based on my limited understanding of
Leo-Editor.

1) Eliminate the generation of a GNX before reading a file.

Since the hidden root node always has GNX hidden-root-vnode-gnx, the
motivation for this GNX generation is very mysterious to me.

It seems reasonable to me, that if a file exists, then it should be read
before generating any GNX that might affect Leo-Editor's handling of the
file. If the file is read and all of its GNX's are known, then avoiding
duplicates is a solved problem.

2) Replace the current non-random GNX with a pseudo-random UUID.

Python 2.5 and up has a library uuid.

I like library shortuuid:

https://pypi.org/project/shortuuid/

But you seem emotionally committed to your non-random GNX's, even
though, so far as I know, no one has ever made any significant use of
the information they contain.

I look forward to your fix of this important-to-me problem. No matter
what your fix is.
--
Segundo Bob
Segun...@gmail.com

Edward K. Ream

unread,
Nov 8, 2019, 8:00:33 AM11/8/19
to leo-editor
On Thu, Nov 7, 2019 at 5:08 PM Segundo Bob <segun...@gmail.com> wrote:

I think changing the user id is a bad solution.

Alright then.  That idea is dead.
My preferences are as follows from most preferable to least preferable.
 
1) Eliminate the generation of a GNX before reading a file.

Hmm.  I wasn't aware that Leo did that.  Why does this cause problems?

Since the hidden root node always has GNX hidden-root-vnode-gnx, the
motivation for this GNX generation is very mysterious to me.

Me too :-)

It seems reasonable to me, that if a file exists, then it should be read
before generating any GNX that might affect Leo-Editor's handling of the
file.  If the file is read and all of its GNX's are known, then avoiding
duplicates is a solved problem.

I'll look into this.

2) Replace the current non-random GNX with a pseudo-random UUID.

We discussed this at length several years ago.  It is not guaranteed to eliminate all gnx conflicts, though it probably would help.
you seem emotionally committed to your non-random GNX's, even
though, so far as I know, no one has ever made any significant use of
the information they contain.

I am willing to add data such as uuid's to gnx's, but not to remove data.

I use the "non-random" part of gnx's, (the user id and timestamp) when investigating mysteries. Imo, it would be a bad mistake to toss that data.

I look forward to your fix of this important-to-me problem.  No matter
what your fix is.

I see that #1348 is closed.  In the last comment you congratulated Brian on his sleuthing, so I am surprised that the issue is still alive for you.

Please create a new issue, referencing #1348 summarizing, as briefly as possible, the present state of affairs.  I am happy to do what I can to help.

Edward

vitalije

unread,
Nov 8, 2019, 8:35:40 AM11/8/19
to leo-editor

1) Eliminate the generation of a GNX before reading a file.

Hmm.  I wasn't aware that Leo did that.  Why does this cause problems?

Since the hidden root node always has GNX hidden-root-vnode-gnx, the
motivation for this GNX generation is very mysterious to me.

Me too :-)


I believe that Leo creates some vnodes during the startup and  therefore generates gnx. For example when scripting plugin creates buttons and commands it creates and stores v instances. 

Perhaps the solution would be to clear gnxDict before reading a new file.

Vitalije

Brian Theado

unread,
Nov 8, 2019, 1:24:44 PM11/8/19
to leo-editor
The stack trace I included in my comment (https://github.com/leo-editor/leo-editor/issues/1348#issuecomment-542014635) shows where I saw the gnx being generated before reading the file. 
In this method, I guess:
leo/core/leoFrame.py(706)createFirstTreeNode()

Reply all
Reply to author
Forward
0 new messages