Re: ENB: Proposal re #199: handling already-open files
On Fri, Jun 26, 2015 at 10:38 AM, Todd Mars tamn...@gmail.com wrote: Hi, There is kind of a standard way to deal with this problem, already. 1) an option to allow multiple versions of the app to run, or not. (maybe check if a file exists in the folder you keep your database file in) I know of no easy, cross-platform way of discovering whether two separate instances of Leo are running. Do you? EKR -- 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 http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: ENB: Proposal re #199: handling already-open files
On Thursday, June 25, 2015 at 4:13:52 PM UTC-5, Terry Brown wrote: On Thu, 25 Jun 2015 07:23:42 -0700 (PDT) Todd Mars tamn...@gmail.com wrote: Hi, Why is it needed to know that another copy of Leo is running? Load outline a.leo in Leo instance A, modify, iconify, forget. Now load outline a.leo (again) in Leo instance B, modify, save, close. Later, de-iconify Leo instance A, save, close. You just overwrote the changes you made to the outline in the second loading in instance B. Thanks, Terry, for this clear explanation. Much better than mine. EKR -- 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 http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: ENB: Proposal re #199: handling already-open files
Hi, There is kind of a standard way to deal with this problem, already. 1) an option to allow multiple versions of the app to run, or not. (maybe check if a file exists in the folder you keep your database file in) 2) When refreshing the display, check if a later version of the file exists than what is opened. (if the stored version is later than the last saved or loaded version) If so, ask the user if the user wants to load the later version of the file. I think this behavior is in Notepad++ which is a good template for what works well for people. It would be so cool to actually diff the two versions and show the user wouldn't it? (in a separate floating window) Sorry I'm being extraneous. thanks! Todd. On Saturday, June 20, 2015 at 7:01:07 PM UTC-4, Edward K. Ream wrote: #199 https://github.com/leo-editor/leo-editor/issues/199 is presently the most serious bug in Leo. Sometimes, but not always, cancelling the load of an already-opened .leo file will hard crash Leo (Python). This post is an Engineering Notebook post. It's most notes to myself and Terry. Feel free to ignore. I am studying a core dump on Ubuntu. It's been fun learning about apport-retrace http://manpages.ubuntu.com/manpages/vivid/en/man1/apport-retrace.1.html, but not *that *much fun. Terry's analysis of the problem is good enough for me. It's time to solve the problem with design, not mere code. *The original problem*Leo should indeed warn users when they attempt to open an already-open file, call it *f.leo*. Saving either copy of f.leo could destroy data previously saved in the *other* copy of f.leo. The problem is not actually very serious, because Leo *already *warns if f.leo has been changed outside of the presently executing copy of Leo. For example, suppose two invocations of Leo exists. Let's call them *A* and *B*. Suppose Leo A saves f.leo. Later, if B saves f.leo, Leo B will issue a warning that f.leo has been changed outside of B. Still, I think it is best to warn the user if f.leo is already open. The mechanism for checking for already-open files is fine. Leo makes entries in the global db file when opening a file and deletes entries in the db when closing the file. This can lead to spurious already open messages if Leo is killed rather than being closed normally. The db will contain an entry for a .leo file that is not, in fact, open. Happily, this has never been a big deal. Furthermore, the following scheme handles this case even more smoothly than before. *Proposal: always open files, even if already open* Leo will no longer issue *per-file* requests for guidance. Instead, Leo will open all possibly-already-open files, putting warnings about them in the log. Finally, Leo will raise a *single *warning dialog. This dialog will list the files that might already be open, and suggest that the user close duplicate files in whatever copy of Leo is more convenient. This scheme solves several problems: 1. Leo always loads files. This instantly eliminates the possibility of hard crashes. 2. It's faster than the existing scheme. The user only has to dismiss the summary dialog. 3. The user will never have to choose *right now *what action to take. Such choices are *always *odious and stressful. Instead, the user can choose to close the duplicate f.leo file in either A or B. In most cases, it's safe to leave *both* copies open, as long as both don't change. To repeat, Leo will issue a warning if that happens. 4. Closing a duplicate file, in either A or B, automatically clears the db entry for that file. There is no need to ask the user whether to reset the db! The only complication will be knowing exactly when/where to issue the warning dialog. The details will be different depending on whether Leo is loading multiple files at startup, or loading a single file later. But this is only a coding detail. *Summary* A single dialog that warns about possibly-already-open files is the simplest thing that could possibly work: - It's easy to code. - It will stamp out hard crashes. - It's simpler, faster, more flexible and less stressful for the user. Unless there are strong objections to this scheme, I plan to put it into effect immediately. Your comments, please, Amigos. Edward http://manpages.ubuntu.com/apport-retrace -- 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 http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: ENB: Proposal re #199: handling already-open files
On Monday, June 22, 2015 at 10:18:01 PM UTC+1, Edward K. Ream wrote: On Mon, Jun 22, 2015 at 1:37 PM, Todd Mars tam...@gmail.com javascript: wrote: The thing where it says it's already open when it's not, now I understand it! Where is this global db file and why is it necessary? It's (usually?) in ~/.leo/db/global/open-leo-files This a binary file (pickleshare). It's necessary because there is no portable way to determine whether another copy of Leo is running. EKR FWIW, I've done this in a cross-platform way by 'allocating' a port number and using a listening socket on that port. You may not like this for other reasons ... ;-/ J^n -- 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 http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: ENB: Proposal re #199: handling already-open files
On Thu, 25 Jun 2015 07:23:42 -0700 (PDT) Todd Mars tamn...@gmail.com wrote: Hi, Why is it needed to know that another copy of Leo is running? Thanks! (this kind of thing is fascinating!) Load outline a.leo in Leo instance A, modify, iconify, forget. Now load outline a.leo (again) in Leo instance B, modify, save, close. Later, de-iconify Leo instance A, save, close. You just overwrote the changes you made to the outline in the second loading in instance B. So it's not really a matter of knowing another instance of Leo is running, which is fine and so routine it doesn't require any warning, it's a matter of knowing another Leo has the same outline open already, and if so issuing a warning. This is achieved by recording which outlines are open in the global shared database, and warning when an already open one is loaded again. I usually experience the flip side of the issue, load some outlines, rudely hard-kill Leo accidentally (kill a VNC server, break an X11 connection, etc). That means Leo never gets a chance to update the global db to record that an outline is no longer open (as it would normally do when Leo exits), so it things it's open elsewhere when it's not. The spurious warning does no harm in those cases, the lack of a warning can cause real heartache, as described in first para. Cheers -Terry On Monday, June 22, 2015 at 5:18:01 PM UTC-4, Edward K. Ream wrote: On Mon, Jun 22, 2015 at 1:37 PM, Todd Mars tam...@gmail.com javascript: wrote: The thing where it says it's already open when it's not, now I understand it! Where is this global db file and why is it necessary? It's (usually?) in ~/.leo/db/global/open-leo-files This a binary file (pickleshare). It's necessary because there is no portable way to determine whether another copy of Leo is running. EKR -- 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 http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: ENB: Proposal re #199: handling already-open files
Hi, Why is it needed to know that another copy of Leo is running? Thanks! (this kind of thing is fascinating!) On Monday, June 22, 2015 at 5:18:01 PM UTC-4, Edward K. Ream wrote: On Mon, Jun 22, 2015 at 1:37 PM, Todd Mars tam...@gmail.com javascript: wrote: The thing where it says it's already open when it's not, now I understand it! Where is this global db file and why is it necessary? It's (usually?) in ~/.leo/db/global/open-leo-files This a binary file (pickleshare). It's necessary because there is no portable way to determine whether another copy of Leo is running. EKR -- 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 http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: ENB: Proposal re #199: handling already-open files
The thing where it says it's already open when it's not, now I understand it! Where is this global db file and why is it necessary? thanks Todd. On Saturday, June 20, 2015 at 7:01:07 PM UTC-4, Edward K. Ream wrote: #199 https://github.com/leo-editor/leo-editor/issues/199 is presently the most serious bug in Leo. Sometimes, but not always, cancelling the load of an already-opened .leo file will hard crash Leo (Python). This post is an Engineering Notebook post. It's most notes to myself and Terry. Feel free to ignore. I am studying a core dump on Ubuntu. It's been fun learning about apport-retrace http://manpages.ubuntu.com/manpages/vivid/en/man1/apport-retrace.1.html, but not *that *much fun. Terry's analysis of the problem is good enough for me. It's time to solve the problem with design, not mere code. *The original problem*Leo should indeed warn users when they attempt to open an already-open file, call it *f.leo*. Saving either copy of f.leo could destroy data previously saved in the *other* copy of f.leo. The problem is not actually very serious, because Leo *already *warns if f.leo has been changed outside of the presently executing copy of Leo. For example, suppose two invocations of Leo exists. Let's call them *A* and *B*. Suppose Leo A saves f.leo. Later, if B saves f.leo, Leo B will issue a warning that f.leo has been changed outside of B. Still, I think it is best to warn the user if f.leo is already open. The mechanism for checking for already-open files is fine. Leo makes entries in the global db file when opening a file and deletes entries in the db when closing the file. This can lead to spurious already open messages if Leo is killed rather than being closed normally. The db will contain an entry for a .leo file that is not, in fact, open. Happily, this has never been a big deal. Furthermore, the following scheme handles this case even more smoothly than before. *Proposal: always open files, even if already open* Leo will no longer issue *per-file* requests for guidance. Instead, Leo will open all possibly-already-open files, putting warnings about them in the log. Finally, Leo will raise a *single *warning dialog. This dialog will list the files that might already be open, and suggest that the user close duplicate files in whatever copy of Leo is more convenient. This scheme solves several problems: 1. Leo always loads files. This instantly eliminates the possibility of hard crashes. 2. It's faster than the existing scheme. The user only has to dismiss the summary dialog. 3. The user will never have to choose *right now *what action to take. Such choices are *always *odious and stressful. Instead, the user can choose to close the duplicate f.leo file in either A or B. In most cases, it's safe to leave *both* copies open, as long as both don't change. To repeat, Leo will issue a warning if that happens. 4. Closing a duplicate file, in either A or B, automatically clears the db entry for that file. There is no need to ask the user whether to reset the db! The only complication will be knowing exactly when/where to issue the warning dialog. The details will be different depending on whether Leo is loading multiple files at startup, or loading a single file later. But this is only a coding detail. *Summary* A single dialog that warns about possibly-already-open files is the simplest thing that could possibly work: - It's easy to code. - It will stamp out hard crashes. - It's simpler, faster, more flexible and less stressful for the user. Unless there are strong objections to this scheme, I plan to put it into effect immediately. Your comments, please, Amigos. Edward http://manpages.ubuntu.com/apport-retrace -- 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 http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: ENB: Proposal re #199: handling already-open files
On Mon, Jun 22, 2015 at 1:37 PM, Todd Mars tamn...@gmail.com wrote: The thing where it says it's already open when it's not, now I understand it! Where is this global db file and why is it necessary? It's (usually?) in ~/.leo/db/global/open-leo-files This a binary file (pickleshare). It's necessary because there is no portable way to determine whether another copy of Leo is running. EKR -- 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 http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: ENB: Proposal re #199: handling already-open files
On Sun, Jun 21, 2015 at 12:18 AM, 'Terry Brown' via leo-editor leo-editor@googlegroups.com wrote: ...the use case I have mostly is yes to all. I.e. they're not really open elsewhere. Hmmm, I guess there's nothing to add to the below to deal with that - the warnings / dialog should say this / these outlines *appear* to be open elsewhere - in my case it arises from killing Leo accidentally in virtual machines, VNC connections, dropped X11 forwarding etc. Thanks for this comment. We are on the same page. I'm wondering what the dialog should say. There is a temptation to explain about the multiple update problem, etc., but I'm leaning toward just having the dialog say, The following files may be open in another copy of Leo. EKR -- 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 http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
ENB: Proposal re #199: handling already-open files
#199 https://github.com/leo-editor/leo-editor/issues/199 is presently the most serious bug in Leo. Sometimes, but not always, cancelling the load of an already-opened .leo file will hard crash Leo (Python). This post is an Engineering Notebook post. It's most notes to myself and Terry. Feel free to ignore. I am studying a core dump on Ubuntu. It's been fun learning about apport-retrace http://manpages.ubuntu.com/manpages/vivid/en/man1/apport-retrace.1.html, but not *that *much fun. Terry's analysis of the problem is good enough for me. It's time to solve the problem with design, not mere code. *The original problem*Leo should indeed warn users when they attempt to open an already-open file, call it *f.leo*. Saving either copy of f.leo could destroy data previously saved in the *other* copy of f.leo. The problem is not actually very serious, because Leo *already *warns if f.leo has been changed outside of the presently executing copy of Leo. For example, suppose two invocations of Leo exists. Let's call them *A* and *B*. Suppose Leo A saves f.leo. Later, if B saves f.leo, Leo B will issue a warning that f.leo has been changed outside of B. Still, I think it is best to warn the user if f.leo is already open. The mechanism for checking for already-open files is fine. Leo makes entries in the global db file when opening a file and deletes entries in the db when closing the file. This can lead to spurious already open messages if Leo is killed rather than being closed normally. The db will contain an entry for a .leo file that is not, in fact, open. Happily, this has never been a big deal. Furthermore, the following scheme handles this case even more smoothly than before. *Proposal: always open files, even if already open* Leo will no longer issue *per-file* requests for guidance. Instead, Leo will open all possibly-already-open files, putting warnings about them in the log. Finally, Leo will raise a *single *warning dialog. This dialog will list the files that might already be open, and suggest that the user close duplicate files in whatever copy of Leo is more convenient. This scheme solves several problems: 1. Leo always loads files. This instantly eliminates the possibility of hard crashes. 2. It's faster than the existing scheme. The user only has to dismiss the summary dialog. 3. The user will never have to choose *right now *what action to take. Such choices are *always *odious and stressful. Instead, the user can choose to close the duplicate f.leo file in either A or B. In most cases, it's safe to leave *both* copies open, as long as both don't change. To repeat, Leo will issue a warning if that happens. 4. Closing a duplicate file, in either A or B, automatically clears the db entry for that file. There is no need to ask the user whether to reset the db! The only complication will be knowing exactly when/where to issue the warning dialog. The details will be different depending on whether Leo is loading multiple files at startup, or loading a single file later. But this is only a coding detail. *Summary* A single dialog that warns about possibly-already-open files is the simplest thing that could possibly work: - It's easy to code. - It will stamp out hard crashes. - It's simpler, faster, more flexible and less stressful for the user. Unless there are strong objections to this scheme, I plan to put it into effect immediately. Your comments, please, Amigos. Edward http://manpages.ubuntu.com/apport-retrace -- 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 http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: ENB: Proposal re #199: handling already-open files
This sounds ok to me - there's something wrong in the current code that could perhaps be hunted down, but I know I already fixed one reproducible bug in this area so it's obviously a hairy area. So the below approach seems like the most robust. I'd just add that the use case I have mostly is yes to all. I.e. they're not really open elsewhere. Hmmm, I guess there's nothing to add to the below to deal with that - the warnings / dialog should say this / these outlines *appear* to be open elsewhere - in my case it arises from killing Leo accidentally in virtual machines, VNC connections, dropped X11 forwarding etc. Cheers -Terry On Sat, 20 Jun 2015 16:01:07 -0700 (PDT) Edward K. Ream edream...@gmail.com wrote: #199 https://github.com/leo-editor/leo-editor/issues/199 is presently the most serious bug in Leo. Sometimes, but not always, cancelling the load of an already-opened .leo file will hard crash Leo (Python). This post is an Engineering Notebook post. It's most notes to myself and Terry. Feel free to ignore. I am studying a core dump on Ubuntu. It's been fun learning about apport-retrace http://manpages.ubuntu.com/manpages/vivid/en/man1/apport-retrace.1.html, but not *that *much fun. Terry's analysis of the problem is good enough for me. It's time to solve the problem with design, not mere code. *The original problem*Leo should indeed warn users when they attempt to open an already-open file, call it *f.leo*. Saving either copy of f.leo could destroy data previously saved in the *other* copy of f.leo. The problem is not actually very serious, because Leo *already *warns if f.leo has been changed outside of the presently executing copy of Leo. For example, suppose two invocations of Leo exists. Let's call them *A* and *B*. Suppose Leo A saves f.leo. Later, if B saves f.leo, Leo B will issue a warning that f.leo has been changed outside of B. Still, I think it is best to warn the user if f.leo is already open. The mechanism for checking for already-open files is fine. Leo makes entries in the global db file when opening a file and deletes entries in the db when closing the file. This can lead to spurious already open messages if Leo is killed rather than being closed normally. The db will contain an entry for a .leo file that is not, in fact, open. Happily, this has never been a big deal. Furthermore, the following scheme handles this case even more smoothly than before. *Proposal: always open files, even if already open* Leo will no longer issue *per-file* requests for guidance. Instead, Leo will open all possibly-already-open files, putting warnings about them in the log. Finally, Leo will raise a *single *warning dialog. This dialog will list the files that might already be open, and suggest that the user close duplicate files in whatever copy of Leo is more convenient. This scheme solves several problems: 1. Leo always loads files. This instantly eliminates the possibility of hard crashes. 2. It's faster than the existing scheme. The user only has to dismiss the summary dialog. 3. The user will never have to choose *right now *what action to take. Such choices are *always *odious and stressful. Instead, the user can choose to close the duplicate f.leo file in either A or B. In most cases, it's safe to leave *both* copies open, as long as both don't change. To repeat, Leo will issue a warning if that happens. 4. Closing a duplicate file, in either A or B, automatically clears the db entry for that file. There is no need to ask the user whether to reset the db! The only complication will be knowing exactly when/where to issue the warning dialog. The details will be different depending on whether Leo is loading multiple files at startup, or loading a single file later. But this is only a coding detail. *Summary* A single dialog that warns about possibly-already-open files is the simplest thing that could possibly work: - It's easy to code. - It will stamp out hard crashes. - It's simpler, faster, more flexible and less stressful for the user. Unless there are strong objections to this scheme, I plan to put it into effect immediately. Your comments, please, Amigos. Edward http://manpages.ubuntu.com/apport-retrace -- 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 http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
