Re: saving cloned @clean files in different @path's

[Edward K. Ream]

On Thu, Nov 9, 2017 at 2:22 PM, Phil  wrote:

>
>
>> ​Rev a627fcc ensures that ​@cloned nodes to two different paths will both
>> be written.  The fix was entirely straightforward and all unit tests pass.
>> But...
>>
>
> Thank you Edward!
>

​You're welcome.

Edward

-- 
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 to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: saving cloned @clean files in different @path's

[Phil]

 

> ​Rev a627fcc ensures that ​@cloned nodes to two different paths will both 
> be written.  The fix was entirely straightforward and all unit tests pass.  
> But...
>

Thank you Edward!
 

>
> *Warning*
>
> ​This rev changes corresponding code in at.readAll, but here the results 
> ​are kinda like rearranging chairs on the Titanic :-)
>
> All will be well as long as both external files contain exactly the same 
> code, but Leo does not detect if the two files are different, say if one 
> has been changed with another editor. Afaik, Leo has *never *been able to 
> detect changes between two different *cloned *nodes with the same gnx.
>
> What will happen is that one of the clones will "win".  Before today, the 
> *first* read node will win.  Now, the *last* cloned node will win.
>
> In short, you are asking for trouble using two cloned @clean nodes (or any 
> other kind of @ node).  This has always been true, and will likely 
> remain so forever.
>
>
Ok, that makes sense to me, and I will keep it in mind in the future. As a 
mostly sole developer writing code almost entirely using Leo, I don't 
usually modify files outside of Leo, so I wouldn't expect problems.

Thanks again!
Phil

-- 
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 to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: saving cloned @clean files in different @path's

[Edward K. Ream]

On Thu, Nov 9, 2017 at 9:59 AM, Edward K. Ream  wrote:

​Imo,  the problem is a fairly straightforward bug in ​in at.writeAll.
> Indeed, this method suppresses writes of any @ node p if p.v has
> already been written.  The "seen" set contains all previously-written
> vnodes.
>
> But this test fails if p.v refers to two different paths.  It looks like
> the "seen" set should contain tuples (p.v, path) where path is the full
> path to the to-be-written file.
>
> I'll attempt a fix immediately.
>

​Rev a627fcc ensures that ​@cloned nodes to two different paths will both
be written.  The fix was entirely straightforward and all unit tests pass.
But...

*Warning*

​This rev changes corresponding code in at.readAll, but here the results
​are kinda like rearranging chairs on the Titanic :-)

All will be well as long as both external files contain exactly the same
code, but Leo does not detect if the two files are different, say if one
has been changed with another editor. Afaik, Leo has *never *been able to
detect changes between two different *cloned *nodes with the same gnx.

What will happen is that one of the clones will "win".  Before today, the
*first* read node will win.  Now, the *last* cloned node will win.

In short, you are asking for trouble using two cloned @clean nodes (or any
other kind of @ node).  This has always been true, and will likely
remain so forever.

Edward

-- 
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 to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: saving cloned @clean files in different @path's

[Edward K. Ream]

On Thu, Nov 9, 2017 at 10:13 AM, vitalije  wrote:


Sorry, for the noise I made. I was writing about the restriction that
> forbid two clone instances in one external file, but now I  realize that it
> is totally different issue.
>

​It's not a problem :-)

Edward

-- 
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 to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: saving cloned @clean files in different @path's

[vitalije]

On Thursday, November 9, 2017 at 4:59:45 PM UTC+1, Edward K. Ream wrote:
>
> On Wed, Nov 8, 2017 at 1:03 PM, vitalije > 
> wrote:
>
> I am not 100% sure, but I believe that this restriction is dictated with 
>> the present read or write algorithm.
>>
>
> ​Imo,  the problem is a fairly straightforward bug in ​in at.writeAll. 
> Indeed, this method suppresses writes of any @ node p if p.v has 
> already been written.  The "seen" set contains all previously-written 
> vnodes.
>
> Sorry, for the noise I made. I was writing about the restriction that 
forbid two clone instances in one external file, but now I  realize that it 
is totally different issue.
Vitalije

