-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dymola 2019 model check fails on class methods #28
Comments
Did it work in older Dymola versions? If yes, can you contact the 3Ds support to ask if the change is by purpose or rather a side-effect? Thanks. I believe it is related to my question in #9 (comment) where I wondered if it is legal Modelica. |
Yes, it does work before Dymola 2019. I'll try to contact DS and let you know. |
Thanks. If it really is an intended error message it would be the show-stopper for ExternData functions. See also mo:#979 (comment). |
I've contacted our DS rep on this issue, let's wait and see what was going on. I'm afraid that, if this is intended, ExternData has to be refactored a bit to pass the constructed object to those reader functions as inputs. It might also be good to encapsulate the c wrapper functions into the class as well. It will also fix the OpenModelica issue I believe. Let me spend some time on it tonight and see if I can fix it. |
BTW, the library still works/simulates as it is before, phew~ It is just those reader functions won't pass the model check and it breaks the unit testing procedure we have internally. |
Are you sure it is a regression? I can reproduce also in Dymola 2018 and 2018 FD01. |
I just checked on Dymola 2018FD01. Yes, I can reproduce this error. Sorry about this. I need to check which version of Dymola the our CI server is using. |
It also occurs on older versions, e.g., Dymola 2016. |
I think I figured what was going on. I usually just do a model check on the whole package, Dymola usually skips those encapsulated functions. That's why they never showed up as errors. Using the testing library provided by Dymola, for some reason, gives different results between 2018FD01 and 2019. Dymola 2018FD01 Testing lib behaves identical as doing a Conclusion: this is a testing library inconsistent issue. Thanks for the help, please close this issue if needed. I still think the syntax should be changed though, just to make it legal Modelica. |
Thanks for figuring it out. Please tell me what to change to make it legal! |
Documentation of Testing.Runners.checkPackage prints that classes with the annotation __Dymola_interactive=true are skipped. Could this be a solution for the Testing issue? |
Yes, for sure. |
OK, check again then. |
Thanks for the fix. All passed.
|
I've made an example of CSV reader |
Nice demonstration. Thanks a lot! I will adapt ExternData to your proposed structure though OpenModelica still gives the same "cyclic dependency" error. |
I tried different things in OpenModelica too, but none of them works. It's giving me different errors, but only one is consistent: I'll keep trying, I am not a fan of passing the filename and constructor settings to each function. Actually, I should say I don't know if it calls the constructor function for each any every |
See also omc:#4448 regarding ExternData in OpenModelica. |
It is found that in Dymola 2019, modelcheck would fail on ExternData reader class methods, e.g.
XMLFile.getReal
,JSONFile.getReal
etc. It seems that Dymola 2019 has changed their model check routine. It is complaining about not able to find the constructed object when doing a individual model check on the methods.The text was updated successfully, but these errors were encountered: