Erroneous huge message when duplicating

[massimo ceraolo]

1) open test.mo
2) duplicate EVBasic in an empty path.
A huge, erroneous red erro message is displayed, even though duplication is correctly made.

Tested on 13.1 for Win and today's nightly build under Ubuntu.

[Francesco Casella]

I also often get this issue. I'm now used to this behaviour, that my colleagues informally baptized with an Italian word I could roughtly render as "burp-o-graph", and I am no longer alarmed by it, because it has no apperent consequence. Maybe it has, and I'm simply missing it. Anyway, it can really be disorienting, particularly for newbies.

I guess we should strive to avoid this kind of behaviour entirely.

[massimo ceraolo]

Replying to casella:

and I am no longer alarmed by it,

Nor am I.
But I strongly support (and use) OM for teaching. One of the things I often tell my students is "please, please, look at the warnings"! They tend, instead, to go straightforward to the plots, which is definitely is not the best thing to do, in case of warnings.

So, removing false warnings would be good especially to favour OM usage among newbies, and to even promote it as the standard modelica tool in universities.

I proposed just "normal" priority, thinking of the general public. But for teaching, yes, I very much welcome the increase of the priority you did, Francesco.
Thanks, @casella.

I guess we should strive to avoid this kind of behaviour entirely.

In recent months several false warnings were effectively removed. So solution of this ticket would be a step more towards the target of of having clean error and warning message lists

[Adeel Asghar]

This message is shown when the diff algorithm fails. In that case omc's pretty printing is used as a fallback. A file called sanitycheck.mo is created in your working directory.

[massimo ceraolo]

Replying to adeas31:

This message is shown when the diff algorithm fails. In that case omc's pretty printing is used as a fallback. A file called sanitycheck.mo is created in your working directory.

Maybe in this cases a message just saying this would be enough.
I mean, something like:
"The duplication operation might have created a slightly different file from the source. Please check manually the validity of the duplicated file"

I don't know if sanitycheck.mo can be of use of the final user. In case it is, something about this file and its usefulness can be added to the previous message.

If this is done, the message is much shorter and much more informative than it is today. Moreover, it seems to me that it should be a warning and not an error message.

And finally, we expect this kind of messages to be more and more rare in the next weeks and months, as soon as diff algorithm becomes smarter.

[Francesco Casella]

I think this is one of those cases where we should radically change our approach, if we ever want OpenModelica to come of age and become more widely used. We can't issue error messages in a GUI like OMEdit the same way we issue messages from the compiler command line. The latter is meant for die-hard experts and geeks, the former is not, nor it should be. Piping stdout and stderr to the message windows was ok in the early days, but now we really have to do better.

New users start their experience with OpenModelica using the GUI. One of the first things they try out is to duplicate existing models (e.g. from the Modelica Standard Library) to modify them. Getting a huge, totally obscure, glaring red error message when you do that is a big deal. What does that mean? Did I do something wrong? Is the duplicate model a valid one? Is OMEdit a totally unreliable tool and should I stop using it before I get seriously hurt? We must be very careful with the messages the tool conveys, even implicit ones.

A GUI user should not be required to learn that there is a diff algorithm running in the background, and that it may have bugs that you should try to cope with by locating a sanitycheck.mo file in the working directory and manually comparing it to the duplicate model. I'm sorry, but this is really insane. That's stuff meant for developers debugging the tool, not for end users.

In fact, implicitly or explicitly asking the end user to "check manually the validity of the duplicated file" is definitely not the right way to go. How could I ever use and trust a tool that asks me to check if a copy of something is valid? Are we dealing with the copy of manuscripts in a 12-th century benedectine abbey, or is this a 21st-century software development environment?

I would even go further: the fundamental assumption one makes when using such a development GUI, is that it will never ever mess up with my code. Do this once to me, and I'll get very angry. Do it twice, and I'll tell the tool goodbye forever, and tell my friends and colleagues to stay away from it. The reputation of the tool is really what is at stake here, and though it is hard in general to build a good reputation, it is very easy to lose it in one instant.

In fact, as I understand, OMEdit is not messing up with the code at all, it simply can't (yet) preserve the formatting in the duplicate, which BTW is something other well-known Modelica tools have a hard time doing as well. Hence, whenever the diff algorithm fails we need to issue the following warning (not an error!):

OMEdit could not preserve the formatting of the original model when duplicating it. The duplicate model was created with OMEdit internal pretty-printing algorithm.

This message

• explains exactly what happened in plain words
• doesn't scare off users
• doesn't give you the impression that you somehow did something inappropriate
• doesn't give you the feeling that there is something potentially fishy or creepy in the duplicate model. You simply lost its the formatting, that's it. It is then up to you to decide what to do.

@adeas31, I think there are many other cases in which the diff algorithm will fail, so I'd suggest you do this at your earliest convenience, and then hand over the diff algorithm failur in this specific case to @sjeolund.se again.

[Adeel Asghar]

I prefer that diff algorithm should work always without any failures. If there is a failure that should be shown but if you think is better to intercept that message and modify it to more user friendly message that is also fine with me.

[massimo ceraolo]

Thank you @casella and @adeas.
Indeed I exactly hoped that the issue regarded just formatting but was not totally sure.
I'm 100% in agreement with Francesco.
All of us hope not to have these issues anymore. But since we cannot be sure, it seems wiser to make the program inform the user in the cleanest way, as francesco recommends.

[Francesco Casella]

Replying to adeas31:

I prefer that diff algorithm should work always without any failures.

Of course, but one of Murphy's law corollaries is "There is always one more bug", so it's always possible to get this kind of failure.

If there is a failure that should be shown but if you think is better to intercept that message and modify it to more user friendly message that is also fine with me.

That's the idea - we shouldn't wait for all bugs to be fixed (by which time we're all dead), but rather start getting meaningful error messages.

[Adeel Asghar]

Done in 516aa19/OpenModelica.

[Francesco Casella]

Very good, thanks @adeas31!