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.
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.
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.)
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.
I'm currently working on a project which source code should be as portable as possible; that is, the project (in C#, but it is not very relevant) represent an application that should be executed on Android (with Mono-Android), on iPhone (with MonoTouch) and WinMobile (with official Compact Framework). Without going into details, the corresponding MSBuild solution consists of an independent-platform library (from a source code point of view, at least) which declare various interfaces and classes that represent an abstraction of each feature that is not common to the various platform (i.e. the UI). In addition, there are a corresponding library that specialize (for each platform) the "base library"; the effective application executable is a program that uses the abstraction and the common standard libraries.
Developing on WinMobile and Android is not really a problem: Mono-Android add-in can be installed on VS 2010, so both platforms can be handled with MS VS.
Initially the solution was created in VS, so the initial configuration and the related projects (Android and WinMobile) are automatically generated.
After that I've imported the solution in MonoDevelop under Mac (the only platform that is officially supported by MonoTouch), and I've created the project for the iPhone library; switching the configuration to generate the assemblies (iPhoneSimulator) the "base library" was not possible to compile due to a missing project type configuration; specifically, the GUID used by MonoTouch for <ProjectTypeGuids> is {E613F3A2-FE9C-494F-B74E-F63BCB86FEA6}; adding this GUID I can now compile "base library" in MonoDevelop.
The problem arises when I try to re-import the solution in VS: since there's no Windows version of MonoTouch, VS cannot find the add-in for the specified project type, and the project doesn't load.
Looking to the specifications of MSBuild project file, it seems that there are tons of options that cannot be set or modified within the project/solution editor in VS; however the format is quite complicated and now I'm asking your help!
Is there a way to specify in the project file that a project type is present only if a particular configuration is selected independently to which is the environment I'm using?
The general approach is something like this; a condition that progressivly builds your property, referencing any value the property already may have:
<ProjectTypeGuids
Condition="'$(BuildingInsideVisualStudio)' != 'true'"
>;{E613F3A2-FE9C-494F-B74E-F63BCB86FEA6}"</ProjectTypeGuids>
<ProjectTypeGuids>{OTHER-GUIDS-HERE}$(ProjectTypeGuids)</ProjectTypeGuids>
This will detect the VS condition (when building) and omit the unkonwn guid. I'm not sure however if it will work when the project is opened, this property might only apply to building. There may be a similar "sentinal" property for building on Mono, and you can reverse the condition.
I solved an unrelated, but very similar issue of cross-platform development by excluding the files that presented themselves as cranky when going between Linux and Windows. I have my project under source control and utilized that to keep things working cooperatively.
http://www.aydabtudev.com/2011/05/what-goes-into-source-control-android.html
It's not a 1-to-1 for your issue, but it might give you clues/ideas on how to solve your problem.
I want to make paid and free versions of my app. I want to structure things so that I can build one version or the other with as few changes as possible. As far as the source code is concerned, this is easily accomplished by having a BOOL constant isFreeVersion somewhere, and referring to it as needed.
But how should I set everything else up? Obviously the App ID will have to change, and this will in turn entail changing some build settings in XCode. What is the best way to keep that to a minimum?
You could use a preprocessor flag (in your Xcode build settings) to switch between the two. The flag can be used across your source code using simple preprocessor directives (e.g. #if IS_FREE_VERSION ... #endif) in a manner similar to an if statement. This will help you avoid build scripts.
The disadvantage of this approach is that by default each time you build, the last build product gets overwritten.
In term of version control in general, I wouldn't recommend using branches unless the impact of building two versions means important code changes between the two set of sources.
If you can have only one set of sources (with your BOOL constants), that means the rest must be managed through building script, which would:
take a parameter to know if it has to build the free version or the paid version of the executable (no parameter means it builds both)
use one XCode build setting or another, depending on the version it has to build.