As a follow up: I figured out the grey box, it's just the unsaved/dirty nodes, so it's not that.
Regarding the file size for the DB, I assume this is because the version I sent you doesn't have any content. So I think this is a legitimate size for the doc, but it probably needs to be vacuumed/cleaned up to reduce it back. https://sqlite.org/lang_vacuum.html The Leo version is 16MB which is a bit smaller but not quite as dramatic. Kevin On Thursday, September 3, 2020 at 4:54:51 PM UTC-4 k-hen wrote: > Hmm ... well at least it seems reproduceable. I did run across at least > one set of nodse after filing this that were behaving as clones but not > flagged as clones, and it's probably the same ones. Not sure if it matters > but the box icon was grey instead of black, I thought that was unusual as > well, but not sure what that indicates > > I'm using the sqlite version because I assumed it could offer better > performance for very large outlines (e.g. potentially 50K+ nodes). > Also, because I like SQL and can connect to it with DBVisualizer/alternate > tools and write queries (read only ones for now) and/or use ETL workflows > with it. > > One thing that _might_ be happening is that I have a 'code' top-level tree > that syncs with other developers using Git. > It's using @file's and so there are now comments scattered throughout the > code base. > Then subnodes within this tree are cloned into @nosent 'documentation' > trees which contains other notes/commentary outputs. > This is mostly doing what I want, but importing the nodes sometimes > results in errors/broken outlines/etc, which I have to repair. > I close Leo, do the pull, then open Leo again and let it import. > Then I fix any issues (mostly nodes losing their parents and appearing at > the root). > I also keep an eye on Git to ensure that I'm not making any unwanted > changes after doing this and can revert if necessary. > It's possible that other developers are copying/moving blocks of code that > include the Leo comments (I've asked them not to do this). > We're making a lot of structural changes now too as we're refactoring so > this should settle down later. > > For now, perhaps I can save as .leo and then save back as .leo.db to > potentially repair any issues. > > Is it perhaps possible to detect and/or repair these broken clones using a > script? > > Thanks so much for all your help. > > Kevin > > > > > On Thu, 2020-09-03 at 11:52 -0700, Edward K. Ream wrote: > > On Wednesday, September 2, 2020 at 3:24:45 PM UTC-5, k-hen wrote: > > Ok, got it, will need a bit of time, but will get back to you soon. > > > Something strange is going on. Here is what I think I know: > > The unpacked original file is leo_error_test_01 - cleared - Copy.db. It is > about 28.1 MB in size. > > Opening the file with Leo does work, but the two "node 5660" are not *shown > as *clones of each other. Yet they have the same gnx and id(v) is the > same for each. Imo, this is likely the ultimate cause of the crash. > > Saving this .db as a .leo file creates a valid .leo file in which the two > "node 5660" are indeed true clones. The bug never appears in the .leo file. > > Saving the .leo file as a .leo.db file creates a much smaller file, about > 1.2 MB. However, in all other respects it appears to be identical to the > original .db file. The two "node 5660" are not *shown as *clones of each > other, and the bug does manifest itself. > > My *tentative* conclusion is that there may be a bug in > fc.retrieveVnodesFromDb. However, there are no special cases in this code, > so what the bug could possibly be is a big mystery. Iirc, Vitalije wrote > this code. Any insights would be appreciated. > > Finally, I note that the .leo files are smaller than the corresponding .db > files, so one workaround would be to use the .leo files instead. > Presumably, however, there are reasons for using the .db files. > > Edward > > -- > You received this message because you are subscribed to a topic in the > Google Groups "leo-editor" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/leo-editor/sANduRjZDVI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > leo-editor+...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/leo-editor/9afd5fe4-7fd3-4e68-91d7-283f02367601o%40googlegroups.com > > <https://groups.google.com/d/msgid/leo-editor/9afd5fe4-7fd3-4e68-91d7-283f02367601o%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/8a91e782-93a9-45d1-b18b-33abe83239a5n%40googlegroups.com.
