Dymola 2019FD01 comes with MSL 3.2.2 by default,
and Dymola 2020 comes with MSL 3.2.3 by default.
If I open a library with annotation(uses(Modelica(version="3.2.3"))); in Dymola 2019FD01 the following popup is displayed, suggesting to use the found old version:
On the other hand, if I open a library with annotation(uses(Modelica(version="3.2.2"))); in Dymola 2020 the following popup is displayed, suggesting to convert:
In my opinion, the correct way to solve this would be to make MSL 3.2.3 available in Dymola 2019FD01. Any comments on this assumption?
Additionally, new Dymola versions could include old MSL version(s), either by default, as an installation option, or the users adds it manually.
As I happen to have both Dymola versions installed, can I just copy the MSL folders between the following two directories?
C:\Program Files\Dymola 2019 FD01\Modelica\Library
C:\Program Files\Dymola 2020\Modelica\Library
Could I also use the MSL as tagged & released on github or are there any changes?
Is there a better (official, documented) way how to handle this?
Is there a reason why old MSL versions are not included in the newest Dymola?
How far back can I go, e.g. would this even work with Dymola 7.4? And with MSL 3.2.1? Obviously the tool has to support the language elements used in the MSL release.
This question is closely related to Update Modelica standard Library in Dymola in Linux
which did not receive an answer, and also related to Modelica libraries use different MSL version which did receive an answer with a workaround that might not be sufficient for all cases.
In my opinion, the correct way to solve this would be to make MSL 3.2.3 available in Dymola 2019FD01. Any comments on this assumption?
Older tools might not support newer library features, see https://github.com/modelica/ModelicaStandardLibrary/issues/2091#issuecomment-272687901 for one recent example I remember. Or take the Modelica synchronous language features for another example.
Could I also use the MSL as tagged & released on github or are there any changes?
The ModelicaServices from the GitHub released MSL are just placeholders and need to be replaced by the tool-specific ModelicaServices one.
The C-Sources of the ModelicaStandardTables etc. from the GitHub released MSL are probably not used, but the tool-distributed will be used.
Is there a better (official, documented) way how to handle this?
Not yet. See https://github.com/modelica/ModelicaSpecification/issues/1023 or https://github.com/modelica/ModelicaSpecification/issues/556 for the corresponding Modelica specification issues.
In Dymola 2020 (and later) there is another way, which even ensures that the MSL-version specific C-sources are used.
Set the global flag Advanced.PlaceDymolaSourceFirst=2
Ensure that you have compiled the C-sources in MSL with the correct compiler.
Possibly set the version as default in Edit > Options Versions tab.
Do NOT install ModelicaServices from GitHub.
This is documented in the Dymola User's Manual Volume 1; section 6.1.5
Additional Setup>Working with a Modelica version that is newer than the one in the distribution, page 909-910 in the Dymola 2020 version. (I just didn't find it earlier.)
Related
Is there a way to make a user created class/package to be read only in Modelica preferably through annotations? Make Modelica class read-only in Dymola gives a Dymola option, I am using OpenModelica and is required to verify a package across its two different versions, since both these versions are editable I am unknowingly making modifications in the older version. Thanks in advance.
I tried to search OpenModelica documentation to see if any OM specific annotations are available. But I couldn't spot them. I am pretty much sure that I have missed it in them, probably used a bad keyword.
In OMEdit there are two ways to open a library: either use "File->System Libraries" or "File->Open Modelica/Library File(s)".
The system libraries only shows packages installed at $HOME/.openmodelica/libraries (on Linux; other path in Windows). These are installed by the package manager or installed there manually. When loading libraries through "File->System Libraries", they are always read-only.
If you load the same library by pointing out the package.mo file, it is opened writable.
You can mark a class read-only in the filesystem by not making the file writable (and if you use a hierarchical file structure instead of the whole library in one file, you can restrict editing to only certain parts in this way).
When loading an encrypted library, it is possible to prevent certain operations on the package using annotations, but editing is always restricted.
I want to use two Modelica libraries together, in Dymola, so for convenience I wrote a little script, loadLibraries.mos that just opens the two libraries.
But they use different versions of the MSL (3.2.1 versus 3.2.2), defined by the uses annotation in the top level package.mo:
annotation(uses(Modelica(version="3.2.1")));
The library developed by us uses 3.2.2, the library that uses MSL 3.2.1 is developed by someone else.
Now whenever I run the mos script (or when I open the two libraries manually), Dymola wants to run an update script. As far as I can see, nothing gets changed by the update script, so I would like to
either not run it at all, e.g. by defining a range of accepted versions like annotation(uses(Modelica(version>="3.2.1")));
or always run it, without asking first, e.g. by setting some flag AlwaysSilentyAcceptMSLUpgrade.
Under Edit, Options, Version there is a checkmark Force upgrade of models to MSL version but I am unsure how to use it from my mos script (for all users).
My pragmatic solution would be to ask yourself if your own library really needs anything from 3.2.2 which is not yet present in 3.2.1. Hence change your library to only require 3.2.1. Or the other way round (given you can change the package.mo of the other library) change the uses annotation there to 3.2.2
Don't change your own library, but make the library using Modelica 3.2.1 read-only (e.g. by making the files read-only).
That should skip the prompt (at least from Dymola 2016) - and as far as I understand you don't edit that library yourself anyway.
That works for libraries that don't need any update between the versions; which obviously holds for Modelica 3.2.1->3.2.2 since there is no conversion - but it would also work if there were a conversion that didn't influence this particular library.
I am on Linux(Ubuntu) with OpenCV 2.4 installed. I am try to use Eclipse to create an opencv project. When I build the project, I got collect2: ld returned 1 exit status error which I guess is caused by missing libs. Then I put libraries in this project, but I find every lib has three very similar brothers, like:
libopencv_highgui.so
libopencv_highgui.so.2.4
libopencv_highgui.so.2.4.0
So, which one should I add to project libraries? And what's the different between them?
Best Regards.
libopencv_highgui.so and libopencv_highgui.so.2.4 are probably symbolic links to libopencv_highgui.so.2.4.0.
Libraries frequently do this so that software that needs to link against specific versions can while keeping the generic library also exposed.
This is mainly useful when a program to be linked against a major or minor version of a library. Consider if a legacy application needed to link against version 1.2 of libopencv_highgui. The program couldn't link against libopencv_highgui.so because that's not guaranteed to be the correct version. However, the program could link against libopencv_highgui.so.1.2. libopencv_highgui.so.1.2 may be a symbolic link to libopencv_highgui.so.1.2.3, but that would be ok since the third number usually means a minor bug fix that won't break compatibility.
So this brings up which file you should link against. This really depends. Unless you need to depend on some bug or quirk of a specific minor revision, I would definitely avoid linking against the 2.4.0 one. That ties your program specifically to version 2.4.0. When 2.4.1 gets released (or trickles down your distro's package manager), it probably won't break your program.
If you link against libopencv_highgui.so and then 2.5 is installed as the main lib (and then libopencv_highgui.so links to libopencv_highgui.so.2.5.0), there is a chance that your program will not link correctly since the second number does sometimes mean compatibility changes.
So in short, if it's a personal project, just link to whatever you want. libopencv_highgui.so is probably safe if it's personal. If it's going to be distributed, figure out what versions of the library your code will link properly against and then use the vaguest one possible. For example, if your code works with 2.2, 2.3 and 2.4, you should go ahead and link to libopencv_highgui.so. If it only works specifically with 2.4.0, you should link with libopencv_highgui.so.2.4.0. If it will work with any sub revision of 2.4, you should go with libopencv_highgui.so.2.4.
Basically you have to make a choice about what you think will link properly on the most people's setups.
I think I make some mistake here. What I need is these libraries, But when I add them into project libraries. YOU SHOULD USE THESE NAMES, for the library I mentioned in the question, we should add opencv_highgui in to eclipse libraries dependency but libopencv_highgui.so.2.4. For the future use, I write these stuff here.
When I do "Add Existing Frameworks" in Xcode, I see three versions of libiconv.
libiconv.dylib
libiconv.2.dylib
libiconv.2.4.0.dylib
This link says the latest and greatest is 1.13.1. I don't think it's the same as the numbers above.
Any clues?
From checking the /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0.1/Symbols/usr/lib/ folder, the only one of those that's an actual library is libiconv.2.dylib. Both libiconv.dylib and libiconv.2.4.0.dylib are aliases (ie, symbolic links if you prefer to think in UNIX terms) for libiconv.2.dylib.
So at the minute, it'll make absolutely no odds which you link to. Link to the one that gives you the most acceptable generality. So if you can handle any version of the API, link to libiconv.dylib, if you need the API that goes with version 2 of libiconv then link to libiconv.2.dylib and if you're relying on functionality in 2.4.0 specifically then link to libiconv.2.4.0.dylib. I assume that, as per the way things tend to work in UNIX, Apple may change what's an alias for what or actually supply multiple versions of the dylib in future as compatibility requires. At the moment it's all academic.
From what I can make out from Google, libiconv-1.12 builds to libiconv.2.4.0.dylib. I'm not able to determine the rationale behind that version numbering or where the idea comes from.
A reference converter from UTF-8/16/32 in C used to be available at ftp://ftp.unicode.org/Public/PROGRAMS/CVTUTF/. This included the files ConvertUTF.h and ConvertUTF.c.
It was freely available and is incorporated into many open source projects. It's even recommended in Microsoft documentation: http://support.microsoft.com/kb/q232580/
But now it's gone! What's the story? Can is still be legally used? Was there a problem with it?
The answer is hinted at here. In short, it was unmaintained, buggy and not kept up to date to the latest Unicode version, thus it was retired.