AURIS

AURIS copied to clipboard

Ol (operations language) is a simple interpreted language, which is used for expressing synthetic parameters. The language should be implemented and parsed into an AST which can be fed to the TM model so that the synthetic parameters can be calculated.

work has started, see https://github.com/oswald2/AURIS/compare/master...adamrk:esa-ol

@adamrk do you plan to continue on this or should I prepare a new pull, even if it's not finished yet?

I started working on evaluation. Out of the house right now, but I can push what I did so far when I'm back in a couple hours.

Just pushed the beginning of an evaluator. I probably won't have time to work on it more in the next couple days in case you want to add stuff @mb21?

Also going to add a link to the documentation here, just to keep track of it.

cool, yeah.. during the week I won't have time either...

btw. the evaluation in the end should run within reflex, right? so maybe @oswald2 can take a look to see whether that evaluator makes sense... it's possible that it can be somehow integrated into reflex to yield a continuously up-to-date parameter values... (what they call a Dynamic).. but I'm not sure..

Thanks a lot! I will have a look, but I will also have not much time during the week.

Looks good! Definitively a good starting point.

Some important points:

• The numerical operations (+, -, etc) will have to be done on a TMValue and not on a TMValueSimple. Reason is, that a TMValue is a TMValueSimple paired with a Validity. So in case the values don't match (like adding a String and a Int), the Validity of the result would be switched to invalid. I had a look and I didn't implement the operations on TMValue yet, as well as not all possible states of the Validity, but this is the goal.
• The parser needs to return the parameter dependencies. Basically, as you have seen, each synthetic parameter is effectively a OL script. All of them are parsed and put into a HashMap in the DataModel type (see esa-base/src/Data/DataModel.hs). For wiring up the reflex graph, we need to know the parameters the OL script depends on (so basically a filter on the the Parameter in the AST), but this can be transitively (a synthetic parameter depending on another synthetic parameter), so there will be a function a level higher to get all dependencies for a script (or AST in that regard) transitively so that all can get wired up correctly.
• The evaluator will somehow get a list of TMParameter values on which the script depends. Basically, there are processing steps before (validity checks, calibrations and limit checks) which we want reflex to handle and then serve them to the evaluator, which will be triggered every time one of the dependencies changes. I am not exactly sure, how to do this yet, we are still very much experimenting with reflex to get it working for this. I see in your Env type the Map you use, which I think is currently fine, it just needs to be rebuilt with the new values when they arrive. Later we will probably have to think if this is ok, as the evaluation is in the performance critical path.

The plan is, that the output of the reflex graph are the processed and calculated new values, which will be stored in a concurrent hashtable (probably from the concurrent-hashtable package, but I have to think more about the use cases involved) to have an actual "image" of current parameter values for the user interface to query.

Documentation of all the code is currently ongoing, also the GTK port is on it's way.

The parser needs to return the parameter dependencies.

ah yes... I suppose this could also be done as a traverse over the AST?

serve them to the evaluator, which will be triggered every time one of the dependencies changes.

I imagine one possibility is that the Env contains Dynamic TMValues and then evalProgram also returns a Dynamic TMValue...

ah yes... I suppose this could also be done as a traverse over the AST?

Yes, I think so.

I imagine one possibility is that the Env contains Dynamic TMValues and then evalProgram also returns a Dynamic TMValue...

This would also be a possibility. But I think this will take shape a bit later, when we know how to do the concrete implementation of the TM model.