-- 
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 to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: saving cloned @clean files in different @path's

[Edward K. Ream]

On Wed, Nov 8, 2017 at 1:03 PM, vitalije  wrote:

I am not 100% sure, but I believe that this restriction is dictated with
> the present read or write algorithm.
>

​Imo,  the problem is a fairly straightforward bug in ​in at.writeAll.
Indeed, this method suppresses writes of any @ node p if p.v has
already been written.  The "seen" set contains all previously-written
vnodes.

But this test fails if p.v refers to two different paths.  It looks like
the "seen" set should contain tuples (p.v, path) where path is the full
path to the to-be-written file.

I'll attempt a fix immediately.

Edward

-- 
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 to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: saving cloned @clean files in different @path's

[Edward K. Ream]

On Mon, Nov 6, 2017 at 2:49 PM, Phil  wrote:

​> ​
It used to be the case that changing a cloned @file-like node would result
in those changes being saved to all the paths under which the clone lived
in the Leo outline.

​I see this behavior.  Please file a bug report.

> it seems inconsistent that changing an organizer-node-clone would trigger
file writes for all files containing that clone, but that changing an
@file-node-clone would not do the same.

I agree.

Edward

-- 
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 to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: saving cloned @clean files in different @path's

[vitalije]

>
> If the reason for not using @file-node-clones is because of the risk of 
> data loss, then my next question becomes "why is there a risk of data 
> loss?" If the answer to this is due to some fundamental property of 
> outlines containing clones, then I'd like to understand that better so that 
> I can work accordingly. If that is not the case however, then the 
> underlying cause of data loss should be addressed, rather than to simply 
> adhere to a convention of not using @file-node-clones.
>

I am not 100% sure, but I believe that this restriction is dictated with 
the present read or write algorithm. IIRC few months ago when I was 
experimenting with the new read/write algorithm I have realized that with 
the new algorithm that restriction can be removed. However, this new 
read/write algorithm is not incorporated into Leo yet.

The experimental code can be found here 

.

One solution could be to use symbolic links instead of real files in other 
directories (that is what I usually use). Or you can write a plugin (or 
script) that registers 'save2' handler which is invoked after outline is 
saved and in the handler make copies of external files. 

Vitalije

-- 
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 to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: saving cloned @clean files in different @path's

[Phil]

Matt,
 

> I replicated the only-1-copy-written behaviour here with both @file and 
> @clean cloned nodes. 
>

Good! I'm not crazy...!


> I Edward explained that he really didn't like cloned 
> @file/@thin/@shadow/... nodes because of {...cache problems? race 
> conditions?} and possibility of data loss. (whee! I found it)
>
> The advised pattern is to have distinct `@file path1/thing` and `@file 
> path2/thing` head nodes and then create an organizer node inside each and 
> clone that instead.
>
 
I tried that, and indeed it works. However, it seems inconsistent that 
changing an organizer-node-clone would trigger file writes for all files 
containing that clone, but that changing an @file-node-clone would not do 
the same.

Further experimentation shows that only the *first* @file-node-clone that 
appears (in top-to-bottom traversal order) in the outline actually gets 
saved on change - subsequent clones are not saved to their respective 
paths. If I exchange the order of the clones in the outline, suddenly a 
different file is being saved, but none of the others.

If the reason for not using @file-node-clones is because of the risk of 
data loss, then my next question becomes "why is there a risk of data 
loss?" If the answer to this is due to some fundamental property of 
outlines containing clones, then I'd like to understand that better so that 
I can work accordingly. If that is not the case however, then the 
underlying cause of data loss should be addressed, rather than to simply 
adhere to a convention of not using @file-node-clones.

-- 
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 to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: saving cloned @clean files in different @path's

