Spinroot

A forum for Spin users

You are not logged in.

#1 2011-12-22 02:55:08

awesan
Member
Registered: 2011-04-30
Posts: 45

iSpin overrwrites the model file after restoring session silently

Steps to reproduce the issue:
1. Launch "iSpin x.pml"
2. In "verification tab", choose a few options to verify (for ex, -n, -q for the verifier)
3. Save session
4. Close iSpin
5. Open some other editor and modify x.pml and save it and close it
6. Launch iSpin
7. Restore the saved session
8. The file (x.pml) is opened without modifications done in Step-5. It looks like it happens because the entire model is stored in the session file and not just the file name.
9. File -> Save overwrites x.pml and all the modifications done in Step-5 are lost silently. ( I usually modify the file in iSpin very minimally, like enabling one or two compiler directives/macros, since that is not currently allowed by iSpin in the simulation tab. That's how I ended up modifying the file and saving it in iSpin)

I literally lost all the changes to the model because iSpin did not prompt any errors but overwrote the contents silently. First of all, until I saw the size of the session file, I never guessed that the model was saved in the session. I expected and assumed the iSpin session to remember the file by the path name and then reopen it. I think it would make sense to store the model in the session file only when a model is written in iSpin and the user plays with the model without saving the model to a physical file. In that case, the model can be stored in a temp file by iSpin and also the contents of the file can be saved in the session. If the use-case of exchanging session files (as opposed to session files and the model file whose path might be relative to the current directory) by themselves between users needs to be covered, then after restoring the session, "File->Save" should not be allowed, IMHO. The session file should not remember the file x.pml at all. I thought of proposing prompting the user while restoring the session by checking the time-stamp of the file, etc, but I think that also might be confusing.

Offline

#2 2011-12-22 06:32:35

spinroot
forum
Registered: 2010-11-18
Posts: 678
Website

Re: iSpin overrwrites the model file after restoring session silently

i understand the frustration when something like this happens and you didn't expect it,
but i have to admit that the behavior is as designed and planned: when you restore a saved session everything is restored to the way it was at the save-point.
it did seem like it was the only reasonable choice, given that all results may be related, including to the specific state of the model....
not sure if i can think of a different way -- once you know that a restore is really a full restore hopefully you wont run into that trap again

Offline

#3 2011-12-22 07:20:39

awesan
Member
Registered: 2011-04-30
Posts: 45

Re: iSpin overrwrites the model file after restoring session silently

Thanks for the quick response. As a user, I would recommend at least getting a warning/prompt in one or both of the following actions:
1. While restoring a session after a file is modified outside iSpin: prompt the user whether he wants to reload the file from disk
2. Saving the buffer to the file (File -> Save) after restoring the session, if the file was modified outside iSpin : prompt the user whether he wants to still overwrite the file, since it was modified outside iSpin and suggest File->SaveAs and choose a different file.

The reason is the following:
That I can think on top of my head, most of the programming language IDEs that allow creating/saving projects/solutions (similar to iSpin session) store only the config data and not the actual source files into the project/solution file itself and the current behavior of iSpin may not be based on the principle of least surprise for some/most users (who typically are used to programming language IDEs and try iSpin), IMHO. Since the cost of this could be really high for users, an extra prompt for a GUI user might not be too annoying (a config option to suppress that would not be a bad idea but the default should be to prompt), again, IMHO.

Offline

Board footer

Powered by FluxBB