Opened 12 years ago
Last modified 7 years ago
#1884 assigned defect
incompatible types when assigning to type 'modelica_real' from type 'modelica_string'
Reported by: | anonymous | Owned by: | somebody |
---|---|---|---|
Priority: | high | Milestone: | Future |
Component: | Backend | Version: | trunk |
Keywords: | input | Cc: |
Description
Caused by this model:
model DataType_OpenModelica input String str(start = "muh"); output Integer length; output String outString(start = "abcdef"); algorithm length:=Modelica.Utilities.Strings.length(str); outString:=str; end DataType_OpenModelica;
Attachments (2)
Change History (15)
by , 12 years ago
Attachment: | DataType_OpenModelica_FMU.log added |
---|
by , 12 years ago
Attachment: | DataType_OpenModelica.c added |
---|
comment:1 by , 12 years ago
Keywords: | input added |
---|---|
Owner: | changed from | to
Status: | new → accepted |
Version: | → trunk |
- This is caused by a missing support for the types int/bool/string as inputs.
comment:4 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | accepted → assigned |
comment:5 by , 10 years ago
Milestone: | 1.9.1 → 1.9.2 |
---|
This ticket was not closed for 1.9.1, which has now been released. It was batch modified for milestone 1.9.2 (but maybe an empty milestone was more appropriate; feel free to change it).
comment:6 by , 10 years ago
Milestone: | 1.9.2 → 1.9.3 |
---|
Milestone changed to 1.9.3 since 1.9.2 was released.
comment:11 by , 8 years ago
Milestone: | 1.11.0 → 1.12.0 |
---|
Milestone moved to 1.12.0 due to 1.11.0 already being released.
comment:12 by , 7 years ago
Milestone: | 1.12.0 → Future |
---|
The milestone of this ticket has been reassigned to "Future".
If you think the issue is still valid and relevant for you, please select milestone 1.13.0 for back-end, code generation and run-time issues, or 2.0.0 for front-end issues.
If you are aware that the problem is no longer present, please select the milestone corresponding to the version of OMC you used to check that, and set the status to "worksforme".
In both cases, a short informative comment would be welcome.
comment:13 by , 7 years ago
Not that easy to fix; top-level inputs need to be treated in a special way which causes them to be put in the code for all top-level inputs. If we remove them from that list, they are either not initialized with the start-value and the real value is simply used for them, or they keep the type's default value.