[Matt Wilkie]

Hi Phil,

I replicated the only-1-copy-written behaviour here with both @file and
@clean cloned nodes.

I used to use cloned @file nodes in order to always have same copy of
`thing.py` in my development folder and in a shared system path. It saved
me from having to keep running a deploy script to update the copy. I really
liked that! Until... something weird happened and both copies got messed
up. And then a few weeks later it happened again. Edward explained that he
really didn't like cloned @file/@thin/@shadow/... nodes because of
{...cache problems? race conditions?} and possibility of data loss. (whee!
I found it)

The advised pattern is to have distinct `@file path1/thing` and `@file
path2/thing` head nodes and then create an organizer node inside each and
clone that instead.

This was a couple years ago. I don't know what might have changed since
then.

-Matt




On Mon, Nov 6, 2017 at 12:49 PM, Phil  wrote:

> Leo 5.6, build 20171105131700, Sun Nov  5 13:17:00 PST 2017
> Git repo info: branch = master, commit = 94ebac1f2510
> Python 2.7.13, PyQt version 5.6.2
> Windows 7 AMD64 (build 6.1.7601) SP1
> isPython3: False
> caching enabled
>
> Place the attached file in a folder containing empty subdirectories sub1
> and sub2. Then open the .leo file and do the following:
>
> 1) Select the test.c node under the sub1 path, make an edit to the body,
> and save the file. The file test.c will be created in directory sub1, but
> not in sub2.
>
> 2) Select the test.c node under the sub2 path, make an edit to the body,
> and save the file. The file test.c in directory sub1 will be modified, but
> there will be no file created in directory sub2.
>
> 3) With the test.c node under the sub2 path still selected, make an edit
> to the body, then save using Ctrl-Shift-W. The file test.c will be created
> in directory sub2 with the new edits, but the file in directory sub1 will
> not be updated.
>
> This behavior does not match what used to happen in the past (maybe more
> than a year ago). It used to be the case that changing a cloned @file-like
> node would result in those changes being saved to all the paths under which
> the clone lived in the Leo outline.
>
> I just recently switched to using the GIT repo as my Leo install, so maybe
> I lost a setting in that switch. Or maybe Leo's behavior changed. Either
> way, I'd like it to be what it used to be. Any suggestions?
>
> Thanks!
> Phil
>
> --
> 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 to this group, send email to leo-editor@googlegroups.com.
> Visit this group at https://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

saving cloned @clean files in different @path's

[Phil]

Leo 5.6, build 20171105131700, Sun Nov  5 13:17:00 PST 2017
Git repo info: branch = master, commit = 94ebac1f2510
Python 2.7.13, PyQt version 5.6.2
Windows 7 AMD64 (build 6.1.7601) SP1
isPython3: False
caching enabled

Place the attached file in a folder containing empty subdirectories sub1 
and sub2. Then open the .leo file and do the following:

1) Select the test.c node under the sub1 path, make an edit to the body, 
and save the file. The file test.c will be created in directory sub1, but 
not in sub2.

2) Select the test.c node under the sub2 path, make an edit to the body, 
and save the file. The file test.c in directory sub1 will be modified, but 
there will be no file created in directory sub2.

3) With the test.c node under the sub2 path still selected, make an edit to 
the body, then save using Ctrl-Shift-W. The file test.c will be created in 
directory sub2 with the new edits, but the file in directory sub1 will not 
be updated.

This behavior does not match what used to happen in the past (maybe more 
than a year ago). It used to be the case that changing a cloned @file-like 
node would result in those changes being saved to all the paths under which 
the clone lived in the Leo outline.

I just recently switched to using the GIT repo as my Leo install, so maybe 
I lost a setting in that switch. Or maybe Leo's behavior changed. Either 
way, I'd like it to be what it used to be. Any suggestions?

Thanks!
Phil

-- 
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 to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.


test.leo
Description: Binary data