Hi All,
I've created this thread separate from Eugene's and Ditmar's session management threads because my concern is mostly about other parts of Geany and I don't want to be seen as criticising either of them as it was their input that started me thinking.
Having multiple Geany instances is a great capability,
* I can have two (or more) projects open to share code or to interrupt work on one to do something an another, * I can have Geany on *both* of my screens so I can see different parts of what I'm working on * I can set up my filemanager to open different instances so opening random files won't affect the work I'm doing
My concern is that we should make sure that the way Geany works is safe and preferably causes no surprises when multiple instances are sharing files.
There are three types of files that Geany instances could share and I think they should be handled differently:
* Files being edited (the second of my use cases above). I don't think it is up to Geany to handle users editing the same file in multiple instances, its up to the user to sort it out when time comes to save. A user can always set readonly to protect against themselves. Making --readonly a command line option would be a good addition.
* Project files (same project in two instances), since the user doesn't explicitly control the project file I think Geany is going to have to become involved in this case. The only options that I can see in this case are:
** when a project file has changed on disk (by date/time), for Geany to ask if it should save or save as or throw away any changes to project from this instance. This way an instance won't silently overwrite changes made by another instance, and with save as I can procrastinate by saving this instances changes elsewhere until I can decide which I want.
** only the Geany not started with --new-instance can save the project file
* Geany.conf (shared by any two or more instances), this is a real potential problem if multiple instances try to save the same file. Discussions in another thread seemed to come to the conclusion that only the Geany that was started without --new-instance should save it preventing races when several instances are closed at once. BUT this is not implemented in the SVN that is about to become 0.19 and in my test a new instance overwrote the main Geany.conf losing session, recent files etc!!!
I think that preventing --new-instance from saving project and preference files should be implemented before 0.19 is released otherwise failing to close instances in the right order or missing an instance when logging out will overwrite the preferences. And configuring a filemanager to use --new-instance will overwrite when closed even if no other Geany is running.
Later on we can look at the other options and also look at indicating to the user which Geany instances can save, maybe by something after the Geany in the title bar?
Cheers Lex
On Fri, 21 May 2010 14:34:36 +1000% Lex Trotman elextr@gmail.com wrote:
Hi All,
I've created this thread separate from Eugene's and Ditmar's session management threads because my concern is mostly about other parts of Geany and I don't want to be seen as criticising either of them as it was their input that started me thinking.
New thread is a good idea. I am tired of looking up for recent messages in that large "Race condition" thread I created :-)
Having multiple Geany instances is a great capability,
- I can have two (or more) projects open to share code or to
interrupt work on one to do something an another,
- I can have Geany on *both* of my screens so I can see different
parts of what I'm working on
- I can set up my filemanager to open different instances so opening
random files won't affect the work I'm doing
My concern is that we should make sure that the way Geany works is safe and preferably causes no surprises when multiple instances are sharing files.
There are three types of files that Geany instances could share and I think they should be handled differently:
- Files being edited (the second of my use cases above). I don't
think it is up to Geany to handle users editing the same file in multiple instances, its up to the user to sort it out when time comes to save. A user can always set readonly to protect against themselves. Making --readonly a command line option would be a good addition.
- Project files (same project in two instances), since the user
doesn't explicitly control the project file I think Geany is going to have to become involved in this case. The only options that I can see in this case are:
** when a project file has changed on disk (by date/time), for Geany to ask if it should save or save as or throw away any changes to project from this instance. This way an instance won't silently overwrite changes made by another instance, and with save as I can procrastinate by saving this instances changes elsewhere until I can decide which I want.
** only the Geany not started with --new-instance can save the project file
The second option seems strange to me. Practically, it will forbid opening two projects simultaneously so that they are both saved. Or do I miss something?
Also, I can't see the point in opening one project in two instances… So, as to me, it isn't worth writing any code to handle that.
- Geany.conf (shared by any two or more instances), this is a real
potential problem if multiple instances try to save the same file. Discussions in another thread seemed to come to the conclusion that only the Geany that was started without --new-instance should save it preventing races when several instances are closed at once. BUT this is not implemented in the SVN that is about to become 0.19 and in my test a new instance overwrote the main Geany.conf losing session, recent files etc!!!
I think that preventing --new-instance from saving project and preference files should be implemented before 0.19 is released otherwise failing to close instances in the right order or missing an instance when logging out will overwrite the preferences. And configuring a filemanager to use --new-instance will overwrite when closed even if no other Geany is running.
Well, actually there is a very simple solution -- just check if we are run with --new-instance in `configuration_save' and forbid saving anything in this case. This is what I committed to SM.
But now there is a suggestion from Dimitar to also support changing preferences in secondary instances. The last solution I wrote in "the large thread" is to change automatic saving when closing. It should save only things that are not related to Preferences dialog (window position, opened files if needed etc.), and only in the main instance, of course. Changed preferences are saved immediately after applying changes user made in the Preferences dialog, either in a main instance or a secondary instance.
As to me, I don't need to be able to change prefs in secondary instances as I always have main instance running. But this feature might be useful to other Geany users…
Later on we can look at the other options and also look at indicating to the user which Geany instances can save, maybe by something after the Geany in the title bar?
As to me, the title is already "overcrowded" (for example, just now I have "notes.html - /home/eugene - [home] - Geany"). Instead, I would like to see this indication in the status bar.
Best regards, Eugene.
On 21 May 2010 15:13, Eugene Arshinov earshinov@gmail.com wrote:
On Fri, 21 May 2010 14:34:36 +1000% Lex Trotman elextr@gmail.com wrote:
Hi All,
I've created this thread separate from Eugene's and Ditmar's session management threads because my concern is mostly about other parts of Geany and I don't want to be seen as criticising either of them as it was their input that started me thinking.
New thread is a good idea. I am tired of looking up for recent messages in that large "Race condition" thread I created :-)
Having multiple Geany instances is a great capability,
- I can have two (or more) projects open to share code or to
interrupt work on one to do something an another,
- I can have Geany on *both* of my screens so I can see different
parts of what I'm working on
- I can set up my filemanager to open different instances so opening
random files won't affect the work I'm doing
My concern is that we should make sure that the way Geany works is safe and preferably causes no surprises when multiple instances are sharing files.
There are three types of files that Geany instances could share and I think they should be handled differently:
- Files being edited (the second of my use cases above). I don't
think it is up to Geany to handle users editing the same file in multiple instances, its up to the user to sort it out when time comes to save. A user can always set readonly to protect against themselves. Making --readonly a command line option would be a good addition.
- Project files (same project in two instances), since the user
doesn't explicitly control the project file I think Geany is going to have to become involved in this case. The only options that I can see in this case are:
** when a project file has changed on disk (by date/time), for Geany to ask if it should save or save as or throw away any changes to project from this instance. This way an instance won't silently overwrite changes made by another instance, and with save as I can procrastinate by saving this instances changes elsewhere until I can decide which I want.
** only the Geany not started with --new-instance can save the project file
The second option seems strange to me. Practically, it will forbid opening two projects simultaneously so that they are both saved. Or do I miss something?
Nope, I didn't say it was a good solution :-) or necessarily the final solution but it could be done before 0.19.
Also, I can't see the point in opening one project in two instances… So, as to me, it isn't worth writing any code to handle that.
To get two windows with the same configuration. My particular area is the build config, but more and more prefs are getting overridden in the project file like long line was recently etc.
Leaving a known potential problem situation in the release is IMHO bad, even if we think its likely to be rare. Its particularly bad if I get bit by it :-)
- Geany.conf (shared by any two or more instances), this is a real
potential problem if multiple instances try to save the same file. Discussions in another thread seemed to come to the conclusion that only the Geany that was started without --new-instance should save it preventing races when several instances are closed at once. BUT this is not implemented in the SVN that is about to become 0.19 and in my test a new instance overwrote the main Geany.conf losing session, recent files etc!!!
I think that preventing --new-instance from saving project and preference files should be implemented before 0.19 is released otherwise failing to close instances in the right order or missing an instance when logging out will overwrite the preferences. And configuring a filemanager to use --new-instance will overwrite when closed even if no other Geany is running.
Well, actually there is a very simple solution -- just check if we are run with --new-instance in `configuration_save' and forbid saving anything in this case. This is what I committed to SM.
I thought you had but I couldn't find it in "the big thread" :-) can you extract that as a patch against SVN?
But now there is a suggestion from Dimitar to also support changing preferences in secondary instances. The last solution I wrote in "the large thread" is to change automatic saving when closing. It should save only things that are not related to Preferences dialog (window position, opened files if needed etc.), and only in the main instance, of course. Changed preferences are saved immediately after applying changes user made in the Preferences dialog, either in a main instance or a secondary instance.
Have to think carefully about which things are in which category, maybe it could be ok, and could be applied to the project files as well. Reload would be good as well so that settings can be transferred between instances.
As to me, I don't need to be able to change prefs in secondary instances as I always have main instance running. But this feature might be useful to other Geany users…
Sure.
Later on we can look at the other options and also look at indicating to the user which Geany instances can save, maybe by something after the Geany in the title bar?
As to me, the title is already "overcrowded" (for example, just now I have "notes.html - /home/eugene - [home] - Geany"). Instead, I would like to see this indication in the status bar.
Sure, fine by me.
Cheers Lex
Best regards, Eugene. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 21 May 2010 16:53:56 +1000 Lex Trotman elextr@gmail.com wrote:
On 21 May 2010 15:13, Eugene Arshinov earshinov@gmail.com wrote:
But now there is a suggestion from Dimitar to also support changing preferences in secondary instances. The last solution I wrote in "the large thread" is to change automatic saving when closing. It should save only things that are not related to Preferences dialog (window position, opened files if needed etc.), and only in the main instance, of course. Changed preferences are saved immediately after applying changes user made in the Preferences dialog, either in a main instance or a secondary instance.
The way it can be implemented in detail (since I fubmled with the respective files in the last few days):
save_dialog_prefs(GKeyFile *config) becomes global configuration_save_dialog_prefs(void).
on_prefs_button_clicked() invokes configuration_save_dialog_prefs() instead of configuration_save().
configuration_save() does not invoke save_dialog_prefs().
quit_app() checks cl_options.new_instance to see if configuration_save() should be called.
There are no other calls of configuration_save(), so that should suffice.
Have to think carefully about which things are in which category, maybe it could be ok, and could be applied to the project files as well. Reload would be good as well so that settings can be transferred between instances.
If this is applied to the projects, it would be something like:
1. Project -> Properties always saves the project dialog properties, but not the file list.
Of course, as Lex wrote out, it'll have to check if the project file was modified, and ask to save / save as / throw away (apply without saving?) the changes.
2. Closing a project or quitting Geany saves only the file list, and only if that's a main instance.
I rarely open a project 2+ times, so RFC how useful would that be?
On 21 May 2010 20:06, Dimitar Zhekov hamster@mbox.contact.bg wrote:
On Fri, 21 May 2010 16:53:56 +1000 Lex Trotman elextr@gmail.com wrote:
On 21 May 2010 15:13, Eugene Arshinov earshinov@gmail.com wrote:
But now there is a suggestion from Dimitar to also support changing preferences in secondary instances. The last solution I wrote in "the large thread" is to change automatic saving when closing. It should save only things that are not related to Preferences dialog (window position, opened files if needed etc.), and only in the main instance, of course. Changed preferences are saved immediately after applying changes user made in the Preferences dialog, either in a main instance or a secondary instance.
The way it can be implemented in detail (since I fubmled with the respective files in the last few days):
save_dialog_prefs(GKeyFile *config) becomes global configuration_save_dialog_prefs(void).
on_prefs_button_clicked() invokes configuration_save_dialog_prefs() instead of configuration_save().
Yeah, save_dialog_prefs would need the parts of configuration_save() that opens and closes the file of course :-)
configuration_save() does not invoke save_dialog_prefs().
quit_app() checks cl_options.new_instance to see if configuration_save() should be called.
There are no other calls of configuration_save(), so that should suffice.
Yes.
Have to think carefully about which things are in which category, maybe
it
could be ok, and could be applied to the project files as well. Reload would be good as well so that settings can be transferred between
instances.
If this is applied to the projects, it would be something like:
- Project -> Properties always saves the project dialog properties,
but not the file list.
Of course, as Lex wrote out, it'll have to check if the project file was modified, and ask to save / save as / throw away (apply without saving?) the changes.
I'm afraid I didn't think this through enough, any change to a setting will update the project file and get it a new timestamp so you would be getting the message all the time.
I guess that if we allow multiple openings of the same project (and I can't see how we can prevent it) then when a setting is changed it will change the project file. Its probably not really a problem, it was the race when multiple instances closed that was the problem.
ATM the project saves the session files in the project each time a setting is changed, that would need fixing.
As I said post 0.19 a reload dialog could be nice so instances could be resynced.
- Closing a project or quitting Geany saves only the file list, and
only if that's a main instance.
Yes this will remove the race for the project file on closing multiple instances.
I rarely open a project 2+ times, so RFC how useful would that be?
Well as I said its to get two windows on two screens both with the same
configuration, its not about the session files in the project but the other config eg build.
Also I've just discovered that if I close a new_instance with files open when the main instance has a project open, on closing the project, the main instance's session matches the session files that were open in the new_instance.
Clearly the main instance is re-reading the conf file and getting the session files written by the new_instance. Saving session files only in the main instance will fix this too.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 21 May 2010 22:05:10 +1000 Lex Trotman elextr@gmail.com wrote:
On 21 May 2010 20:06, Dimitar Zhekov hamster@mbox.contact.bg wrote:
The way it can be implemented in detail (since I fubmled with the respective files in the last few days): [...]
Yeah, save_dialog_prefs would need the parts of configuration_save() that opens and closes the file of course :-)
[...]
Yes.
OK then, I'll write a patch for 4934.
If this is applied to the projects, it would be something like: [...]
I'm afraid I didn't think this through enough, any change to a setting will update the project file and get it a new timestamp so you would be getting the message all the time.
Edit -> Preferences will be saving only the main dialog preferences now, so that will be less common.
I guess that if we allow multiple openings of the same project (and I can't see how we can prevent it) then when a setting is changed it will change the project file. Its probably not really a problem, it was the race when multiple instances closed that was the problem.
Isn't the "race" (as in broken file because 2+ instances write it at once) only a problem of the original SM implementation? I mean, a user can't close two projects or two Geany-s _that_ fast?..
- Closing a project or quitting Geany saves only the file list, and
only if that's a main instance.
Hmmm... Now did I assumed that a project is first open in a main instance?.. Or that it's open in any main instance at all? If I open foo.geany in main and bar.geany in secondary instance, bar's files will never be saved? Clearly a no-go.
Yes this will remove the race for the project file on closing multiple instances.
Socket-based main/secondary instances can't a fix race. In post-0.18 you can specify a socket name and have several "main" instances. The geany.conf patch will help with improper manual close order, not racing.
Also I've just discovered that if I close a new_instance with files open when the main instance has a project open, on closing the project, the main instance's session matches the session files that were open in the new_instance.
Clearly the main instance is re-reading the conf file and getting the session files written by the new_instance. Saving session files only in the main instance will fix this too.
Exactly the "improper manual close order", the patch should fix it.
Hopefully a fix for the save settings into geany.conf issue.
There is one more case when geany.conf may be modified by a secondary instance: saving the project-less file list on Project -> New / Open. Patch attached.
Hi,
I like time zone differences, I go to bed with a problem and wake up to a nice patch (or two) to read over breakfast :-) so here's one for you.
The only real solution to potential corruption is to make the writes to shared config files atomic. The patch uses the good old fashioned exclusive lock file method. IIUC this should also work on windows, but may need registry settings to be correct, I'm not sure. Nothing else I researched seemed to be portable.
In race conditions this patch doesn't say which write will win, but it is intended to guarantee that whichever does will be written atomically and not corrupted.
In general there is no way Geany can know which write should win, the user has to do that themselves by closing instances manually in the right order so the last wins.
The patch has both yours and mine in the one.
Your patches stop new_instances upsetting geany.conf and mine handles shared project files and geany.conf in the case of multiple main instances.
Lets see if anyone else can get it to fail.
Cheers Lex
On 21 May 2010 23:52, Dimitar Zhekov hamster@mbox.contact.bg wrote:
There is one more case when geany.conf may be modified by a secondary instance: saving the project-less file list on Project -> New / Open. Patch attached.
-- E-gards: Jimmy
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi.
Just to mention, I ported to my SM branch the patches posted earlier in this thread.
Also, I've changed the code to write changed recent files and projects lists to geany.conf as soon as possible instead of writing them on exit. It is a good addition to "dialog_prefs" and "filetypes" patches and allows several instances to combine their recent lists. If someone is interested in porting these changes to master, I'll extract the corresponding patches and post them here. Details of implementation are given below.
After this one problem remains: handling of a project opened in several instances. It could be easy to apply "immediate save" technique for them too if we hadn't to maintain list of project's files. How should lists of files from several instances be combined?
--- Details about recent lists ---
Basically, each instance maintains its own recent lists and displays them in menus. When a recent list is updated, corresponding items are appended to menus and (as soon as possible) updates are written to geany.conf. In geany.conf the updates are combined with files which are already there (but those files aren't appended to menus). According to this scheme, in a menu user sees which files he previously opened/reloaded/etc. *in this instance*, while in geany.conf we have files previously opened/reloaded/etc. *globally*.
In order to implement it I changed the way how `ui_prefs.recent_queue' and `ui_prefs.recent_projects_queue' are used. To combine updates in geany.conf properly it's necessary to remember which elements of the queues were already written and which weren't. I chose to simply clear the queue after an update, i.e. now the queues store file names which weren't yet written to geany.conf. Other option could be to use two queues instead of each one, or to use a special marker (say, NULL) to split a queue into two parts. I preferred the accepted way because files already written to geany.conf are stored in menus and there is basically no point in keeping them in a queue too.
There is one trouble with recent lists. In contrast to dialog preferences or filetypes, they can change frequently, so it can be tricky to do necessary updates of geany.conf as rarely as possible. To support it, there is a boolean argument of ui_add_recent_file() and configuration_save_recent_files() function which are used, for example, when lots of files are opened in cycle.
On my way, I introduced a separate queue for recently closed file. Now "Open last closed tab" works more reliably.
Best regards, Eugene.
On Mon, 31 May 2010 13:35:26 +0400 Eugene Arshinov earshinov@gmail.com wrote:
Just to mention, I ported to my SM branch the patches posted earlier in this thread.
Also, I've changed the code to write changed recent files and projects lists to geany.conf as soon as possible instead of writing them on exit. [...]
I wanted to test that, but the sm-4977 works quite amazing on my system: running geany closes the entire session, without as much as a xfce sm signal to the applications. The only error message I was able to record is "ICE default IO error handler doing an exit(), pid = 8983, errno = 32". The pid is Geany's.
After this one problem remains: handling of a project opened in several instances. It could be easy to apply "immediate save" technique for them too if we hadn't to maintain list of project's files.
Currently, both the project settings and files are saved on any of Project -> Preferences, Project -> Close / New / Open and File -> Quit.
Following the logic of the other patches, IMHO Project -> Preferences should save the settings only, and the other functions should save the file list only. As of a project open 2+ times, I expect the file list to be almost identical. It's not like running a -i instance, which starts with an empty file list.
How should lists of files from several instances be combined?
Should they be combined? We never discussed such thing for 2+ instances, not even for 2+ main instances. Merging recent makes sense, indeed, but adding files to be open on the next run of Geany, or the next time a project is open?..
On Tue, 1 Jun 2010 19:55:27 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Mon, 31 May 2010 13:35:26 +0400 Eugene Arshinov earshinov@gmail.com wrote:
Just to mention, I ported to my SM branch the patches posted earlier in this thread.
Also, I've changed the code to write changed recent files and projects lists to geany.conf as soon as possible instead of writing them on exit. [...]
I wanted to test that, but the sm-4977 works quite amazing on my system: running geany closes the entire session, without as much as a xfce sm signal to the applications. The only error message I was able to record is "ICE default IO error handler doing an exit(), pid = 8983, errno = 32". The pid is Geany's.
It is terrible… I'm not experiencing this here in GNOME. Could you check previous revisions to determine when the bug appeared?
After this one problem remains: handling of a project opened in several instances. It could be easy to apply "immediate save" technique for them too if we hadn't to maintain list of project's files.
Currently, both the project settings and files are saved on any of Project -> Preferences, Project -> Close / New / Open and File -> Quit.
Following the logic of the other patches, IMHO Project -> Preferences should save the settings only, and the other functions should save the file list only.
Yes, precisely.
As of a project open 2+ times, I expect the file list to be almost identical. It's not like running a -i instance, which starts with an empty file list.
How should lists of files from several instances be combined?
Should they be combined? We never discussed such thing for 2+ instances, not even for 2+ main instances. Merging recent makes sense, indeed, but adding files to be open on the next run of Geany, or the next time a project is open?..
Just for clarity, in the question I meant several instances where the same project is opened. So in case we decide to merge recent, the resulting files should go to the project and nowhere else.
Speaking about merging recent, I think it isn't worth implementing (too much efforts for a not so significant outcome). Maybe simply letting the instances race for the project file (with locking, of course) is the best choice…
Best regards, Eugene.
On Tue, 1 Jun 2010 21:15:09 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Tue, 1 Jun 2010 19:55:27 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
I wanted to test that, but the sm-4977 works quite amazing on my system: running geany closes the entire session [...]
It is terrible… I'm not experiencing this here in GNOME. Could you check previous revisions to determine when the bug appeared?
67 works, 68 fails. Stable.
On Tue, 1 Jun 2010 21:22:06 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Tue, 1 Jun 2010 21:15:09 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Tue, 1 Jun 2010 19:55:27 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
I wanted to test that, but the sm-4977 works quite amazing on my system: running geany closes the entire session [...]
It is terrible… I'm not experiencing this here in GNOME. Could you check previous revisions to determine when the bug appeared?
67 works, 68 fails. Stable.
Thanks much for investigating this.
Seems that it will be hard to fix. I've looked through the changes made by merge to files I usually touch in SM, but did not find anything that could cause such a failure. And core SM code in sm.c during the merge, of course, remained the same.
I've also googled this problem a bit. In some cases removing ~/.ICEauthority helps, and in one case [1] this failure is probably caused by a long delay when the program is starting. The latter is probably not the case with Geany as startup code main.c remained mostly unchanged, so I believe Geany's startup time didn't increase significantly.
In all cases I've googled it's only the program that crashes, not the entire session… Also, errno=32 (EPIPE) indicates something weird is going on. Maybe (blind guess), if startup time is nevertheless the issue, XFCE session manager terminates the connection on timeout…
Maybe you can track down the bug further by merging trunk to 4967 «step by step» and checking whether the bug is present after each step. When using binary search, those 500 trunk commits will require 10 steps to check. AFAIU, I had no large conflicts while merging. So, if you suddenly have free time for this method, please give it a try.
Could anyone else test SM branch (preferably using XFCE)?
Best regards, Eugene.
[1] http://my.opera.com/community/forums/topic.dml?id=105445&t=1252278040&page=1
On Wed, 2 Jun 2010 09:39:44 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Tue, 1 Jun 2010 21:22:06 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
67 works, 68 fails. Stable.
Thanks much for investigating this.
Seems that it will be hard to fix. I've looked through the changes made by merge to files I usually touch in SM, but did not find anything that could cause such a failure. And core SM code in sm.c during the merge, of course, remained the same.
It's somehow sm-related. If I comment out smc_conn = sm_connect(...), 4968 works.
BTW, you should pass the new client id to gdk_set_sm_client_id(), not the old/NULL one, but that's not the cause of the error.
In all cases I've googled it's only the program that crashes, not the entire session… Also, errno=32 (EPIPE) indicates something weird is going on. Maybe (blind guess), if startup time is nevertheless the issue, XFCE session manager terminates the connection on timeout…
The "startup time" between which two events? The SM does not know when a program is started, and does not care when/if it's first window will be displayed. You can even write a console program with SM support. :)
Maybe you can track down the bug further by merging trunk to 4967 «step by step» and checking whether the bug is present after each step. When using binary search, those 500 trunk commits will require 10 steps to check. AFAIU, I had no large conflicts while merging. So, if you suddenly have free time for this method, please give it a try.
That'll be a bit more complex. The commits are related, so I can't just arbitarily "turn on/off" half or quarter of them. And if the crash is caused by 2+ related changes, well... Anyway, I'll run some tests in the weekend.
On Wed, 2 Jun 2010 20:33:37 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Wed, 2 Jun 2010 09:39:44 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Tue, 1 Jun 2010 21:22:06 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
67 works, 68 fails. Stable.
Thanks much for investigating this.
Seems that it will be hard to fix. I've looked through the changes made by merge to files I usually touch in SM, but did not find anything that could cause such a failure. And core SM code in sm.c during the merge, of course, remained the same.
It's somehow sm-related. If I comment out smc_conn = sm_connect(...), 4968 works.
Nice, our estimates are now confirmed.
BTW, you should pass the new client id to gdk_set_sm_client_id(), not the old/NULL one, but that's not the cause of the error.
I don't know how to properly express it in English, but I sometimes think that making stupid little mistakes like this is my second nature. Or maybe the first? :) It's strange that even old client-id seemed to improve the behaviour of Geany on my system… Anyway, I'll fix this error soon, thanks for notice.
In all cases I've googled it's only the program that crashes, not the entire session… Also, errno=32 (EPIPE) indicates something weird is going on. Maybe (blind guess), if startup time is nevertheless the issue, XFCE session manager terminates the connection on timeout…
The "startup time" between which two events? The SM does not know when a program is started, and does not care when/if it's first window will be displayed. You can even write a console program with SM support. :)
Between, for example, establishing the connection and the time when we can handle the first message from session manager (i.e., the time message loop starts working). Again, it's just a wild guess.
Maybe you can track down the bug further by merging trunk to 4967 «step by step» and checking whether the bug is present after each step. When using binary search, those 500 trunk commits will require 10 steps to check. AFAIU, I had no large conflicts while merging. So, if you suddenly have free time for this method, please give it a try.
That'll be a bit more complex. The commits are related, so I can't just arbitarily "turn on/off" half or quarter of them.
But you can merge 1/2 to r67. If the bug appears, go back to r67 and merge 1/4. If the bug doesn't appear, merge 1/8 more. Such a method should work.
And if the crash is caused by 2+ related changes, well...
At least we will find the last of those changes, right? :)
Anyway, I'll run some tests in the weekend.
Thanks you very much in advance.
Best regards, Eugene.
On Wed, 2 Jun 2010 22:17:02 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Wed, 2 Jun 2010 20:33:37 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
The "startup time" between which two events? The SM does not know when a program is started, and does not care when/if it's first window will be displayed. You can even write a console program with SM support. :)
Between, for example, establishing the connection and the time when we can handle the first message from session manager (i.e., the time message loop starts working). Again, it's just a wild guess.
I read the above and was enlightened. The first message a SM sends to a newly registered application, when adding it to a session, is a "SaveYourself(SaveLocal)".
With the sm_set_runtime_props() call in sm_save_yourself_callback() commented out, 4968 does not kill the session on startup.
While reading sm.c, however, I noticed what looks like two more bugs.
if (cl_options.load_session) /* Files will be restored by Geany session management facilities. */ store_project = store_files = FALSE;
If I'm not mistaken, this code leaves the file/project list save/restore to Geany, for a main instance only. But what if you have 2+ main instances? They will all try to save their file list or active project in geany.conf; even with race .lock protection, only one will succeed; and on session restore, there will be 2+ identical instances.
The fix is pretty easy, just remove the above check. Any per-file settings for project-less instances will be lost, but they are lost for the secondary project-less instances anyway...
if (project_prefs.project_session) /* Files will be restored when the project is reopened. */ store_files = FALSE;
This assumes that the value of project_prefs.project_session is identical at the time when Geany is stopped and then restarted. But with your sm, on restart, all geany-s read their options from the single geany.conf. What if I have 3 instances running, choose Edit -> Preferences in one of them, and (un)check "Project based session files"? The other 2 instances will not be aware of the change when being stopped, and will get the new value when restarted.
On Thu, 3 Jun 2010 19:14:39 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Wed, 2 Jun 2010 22:17:02 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Wed, 2 Jun 2010 20:33:37 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
The "startup time" between which two events? The SM does not know when a program is started, and does not care when/if it's first window will be displayed. You can even write a console program with SM support. :)
Between, for example, establishing the connection and the time when we can handle the first message from session manager (i.e., the time message loop starts working). Again, it's just a wild guess.
I read the above and was enlightened. The first message a SM sends to a newly registered application, when adding it to a session, is a "SaveYourself(SaveLocal)".
With the sm_set_runtime_props() call in sm_save_yourself_callback() commented out, 4968 does not kill the session on startup.
Interesting. It's worth debugging sm_set_runtime_props() with gdb step-by-step and see when session is killed.
While reading sm.c, however, I noticed what looks like two more bugs.
if (cl_options.load_session) /* Files will be restored by Geany session management facilities. */ store_project = store_files = FALSE;
If I'm not mistaken, this code leaves the file/project list save/restore to Geany, for a main instance only. But what if you have 2+ main instances? They will all try to save their file list or active project in geany.conf; even with race .lock protection, only one will succeed; and on session restore, there will be 2+ identical instances.
The fix is pretty easy, just remove the above check. Any per-file settings for project-less instances will be lost, but they are lost for the secondary project-less instances anyway...
Well, in addition to removing the check I will have to forbid reading file list from config when an instance is started by session manager. Not too hard, though.
To speak truth, when I wrote this code I didn't think about several main instances. I still does not understand why they are needed. Lex explained me why opening one project in several instances can be useful, but opening several main instances seems to be even more crazy stuff :)
if (project_prefs.project_session) /* Files will be restored when the project is reopened. */ store_files = FALSE;This assumes that the value of project_prefs.project_session is identical at the time when Geany is stopped and then restarted. But with your sm, on restart, all geany-s read their options from the single geany.conf. What if I have 3 instances running, choose Edit -> Preferences in one of them, and (un)check "Project based session files"? The other 2 instances will not be aware of the change when being stopped, and will get the new value when restarted.
Good catch. Seems that always storing files in command-line and not loading them from project file on restore would fix this "boundary case".
Best regards, Eugene.
On Fri, 4 Jun 2010 11:48:22 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Thu, 3 Jun 2010 19:14:39 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
With the sm_set_runtime_props() call in sm_save_yourself_callback() commented out, 4968 does not kill the session on startup.
Interesting. It's worth debugging sm_set_runtime_props() with gdb step-by-step and see when session is killed.
That didn't work, the session was killed asynchronously. But while trying to trace geany with nemiver, the session remained stable - only geany-4968 was closed, and a new geany was started, as if the SM tried to clone or restart it (hint restart now?), using the program name from the legacy SM protocol.
Anyway, commenting out SmcSetProperties() for _both_ the restart and clone commands resulted in a stable running Geany. So there's probably something wrong with their prop values.
Well, in addition to removing the check I will have to forbid reading file list from config when an instance is started by session manager. Not too hard, though.
Yes, a --no-session will do. You should mark it as non-persistent anyway, otherwise a geany once started with --no-session will come empty (no files open) each time the session is restored.
To speak truth, when I wrote this code I didn't think about several main instances. I still does not understand why they are needed. Lex explained me why opening one project in several instances can be useful, but opening several main instances seems to be even more crazy stuff :)
I have two main instances running (with sm) since may-19: one on desktop 1 with BDF/FNA files, and another on desktop 2 with geany source files. My file manager is set to open bdf/fna with geany socket file "desktop1", and [ch] files with "desktop2".
But it'll be better to write a short script that runs geany with socket "desktop<current>". That's how nedit worked, very convinient.
On Fri, 4 Jun 2010 19:58:15 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 4 Jun 2010 11:48:22 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Thu, 3 Jun 2010 19:14:39 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
With the sm_set_runtime_props() call in sm_save_yourself_callback() commented out, 4968 does not kill the session on startup.
Interesting. It's worth debugging sm_set_runtime_props() with gdb step-by-step and see when session is killed.
That didn't work, the session was killed asynchronously. But while trying to trace geany with nemiver, the session remained stable - only geany-4968 was closed, and a new geany was started, as if the SM tried to clone or restart it (hint restart now?), using the program name from the legacy SM protocol.
Anyway, commenting out SmcSetProperties() for _both_ the restart and clone commands resulted in a stable running Geany. So there's probably something wrong with their prop values.
I'll look at them.
Well, in addition to removing the check I will have to forbid reading file list from config when an instance is started by session manager. Not too hard, though.
Yes, a --no-session will do. You should mark it as non-persistent anyway, otherwise a geany once started with --no-session will come empty (no files open) each time the session is restored.
Hm, I don't understand the last point. Why will no-session'ed instances come empty if their files are passed via command-line? My original thought was not using --no-session, but simply don't load files from config if --libsm-client-id is passed.
To speak truth, when I wrote this code I didn't think about several main instances. I still does not understand why they are needed. Lex explained me why opening one project in several instances can be useful, but opening several main instances seems to be even more crazy stuff :)
I have two main instances running (with sm) since may-19: one on desktop 1 with BDF/FNA files, and another on desktop 2 with geany source files. My file manager is set to open bdf/fna with geany socket file "desktop1", and [ch] files with "desktop2".
But it'll be better to write a short script that runs geany with socket "desktop<current>". That's how nedit worked, very convinient.
Yes, this is indeed useful.
Best regards, Eugene.
On Fri, 4 Jun 2010 21:58:09 +0400 Eugene Arshinov earshinov@gmail.com wrote:
Well, in addition to removing the check I will have to forbid reading file list from config when an instance is started by session manager. Not too hard, though.
Yes, a --no-session will do. You should mark it as non-persistent anyway, otherwise a geany once started with --no-session will come empty (no files open) each time the session is restored.
Hm, I don't understand the last point. Why will no-session'ed instances come empty if their files are passed via command-line? My original thought was not using --no-session, but simply don't load files from config if --libsm-client-id is passed.
My mistake, I mixed my sm with the current and the proposed behaviour of yours. A reproduced --no-session will clear the file list only if you leave a main session to be restored with Geany session management facilities. Once you change that, and prevent loading files from config, --no-session will be persistable and meaningless.
On Fri, 4 Jun 2010 21:58:09 +0400% Eugene Arshinov earshinov@gmail.com wrote:
On Fri, 4 Jun 2010 19:58:15 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 4 Jun 2010 11:48:22 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Thu, 3 Jun 2010 19:14:39 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
With the sm_set_runtime_props() call in sm_save_yourself_callback() commented out, 4968 does not kill the session on startup.
Interesting. It's worth debugging sm_set_runtime_props() with gdb step-by-step and see when session is killed.
That didn't work, the session was killed asynchronously. But while trying to trace geany with nemiver, the session remained stable - only geany-4968 was closed, and a new geany was started, as if the SM tried to clone or restart it (hint restart now?), using the program name from the legacy SM protocol.
Anyway, commenting out SmcSetProperties() for _both_ the restart and clone commands resulted in a stable running Geany. So there's probably something wrong with their prop values.
I'll look at them.
I looked through the code, but did not find anything that could cause the bug. What happens if you leave SmcSetProperties() for restart and clone commands uncommented, but comment out one of/both sm_cmd_props() and sm_files_props() calls?
Well, in addition to removing the check I will have to forbid reading file list from config when an instance is started by session manager. Not too hard, though.
Yes, a --no-session will do. You should mark it as non-persistent anyway, otherwise a geany once started with --no-session will come empty (no files open) each time the session is restored.
Hm, I don't understand the last point. Why will no-session'ed instances come empty if their files are passed via command-line? My original thought was not using --no-session, but simply don't load files from config if --libsm-client-id is passed.
To speak truth, when I wrote this code I didn't think about several main instances. I still does not understand why they are needed. Lex explained me why opening one project in several instances can be useful, but opening several main instances seems to be even more crazy stuff :)
I have two main instances running (with sm) since may-19: one on desktop 1 with BDF/FNA files, and another on desktop 2 with geany source files. My file manager is set to open bdf/fna with geany socket file "desktop1", and [ch] files with "desktop2".
But it'll be better to write a short script that runs geany with socket "desktop<current>". That's how nedit worked, very convinient.
Yes, this is indeed useful.
Now I always specify file names in restart command, thanks for suggestions. I'll commit it soon, after I'm confident enough that it works.
Best regards, Eugene.
On Mon, 14 Jun 2010 08:53:14 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Fri, 4 Jun 2010 21:58:09 +0400% Eugene Arshinov earshinov@gmail.com wrote:
I looked through the code, but did not find anything that could cause the bug. What happens if you leave SmcSetProperties() for restart and clone commands uncommented, but comment out one of/both sm_cmd_props() and sm_files_props() calls?
It's sm_cmd_props(), in particular when run with --config. You should preserve alternate_configdir, like in my sm.
I should've said that I'm always running non-official Geany-s with alternate config dir... Your earlier revisions probably didn't crash because alternate_configdir pointed to something acceptable.
On Tue, 15 Jun 2010 21:53:22 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Mon, 14 Jun 2010 08:53:14 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Fri, 4 Jun 2010 21:58:09 +0400% Eugene Arshinov earshinov@gmail.com wrote:
I looked through the code, but did not find anything that could cause the bug. What happens if you leave SmcSetProperties() for restart and clone commands uncommented, but comment out one of/both sm_cmd_props() and sm_files_props() calls?
It's sm_cmd_props(), in particular when run with --config. You should preserve alternate_configdir, like in my sm.
Well, actually I preserve it (see the code of sm_cmd_props() and optentries_aux array in main.c). The bug may be in main.c:parse_command_line_options() where we simply assign app->configdir = alternate_config. And after that, in several places, we use setptr() and g_free() on app->configdir… Try to replace the assignment in parse_command_line_options() with app->configdir = g_strdup(alternate_config), maybe this will help.
I should've said that I'm always running non-official Geany-s with alternate config dir... Your earlier revisions probably didn't crash because alternate_configdir pointed to something acceptable.
On Wed, 16 Jun 2010 11:43:51 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Tue, 15 Jun 2010 21:53:22 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
It's sm_cmd_props(), in particular when run with --config. You should preserve alternate_configdir, like in my sm.
Well, actually I preserve it (see the code of sm_cmd_props() and optentries_aux array in main.c).
I wanted to say that you should not let main.c free it. The alternate sm I sent on may-19 does that (main.c @@ -707,7 +746,10 @@), but the app->configdir = g_strdup(alternate_config) you suggest is better.
The bug may be in main.c:parse_command_line_options() where we simply assign app->configdir = alternate_config. And after that, in several places, we use setptr() and g_free() on app->configdir
Exactly (except it's not a bug in sm-less Geany). I tested with g_strdup(), just to be sure - works.
On Wed, 16 Jun 2010 18:56:36 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Wed, 16 Jun 2010 11:43:51 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Tue, 15 Jun 2010 21:53:22 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
It's sm_cmd_props(), in particular when run with --config. You should preserve alternate_configdir, like in my sm.
Well, actually I preserve it (see the code of sm_cmd_props() and optentries_aux array in main.c).
I wanted to say that you should not let main.c free it. The alternate sm I sent on may-19 does that (main.c @@ -707,7 +746,10 @@), but the app->configdir = g_strdup(alternate_config) you suggest is better.
The bug may be in main.c:parse_command_line_options() where we simply assign app->configdir = alternate_config. And after that, in several places, we use setptr() and g_free() on app->configdir
Exactly (except it's not a bug in sm-less Geany). I tested with g_strdup(), just to be sure - works.
Great, committed now to SM (together with similar fixes for other string command-line options).
Best regards, Eugene.
Hi, Eugene,
I see your sm now always saves the open files in the restart/clone command line, so their per-file settings are lost. Why not at least append :line:column to the file names? Better than nothing...
On Thu, 17 Jun 2010 21:03:18 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Hi, Eugene,
I see your sm now always saves the open files in the restart/clone command line, so their per-file settings are lost. Why not at least append :line:column to the file names? Better than nothing...
Hi
Thanks for suggestion, committed.
Best regards, Eugene.
<snip>
Should they be combined? We never discussed such thing for 2+ instances, not even for 2+ main instances. Merging recent makes sense, indeed, but adding files to be open on the next run of Geany, or the next time a project is open?..
Just for clarity, in the question I meant several instances where the same project is opened. So in case we decide to merge recent, the resulting files should go to the project and nowhere else.
Speaking about merging recent, I think it isn't worth implementing (too much efforts for a not so significant outcome). Maybe simply letting the instances race for the project file (with locking, of course) is the best choice…
Hi all,
Having gotten confused where each of the implementations is up to I want to summarise the overall operation.
The same problem applies to three types of files, the config file (geany.conf), the project file and (possibly several) filetype files.
BTW changing filetype files is not that rare, every time you add an option to your compile command you change one. Me, I add/remove -g quite often :)
Actions performed by the user are fine because they serialise them, ie users can only do one thing at a time, problems only occur on multi instance session close and restart.
I can summarise what is for me, the only correct answer (after a LOT of discussion, thanks for the patience Ditmar & Eugene):
1. save the config/project/filetype file settings when changed, in any instance but with warning in non-main instances, no race because user serialises, last changed wins (see !! below), add reload menu item(s) to allow user to sync instances if desired 2. When closed by sm, save the file list in a per instance session file not the config/project file, then when the session is restarted each instance loads its session file list not the config/project file list and doesn't store in project or config file, no race 3. when closed by user, save the file list in the config/project file as normal, no race because user serialises closing, last wins (easily understandable) 4. when SIGHUPed, ie non-session multiple shutdown, save nothing (current behaviour) 5. when project loaded in non-main instance do not store current file list in config file, no race, and won't overwrite main instance list with an empty one 6. when project loaded in main instance (by user not by sm) store the current file list in config file, last main instance opening project wins, no race because user serialises
(!!) Note item 1. currently all preferences are saved, lots more work but better, would be to only save those items changed so a sort of merge would happen instead of total overwrite, maybe this could be a later version.
I think that covers it. No races, maximum flexibility with warnings for non-main instance changes and good restoration of the current session on restart.
I admit I don't use recent file list much so my choice is for the easiest :). So I agree, I wouldn't bother merging recent list. Since its in the same file(s) as the file list just let it work as the file list does in 1-6.
If enough users of the feature want it to merge, make it append to whats in the config/project file every time a file is opened/closed by user (ie act like a preference in 1. above). I'd prefer to not have this much traffic on the config/project file though, so by preference only.
Cheers Lex
Best regards, Eugene. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 2 Jun 2010 12:14:48 +1000% Lex Trotman elextr@gmail.com wrote:
<snip>
Should they be combined? We never discussed such thing for 2+ instances, not even for 2+ main instances. Merging recent makes sense, indeed, but adding files to be open on the next run of Geany, or the next time a project is open?..
Just for clarity, in the question I meant several instances where the same project is opened. So in case we decide to merge recent, the resulting files should go to the project and nowhere else.
Speaking about merging recent, I think it isn't worth implementing (too much efforts for a not so significant outcome). Maybe simply letting the instances race for the project file (with locking, of course) is the best choice…
Hi all,
Having gotten confused where each of the implementations is up to I want to summarise the overall operation.
The same problem applies to three types of files, the config file (geany.conf), the project file and (possibly several) filetype files.
BTW changing filetype files is not that rare, every time you add an option to your compile command you change one. Me, I add/remove -g quite often :)
Actions performed by the user are fine because they serialise them, ie users can only do one thing at a time, problems only occur on multi instance session close and restart.
I can summarise what is for me, the only correct answer (after a LOT of discussion, thanks for the patience Ditmar & Eugene):
- save the config/project/filetype file settings when changed, in any
instance but with warning in non-main instances, no race because user serialises, last changed wins (see !! below), add reload menu item(s) to allow user to sync instances if desired 2. When closed by sm, save the file list in a per instance session file not the config/project file, then when the session is restarted each instance loads its session file list not the config/project file list and doesn't store in project or config file, no race 3. when closed by user, save the file list in the config/project file as normal, no race because user serialises closing, last wins (easily understandable) 4. when SIGHUPed, ie non-session multiple shutdown, save nothing (current behaviour) 5. when project loaded in non-main instance do not store current file list in config file, no race, and won't overwrite main instance list with an empty one 6. when project loaded in main instance (by user not by sm) store the current file list in config file, last main instance opening project wins, no race because user serialises
(!!) Note item 1. currently all preferences are saved, lots more work but better, would be to only save those items changed so a sort of merge would happen instead of total overwrite, maybe this could be a later version.
I think that covers it. No races, maximum flexibility with warnings for non-main instance changes and good restoration of the current session on restart.
Great summary. Now what we need is a comparison table with four columns for trunk, trunk with your and Dimitar's patches, my SM and Dimitar's SM.
At first glance, seems that my SM implements 1 (but without warnings and possibility of reload), 3, 4, 5, and the first half of 6.
It does not implement 2, and I do not consider it a severe issue. I believe a "normal" user rarely opens one project in two instances or runs several main instances using --socket command line options. If he doesn't, there won't be any race. Even with my SM implementation :)
The second half of 6 ("last main instance opening project wins") seems somewhat strange to me: * Shouldn't it also hold for secondary instances? I think we shouldn't differentiate the behaviour of main and secondary instances in respect to handling of project files. * I'd prefer "last closing wins", not "last opening wins" (the way we usually implement things, isn't it?).
I admit I don't use recent file list much so my choice is for the easiest :). So I agree, I wouldn't bother merging recent list. Since its in the same file(s) as the file list just let it work as the file list does in 1-6.
If enough users of the feature want it to merge, make it append to whats in the config/project file every time a file is opened/closed by user (ie act like a preference in 1. above). I'd prefer to not have this much traffic on the config/project file though, so by preference only.
Just for clarity, this is how recent lists are now handled in SM, except that the preference is not provided.
Best regards, Eugene.
On 2 June 2010 17:19, Eugene Arshinov earshinov@gmail.com wrote:
On Wed, 2 Jun 2010 12:14:48 +1000% Lex Trotman elextr@gmail.com wrote:
<snip>
Should they be combined? We never discussed such thing for 2+ instances, not even for 2+ main instances. Merging recent makes sense, indeed, but adding files to be open on the next run of Geany, or the next time a project is open?..
Just for clarity, in the question I meant several instances where the same project is opened. So in case we decide to merge recent, the resulting files should go to the project and nowhere else.
Speaking about merging recent, I think it isn't worth implementing (too much efforts for a not so significant outcome). Maybe simply letting the instances race for the project file (with locking, of course) is the best choice…
Hi all,
Having gotten confused where each of the implementations is up to I want to summarise the overall operation.
The same problem applies to three types of files, the config file (geany.conf), the project file and (possibly several) filetype files.
BTW changing filetype files is not that rare, every time you add an option to your compile command you change one. Me, I add/remove -g quite often :)
Actions performed by the user are fine because they serialise them, ie users can only do one thing at a time, problems only occur on multi instance session close and restart.
I can summarise what is for me, the only correct answer (after a LOT of discussion, thanks for the patience Ditmar & Eugene):
- save the config/project/filetype file settings when changed, in any
instance but with warning in non-main instances, no race because user serialises, last changed wins (see !! below), add reload menu item(s) to allow user to sync instances if desired 2. When closed by sm, save the file list in a per instance session file not the config/project file, then when the session is restarted each instance loads its session file list not the config/project file list and doesn't store in project or config file, no race 3. when closed by user, save the file list in the config/project file as normal, no race because user serialises closing, last wins (easily understandable) 4. when SIGHUPed, ie non-session multiple shutdown, save nothing (current behaviour) 5. when project loaded in non-main instance do not store current file list in config file, no race, and won't overwrite main instance list with an empty one 6. when project loaded in main instance (by user not by sm) store the current file list in config file, last main instance opening project wins, no race because user serialises
(!!) Note item 1. currently all preferences are saved, lots more work but better, would be to only save those items changed so a sort of merge would happen instead of total overwrite, maybe this could be a later version.
I think that covers it. No races, maximum flexibility with warnings for non-main instance changes and good restoration of the current session on restart.
Great summary. Now what we need is a comparison table with four columns for trunk, trunk with your and Dimitar's patches, my SM and Dimitar's SM.
Good idea, if Ditmar can say how his works against the points, I'll fill in trunk versions properly tomorrow, but quick look says:
trunk: not 1, 2 is irrelevant (no sm), 3, 4, not 5 and can corrupt but took opening multiple instances in a script for it to happen, not 6 (stores on all project opens) patches, I think do: 1 without warning or reload, 2 still irrelevant, 3, 4, 5 I'm not sure, 6 without preference, I need to check where we ended up re main vs new-instance and what they saved.
At first glance, seems that my SM implements 1 (but without warnings and possibility of reload), 3, 4, 5, and the first half of 6.
It does not implement 2, and I do not consider it a severe issue. I believe a "normal" user rarely opens one project in two instances or runs several main instances using --socket command line options. If he doesn't, there won't be any race. Even with my SM implementation :)
I'm confused, how does the session restore if you don't save each instance file list, current project etc.?
And as multi screen workstations are more common among developers, running multiple instances is the only way to get Geany on both screens, and they are likely to want the same project, thats what the user is working on after all. I agree less likely to be two main instances, but main and --new-instance is very likely, I'm planning to use it a lot to look at C++ .hpp and .cpp files at the same time.
AT least until Geany can show multiple top level windows. :-) (I know, someone has to do it)
The second half of 6 ("last main instance opening project wins") seems somewhat strange to me:
- Shouldn't it also hold for secondary instances? I think we shouldn't
differentiate the behaviour of main and secondary instances in respect to handling of project files.
- I'd prefer "last closing wins", not "last opening wins" (the way we
usually implement things, isn't it?).
Sorry if I wasn't clear enough, I was talking about Geany saving the current file list in the *config* file when a project is opened, not about the project file, when another instance closes its project, it restores the file list saved in the config by the instance that last *opened* a project. By limiting save it to the main instances I was hoping to reduce the surprise somewhat, but a better answer would be welcome.
I admit I don't use recent file list much so my choice is for the easiest :). So I agree, I wouldn't bother merging recent list. Since its in the same file(s) as the file list just let it work as the file list does in 1-6.
If enough users of the feature want it to merge, make it append to whats in the config/project file every time a file is opened/closed by user (ie act like a preference in 1. above). I'd prefer to not have this much traffic on the config/project file though, so by preference only.
Just for clarity, this is how recent lists are now handled in SM, except that the preference is not provided.
Ok, as I said don't care except for the overhead.
Cheers Lex
Best regards, Eugene. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 2 Jun 2010 18:10:26 +1000% Lex Trotman elextr@gmail.com wrote:
On 2 June 2010 17:19, Eugene Arshinov earshinov@gmail.com wrote:
On Wed, 2 Jun 2010 12:14:48 +1000% Lex Trotman elextr@gmail.com wrote:
<snip>
Should they be combined? We never discussed such thing for 2+ instances, not even for 2+ main instances. Merging recent makes sense, indeed, but adding files to be open on the next run of Geany, or the next time a project is open?..
Just for clarity, in the question I meant several instances where the same project is opened. So in case we decide to merge recent, the resulting files should go to the project and nowhere else.
Speaking about merging recent, I think it isn't worth implementing (too much efforts for a not so significant outcome). Maybe simply letting the instances race for the project file (with locking, of course) is the best choice…
Hi all,
Having gotten confused where each of the implementations is up to I want to summarise the overall operation.
The same problem applies to three types of files, the config file (geany.conf), the project file and (possibly several) filetype files.
BTW changing filetype files is not that rare, every time you add an option to your compile command you change one. Me, I add/remove -g quite often :)
Actions performed by the user are fine because they serialise them, ie users can only do one thing at a time, problems only occur on multi instance session close and restart.
I can summarise what is for me, the only correct answer (after a LOT of discussion, thanks for the patience Ditmar & Eugene):
- save the config/project/filetype file settings when changed, in
any instance but with warning in non-main instances, no race because user serialises, last changed wins (see !! below), add reload menu item(s) to allow user to sync instances if desired 2. When closed by sm, save the file list in a per instance session file not the config/project file, then when the session is restarted each instance loads its session file list not the config/project file list and doesn't store in project or config file, no race 3. when closed by user, save the file list in the config/project file as normal, no race because user serialises closing, last wins (easily understandable) 4. when SIGHUPed, ie non-session multiple shutdown, save nothing (current behaviour) 5. when project loaded in non-main instance do not store current file list in config file, no race, and won't overwrite main instance list with an empty one 6. when project loaded in main instance (by user not by sm) store the current file list in config file, last main instance opening project wins, no race because user serialises
(!!) Note item 1. currently all preferences are saved, lots more work but better, would be to only save those items changed so a sort of merge would happen instead of total overwrite, maybe this could be a later version.
I think that covers it. No races, maximum flexibility with warnings for non-main instance changes and good restoration of the current session on restart.
Great summary. Now what we need is a comparison table with four columns for trunk, trunk with your and Dimitar's patches, my SM and Dimitar's SM.
Good idea, if Ditmar can say how his works against the points, I'll fill in trunk versions properly tomorrow, but quick look says:
trunk: not 1, 2 is irrelevant (no sm), 3, 4, not 5 and can corrupt but took opening multiple instances in a script for it to happen, not 6 (stores on all project opens) patches, I think do: 1 without warning or reload, 2 still irrelevant, 3, 4, 5 I'm not sure, 6 without preference, I need to check where we ended up re main vs new-instance and what they saved.
At first glance, seems that my SM implements 1 (but without warnings and possibility of reload), 3, 4, 5, and the first half of 6.
It does not implement 2, and I do not consider it a severe issue. I believe a "normal" user rarely opens one project in two instances or runs several main instances using --socket command line options. If he doesn't, there won't be any race. Even with my SM implementation :)
I'm confused, how does the session restore if you don't save each instance file list, current project etc.?
My SM works by specifying restart command, where I can specify any command-line arguments. Opened project, files, and some settings (--new-instance, --no-session etc.) are passed this way.
And as multi screen workstations are more common among developers, running multiple instances is the only way to get Geany on both screens, and they are likely to want the same project, thats what the user is working on after all. I agree less likely to be two main instances, but main and --new-instance is very likely, I'm planning to use it a lot to look at C++ .hpp and .cpp files at the same time.
AT least until Geany can show multiple top level windows. :-) (I know, someone has to do it)
Multiscreen is a good argument. Never thought about it, because I've never had several monitors :)
The second half of 6 ("last main instance opening project wins") seems somewhat strange to me:
- Shouldn't it also hold for secondary instances? I think we
shouldn't differentiate the behaviour of main and secondary instances in respect to handling of project files.
- I'd prefer "last closing wins", not "last opening wins" (the way
we usually implement things, isn't it?).
Sorry if I wasn't clear enough, I was talking about Geany saving the current file list in the *config* file when a project is opened, not about the project file, when another instance closes its project, it restores the file list saved in the config by the instance that last *opened* a project.
Thanks, now it's more clear, but I'm still confused. Could you further explain the last phrase "when another instance closes its project, it restores the file list saved in the config by the instance that last *opened* a project"? Why do we need such complexity (we must know whether the instance which was the last to write the file list to the config opened the project before or after us…)? Why can't we let the last instance overwrite the file list completely?
By limiting save it to the main instances I was hoping to reduce the surprise somewhat, but a better answer would be welcome.
Well, in SM the file list and the recent project in the config are indeed saved only by main instances. Secondary instances are not allowed to touch them (being more concrete, in SM --new-instance implies --no-session).
I admit I don't use recent file list much so my choice is for the easiest :). So I agree, I wouldn't bother merging recent list. Since its in the same file(s) as the file list just let it work as the file list does in 1-6.
If enough users of the feature want it to merge, make it append to whats in the config/project file every time a file is opened/closed by user (ie act like a preference in 1. above). I'd prefer to not have this much traffic on the config/project file though, so by preference only.
Just for clarity, this is how recent lists are now handled in SM, except that the preference is not provided.
Ok, as I said don't care except for the overhead.
Cheers Lex
Best regards, Eugene. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 3 June 2010 01:08, Eugene Arshinov earshinov@gmail.com wrote:
On Wed, 2 Jun 2010 18:10:26 +1000% Lex Trotman elextr@gmail.com wrote:
On 2 June 2010 17:19, Eugene Arshinov earshinov@gmail.com wrote:
On Wed, 2 Jun 2010 12:14:48 +1000% Lex Trotman elextr@gmail.com wrote:
<snip>
Should they be combined? We never discussed such thing for 2+ instances, not even for 2+ main instances. Merging recent makes sense, indeed, but adding files to be open on the next run of Geany, or the next time a project is open?..
Just for clarity, in the question I meant several instances where the same project is opened. So in case we decide to merge recent, the resulting files should go to the project and nowhere else.
Speaking about merging recent, I think it isn't worth implementing (too much efforts for a not so significant outcome). Maybe simply letting the instances race for the project file (with locking, of course) is the best choice…
Hi all,
Having gotten confused where each of the implementations is up to I want to summarise the overall operation.
The same problem applies to three types of files, the config file (geany.conf), the project file and (possibly several) filetype files.
BTW changing filetype files is not that rare, every time you add an option to your compile command you change one. Me, I add/remove -g quite often :)
Actions performed by the user are fine because they serialise them, ie users can only do one thing at a time, problems only occur on multi instance session close and restart.
I can summarise what is for me, the only correct answer (after a LOT of discussion, thanks for the patience Ditmar & Eugene):
- save the config/project/filetype file settings when changed, in
any instance but with warning in non-main instances, no race because user serialises, last changed wins (see !! below), add reload menu item(s) to allow user to sync instances if desired 2. When closed by sm, save the file list in a per instance session file not the config/project file, then when the session is restarted each instance loads its session file list not the config/project file list and doesn't store in project or config file, no race 3. when closed by user, save the file list in the config/project file as normal, no race because user serialises closing, last wins (easily understandable) 4. when SIGHUPed, ie non-session multiple shutdown, save nothing (current behaviour) 5. when project loaded in non-main instance do not store current file list in config file, no race, and won't overwrite main instance list with an empty one 6. when project loaded in main instance (by user not by sm) store the current file list in config file, last main instance opening project wins, no race because user serialises
(!!) Note item 1. currently all preferences are saved, lots more work but better, would be to only save those items changed so a sort of merge would happen instead of total overwrite, maybe this could be a later version.
I think that covers it. No races, maximum flexibility with warnings for non-main instance changes and good restoration of the current session on restart.
Great summary. Now what we need is a comparison table with four columns for trunk, trunk with your and Dimitar's patches, my SM and Dimitar's SM.
Good idea, if Ditmar can say how his works against the points, I'll fill in trunk versions properly tomorrow, but quick look says:
trunk: not 1, 2 is irrelevant (no sm), 3, 4, not 5 and can corrupt but took opening multiple instances in a script for it to happen, not 6 (stores on all project opens) patches, I think do: 1 without warning or reload, 2 still irrelevant, 3, 4, 5 I'm not sure, 6 without preference, I need to check where we ended up re main vs new-instance and what they saved.
At first glance, seems that my SM implements 1 (but without warnings and possibility of reload), 3, 4, 5, and the first half of 6.
It does not implement 2, and I do not consider it a severe issue. I believe a "normal" user rarely opens one project in two instances or runs several main instances using --socket command line options. If he doesn't, there won't be any race. Even with my SM implementation :)
I'm confused, how does the session restore if you don't save each instance file list, current project etc.?
My SM works by specifying restart command, where I can specify any command-line arguments. Opened project, files, and some settings (--new-instance, --no-session etc.) are passed this way.
I see, I assume that those commands are stored by the session manager
And as multi screen workstations are more common among developers, running multiple instances is the only way to get Geany on both screens, and they are likely to want the same project, thats what the user is working on after all. I agree less likely to be two main instances, but main and --new-instance is very likely, I'm planning to use it a lot to look at C++ .hpp and .cpp files at the same time.
AT least until Geany can show multiple top level windows. :-) (I know, someone has to do it)
Multiscreen is a good argument. Never thought about it, because I've never had several monitors :)
As you get older your font gets bigger and you need more real estate :)
The second half of 6 ("last main instance opening project wins") seems somewhat strange to me:
- Shouldn't it also hold for secondary instances? I think we
shouldn't differentiate the behaviour of main and secondary instances in respect to handling of project files.
- I'd prefer "last closing wins", not "last opening wins" (the way
we usually implement things, isn't it?).
Sorry if I wasn't clear enough, I was talking about Geany saving the current file list in the *config* file when a project is opened, not about the project file, when another instance closes its project, it restores the file list saved in the config by the instance that last *opened* a project.
Thanks, now it's more clear, but I'm still confused. Could you further explain the last phrase "when another instance closes its project, it restores the file list saved in the config by the instance that last *opened* a project"? Why do we need such complexity (we must know whether the instance which was the last to write the file list to the config opened the project before or after us…)? Why can't we let the last instance overwrite the file list completely?
This isn't added complexity, its just how it works now, if sm changes that then I didn't notice, sorry.
Let me give example sequences:
How it works with a single instance:
open Geany, open several files, open project, Geany saves the list of several files in Geany.conf and opens the project file list, close project (which can be after several opens and closes of Geany) saves list of open files in project file and close them and then open the files listed in Geany.conf Perfect!!
How it works with several instances (numbered):
open Geany1, open several files1, open project1 Geany1 saves list of files1 in Geany.conf and opens the project1 file list, open --new-instance Geany2, open some files2, open project2, Geany2 saves the file list2 in Geany.conf overwriting file list1, close project1, Geany 1 saves project1 file list and opens file list2!!! it reads from Geany.conf, confused grumpy user :(
or if --new-instance versions are not allowed to save file list, how do they restore the open files when the project is closed?
By limiting save it to the main instances I was hoping to reduce the surprise somewhat, but a better answer would be welcome.
Well, in SM the file list and the recent project in the config are indeed saved only by main instances. Secondary instances are not allowed to touch them (being more concrete, in SM --new-instance implies --no-session).
Which raises the second problem noted above.
I don't claim to have a good solution for this one, I just want to get the solution with most user utility and least user surprise.
Cheers Lex
I admit I don't use recent file list much so my choice is for the easiest :). So I agree, I wouldn't bother merging recent list. Since its in the same file(s) as the file list just let it work as the file list does in 1-6.
If enough users of the feature want it to merge, make it append to whats in the config/project file every time a file is opened/closed by user (ie act like a preference in 1. above). I'd prefer to not have this much traffic on the config/project file though, so by preference only.
Just for clarity, this is how recent lists are now handled in SM, except that the preference is not provided.
Ok, as I said don't care except for the overhead.
Cheers Lex
Best regards, Eugene. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi.
Taking point from the proposition to merge the recent files, what do you think about considering the recent files a logical part of the file list, and load/save the open/recent file lists together? This way, we will have better/more recent files (one set for each project) without the need to override geany.conf on each file open/close. N.B. Since the list will be handled together, "Project based session files" will affect the recent file list too.
Per-project interface settings (mostly the interface layout) seems reasonable too IMHO. I have several programming projects, and the message window/side bar are very convinient for them. But for my other projects, one with XSMP documentation/snippets and another with BDF files, the message window/side bar are practically useless.
As a side effect, if per-project recent files and interface settings are implemented, Eugene's sm will be able to restore the Geany-s state better. Isn't it time to make the two sm-s functionally more similar, so we could choose one based on the implementation only?
On 4 June 2010 03:11, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Hi.
Taking point from the proposition to merge the recent files, what do you think about considering the recent files a logical part of the file list, and load/save the open/recent file lists together? This way, we will have better/more recent files (one set for each project) without the need to override geany.conf on each file open/close. N.B. Since the list will be handled together, "Project based session files" will affect the recent file list too.
Would suit me, depends on what other people think.
Per-project interface settings (mostly the interface layout) seems reasonable too IMHO. I have several programming projects, and the message window/side bar are very convinient for them. But for my other projects, one with XSMP documentation/snippets and another with BDF files, the message window/side bar are practically useless.
Ditto.
As a side effect, if per-project recent files and interface settings are implemented, Eugene's sm will be able to restore the Geany-s state better. Isn't it time to make the two sm-s functionally more similar, so we could choose one based on the implementation only?
Agree, that is part of what the list in the other thread was intended to do and why I was trying to define it in terms of user visible behaviour, so I'm all for this.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 4 Jun 2010 12:17:38 +1000% Lex Trotman elextr@gmail.com wrote:
On 4 June 2010 03:11, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Hi.
Taking point from the proposition to merge the recent files, what do you think about considering the recent files a logical part of the file list, and load/save the open/recent file lists together? This way, we will have better/more recent files (one set for each project) without the need to override geany.conf on each file open/close. N.B. Since the list will be handled together, "Project based session files" will affect the recent file list too.
Would suit me, depends on what other people think.
This is a good alternative to "global recent files list" approach I described.
Per-project interface settings (mostly the interface layout) seems reasonable too IMHO. I have several programming projects, and the message window/side bar are very convinient for them. But for my other projects, one with XSMP documentation/snippets and another with BDF files, the message window/side bar are practically useless.
Ditto.
Not currently needed by me, but I'm sure it would be useful.
As a side effect, if per-project recent files and interface settings are implemented, Eugene's sm will be able to restore the Geany-s state better. Isn't it time to make the two sm-s functionally more similar, so we could choose one based on the implementation only?
Agree, that is part of what the list in the other thread was intended to do and why I was trying to define it in terms of user visible behaviour, so I'm all for this.
The more similar the two versions are, the better. And, I agree, that would make it simpler to see their differences.
Best regards, Eugene.
On Fri, 4 Jun 2010 12:13:39 +0400% Eugene Arshinov earshinov@gmail.com wrote:
On Fri, 4 Jun 2010 12:17:38 +1000% Lex Trotman elextr@gmail.com wrote:
On 4 June 2010 03:11, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Hi.
Taking point from the proposition to merge the recent files, what do you think about considering the recent files a logical part of the file list, and load/save the open/recent file lists together? This way, we will have better/more recent files (one set for each project) without the need to override geany.conf on each file open/close. N.B. Since the list will be handled together, "Project based session files" will affect the recent file list too.
Would suit me, depends on what other people think.
This is a good alternative to "global recent files list" approach I described.
I forgot a side note: this won't do for recent *projects* list. I think recent projects should be "global". Though it won't prevent using the described approach for recent *files*.
Per-project interface settings (mostly the interface layout) seems reasonable too IMHO. I have several programming projects, and the message window/side bar are very convinient for them. But for my other projects, one with XSMP documentation/snippets and another with BDF files, the message window/side bar are practically useless.
Ditto.
Not currently needed by me, but I'm sure it would be useful.
As a side effect, if per-project recent files and interface settings are implemented, Eugene's sm will be able to restore the Geany-s state better. Isn't it time to make the two sm-s functionally more similar, so we could choose one based on the implementation only?
Agree, that is part of what the list in the other thread was intended to do and why I was trying to define it in terms of user visible behaviour, so I'm all for this.
The more similar the two versions are, the better. And, I agree, that would make it simpler to see their differences.
Best regards, Eugene.
Sorry, forgot to answer this in the afternoon.
On Thu, 3 Jun 2010 16:11:03 +1000% Lex Trotman elextr@gmail.com wrote:
On 3 June 2010 01:08, Eugene Arshinov earshinov@gmail.com wrote:
On Wed, 2 Jun 2010 18:10:26 +1000% Lex Trotman elextr@gmail.com wrote:
On 2 June 2010 17:19, Eugene Arshinov earshinov@gmail.com wrote:
The second half of 6 ("last main instance opening project wins") seems somewhat strange to me:
- Shouldn't it also hold for secondary instances? I think we
shouldn't differentiate the behaviour of main and secondary instances in respect to handling of project files.
- I'd prefer "last closing wins", not "last opening wins" (the
way we usually implement things, isn't it?).
Sorry if I wasn't clear enough, I was talking about Geany saving the current file list in the *config* file when a project is opened, not about the project file, when another instance closes its project, it restores the file list saved in the config by the instance that last *opened* a project.
Thanks, now it's more clear, but I'm still confused. Could you further explain the last phrase "when another instance closes its project, it restores the file list saved in the config by the instance that last *opened* a project"? Why do we need such complexity (we must know whether the instance which was the last to write the file list to the config opened the project before or after us…)? Why can't we let the last instance overwrite the file list completely?
This isn't added complexity, its just how it works now, if sm changes that then I didn't notice, sorry.
Let me give example sequences:
How it works with a single instance:
open Geany, open several files, open project, Geany saves the list of several files in Geany.conf and opens the project file list, close project (which can be after several opens and closes of Geany) saves list of open files in project file and close them and then open the files listed in Geany.conf Perfect!!
How it works with several instances (numbered):
open Geany1, open several files1, open project1 Geany1 saves list of files1 in Geany.conf and opens the project1 file list, open --new-instance Geany2, open some files2, open project2, Geany2 saves the file list2 in Geany.conf overwriting file list1, close project1, Geany 1 saves project1 file list and opens file list2!!! it reads from Geany.conf, confused grumpy user :(
Thanks for explanation.
or if --new-instance versions are not allowed to save file list, how do they restore the open files when the project is closed?
By limiting save it to the main instances I was hoping to reduce the surprise somewhat, but a better answer would be welcome.
Well, in SM the file list and the recent project in the config are indeed saved only by main instances. Secondary instances are not allowed to touch them (being more concrete, in SM --new-instance implies --no-session).
Which raises the second problem noted above.
I don't claim to have a good solution for this one, I just want to get the solution with most user utility and least user surprise.
We may store files that were opened before the project internally and properly restore them after the project is closed. It's a simple idea, but it may be difficult to implement because practically we'll have to maintain internally two projects: "default project" and opened "real project" (if any).
Also, this will introduce a new challenge for Geany's session management and SM: whether we need to save also "default project" if "real project" was opened when Geany exited?
Best regards, Eugene.
On Wed, 2 Jun 2010 12:14:48 +1000 Lex Trotman elextr@gmail.com wrote:
(This is an answer to Eugene too)
BTW changing filetype files is not that rare, every time you add an option to your compile command you change one. Me, I add/remove -g quite often :)
Yet the race is not that often - you'll need to change something for the same filetype in 2+ instances in the Set build commands (not the project) dialog. That should be movered, of course.
- save the config/project/filetype file settings when changed, in any
instance but with warning in non-main instances, no race because user serialises, last changed wins (see !! below), add reload menu item(s) to allow user to sync instances if desired
Do you mean a warning that the settings are saved, a question whether to save the settings, or a question whether to accept and save them?
In any case, Edit -> Preferences -> Apply will be problematic. It saves the settings without closing the dialog, so there will be a question on each Apply.
- When closed by sm, save the file list in a per instance session
file not the config/project file, then when the session is restarted each instance loads its session file list not the config/project file list and doesn't store in project or config file, no race
My sm saves the entire configuration (including the file list) into a session file, so each Geany is restored with it's own settings and interface layout too.
[...]
Thank you for writing the summary, it was about time. The behaviour looks quite reasonable behaviour IMHO. Let me add:
7. Any time a project is closed, save it's file list in the project file.
Most of the above are already available as patches. What remains:
- Warnings (questions?) on Edit -> Preferences, Project -> Properties and Build -> Set build commands.
- Limit Project -> Properties to saving the preferences only, and limit project_close() to saving the file list only.
I can write the latter, if we agree on the above behaviour.
I admit I don't use recent file list much so my choice is for the easiest :). So I agree, I wouldn't bother merging recent list. Since its in the same file(s) as the file list just let it work as the file list does in 1-6.
Since I use Geany under X only, and my sm saves the recent files / projects for each Geany, merging the recent lists won't be very beneficial to me... So let the others decide.
On Wed, 2 Jun 2010 11:19:06 +0400 Eugene Arshinov earshinov@gmail.com wrote:
Great summary. Now what we need is a comparison table with four columns for trunk, trunk with your and Dimitar's patches, my SM and Dimitar's SM.
My sm requires the Build -> Set build commands changes to be saved immediately [save-filetypes-now.diff I sent on 24.05] to avoid the filetype files race described in the first paragraph.
Aside from that, it neither requires nor implements #1 and #3..#7. The patches I wrote for some of them were to make Geany behaviour more useful and predictable.
The implementation of #2 is described above.
On 3 June 2010 04:55, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Wed, 2 Jun 2010 12:14:48 +1000 Lex Trotman elextr@gmail.com wrote:
(This is an answer to Eugene too)
BTW changing filetype files is not that rare, every time you add an option to your compile command you change one. Me, I add/remove -g quite often :)
Yet the race is not that often - you'll need to change something for the same filetype in 2+ instances in the Set build commands (not the project) dialog. That should be movered, of course.
No matter how hard it is for it to occur, somewhere something bad will happen to someone, so yes the race needs to be removed.
- save the config/project/filetype file settings when changed, in any
instance but with warning in non-main instances, no race because user serialises, last changed wins (see !! below), add reload menu item(s) to allow user to sync instances if desired
Do you mean a warning that the settings are saved, a question whether to save the settings, or a question whether to accept and save them?
Something like "This is a secondary instance of Geany, saving your settings will overwrite the settings from your main instance, Save/Cancel". They should still be applied locally of course, otherwise why allow the prefs dialog at all.
In any case, Edit -> Preferences -> Apply will be problematic. It saves the settings without closing the dialog, so there will be a question on each Apply.
True, annoying, but so is overwriting settings :)
- When closed by sm, save the file list in a per instance session
file not the config/project file, then when the session is restarted each instance loads its session file list not the config/project file list and doesn't store in project or config file, no race
My sm saves the entire configuration (including the file list) into a session file, so each Geany is restored with it's own settings and interface layout too.
[...]
Thank you for writing the summary, it was about time. The behaviour looks quite reasonable behaviour IMHO. Let me add:
- Any time a project is closed, save it's file list in the project
file.
Yes, better to be explicit, I'd add "last close of a specific project wins"
Most of the above are already available as patches. What remains:
- Warnings (questions?) on Edit -> Preferences, Project -> Properties
and Build -> Set build commands.
- Limit Project -> Properties to saving the preferences only, and limit
project_close() to saving the file list only.
I can write the latter, if we agree on the above behaviour.
I admit I don't use recent file list much so my choice is for the easiest :). So I agree, I wouldn't bother merging recent list. Since its in the same file(s) as the file list just let it work as the file list does in 1-6.
Since I use Geany under X only, and my sm saves the recent files / projects for each Geany, merging the recent lists won't be very beneficial to me... So let the others decide.
In my experience the recent file list is only there to make it easier to re-open files I incorrectly closed :-)
On Wed, 2 Jun 2010 11:19:06 +0400 Eugene Arshinov earshinov@gmail.com wrote:
Great summary. Now what we need is a comparison table with four columns for trunk, trunk with your and Dimitar's patches, my SM and Dimitar's SM.
My sm requires the Build -> Set build commands changes to be saved immediately [save-filetypes-now.diff I sent on 24.05] to avoid the filetype files race described in the first paragraph.
Aside from that, it neither requires nor implements #1 and #3..#7. The patches I wrote for some of them were to make Geany behaviour more useful and predictable.
What I'm trying to get at is what is the behaviour of Geany as a user would see it after your patches are applied.
How would a Geany with your sm and whatever patches you choose to apply behave against the (now) 7 points? The reason I'm asking is that I've lost track of exactly what patches were proposed and their effects and I think (but correct me if I'm wrong) that some of the patches were superseded by others.
Talking on behalf of Enrico and Nick, my feeling is that we need to make another branch in SVN and apply your recommended set of patches and then people could try both implementations and compare them. I think that in the end thats the only way to decide.
BTW both also need to update the documentation to describe the resulting behaviour so other people don't need to go through this exercise.
Cheers Lex
The implementation of #2 is described above.
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 3 Jun 2010 16:38:57 +1000 Lex Trotman elextr@gmail.com wrote:
How would a Geany with your sm and whatever patches you choose to apply behave against the (now) 7 points? The reason I'm asking is that I've lost track of exactly what patches were proposed and their effects and I think (but correct me if I'm wrong) that some of the patches were superseded by others.
Here is what the patches do:
Entire configuration ::= all geany.conf settings, the list of open files, the interface layout and the recent files / projects The project ::= project settings and project file list
Edit -> Preferences -> OK or Apply: [save-settings-fix.diff]
before: Save the entire configuration after: Save the Preferences dialog settings only
Build -> Set build commands: [save-filetypes-now.diff]
before: Save nothing (the changed commands are saved on quit Geany or Project -> Close or switch to another project) after: Save the changed commands
Quit Geany: [save-settings-fix.diff, save-filetypes-now.diff]
before: Save the entire configuration, the project and the changed build commands after: main instance: Save the configuration except for the settings from Edit -> Preferences; save the project after: secondary instance: save the project
As of the sm, it implements #2 in a more extended variant, requires save-filetypes-now.diff (for the filetypes files race), and neither requires nor implements #1 #3..#7.
I'd prefer to discuss the multiple instances and session management separately. The user/interactive functionality of Geany is leading, while sm is just a technical problem of whoever implements it, and should not affect, much less define the user/interactive behaviour.
On 4 June 2010 02:56, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Thu, 3 Jun 2010 16:38:57 +1000 Lex Trotman elextr@gmail.com wrote:
How would a Geany with your sm and whatever patches you choose to apply behave against the (now) 7 points? The reason I'm asking is that I've lost track of exactly what patches were proposed and their effects and I think (but correct me if I'm wrong) that some of the patches were superseded by others.
Here is what the patches do:
Entire configuration ::= all geany.conf settings, the list of open files, the interface layout and the recent files / projects The project ::= project settings and project file list
Edit -> Preferences -> OK or Apply: [save-settings-fix.diff]
before: Save the entire configuration after: Save the Preferences dialog settings only
Build -> Set build commands: [save-filetypes-now.diff]
before: Save nothing (the changed commands are saved on quit Geany or Project -> Close or switch to another project) after: Save the changed commands
Quit Geany: [save-settings-fix.diff, save-filetypes-now.diff]
before: Save the entire configuration, the project and the changed build commands after: main instance: Save the configuration except for the settings from Edit -> Preferences; save the project after: secondary instance: save the project
Ok, now its clear thanks, I'll try and put the table together on the weekend.
As of the sm, it implements #2 in a more extended variant, requires save-filetypes-now.diff (for the filetypes files race), and neither requires nor implements #1 #3..#7
I'd prefer to discuss the multiple instances and session management separately. The user/interactive functionality of Geany is leading, while sm is just a technical problem of whoever implements it, and should not affect, much less define the user/interactive behaviour.
The items affecting user visible behaviour were suggested as solutions to race conditions, if your sm doesn't expose that race and so is independent of the user visible changes thats great. In trying to understand the overall sm position those visible changes are relevant, and I'll note your sm can go either way.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 2 Jun 2010 21:55:04 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Most of the above are already available as patches. What remains:
- Warnings (questions?) on Edit -> Preferences, Project -> Properties
and Build -> Set build commands.
- Limit Project -> Properties to saving the preferences only, and
limit project_close() to saving the file list only.
I can write the latter, if we agree on the above behaviour.
I appreciate. I was going to implement it myself, but, if you suggest first… :)
Best regards, Eugene.
Hi,
- Limit Project -> Properties to saving the preferences only, and
limit project_close() to saving the file list only.
Here it is, combined with the other save-* patches. BTW, when creating a new project, it's immediately saved, both the settings and the file list. So to avoid function cloning, and since it's unclear what save behaviour will be approved, I decided to declare an enum save {dialog, non-dialog, all} and use such argument for configuration_save() and project's write_config().
What remains:
Decide on "Save settings?" prompts, or make it an option - see below.
Decide whether to merge the recent files in geany.conf in real time, or have separate geany.conf and per-project recent file lists (since we have per-project open file lists).
On Thu, 3 Jun 2010 16:38:57 +1000 Lex Trotman elextr@gmail.com wrote:
Something like "This is a secondary instance of Geany, saving your settings will overwrite the settings from your main instance, Save/Cancel". They should still be applied locally of course, otherwise why allow the prefs dialog at all.
The more I think about that, the less I like it. Not only will be such a prompt irritating, especially for Apply, but how many times before the user chooses the wrong button and overrides the settings, or loses them after exiting geany?
Why not make it an option, default=on for compatibility, disabled for the secondary instances (since they depend on it). Personally I'll just leave it on and be done, while you will probably turn it off.
On Sat, 5 Jun 2010 12:10:01 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Hi,
- Limit Project -> Properties to saving the preferences only, and
limit project_close() to saving the file list only.
Here it is, combined with the other save-* patches. BTW, when creating a new project, it's immediately saved, both the settings and the file list. So to avoid function cloning, and since it's unclear what save behaviour will be approved, I decided to declare an enum save {dialog, non-dialog, all} and use such argument for configuration_save() and project's write_config().
I ported this patch to SM branch and will commit it soon, after I'm confident enough that I didn't break anything.
Here are some changes I made to your original patch:
* Renamed your GeanySaveSettingsType enum to GeanySettingsTypes and converted simple constants in it to flags, which is more natural.
* AFAIK in Geany doc-comments (/**) are used only for symbols exported for plugins. I modified the comment before GeanySettingsTypes accordingly.
* Created a separate GeanyProjectSettingsTypes for project.c:write_config(): with my implementation of recent file lists I have additional _RECENT_FILES and _RECENT_PROJECTS flags in GeanySettingsTypes, which are not applicable to GeanyProjectSettingsTypes
In case it's interesting for someone, I attach the combined patch, modified to apply cleanly to SM. It also includes the patch from Lex to add locking and my changes to recent files handling (probably the latter takes the largest part of the patch).
What remains:
Decide on "Save settings?" prompts, or make it an option - see below.
Decide whether to merge the recent files in geany.conf in real time, or have separate geany.conf and per-project recent file lists (since we have per-project open file lists).
On Thu, 3 Jun 2010 16:38:57 +1000 Lex Trotman elextr@gmail.com wrote:
Something like "This is a secondary instance of Geany, saving your settings will overwrite the settings from your main instance, Save/Cancel". They should still be applied locally of course, otherwise why allow the prefs dialog at all.
The more I think about that, the less I like it. Not only will be such a prompt irritating, especially for Apply, but how many times before the user chooses the wrong button and overrides the settings, or loses them after exiting geany?
Why not make it an option, default=on for compatibility, disabled for the secondary instances (since they depend on it). Personally I'll just leave it on and be done, while you will probably turn it off.
On Mon, 14 Jun 2010 08:46:42 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Sat, 5 Jun 2010 12:10:01 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Hi,
- Limit Project -> Properties to saving the preferences only, and
limit project_close() to saving the file list only.
Here are some changes I made to your original patch:
[...]
- AFAIK in Geany doc-comments (/**) are used only for symbols exported for plugins. I modified the comment before GeanySettingsTypes accordingly.
Hmmm... Now that I think of it, how is a plugin supposed to save it's settings in a project file when closing a project, and why does it receive a signal when the dialog settings are confirmed? The former question applies to the original Geany (and the latter is my overlook, unless I'm missing something and a plugin can somehow add elements in the project settings dialog).
On 16 June 2010 04:12, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Mon, 14 Jun 2010 08:46:42 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Sat, 5 Jun 2010 12:10:01 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Hi,
- Limit Project -> Properties to saving the preferences only, and
limit project_close() to saving the file list only.
Here are some changes I made to your original patch:
[...]
- AFAIK in Geany doc-comments (/**) are used only for symbols exported
for plugins. I modified the comment before GeanySettingsTypes accordingly.
Hmmm... Now that I think of it, how is a plugin supposed to save it's settings in a project file when closing a project
connect to the "project-save" signal, the user_data is the g_key_file of the config file. So long as you use new groups you can save data without interfering with existing contents ok.
Cheers Lex
, and why does it
receive a signal when the dialog settings are confirmed? The former question applies to the original Geany (and the latter is my overlook, unless I'm missing something and a plugin can somehow add elements in the project settings dialog).
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 16 Jun 2010 08:19:44 +1000 Lex Trotman elextr@gmail.com wrote:
On 16 June 2010 04:12, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Hmmm... Now that I think of it, how is a plugin supposed to save it's settings in a project file when closing a project
connect to the "project-save" signal, the user_data is the g_key_file of the config file. [...]
That's the point: project_close() calls write_config() with emit_signal = FALSE. So there is no "project-save" when closing a project, only on create project and Project -> Properties -> OK.
On 17 June 2010 01:30, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Wed, 16 Jun 2010 08:19:44 +1000 Lex Trotman elextr@gmail.com wrote:
On 16 June 2010 04:12, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Hmmm... Now that I think of it, how is a plugin supposed to save it's settings in a project file when closing a project
connect to the "project-save" signal, the user_data is the g_key_file of the config file. [...]
That's the point: project_close() calls write_config() with emit_signal = FALSE. So there is no "project-save" when closing a project, only on create project and Project -> Properties -> OK.
Ahhh, I hadn't noticed that, maybe Nick or Enrico can explain the reasoning behind that.
Cheers lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
<snip>
I guess that if we allow multiple openings of the same project (and I
can't
see how we can prevent it) then when a setting is changed it will change
the
project file. Its probably not really a problem, it was the race when multiple instances closed that was the problem.
Isn't the "race" (as in broken file because 2+ instances write it at once) only a problem of the original SM implementation? I mean, a user can't close two projects or two Geany-s _that_ fast?..
No, but logout or shutdown can :-(, the problem isn't sm dependent, it can happen on 0.19 without any sm, in fact with a script terminating several geanys I got corruption of geany.conf. I didn't get project file corruption but that was just luck and the project file needs the same protection. That was on a local filesystem, if your home dir is NFSed from a server it would be slower and the time window for problems would be even greater.
- Closing a project or quitting Geany saves only the file list, and
only if that's a main instance.
Hmmm... Now did I assumed that a project is first open in a main instance?.. Or that it's open in any main instance at all? If I open foo.geany in main and bar.geany in secondary instance, bar's files will never be saved? Clearly a no-go.
Oh dear!!
Yes this will remove the race for the project file on closing multiple instances.
Socket-based main/secondary instances can't a fix race. In post-0.18 you can specify a socket name and have several "main" instances. The geany.conf patch will help with improper manual close order, not racing.
Oh Dear!!
Also I've just discovered that if I close a new_instance with files open when the main instance has a project open, on closing the project, the
main
instance's session matches the session files that were open in the new_instance.
Clearly the main instance is re-reading the conf file and getting the session files written by the new_instance. Saving session files only in
the
main instance will fix this too.
Exactly the "improper manual close order", the patch should fix it.
Given the number of "Oh dear"s aboveI guess we have to do it properly, see response to your patch
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 22 May 2010 12:55:40 +1000 Lex Trotman elextr@gmail.com wrote:
[...]
Isn't the "race" (as in broken file because 2+ instances write it at once) only a problem of the original SM implementation? I mean, a user can't close two projects or two Geany-s _that_ fast?..
No, but logout or shutdown can :-(
Perhaps under Windows only? When I logout, Geany is simply killed, and the configuration file remains unchanged. If fact, if the normal application quit sequences were executed on logout (as under Windows), X11 woudn't need much of a session manager.
That was on a local filesystem, if your home dir is NFSed from a server it would be slower and the time window for problems would be even greater.
Indeed... Speaking of NFS (I read the patch) O_EXCL is problematic. On Linux, NFSv3+ and kernel 2.6+ are enough, so it should work, but I don't know about the other OS-es.
http://www.kernel.org/doc/man-pages/online/pages/man2/open.2.html specifies how to do atomic O_EXCL on NFS, but uses link(), which is not available under Windows...
[...]
Oh dear!!
One more "Oh, dear" situation: when Geany is _started_ with a project file, it writes the project-less file list into geany.conf. With the patch applied, at least the secondary instances don't do this...
Given the number of "Oh dear"s aboveI guess we have to do it properly, see response to your patch
If the lock file is not successfully unlinked by Geany for some reason, for example a broken NFS connection, it'll have to be deleted manually. Well, that shoudn't be a big problem, but if there's some way to avoid it...
On 22 May 2010 19:05, Dimitar Zhekov hamster@mbox.contact.bg wrote:
On Sat, 22 May 2010 12:55:40 +1000 Lex Trotman elextr@gmail.com wrote:
[...]
Isn't the "race" (as in broken file because 2+ instances write it at once) only a problem of the original SM implementation? I mean, a user can't close two projects or two Geany-s _that_ fast?..
No, but logout or shutdown can :-(
Perhaps under Windows only? When I logout, Geany is simply killed, and the configuration file remains unchanged. If fact, if the normal application quit sequences were executed on logout (as under Windows), X11 woudn't need much of a session manager.
Thats kind of nasty, glad I always save my files.
That was on a local filesystem, if your home dir is NFSed from a server it would be slower and the time window for problems would be even
greater.
Indeed... Speaking of NFS (I read the patch) O_EXCL is problematic. On Linux, NFSv3+ and kernel 2.6+ are enough, so it should work, but I don't know about the other OS-es.
Thats correct, note I used g_open which seems to say that it works under
windows as well. Windows actually has better locking than Unix in some ways, so if g_open uses it right it should be ok, the only potential problem is that it can be disabled by registery settings, according to Samba documentation anyway.
http://www.kernel.org/doc/man-pages/online/pages/man2/open.2.html specifies how to do atomic O_EXCL on NFS, but uses link(), which is not available under Windows...
Yeah, so I just used the plain file create lock.
[...]
Oh dear!!
One more "Oh, dear" situation: when Geany is _started_ with a project file, it writes the project-less file list into geany.conf. With the patch applied, at least the secondary instances don't do this...
Yes, saw your patch for that.
Given the number of "Oh dear"s aboveI guess we have to do it properly,
see
response to your patch
If the lock file is not successfully unlinked by Geany for some reason, for example a broken NFS connection, it'll have to be deleted manually. Well, that shoudn't be a big problem, but if there's some way to avoid it...
Not that I'm aware of, anybody who knows any other way that works on *ix and Windows is welcome to suggest it.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 22 May 2010 21:15:59 +1000 Lex Trotman elextr@gmail.com wrote:
Speaking of NFS (I read the patch) O_EXCL is problematic [...]
Thats correct, note I used g_open which seems to say that it works under windows as well. [...] the only potential problem is that it can be disabled by registery settings, according to Samba documentation anyway.
If the lock file is not successfully unlinked by Geany for some reason, for example a broken NFS connection, it'll have to be deleted manually. Well, that shoudn't be a big problem, but if there's some way to avoid it...
Not that I'm aware of, anybody who knows any other way that works on *ix and Windows is welcome to suggest it.
Both on *ix and Win~1, hmmm...
It just occured to me, what if we write the configuration into geany-some-unique-id.conf and then g_rename() it? Rename is an atomic operation; on NFS, "you can not assume that if the operation failed the file was not renamed" - well, we can emit a geany_debug() message for this. Even if Win~1 g_rename() is somehow broken, a MoveFileEx (..., MOVEFILE_REPLACE_EXISTING) will do.
We know that both entries are files, they are on the same filesystem, and the destination file is writable - that eliminates almost any possible rename error.
On 22 May 2010 23:16, Dimitar Zhekov hamster@mbox.contact.bg wrote:
On Sat, 22 May 2010 21:15:59 +1000 Lex Trotman elextr@gmail.com wrote:
Speaking of NFS (I read the patch) O_EXCL is problematic [...]
Thats correct, note I used g_open which seems to say that it works under windows as well. [...] the only potential problem is that it can be disabled by registery settings, according to Samba documentation anyway.
If the lock file is not successfully unlinked by Geany for some reason, for example a broken NFS connection, it'll have to be deleted manually. Well, that shoudn't be a big problem, but if there's some way to avoid it...
Not that I'm aware of, anybody who knows any other way that works on *ix and Windows is welcome to suggest it.
Both on *ix and Win~1, hmmm...
It just occured to me, what if we write the configuration into geany-some-unique-id.conf and then g_rename() it? Rename is an atomic operation; on NFS, "you can not assume that if the operation failed the file was not renamed" - well, we can emit a geany_debug() message for this. Even if Win~1 g_rename() is somehow broken, a MoveFileEx (..., MOVEFILE_REPLACE_EXISTING) will do.
We know that both entries are files, they are on the same filesystem, and the destination file is writable - that eliminates almost any possible rename error.
Hi,
You can get this behaviour by setting the hidden preference use_safe_file_saving, in that case utils_write_file uses g_file_set_contents which does exactly what you describe, problem is it changes owners and permissions and doesn't work on some file systems, see thread "[Geany-devel] Safe file saving - permissions issue" and older ones on the same topic.
Enrico still gets headaches when he thinks about that thread :-) because the "fix" seems to require GIO which isn't available with the oldest glib supported by Geany so it would require two file handling codes to maintain.
Cheers Lex
PS I figured out that the reason I got geany.conf corruption when signalling multiple Geanys wasn't when they closed, because as you said they don't save anything when SIGHUPed, but when the script opened lots of Geanys, each with a project, the old session files were being saved in geany.conf. Still fixed by atomic write, I was going to say unlikely in practice but of course session managers can re-start several Geanys at once, add it to the "oh dear" list.
But OTOH I now think it unlikely that 0.19 will get problems (unless you do extreme things like my script :-), so we are only talking about sm versions needing the lock
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sun, 23 May 2010 08:04:33 +1000 Lex Trotman elextr@gmail.com wrote:
You can get this behaviour by setting the hidden preference use_safe_file_saving, in that case utils_write_file uses g_file_set_contents which does _exactly_ what you describe, problem is it changes owners and permissions and doesn't work on some file systems, see thread "[Geany-devel] Safe file saving - permissions issue" and older ones on the same topic.
Not exactly. geany.conf is a special case: it's more important to make sure that it is consistent than that it is saved. As of the permissions, do we support such thing as "shared configuration directory"? If not, they won't be an issue either.
Enrico still gets headaches when he thinks about that thread :-) because the "fix" seems to require GIO which isn't available with the oldest glib supported by Geany so it would require two file handling codes to maintain.
Both the g_open() used by you, and g_rename(), exist since 2.6; the documentation says they are wrappers for the respective POSIX functions. Personally I'd expect that the support for open(O_EXCL) is worse that rename(), the latter being also an ANSI function.
[...] But OTOH I now think it unlikely that 0.19 will get problems (unless you do extreme things like my script :-), so we are only talking about sm versions needing the lock
I think so too, and my X sm is raceless, so...
Can anyone please test if Windows waits for the WM_QUIT message to be processed before sending a WM_QUIT to another program on logout? Just open 2 Geany-s, modify a file in both of them and logout. If the "Do you want to save?" messages are displayed one by one, we'd better drop the locking/renaming at all, it has too many potential problems.
On 24 May 2010 01:04, Dimitar Zhekov hamster@mbox.contact.bg wrote:
On Sun, 23 May 2010 08:04:33 +1000 Lex Trotman elextr@gmail.com wrote:
You can get this behaviour by setting the hidden preference use_safe_file_saving, in that case utils_write_file uses g_file_set_contents which does _exactly_ what you describe, problem is it changes owners and permissions and doesn't work on some file systems, see thread "[Geany-devel] Safe file saving - permissions issue" and older ones on the same topic.
Not exactly. geany.conf is a special case: it's more important to make sure that it is consistent than that it is saved.
Don't quite understand what you mean by this, I was just noting that your implementation is available already via an option and noting some reported issues with it.
If there were no reported issues then it would be fine to use, but since there are issues I wouldn't want to enforce use of this method.
As of the
permissions, do we support such thing as "shared configuration directory"? If not, they won't be an issue either.
I'm not sure if its explicitly supported or prohibited, I think its not thought about before, but it is possible, so someone will do it :) plus project files are not in the config directory so they are more likely to be relevant.
Enrico still gets headaches when he thinks about that thread :-) because the "fix" seems to require GIO which isn't available with the oldest glib supported by Geany so it would require two file handling codes to maintain.
Both the g_open() used by you, and g_rename(), exist since 2.6; the documentation says they are wrappers for the respective POSIX functions. Personally I'd expect that the support for open(O_EXCL) is worse that rename(), the latter being also an ANSI function.
Both are documented as working and I can't find any recent reports of problems, note that exclusive access is the default in the windows CreateFile() call used by windows open()
[...] But OTOH I now think it unlikely that 0.19 will get problems (unless you do extreme things like my script :-), so we are only talking about sm versions needing the lock
I think so too, and my X sm is raceless, so..
Answered in the other thread, this one is intended to be for sm-less version to see what might be needed for 0.19 release. I'm presuming that one or other sm version will make it into 0.20 so we don't need to finalise that quickly.
Can anyone please test if Windows waits for the WM_QUIT message to be processed before sending a WM_QUIT to another program on logout? Just open 2 Geany-s, modify a file in both of them and logout. If the "Do you want to save?" messages are displayed one by one, we'd better drop the locking/renaming at all, it has too many potential problems.
Also answered in other thread.
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
To summarise I propose that the only changes that need to be suggested for 0.19 are:
* preference dialog preferences but not session preferences are saved when the dialog is closed and not when Geany is closed.
* --new-instance instances should not save the geany.conf on close but the main instance should save the session part without modifying the dialog prefs part.
These are usage issues not race issues, with this change --new-instances won't upset the main session but any instance can set the preferences and whichever set them last will be the ones used when starting any new Geanys.
Post 0.19 perhaps the preferences dialog could have a reload button to allow multiple instances to re-sync with the saved prefs or it could even be auto if geany.conf was monitored.
Saving of projects in --new-instances has benefits both ways, so I suggest leaving it as is for now (ie does save).
Your patches save-settings-fix and save-filelist-fix do this fine so I suggest to Enrico/Nick that they should be part of 0.19.
Cheers Lex
On Mon, 24 May 2010 14:38:53 +1000 Lex Trotman elextr@gmail.com wrote:
And I just thought of another one, filetypes files, see filetypes_save_commands() called from main_quit() so there can be a race here too I think.
Indeed. Now: - Why are the filetype saves postponded until quit? - Should the secondary instances do filetype saves?
If we want the filetype save to be consistent with "Edit -> Preferences" and "Project -> Properties", I think the commands should be saved on "Build -> Set build commands", for both main and secondary sessions. And since there is nothing else to be saved, main_quit() will not need to do filetypes_save_commands(), hence no race.
On 24 May 2010 01:04, Dimitar Zhekov hamster@mbox.contact.bg wrote:
Can anyone please test if Windows waits for the WM_QUIT message to be processed before sending a WM_QUIT to another program on logout? Just open 2 Geany-s, modify a file in both of them and logout. If the "Do you want to save?" messages are displayed one by one, we'd better drop the locking/renaming at all, it has too many potential problems.
Also answered in other thread.
Yes, but I had half an hour today to test under Windows, and found yet another "On dear!". On Win~1 logout, any modified files are silently discarded, and the .conf file is not saved (== the normal geany stop sequence is not executed). This is currently consistent with the X behaviour - both will lose your files/settings, that is - so I'm not sure it can be considered a bug... But once we add sm support for X, the Win~1 logout should be dealt with too.
(BTW, closing 2+ Wordpad-s works just fine for us - the save prompts appear one by one. Win~1 waits for a program to close before asking the next program to quit.)
-- E-gards: Jimmy
On 24 May 2010 18:18, Dimitar Zhekov hamster@mbox.contact.bg wrote:
On Mon, 24 May 2010 14:38:53 +1000 Lex Trotman elextr@gmail.com wrote:
And I just thought of another one, filetypes files, see filetypes_save_commands() called from main_quit() so there can be a race here too I think.
Indeed. Now:
- Why are the filetype saves postponded until quit?
The way it was, didn't matter until multiple instances
- Should the secondary instances do filetype saves?
Well... oh why not? Make it work like projects.
If we want the filetype save to be consistent with "Edit -> Preferences" and "Project -> Properties", I think the commands should be saved on "Build -> Set build commands", for both main and secondary sessions. And since there is nothing else to be saved, main_quit() will not need to do filetypes_save_commands(), hence no race.
Sounds like a plan.
On 24 May 2010 01:04, Dimitar Zhekov hamster@mbox.contact.bg wrote:
Can anyone please test if Windows waits for the WM_QUIT message to be processed before sending a WM_QUIT to another program on logout? Just open 2 Geany-s, modify a file in both of them and logout. If the "Do you want to save?" messages are displayed one by one, we'd better drop the locking/renaming at all, it has too many potential problems.
Also answered in other thread.
Yes, but I had half an hour today to test under Windows, and found yet another "On dear!". On Win~1 logout, any modified files are silently discarded, and the .conf file is not saved (== the normal geany stop sequence is not executed). This is currently consistent with the X behaviour - both will lose your files/settings, that is - so I'm not sure it can be considered a bug...
Either that or both are considered a bug, especially since you lose all your unsaved files, but thats separate from this discussion.
But once we add sm support for X,
the Win~1 logout should be dealt with too.
(BTW, closing 2+ Wordpad-s works just fine for us - the save prompts appear one by one. Win~1 waits for a program to close before asking the next program to quit.)
But what happens when there are no unsaved files to use the user as the serialising critical section :)
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 24 May 2010 20:32:33 +1000 Lex Trotman elextr@gmail.com wrote:
On 24 May 2010 18:18, Dimitar Zhekov hamster@mbox.contact.bg wrote:
If we want the filetype save to be consistent with "Edit -> Preferences" and "Project -> Properties", I think the commands should be saved on "Build -> Set build commands", for both main and secondary sessions. And since there is nothing else to be saved, main_quit() will not need to do filetypes_save_commands(), hence no race.
Sounds like a plan.
Here it is then.
(BTW, closing 2+ Wordpad-s works just fine for us - the save prompts appear one by one. Win~1 waits for a program to close before asking the next program to quit.)
But what happens when there are no unsaved files to use the user as the serialising critical section :)
The save prompts one-by-one means that Win~1 sends WM_QUIT to foo.exe, waits for the message to be processed (i.e. the foo.exe to be closed), and only then sends WM_QUIT to bar.exe. That's fine even if there are no unsaved files. I only needed the prompts as a visual indicator of the message processing, not as serializer.