Opened 10 years ago
Closed 5 years ago
#3645 closed defect (fixed)
Modelica.Utilities.Files.removeFile doesn't work
| Reported by: | Francesco Casella | Owned by: | somebody |
|---|---|---|---|
| Priority: | critical | Milestone: | 1.16.0 |
| Component: | New Instantiation | Version: | |
| Keywords: | Cc: |
Description
Run the attached model, which opens a file, writes something to it, closes it and then removes it. At the end of the process the file is still there, yet no error is generated.
Attachments (1)
Change History (22)
by , 10 years ago
| Attachment: | TestDelete.mo added |
|---|
comment:1 by , 10 years ago
comment:2 by , 10 years ago
Seems like it is marked impure in MSL, but not printed if the function has the impure annotation. Would need some more time to figure out what was wrong...
comment:3 by , 10 years ago
See also m:#1886. We now remove the print functions, but the other parts probably behave as expected.
comment:6 by , 10 years ago
Too bad. BTW, I understand the currently impelmented heuristics is that functions with no output are considered impure. However, I have some test cases where the behaviour changes for better if I also add the impure keyword to the declaration.
comment:7 by , 10 years ago
No, functions with no output are not considered impure. Because then you could not call print, hashtables functions, etc as used in MetaModelica.
comment:8 by , 10 years ago
Sorry, I am totally confused then. What kind of heuristics is currently available in OMC to detect impure function calls with constant inputs and avoid optimizing them away at initialization?
comment:9 by , 10 years ago
Pretty much none. We look for __OpenModelica_Impure=true, or we run with -d=nogen which disables generation of dll's (but since some external functions are structurally necessary, some external calls are allowed and are handled by -d=evalfunc).
comment:10 by , 10 years ago
Aha. On 22 Feb 2016 9:25 you wrote me on Skype
I think we detect that they don't return anything, so we consider them impure :)
I was misled by that...
comment:11 by , 10 years ago
Well. I think we try to not evaluate them (at least in some instances). But not by considering them the same as impure (since impure functions are more special).
comment:12 by , 10 years ago
Which is even worse from the user's point of view, because sometimes they work as expected and sometimes they don't, without any obvious pattern...
comment:16 by , 9 years ago
| Milestone: | 1.11.0 → 1.12.0 |
|---|
Milestone moved to 1.12.0 due to 1.11.0 already being released.
comment:17 by , 8 years ago
| Milestone: | 1.12.0 → 1.13.0 |
|---|
Milestone moved to 1.13.0 due to 1.12.0 already being released.
comment:19 by , 6 years ago
| Milestone: | 1.14.0 → 1.16.0 |
|---|
Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2. This issue is rescheduled to 1.16.0
comment:21 by , 5 years ago
| Component: | Run-time → New Instantiation |
|---|---|
| Milestone: | 1.17.0 → 1.16.0 |
| Resolution: | → fixed |
| Status: | new → closed |
This works with the new frontend now which doesn't remove any of the calls and marks functions as impure correctly.
removeFile("file.txt"); is not part of the flattened code for some reason :) I assume because it was not marked impure in MSL.