Lookup: how to start from top level

[m.thorade@…]

This line fails to work in OpenModelica:
​https://github.com/UdK-VPT/BuildingSystems/blob/9c13fdd95c551e974ecd8599d2f3cf06c6962d09/BuildingSystems/Utilities/NcDataReader2/NcDataReader.mo#L5
The model is in the package BuildingSystems.Utilities.NcDataReader2 and tries to import something from another library which happens to have the same name NcDataReader2

The easiest solution would be to rename the package in our library, but are there other solutions?
I already tried
import nc = .NcDataReader2.Functions;
because I thought that was the syntax to tell the tool to start looking on the top level, but that also failed.

Should that be fixed on OpenModelica side, or is our model just wrong? It works as it is in Dymola.

[m.thorade@…]

Due to this, all models in our library that use the netCDF reader fail:
​https://libraries.openmodelica.org/branches/master/BuildingSystems/BuildingSystems.html

For xample this one:
​https://libraries.openmodelica.org/branches/master/BuildingSystems/files/BuildingSystems_BuildingSystems.Technologies.SolarThermal.Examples.BigCollectorInstallationWithStorage.err

[tbc@…]

Subscribe issue

[m.thorade@…]

This is a better example:
​https://libraries.openmodelica.org/branches/master/BuildingSystems/files/BuildingSystems_BuildingSystems.Technologies.SolarThermal.Examples.SingleCollectorTest.err
because it had only this one error.

I renamed the package in our library here:
​https://github.com/UdK-VPT/BuildingSystems/pull/80
Lookup then works, but a new error is generated:
Could not find library netcdf in either of:
and a list of directories

[perost]

Imports are always looked up from the top level, so using a dot at the start of the import path is redundant. It's actually not even allowed by the Modelica syntax, so I have fixed our parser to be more compliant and reject such code.

I have also fixed the lookup issue, which was actually not related to imports at all but a bug in our handling of extends. I don't know what the issue is with not finding the library though, maybe someone else has a better clue about that issue.

[m.thorade@…]

Thanks for clarification & the fix!

So, the issue with not finding the library should become visible here pretty soon:
​https://libraries.openmodelica.org/branches/master/BuildingSystems/files/BuildingSystems_BuildingSystems.Technologies.SolarThermal.Examples.SingleCollectorTest.err

The same issue can also be reproduced by running the FullAPI example from the NcDataReade2 library, as reported here:
https://trac.openmodelica.org/OpenModelica/ticket/4356#comment:4
That model used to work in the past, IIRC.

[perost]

Replying to m.thorade@…:

So, the issue with not finding the library should become visible here pretty soon:
​https://libraries.openmodelica.org/branches/master/BuildingSystems/files/BuildingSystems_BuildingSystems.Technologies.SolarThermal.Examples.SingleCollectorTest.err

Yes, my fix is pushed into master, so it should hopefully be visible tomorrow.

[anonymous]

Imports are always looked up from the top level, so using a dot at the start of the import path is redundant. It's actually not even allowed by the Modelica syntax, so I have fixed our parser to be more compliant and reject such code.

Should ​https://github.com/modelica/Modelica-Compliance/blob/master/ModelicaCompliance/Scoping/NameLookup/Imports/Recursive.mo#L7 be fixed then to point to the recursive import problem instead to the leading dot.

[perost]

Replying to anonymous:

Imports are always looked up from the top level, so using a dot at the start of the import path is redundant. It's actually not even allowed by the Modelica syntax, so I have fixed our parser to be more compliant and reject such code.

Should ​https://github.com/modelica/Modelica-Compliance/blob/master/ModelicaCompliance/Scoping/NameLookup/Imports/Recursive.mo#L7 be fixed then to point to the recursive import problem instead to the leading dot.

The syntax for imports doesn't seem to have changed since they were added in Modelica 1.4, and has never allowed a leading dot. So yes, that test case should be fixed.

[anonymous]

The lookup has been fixed and works as expected and the compliance model has been updated, so I think this ticket can be closed.