I have recently renewed the license of Dymola and I received access to Dymola 2021. I believe that there are some changes in parameter sweep. the point is that I used to sweep parameters of my model conveniently with older version, but now I receive the following error:
setting ParameterName has no effect in model.
After translation you can only set literal start-values and non evaluated parameters.
I would appreciate if someone could advise.
Difficult to judge without the actual code. The reason could be, that the new Dymola version evaluates other parameters than the old one does. Instead of reverting to an older version of Dymola you could try this:
The solution could be to force Dymola to not evaluate the parameter you want to sweep. This can be done by adding annotation(Evaluate=false) to the parameter that shall be changed during the sweep.
In addition to the answer by #MarkusA I would like to add that downgrading due to this specific warning is not a good idea.
Apart from changes in evaluation of parameters the main change in Dymola 2021 is that the warning was added to sweep parameter, whereas previously the sweep could produce constant output without any warning.
Related
I have reviewed the questions/answers asking whether or not directory/file names are case sensitive in a Windows environment as well as those discussing a need for case-sensitive searching [usually in Python, not C], so I think I understand the essential facts, but none of the postings include my particular application architecture, and the problem I am having resolving the problem.
So, let me briefly explain the application architecture of which I am speaking. The heart of the application is built using Adobe AIR. Yes, that means that much of the U/I involves the Flex framework, but the file handling problem I am needing help with has no dependency upon the Flex U/I part of the application.
As I am trying to process a very large list of recursive directory structures, I am using the low level C RunTime API via a well-behaved mechanism which AIR provides for such cases where access to the host's Native Environment is needed.
The suite of functions which I am using is FindFileFirst, FindFileNext and FindClose. If I write a stand-alone test program, it nicely lists the directories, sub-directories and files. The case of the directories and files is correctly shown -- just as they are correctly shown in Windows Explorer, or using the dir command.
If, however, I launch precisely the same function via the Adobe ANE interface, I receive exactly the same output with the exception that all directory names will be reduced to lower case.
Now, I should clarify that when this code is being executed as a Native Extension, it is not passing data back to AIR, it is directly outputting the results in a file that is opened and closed entirely in the CRT world, so we are not talking about any sort of communication confusion via the passing of either text or byte arrays between two different worlds.
Without kludging up this forum with lots and lots of extraneous code, I think what will help anyone who is able to help me is these snippets:
// This is where the output gets written.
FILE* textFile = _wfopen (L"Peek.txt", L"wt,ccs=UTF8");
WIN32_FIND_DATAW fdf;
HANDLE find = NULL;
wchar_t fullPath[2048];
// I am just showing the third argument as a literal to exemplify
// what, in reality is passed into the recursively-called function as
// a variable.
wsprintf (fullPath, L"\\\\?\\%ls\\*.*", L"F:\\");
hFind = FindFirstFile (fullPath, &fdf);
// After checking for success there appears a do..while loop
// inside which there is the expected check for the "." and ".."
// pseudo directories and a test of fdf.dwFileAttributes for
// file versus sub-directory.
// When the NextFile is a file a function is called to format
// the output in the textFile, like this:
fwprintf (textF, L"%ls\t%ls\t%2.2x\t%4d/%02d/%02d/%02d/%02d/%02d \t%9ld.\n",
parentPath, fdf.cFileName,
(fdf.dwFileAttributes & 0x0f),
st.wYear, st.wMonth, st.wDay,
st.wHour, st.wMinute, st.wSecond,
fSize);
At that point parentPath will be a concatenated wide character string and
the other file attributes will be of the types shown.
So, to summarize: All of this code works perfectly if I just write a stand-alone test. When, however, the code is running as a task called from an Adobe ANE, the names of all the sub-directory parts are reduced to lower case. I have tested every combination of file type attribute -- binary and text and encoding -- UTF-8 and UTF-16LE, but no matter what configuration I choose, the result remains the same: Standalone the API delivers case-correct strings, running as a task in a dll invoked from AIR, the same API delivers only lower-case strings.
First, my thanks to Messrs Ogilvie and Passant for helpful suggestions.
Second, I apologize for not really knowing the protocol here as a very infrequent visitor. If I am supposed to flag either response as helpful and therefore correct, let these words at least reflect that fact.
I am providing an answer which was discovered by taking the advice above.
A. I discovered several tools that helped me get a handle on the contents of the .exe and .dll files. I should add some detail that was not part of the original posting: I have purposely been using the mingw-w64 toolchain rather than Visual Studio for this development work. So, as it turns out, both ldd and dumpbin helped me get a handle on whether or not the two slightly-different build environments were perhaps leaving me with different dependencies.
B. When I saw that one output included a reference to FindFirstFileExW, which function I had once tried in order to solve what I thought was the problem, I thought I had perhaps found a reason for the different results. In the event, that was just a red-herring and I do not mean to waste the forum's time with my low-level of experience and understanding, but it seems useful to note this sort of trouble-shooting methodology as a possible assist to others.
C. So what was the problem? There was, indeed, a small difference in the code between the stand-alone and the ANE-integrated implementations of the recursive directory search. In the production ANE use case, there is logic to apply a level of filtering to the returned results. The actual application allows the user to qualify a search for duplicate files by interrogating parts of the parent string in addition to the filename string itself.
In one corner condition, the filter may be case-sensitive or case-insensitive and I was using _wcslwr in the mistaken belief that that function behaved the nice, Unicode-compliant way that string handling methods are provided in AIR/Actionscript3. I did not notice that the function actually does an in-place replacement of the original string with one reduced to lowercase.
User error, not, any untoward linking of non-standard CRT Kernel functions by Adobe's Native Extension interoperability, was the culprit.
My use case is as follows. In the automated testing of one of my libraries I use the mktemp function in order to obtain a filename in order to create a temporary file. Xcode correctly complains about this as a security risk, but in this case I have no option (the API I must follow demands filenames) and I am willing to take the risk since the code is only the test code and not in an actual service. (Hence the security risk is not applicable.)
I suppose I could create my own version of a mktemp that is local to my testing, but I would prefer not to write things that have already been written.
So what I am wondering is if there is a way that I can tell the analyzer to stop complaining this instance of the problem? Note that this differs from the question asked in Is it possible to suppress Xcode 4 static analyzer warnings? in that this is not a false positive, and I do not want to suppress analyzing the file or all instances of this check. I just want to suppress this one instance. (i.e. something similar to cppcheck-suppress comment in Cppcheck)
#JonathanLeffler last comment was absolutely correct and I don't know how I missed it when I read the question I referenced. The following code segment does exactly what I want - it suppresses the analyzer warning in this instance of mktemp while leaving it active for all other instances that would use mktemp.
#if defined(__clang_analyzer__)
char* filename = "/tmp/somename";
#else
char* filename = mktemp("/tmp/prefixXXXX");
#endif
I'm specifically concerned about utarray version 2.0.2 vs. 1.9.6. (The most recent copyrights being 2017 and 2012, respectively).
I need to add uthash.h to an existing project that makes use of utarray.h, and would rather both these headers come from the same version/commit, so I'm considering replacing the older utarray.h with the newer.
I should note I'm not terribly concerned about compile-time incompatibilities, such as name changes and the like. My main concern would be run-time breakages.
If you look at utarray.h, you'll see that all it defines are macros, a few static functions, and some typedefs; there are no public symbols, so everything should be restricted to the current compilation unit.
In other words, yes, as long as you don't include both headers in the same file (which would likely cause a compile-time error) or expose it in your public API you should be safe.
That said, the answer to the question in your title is "no"; incompatible changes in the API break backward compatibility. But with the restrictions you mention in the body you should be okay.
A rare but 100% reproducible stack corruption issue around usage of utarray caused me to attempt an upgrade, of JUST utarray.h, but across the board at my company.
The short answer is NO, it is not 100% backward compatible. But it's very close.
The longer answer is for our applications, the required changes were extremely trivial, basic usage does not change, and the stack corruption issue seems to have gone away. It also seems to be interacting well with other, older headers, such as uthash.
The only interface change I found was a _UNUSED_ macro for hushing gcc warnings changed to UTARRAY_UNUSED. Everything else seems to be bug fixes.
Edit: I'm not naive enough to be even remotely confident that 1.9.6 had an issue causing our stack corruption, but I'm not totally dismissing the possibility after carefully stepping through the same 10 lines of code in the debugger for about 2 hours, and watching every variable be correct.
I have structure that has a 32bit field for item_id. This field has been used in my complete project as a 32bit field directly, for passing to a function or to save value in a temporary variable. I need to now change this var to be 64bit. That would mean tracing all its usage manually and changing at required places. I am afraid this might miss out some places and can lead to unexpected rollovers. Can I use some mechanized way to do this? Even an exhaustive list of where all I need to change would also help. I was thinking on the lines of using some gcc flag to enable warnings/errors for this. Any idea which should flag should use?
Rename item_id to item64_id and recompile.
The compiler will point you to each and every occurence of the old, now invalid name. Inspect and fix each occurence.
Optionally you can rename it back afterwards using your IDE's refactoring feature.
In windows APIs and various other libraries where I have seen multiple entry points to methods I have noticed the use of the Ex abbreviation in scenarios such as MyApiCall and MyApiCallEx.
My assumption is that this stands for Extension or Extra could someone please confirm?
Any history on why Ex was chosen rather then MyApiCall2 or similar would also be appreciated.
I was under the impression it stood for extended, as in a more detailed interface for that particular library.
For example, CreateFile with 4 parameters is the typical version and CreateFileEx with 17 is the version offering more control and finer detail over how the file is opened, what occurs if it doesn't exist, etc, and is thus extended.
When Microsoft updates a function and the new function is incompatible with the old one, Microsoft continues to support the old function. The new function keeps the same name as the old function, with added -Ex suffix.