@clean/@auto files are not always written

143 views
Skip to first unread message

gar

unread,
Dec 2, 2019, 7:31:04 AM12/2/19
to leo-editor
I am using Leo 6.2-b1-devel, devel branch, build 17a59d4ad2, on Windows7-x64 with python 3.7
I am trying to develop html; I made a @clean node and sections for css, body and etc. 
I discovered that occasionally when I save .leo project with ctrl-s @clean file is not written to the disk, and when I reload it in the browser - it displays it with old css.
I also check it via opening in notepad by abs path and see that changes were not applied.
Afterwards changes cannot be saved almost for ever. But sometimes they do.
I cannot say anything more but that it happens relatively often and happens with @auto node too (first saw editing .js file).

gar

unread,
Dec 2, 2019, 7:37:52 AM12/2/19
to leo-editor
When saving OK the text "saved: <project>.leo \n saved: <file>.html" appears in the log pane.
When saving does not happen -  no line about saving <file>.html.
Sometimes line "unchanged: <file>/html" appears while it is definitely changed.
Looks like an optimization for saving file nodes works wrong.

Matt Wilkie

unread,
Dec 2, 2019, 4:33:20 PM12/2/19
to leo-e...@googlegroups.com
I discovered that occasionally when I save .leo project with ctrl-s @clean file is not written to the disk, and when I reload it in the browser - it displays it with old css.

I've a long had an uneasy feeling there's a subtle bug in external file reading/writing cache but every time I think I can reproduce or describe it, it disapears. #1081 is one of the explorations, though central wierdness was @asis not @clean so high probability not related at all to your experience.I sometimes wonder if the source emanates from outide Leo (anti-virus scanner induced file-system delay, network timing issues, ...). Safeguard by using version control and/or file-system "previous versions" feature.

-matt

Matt Wilkie

unread,
Dec 2, 2019, 4:33:46 PM12/2/19
to leo-editor

John Clark

unread,
Dec 4, 2019, 3:42:07 PM12/4/19
to leo-editor
Reliable two-way synchronisation is a complex programming challenge. In my experience the proportion of two-way sync tools that actually work reliably, particularly in common (let alone obscure) edge cases, is quite small. Unison is one of the few examples of two-way sync that actually works reliably.

For this reason my latest leo-based project I have used @nosent nodes exclusively. This way, the @nosent leo nodes are the only "source of truth" for generated file content. 

Of course, @nosent nodes can't be used (smoothly) for projects where there are multiple contributors or where it's unavoidable that non-leo tools will be changing file contents.

The reason I bring this up here is I recently created issue #1450 which concerns what I believe are bug(s) concerning writing of @nosent file nodes. 

I suspect that my issue is related to yours, at least in part. See the comments in my issue for further info, specifically the bit about where leo was silently failing to write some nodes.

Cheers

gar

unread,
Dec 5, 2019, 1:50:58 AM12/5/19
to leo-editor
Thank you. John!
Looks like I would have to write the same script if I want to keep working on my project in leo.
Now it's kinda hard cause I just dont trust leo anymore and cant say for sure is the observed misbehavior in my code introduced by my own or files were not written properly (especially when you deal with not obvious css subtleties).
I tired to chek out the contents on every suspect and for now switched back to vim. It just works.
Hope very much that such a critical bug would be fixed in the nearest future. Unfortunately I cannot take care of it by myself because of poor knowledge of leo's internals and ecosystem.

среда, 4 декабря 2019 г., 23:42:07 UTC+3 пользователь John Clark написал:

gar

unread,
Dec 5, 2019, 1:58:51 AM12/5/19
to leo-editor
After some days of observations I made a conclusion that the most probability to silently skip saving have files with small changes introduced since last save.
If I change 5-10 LOCs - then file is generally written normally.
If I say change a propertie's value in the css - it can be ignore with a chance of 15-20%.
For now I track changed files by their icons with my eyes and carefully read what leo writes to log pane - and if line with `written: file_with_small_changes.css` is missing then I start to play around with doing useless changes until file is saved.
Well it's kinda not the thing I expect to use in the 21st century :-)

Edward K. Ream

unread,
Dec 5, 2019, 5:25:55 AM12/5/19
to leo-editor


On Wed, Dec 4, 2019 at 2:42 PM John Clark <leve...@theinsideworld.net> wrote:
Reliable two-way synchronization is a complex programming challenge.

