Unwanted behaviour of OMEdit with syntactically incorrect models

[Francesco Casella]

Try the following with OMEdit 1.9.0:

• File | New Modelica class: add a new model foo
• Save it
• Switch to Modelica text view
• Try to change the code in any way

As soon as a non-whitespace character is typed, OMC complains that the model is not correct. Hitting the button to solve the problem manually doesn't work, and one can only hit "reload previous version".
The same thing happens if one tries to change the name of the model: as soon as the name in the first line changes, OMC complains (because it doesn't match with the name at the end), so it is impossible to actually change the model name.

This is obviously unwanted behaviour. However, it doesn't take place if foo is inside a package.

More in general, it is not clear at all when the syntactical correctness is checked. When does this take place? I understand it is only when you hit save, but this is not the case for a stand-alone model not contained in a package.

[Adeel Asghar]

I guess you have auto save enabled with a very short time interval. Disable it or set the interval to some reasonable duration.
Tools->Options->General->Enable Auto Save.

[massimo ceraolo]

The issue occurs instantly when auto save is set to 300 s.
In reality when one tries to change the model's name two independent issues are evidenced:
1) the program complains instantly about incompatibiilty between the model's name at the first and last row of the model's definition (without waiting the correct instant, e.g. when saving or when switching to diagram view)
2) of one tries to "fix the error manually" this indeed will not be possible

Note that older versions (for instance r16954) did not have these issues.

[Adeel Asghar]

It should work in r17652. It was my mistake. The interval accepts the value of milliseconds and i was giving it seconds. So it was triggering after every 0.3 secs.

[Henning Kiel]

(I have not looked into the code to see how the timer is implemented.)

If it is a "constant" timer that saves each x seconds, then the problem above is not solved at all, because if you just type the first letter right before the timer elapses, then the same problem will occur.
If you wait x seconds after the last keypress, then it is again less likely to have the above error, but not impossible and additionally autosave would be disabled while you type.

My idea would be to change the autosave function not to pass the model to omc, but to save it to disk only (that's what I would expect anyways), so your unsaved changes are not lost, but also not send to the interpreter.

[Francesco Casella]

I would suggest that we step back a moment and agree on the requirements for the autosave functionality.

When people develop new models and write Modelica code , they usually go through some process which involves some kind of trial-and-error, and goes through intermediate stages where the code is not syntactically nor semantically correct. At some point, when the whole thing seems reasonable (e.g., it checks, or maybe even produces the desired results in one or more test cases), one hits the "save" button, which is the equivalent in terms of mountain climbing of fixing a bolt on the rock, or of a commit in SVN/GIT lingo. If anything goes wrong with the code (e.g., one cannot get it to compile any more), one can always step back to the saved version.

The problem is that sometimes programmers simply forget to hit "save" for long working hours and keep on climbing higher and higher, until suddenly the editor crashes, and voilà, you've suddenly lost an entire afternoon of hard work. Unrepeatable swearing (sometimes in the direction of the tool developer) usually takes place, followed by long hours trying to recollect from brain memory what had been written on the screen before the crash.

An additional problem with OMEdit (I understand) is that the code is stored in the omc back-end in the form of an AST, so only syntactically correct code can be stored, and then saved. It is not too clear to me when the code that has been typed in the textual window is actually passed to the back-end (in Dymola, this happens whenever the user switches focus), I guess we should first make that clear and explicit to the user (no magic involved!).

In my opinion, the "autosave" feature should just be a kind of extra safety feature, a kind of skyhook, so in case OMEdit crashes and you've not saved for a long time, there is a way to restore the status you had shortly befor the crash, so you're not falling all the way down to the base of the mountain. Ideally, I would keep this separate from the stuff which is saved to the .mo files, because a user should have a chance of deciding when to save (i.e. make a kind of local commit) only when the code is in a proper state, and not just at regular points in time, where the code might still not make sense, even if it is syntactically correct. If this is possible without too much effort (e.g., by storing the content of all open textual windows in some local .txt file that can be recovered when OMEdit is next loaded), that would be ideal.

Otherwise, we need to find a mechanism which is not too intrusive (i.e., it doesn't complain if the code is not syntactically correct when the timer elapse, which will happen in 99% of the case). One possible option is that some process runs in the background every X seconds, checks if the code is correct, and if it is, it silently saves it without any user interaction. The only drawback that I see is that it is impossible for a user to play around with the code, knowning that he/she can always revert to the last explicitly saved version. A possible way to partially overcome this is that the user is asked if he really wants to save, but for sure this question should only be asked when the code is syntactically correct.

Comments/suggestions?

[Martin Sjölund]

This ticket was not closed for 1.9.1, which has now been released. It was batch modified for milestone 1.9.2 (but maybe an empty milestone was more appropriate; feel free to change it).

[Martin Sjölund]

Milestone changed to 1.9.3 since 1.9.2 was released.

[Martin Sjölund]

Moved to new milestone 1.9.4

[Martin Sjölund]

Milestone pushed to 1.9.5

[Martin Sjölund]

Milestone renamed

[Adeel Asghar]

Fixed in 1ec6313/OMEdit.

The auto save functionality is disabled when user is editing the code in text mode. When users switches away from text mode the auto save is enabled again.

[Martin Sjölund]

Milestone deleted