Opened 6 years ago
Last modified 5 years ago
#5426 assigned defect
Compiler fails when model name is too long in OMEdit
Reported by: | Owned by: | Adrian Pop | |
---|---|---|---|
Priority: | blocker | Milestone: | 2.0.0 |
Component: | Frontend | Version: | v1.14.0-dev-nightly |
Keywords: | Cc: |
Description
I know it's an almost-duplicate ticket compared to https://trac.openmodelica.org/OpenModelica/ticket/5315, but I think it's conceptually very different: this is specifically for OMEdit, where the user does *not* handle directly the fileNamePrefix
as if it was for the buildModel
and buildModelFMU
script commands (except if it specifically sets the equivalent option in the Simulation Setup>Output>File Name Prefix).
Long-name models (even those whose name comes from a deep nesting) fail to build with no meaningful error message.
Such a problem could be very annoying to debug if someone does not know about the modelname length problem: if allowing long names it's a problem, then at least the user should be warned about the issue.
The very simple model
model shortModelName Real t; equation t = time; end shortModelName;
when nested into something like this:
model longModelName model longModelName model longModelName model longModelName model longModelName model longModelName model shortModelName Real t; equation t = time; end shortModelName; end longModelName; end longModelName; end longModelName; end longModelName; end longModelName; end longModelName;
gives the following error:
[1] 15:55:51 Scripting Error Error writing to file BipartiteGraph_longModelName.longModelName.longModelName.longModelName.longModelName.longModelName.shortModelName.graphml.
Obviously, I'm not playing to make long names on purpose!
I hit this problem when I had to run a real model: CrtVehicleTesting.Mechanics.Rotational.Differentials.DifferentialElectronicLimitedSlipTest
Change History (8)
comment:1 by , 6 years ago
Milestone: | Future → 2.0.0 |
---|---|
Priority: | high → blocker |
comment:2 by , 6 years ago
You can also set fileNamePrefix
for buildModelFMU
via Tools->Options->FMI->FMU Name
.
comment:3 by , 6 years ago
Component: | OMEdit → Frontend |
---|---|
Owner: | changed from | to
Status: | new → assigned |
See #4844.
follow-up: 5 comment:4 by , 5 years ago
I'm back here because I hit the same issue again and I spent half a day to debug the same exact thing.
Guys, I'm not saying to let long-named models to _run_; I'm just asking to _warn_ the user that the name is too long.
Wouldn't it be a perfect temporary workaround? Wouldn't it be just a matter of
if length(name) > 64 then disp('Hey, this name is too long')
?
Just an idea.
Thanks, as always, for your work
comment:5 by , 5 years ago
Replying to dariomangoni@…:
I'm back here because I hit the same issue again and I spent half a day to debug the same exact thing.
Guys, I'm not saying to let long-named models to _run_; I'm just asking to _warn_ the user that the name is too long.
Wouldn't it be a perfect temporary workaround? Wouldn't it be just a matter of
if length(name) > 64 then disp('Hey, this name is too long')
?
I agree this issue is nasty, and it also costed me waste of time in the recent past.
The problem is, we don't know what the maximum length, because it depends on various system-specific factors, such as the length of your temp directory path, your OS (Linux doesn't have this limitation), etc..
See #5796 for a proper solution; this requires to fix the code generation part.
You can also change the working directory to a short path such as c:\temp
, this should give you some more headroom.
comment:6 by , 5 years ago
I'm already in C:\workspace
!
I can't actually move any objection since I do not know in which part of the code the compiler fails:
- if it is because a path is longer than MAX_PATH then you might be able to catch it beforehand just checking the string length (unless the problem comes from a string that is given by some kind of expansion provided by the OS)
- if not, I would think "how many reasons there are for a file not to be written?" well, many... I don't know if you already catch any of those, but maybe you can provide a suggestion/warning that gives the user the hint that its filename it's too long;
Just ideas...
comment:7 by , 5 years ago
I just counted about 90 characters in the class name you reported above. That gives 90+90 characters for the directory name and the file prefix, plus about 10 characters for suffixes like _info.json
, plus other 10 for c:\workspace
(hint: you can make it c:\w
and save 7 more). That gives 200. I understand the limit is 260 or something like that, so I'm not sure I understand what's missing.
BTW, would you like to try with this trick?
comment:8 by , 5 years ago
That could make it, but I'm not looking for solutions for me.
I'm here to push solutions for everyone!
I guess this should be really fixed for 2.0.0. If we can do it in 1.14.0, that would be even better.