Opened 12 years ago
Closed 12 years ago
#2113 closed defect (fixed)
fill dimension arguments
Reported by: | Lennart Ochel | Owned by: | Adrian Pop |
---|---|---|---|
Priority: | blocker | Milestone: | 1.9.0 |
Component: | Frontend | Version: | trunk |
Keywords: | Cc: | Martin Sjölund, Adrian Pop |
Description (last modified by )
model test Real y[5]; Integer n; algorithm n := 0; y := fill(1, 5); n := n + 2; y[1:n] := fill(2, n); end test;
error message
[/home/lochel/Documents/tests/temp/bug_2113.mo:9:3-9:23:writable] Error: Wrong type or wrong number of arguments to fill(1, n)'. (in component <NO COMPONENT>)
I guess there is no reason (and nothing in the spec) to forces the dimension arguments to be of parameter variability.
Change History (7)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Description: | modified (diff) |
---|
comment:3 by , 12 years ago
Priority: | high → blocker |
---|
I do not know how the frontend works and how to fix this. So is there anyone who can do this?
This ticket blocks the support of the PNlib (together with some other bugs ;-)) and should be fixed quite soon.
comment:4 by , 12 years ago
This is an easy thing to fix and good for learning how the frontend works :)
Search for "fill"
in Static.mo. *Goes back to proofreading his thesis*
comment:5 by , 12 years ago
Owner: | changed from | to
---|---|
Status: | new → accepted |
Don't bother, I'll have a look at this.
comment:6 by , 12 years ago
Attempt to fix it using r15804.
We can flatten this model now but then we have issues with code generation:
$ ~/dev/OpenModelicaNoChanges/build/bin/omc +showErrorMessages +locale=C +s test.mo class test Real y[1]; Real y[2]; Real y[3]; Real y[4]; Real y[5]; Integer n; algorithm n := 0; y := {1.0, 1.0, 1.0, 1.0, 1.0}; n := 2 + n; y[1:n] := fill(2.0, n); end test; {"Error: Internal error ComponentReference.expandSlice: Unknown slice 1:n", "TRANSLATION", "Error", "63"} Error processing file: test.mo Error: Internal error ComponentReference.expandSlice: Unknown slice 1:n # Error encountered! Exiting... # Please check the error message and the flags. Execution failed!
Yes, but nothing forces a tool to require that structural parameters be possible to evaluate before code generation either.
Lots of things are up to tools to decide ;) On the other hand, I think this is supported in function context already anyway, so handling it shouldn't be hard. You can do it.