I've put a lot of work into @clean. I intend to have it work perfectly.

I have just created #1451 to deal with recent reports.  This is not likely to be a problem in the @clean or @auto logic itself.  Instead, it is more likely to be an issue with marking the root @<file> nodes dirty.

Edward

gar

unread,
Dec 5, 2019, 6:44:57 AM12/5/19
to leo-e...@googlegroups.com
I suspect that the problem is not exactly in the auto/clean/nosent saving algos.
Please consider that " `written: file_with_small_changes.css`" is missing - so probably the node is not taken into account at all.
Thanks a lot that took care about this issue, it's very annoying.

чт, 5 дек. 2019 г. в 13:25, Edward K. Ream <edre...@gmail.com>:
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS1vvf_Jq-BveUaJ66Vvj8Gv975%3DQKRiXZ9MHO0JAr%3DZkw%40mail.gmail.com.

gar

unread,
Dec 5, 2019, 2:48:51 PM12/5/19
to leo-editor
Tonight when I changed my @clean html file with a single line ending and saved the .leo I saw the following line in the log: color:white
So this is definitely something's wrong with the code responsible for discovering dirty nodes.

Edward K. Ream

unread,
Dec 6, 2019, 2:35:10 PM12/6/19
to leo-editor


On Thursday, December 5, 2019 at 1:48:51 PM UTC-6, gar wrote:
Tonight when I changed my @clean html file with a single line ending and saved the .leo I saw the following line in the log: color:white

You saw "color:white" in the log??

So this is definitely something's wrong with the code responsible for discovering dirty nodes.

I agree. I'll get to it next.

Edward

Edward K. Ream

unread,
Dec 6, 2019, 2:38:38 PM12/6/19
to leo-editor
My apologies for these troubles. There is indeed some logic concerning "small changes".  It's supposed to be involved in the @auto logic somehow, I don't remember the details. Perhaps the logic is being used inappropriately.  This is an important clue.

Edward

gar

unread,
Dec 6, 2019, 4:17:27 PM12/6/19
to leo-e...@googlegroups.com
пт, 6 дек. 2019 г. в 22:35, Edward K. Ream <edre...@gmail.com>:
You saw "color:white" in the log??
No, it's a mistype. I sometimes dont see standart 'wrote: filename.auto' message 

Edward K. Ream

unread,
Dec 6, 2019, 5:28:14 PM12/6/19
to leo-editor
It looks like some file-caching code may be involved.  If so, I'm going to ban file caching :-) The benefits don't begin to outweigh the pain when things go wrong.

Edward

gar

unread,
Dec 7, 2019, 1:51:22 AM12/7/19
to leo-e...@googlegroups.com
Edward, I also want to note, that I switched away from @auto to @clean files (I was hoping  that bug will go away).
And now not totally sure that the things I told you above happen with @auto.
But they definitely do with @clean.

сб, 7 дек. 2019 г. в 01:28, Edward K. Ream <edre...@gmail.com>:
--
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+...@googlegroups.com.

Edward K. Ream

unread,
Dec 7, 2019, 6:13:11 AM12/7/19
to leo-editor
On Sat, Dec 7, 2019 at 12:51 AM gar <gar...@gmail.com> wrote:
Edward, I also want to note, that I switched away from @auto to @clean files (I was hoping  that bug will go away).
And now not totally sure that the things I told you above happen with @auto.
But they definitely do with @clean.

Thanks for the clarification.  I am about to look at this issue.

Edward

Edward K. Ream

unread,
Dec 8, 2019, 5:43:15 AM12/8/19
to leo-editor
On Wednesday, December 4, 2019 at 2:42:07 PM UTC-6, John Clark wrote:

Reliable two-way synchronisation is a complex programming challenge.

Did I delete your script by mistake?  Matt thanked you for it, but I can't seem to find it.  Could you give it to us again.  Thanks.

Edward

John Clark

unread,
Dec 9, 2019, 5:02:25 AM12/9/19
to leo-editor
Edward,

Was your question directed at me? If so, I'm not sure what script you're referring to.

Edward K. Ream

unread,
Dec 11, 2019, 6:37:04 AM12/11/19
to leo-editor
On Mon, Dec 9, 2019 at 4:02 AM John Clark <leve...@theinsideworld.net> wrote:
Edward,

Was your question directed at me? If so, I'm not sure what script you're referring to.

Apparently not.

Edward
Reply all
Reply to author
Forward
0 new messages