Let OM automatically load packages as specified in import statements

[Dietmar Winkler]

Currently, OMEdit (and omc I guess) does not automatically load a package that is specified in a import statement. In other tools (e.g., Dymola) it's normally enough to have the package that is listed in an import statement to be either present in the same working directory or in the MODELICAPATH. Having to manually load those packages seems to be an unnecessary burden on the user and can be easily done by the tool.

I can't really think of any reason why this would *not* be a good feature to have.

[Martin Sjölund]

But we do consider the uses annotation... If a uses-annotation is on a package, it is loaded automatically. If a uses-annotation is on a model, it is loaded automatically. And that is often a bit annoying because Dymola adds the annotation even if the library is not used...

[Dietmar Winkler]

So what drawback is it to also look for the package when it's specified in an import statement? I can't really think of a performance issue, right?

[Adrian Pop]

Are you sure you want a tool like Windows that does
things "magically" and loads wrong versions of packages
that appear as import?
Also, the Modelica Specification say nothing about this.

Of course we could support it and give a warning when
we load the package. But I'm not really convinced this
is a good thing to have.

[Martin Sjölund]

Well. Do you want to look in imports of the class you click simulate on or all the classes that it references? The uses-annotation at top level is a lot faster.

If it is about OMEdit, maybe. Look at the imports as you expand one level in the library tree.

And Adrian, we already add notifications that we load libraries. However, it seems OMEdit does not detect this :)

model M
  annotation(uses(Buildings(version="latest")));
end M;

Scripting	22:19:55		0:0-0:0	Automatically loaded package Buildings 1.5 due to uses annotation.

It's not in the tree, so I try to load it and it tells me it won't add it because it already exists. But it won't appear in the tree anyway ;)

[Dietmar Winkler]

I know the Spec does not say anything about this. Hence I marked this as enhancement and not as defect ;)

You are probably right about the version issue though. But this should be documented in the user's Guide then (since it's not in the Spec). BTW, I just tested it with uses but OMEdit does not look for the package in the current working directory it seems. Again, something that is very useful when developing libraries that should not (yet) be placed within MODELICAPATH.

[Dietmar Winkler]

version="latest"

... never seen this before. Is this a OM thing. Could not find it in the Specs.

[Martin Sjölund]

Well... If it should not be on the MODELICAPATH, they shouldn't be loaded, right? Regardless, OMEdit has no concept of working directory (being always in its tmp-dir)...

[Martin Sjölund]

I have 2 versions of Buildings 1.5 :)

/usr/lib/omlibrary/Buildings 1.5/
/usr/lib/omlibrary/Buildings latest/

[Dietmar Winkler]

Ha, cheeky.

Well I guess I need to enhance this enhancement ticket then :) Let OMEdit also look for packages inside the directory a currently opened model is residing in when there is a uses clause.

[Dietmar Winkler]

As for having to traverse through all the classes in order to identify the import statements ... well you have to do this anyway when checking/simulating. So the only thing left would be simply to also check if the package is available in the directory of the model (please) or MODELICAPATH and then load the latest stable version as the spec suggests.

[Per Östlund]

A bit late to the party, but the specification says in 13.2.4:

If a top-level name is not found at global scope, a Modelica translator shall look up additional classes in an ordered list of library roots, called MODELICAPATH.

I interpret this to mean that we should load libraries automatically if they are used anywhere in a model, not only in imports.

[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

[Martin Sjölund]

Ticket retargeted after milestone closed

[Adeel Asghar]

Milestone changed to 1.12.0 since 1.11.0 was released.

[Francesco Casella]

Rescheduled to 1.14.0 after 1.13.0 releasee

[Francesco Casella]

Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2. This issue is rescheduled to 1.16.0

[Francesco Casella]

Retargeted to 1.17.0 after 1.16.0 release

[Francesco Casella]

Retargeted to 1.18.0 because of 1.17.0 timed release.

[Francesco Casella]

Ticket retargeted after milestone closed

[Per Östlund]

This was fixed a while ago in 8e7c3944. The new frontend now tries to find a library to load if it encounters a top level name it can't find, as specified in the Modelica specification.

[Dietmar Winkler]

Loading from current working directory still does not work in OMEdit. Even though "." is part of MODELICAPATH. So I would argue this is far from fixed.

[Per Östlund]

Replying to dietmarw:

Loading from current working directory still does not work in OMEdit. Even though "." is part of MODELICAPATH. So I would argue this is far from fixed.

Did you add . to the MODELICAPATH yourself? We don't add it by default I think, at least it's not in my MODELICAPATH (OMEdit shows it in Tools->Options->Libraries).

If you do have . in your MODELICAPATH and OM stills doesn't load libraries from it, then please open a new issue on GitHub since it's better to have a more focused ticket for that particular issue.

[Dietmar Winkler]

"." is specified in the User Libraries section but seems to get ignored. That was the whole reason for this ticket if I recall correctly.

[Dietmar Winkler]

No need to open a new one as this already exists as a broken import ticket ;-)
​https://github.com/OpenModelica/OpenModelica/issues/2447

[Francesco Casella]

@dietmarw, can this ticket be closed, now that #2447 is taken care of?

[Dietmar Winkler]

Sure. I never understood why Trac is still used when the _same_ ticket exists on GitHub as import.

[Francesco Casella]

@dietmarw, what @perost was asking is to please open a new ticket with a different number, that focused specifically on the problem of the modelicapath. We have a lot of very old, very long tickets with shifting subjects, that are difficult to manage and tend to linger around forever, so we are trying to come up with updated tickets that are really focused on as narrow an issue as possible.

I messed up myself as well, by not recognizing that the ticket number was the same; I thought you were referring to an imported ticket with another number, and I added content to that. Of course it was the same number, instead :)

Summing up:

• we had a plan to automatically migrate all trac tickets to GitHub, including their content
• as a first step, we set up placeholders, so that we could continue numbering new issues in GitHub without overlapping with old tickets in trac; that went well
• the actual content migration turned out to be more difficult than we thought (the devil is in the details), so we'll need to carry on with this duplication for a while. That is no big deal, as the people involved in old trac tickets are mostly developers and old-timers like you.
• of course the status of tickets with the same number should be the same.

So, I apologize for the mess and reopen this as well.

[Francesco Casella]

See continuing discussion in ​#2447

[Dietmar Winkler]

So could you please clarify if the issue should continue to get discussed here or on the GitHub ticket clone.

[Francesco Casella]

Replying to casella:

See continuing discussion in ​#2447

Better continuing there, since the most relevant information is now on GitHub.

Thanks!