Francesco Casella

Before we continue the discussion, let me write some statements that we should all agree upon: 1. Modelica is an open standard: if I write Modelica code according to the...

Now, consider the following scenario. John Doe is writing a Modelica package with external C functions that he is also developing from scratch; he wants to provided them to the...

> > I am also in favour of reverting [#3871](https://github.com/modelica/ModelicaStandardLibrary/pull/3871) for MSL v4.1.0 and provided a (draft) PR in [#4487](https://github.com/modelica/ModelicaStandardLibrary/pull/4487). > > I did not change my mind. Let's revert...

> In my opinion we are way (way way way) past the point where we make non-critical bug-fix changes for 4.1.0. I would not call this a critical bug-fix, since...

> If we remove the binaries completely (and not even provide in a released version) then we could get rid of ModelicaUtilities.h. But that's not scheduled for v4.1.0. Hence, my...

> Tool vendors should not be allowed to customize ModelicaUtilities.h. If some OS-specific details such as dllexport declarations are needed, they should be contributed by means of #ifdefs to the...

I'm a bit taken aback by what you state here. I thought that adjacency analysis for functions always assumed them as black-boxes, i.e., all outputs depend on all inputs. It...

I apologize, I was thinking about a _function_, but here you have `a block`, so it's a bit more complicated.. If the FFT computation was done by a function, it...

> If that is true we over-complicated this in the backend. I have seen fragments of structures and algorithms used to compute iverse algorithms in the old backend, i guess...

Rather than investing efforts in inverting algorithms, I would rather invest effort in advanced function and algorithm inlining, i.e., turning algorithms into equations. Then, we can re-use the inversion machinery...