Add more granularity to function evaluation

[Martin Sjölund]

Currently, we have -d=gen and -d=evalFunc to control how to evaluate functions at compile-time. We need some additional granularity. A good default would be:

• Interpret functions whenever
• Compile+dynamically load functions only as a fall-back when calling a function from the scripting interface

I propose an enumeration flag:
--functionEvaluation=default|interpret|dynload|interpretDynload

A string list flag could also be used, but this one I expect would be checked a lot during runtime and integer comparison is cheaper.

Any comments?

[Rüdiger Franke]

In mine the decisions should be based on the Modelica syntax as much as possible. For instance: constants, final parameters or protected parameters are pre-evaluated. The same holds for structural parameters. The evaluation of functions for the initialization of regular parameters should be postponed to the runtime.

There should be no need for compiler flags to get a reasonable default behavior.

[Martin Sjölund]

You need to evaluate certain parameters in order to determine array dimensions or conditional connectors, for example. There absolutely needs to be compiler flags to control this.

[Rüdiger Franke]

These are structural parameters and must be evaluated. No need to configure this with compiler flags until the backend will be able to process arrays with variable dimensions.

One might want to have some flags, e.g. to evaluate non-top-level parameters during model translation. But most things are clear from the Modelica syntax and from limitations of todays backend algorithms / output formats.

[Martin Sjölund]

This is configuring which strategy to use to evaluate function calls. You get different performance and stability depending on which one is used. And since crashing OMC can cause OMEdit to crash, it is desirable to limit the ways in which it can crash.

[Martin Sjölund]

Moved to new milestone 1.9.4

[Martin Sjölund]

Milestone pushed to 1.9.5

[Martin Sjölund]

Milestone renamed

[Martin Sjölund]

Ticket retargeted after milestone closed

[Martin Sjölund]

Milestone moved to 1.12.0 due to 1.11.0 already being released.

[Francesco Casella]

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.