xraylarch
xraylarch copied to clipboard
[xas_viewer] improvements for the session (auto)saving
@newville I propose the following for the session file saving:
- put back the saving behavior as discussed in #325
- add an unique random identifier to the
session_autosave_####.larix
file (this is a bug, in fact, when running multiple instances of xas_viewer all write in the same session file, creating a big mess)
@maurov
put back the saving behavior as discussed in https://github.com/xraypy/xraylarch/issues/325
maybe I don't recall what the desired behavior is. Right now, it is effectively always "save as...". Do you want "Save" to be "save and overwrite the most recent session file without prompting, maybe except the first time" and a separate "Save As" that always prompts for a file name? That would be OK with me...
add an unique random identifier to the session_autosave_####.larix file (this is a bug, in fact, when running multiple instances of xas_viewer all write in the same session file, creating a big mess)
Ah, that is a good point, but might need some thinking/discussion. It might make "restore last session" a bit complicated, and could make the ".larch/xas_viewer" folder fill up with session files. I'm not opposed, just not sure how to do it well...
put back the saving behavior as discussed in #325
maybe I don't recall what the desired behavior is. Right now, it is effectively always "save as...". Do you want "Save" to be "save and overwrite the most recent session file without prompting, maybe except the first time" and a separate "Save As" that always prompts for a file name? That would be OK with me...
Sorry, I put only the reference to the previous issue where this was discussed. Yes, the "expected behavior" is that the "first Save" or "Save as" should prompt for a file name were to save the current session. After that, all the "Save" actions should overwrite that file without prompting.
add an unique random identifier to the session_autosave_####.larix file (this is a bug, in fact, when running multiple instances of xas_viewer all write in the same session file, creating a big mess)
Ah, that is a good point, but might need some thinking/discussion. It might make "restore last session" a bit complicated, and could make the ".larch/xas_viewer" folder fill up with session files. I'm not opposed, just not sure how to do it well...
In my opinion, each time a xas_viewer instance is started, a temporary and unique session file should be created in the larch user directory and the session automatically saved on regular time base, e.g. every 10 seconds (with this parameter settable in the preferences). I would remove then the "auto-save larch session" in the file menu. When xas_viewer is closed, it should prompt if the current session was not saved to a separate file and then remove the temporary session file from disk.
In case of a xas_viewer crash, the session file will probably stay in the larch user home, so when restarting xas_viewer, it should prompt to recover that file. I would remove then from the file menu the "restore last session" action.
To me, after a clean exit of xas_viewer there should not be any temporary session file stored in the larch user directory. The user takes care of saving the session to disk.
@newville does all this sounds fine to you?
@maurov
maybe I don't recall what the desired behavior is. Right now, it is effectively always "save as...". Do you want "Save" to be "save and overwrite the most recent session file without prompting, maybe except the first time" and a separate "Save As" that always prompts for a file name? That would be OK with me...
Sorry, I put only the reference to the previous issue where this was discussed. Yes, the "expected behavior" is that the "first Save" or "Save as" should prompt for a file name were to save the current session. After that, all the "Save" actions should overwrite that file without prompting.
Thank, I just wanted to be clear, but yes, will do.
In my opinion, each time a xas_viewer instance is started, a temporary and unique session file should be created in the larch user directory and the session automatically saved on regular time base, e.g. every 10 seconds (with this parameter settable in the preferences). I would remove then the "auto-save larch session" in the file menu. When xas_viewer is closed, it should prompt if the current session was not saved to a separate file and then remove the temporary session file from disk.
In case of a xas_viewer crash, the session file will probably stay in the larch user home, so when restarting xas_viewer, it should prompt to recover that file. I would remove then from the file menu the "restore last session" action.
To me, after a clean exit of xas_viewer there should not be any temporary session file stored in the larch user directory. The user takes care of saving the session to disk.
@newville does all this sounds fine to you?
I'm still thinking about this.
I kind of like the idea of "automatically save the past few sessions", and especially the ability to "restore last session" at startup time. I find it very helpful during development but also when looking at different user datasets. But, this could definitely be made more customizable.
I also don't see crashes very often -- maybe I'm not trying hard enough?. If you are seeing crashes, let's try to figure that out.
When you do see conflicts with auto-saved session files, is that because of multiple instances of XAS Viewer running on the same machine for an account or is this with multiple logins from different machines but with a user account with a common home directory? That is, maybe the autosaved session files should include a tag for host computer and process. And then at startup time, "old autosaved session" files could be deleted so that only N (5? 10? should be a preference) are preserved. Would that be OK?
@newville
I kind of like the idea of "automatically save the past few sessions", and especially the ability to "restore last session" at startup time. I find it very helpful during development but also when looking at different user datasets. But, this could definitely be made more customizable.
I think there are various distinct features here:
- automatically save the current working session to a unique temporary file.
- store the temporary session file somewhere on disk -> I think is up to the user decide if and where to store it.
- quickly restore a previous session from disk -> this can be done by storing a list of recent files and let the user the possibility to open from such list from the file menu.
I also don't see crashes very often -- maybe I'm not trying hard enough?. If you are seeing crashes, let's try to figure that out.
I haven't seen crashes too. I was thinking about the only case where the temporary session file would not be removed from the larch user directory at exit.
When you do see conflicts with auto-saved session files, is that because of multiple instances of XAS Viewer running on the same machine for an account or is this with multiple logins from different machines but with a user account with a common home directory? That is, maybe the autosaved session files should include a tag for host computer and process. And then at startup time, "old autosaved session" files could be deleted so that only N (5? 10? should be a preference) are preserved. Would that be OK?
Our typical workflow at the beamline is to open many instances of xas_viewer in parallel (at the same time for the same user on the same computer). Here what we do while acquiring data:
- One instance of xas_viewer per sample and per edge/line where we collect all the raw scans
- preprocess them (select good ones, deglitch, normalize)
- merge
- save the session file to "sampleN_edgeX_lineY.larix"
- Open additional instances of xas_viewer where we load merged data
- process multi-sample data (PCA/LCF, pre-peaks, EXAFS)
- save the session file to "analysis_paramZ.larix"
All this is iterative while acquiring new scans to get the wanted statistics on the data. So, having a transparent and clean saving of the multiple session files is crucial for us.
To sum all this up, my proposal would be:
- [ ] each instance of xas_viewer creates an unique temporary session file in the larch users directory.
- [ ] this session file is automatically saved each 10 seconds (with this interval parameter customizable in the settings).
- [ ] at first "Save" or at "Save as" prompt where to save the session file.
- [ ] store the path to this file in the list of recent session files on disk (keep the last 10 files only, with this parameter customizable).
- [ ] at next "Save" overwrite the existing file without prompt and store when the session file was last saved.
- [ ] at exit, if the current session file was not saved (via the "Save" or "Save as" action) in the last 10 seconds (use the interval parameter of the automatically save procedure), prompt for saving to disk.
- [ ] remove the temporary session file.
- [ ] add in the file menu a "restore from recent sessions" showing the list of recent files previously stored.
@maurov
I agree with most of this. A couple of points:
a) I think we should autosave without user's necessarily being aware - it's kind of an "intermediate feature", not something to force every user to think about. That is, let's avoid, "open a workspace" at startup.... So keeping these in ".larch/xas_viewer" seems ok to me.
b) autosave times currently defaults to 900 seconds. I think going faster than 60 seconds is overkill. I might suggestion 300 seconds.
c) I think we keep up to 4 files per "process id/session", say "session_autosave_21321_01.larix" for process ID=21321. It already knows to not save a file if there is no actual activity.
d) we have a maximum number of session files (say, 5). At startup, the program may remove old versions of any saved session, first by removing older versions from any session, and then by removing the oldest session, until there 5 files remaining, which could then be the last save files from 5 different sessions. While running, there could be more than 5 autosave files, but we should be able to avoid having many such files.
e) All these numbers are defaults that go in the "autosave" section of Preferences. I would say "4" and "5".
But I do agree with Save vs Save As, and keeping a list for "Open Recent Sessions" that would include the autosaved sessions.
@newville
Great! Thanks for your feedback. I agree with all points. Let's try this way and we will see with usage.