Back Midas Rome Roody Rootana
  Midas DAQ System  Not logged in ELOG logo
Entry  04 Jul 2019, Lukas Gerritzen, Info, Limitations of MSL 
    Reply  05 Jul 2019, Konstantin Olchanski, Info, Limitations of MSL 
       Reply  08 Jul 2019, Stefan Ritt, Info, Limitations of MSL 
          Reply  08 Jul 2019, Lukas Gerritzen, Info, Limitations of MSL 
             Reply  08 Jul 2019, Konstantin Olchanski, Info, Limitations of MSL 
                Reply  09 Jul 2019, Stefan Ritt, Info, Limitations of MSL 
          Reply  08 Jul 2019, Konstantin Olchanski, Info, Limitations of MSL 
          Reply  16 Jul 2019, Lukas Gerritzen, Info, Limitations of MSL 
             Reply  30 Jul 2019, Stefan Ritt, Info, Limitations of MSL 
Message ID: 1593     Entry time: 05 Jul 2019     In reply to: 1589     Reply to this: 1594
Author: Konstantin Olchanski 
Topic: Info 
Subject: Limitations of MSL 
> I am missing a few features.

MSL did not start out as a fully featured programming language.

Rather than extending it until it becomes one, I think a better approach would be to take
one of the existing extensible scripting language libraries and extend it with midas functions.

For example, LUA (https://www.lua.org/about.html) seems to be popular.

There were also requests for a midas extension for PYTHON (actually this has been done before,
but never added to the midas repository. I still have that code and I suppose it could be resurrected).

K.O.


> Do any of the following exist and I have just
> overlooked them?
> 
> - Arithmetics:
>     SET foo, 2
>     SET bar, 2
>     SET FOOBAR, $foo + $bar
>     -> FOOBAR is 2, not 4
> 
> - Vectors/arrays
>     As far as I understand, "SET" only allows for single variables and no 
>     "scripting" in variable names, i. e. doing something like the following
>     scripted: 
>     SET var_1, 0
>     SET var_2, 0
>     ...
>     LOOP n, 10
>         ...
>         IF something
>             SET var_${n}, 1
>         ENDIF 
>     
>     The only way I could think of doing something similar is via the ODB.
>     I don't know if it's good practice to fill the ODB with variables like this.
> 
> - Loading scripts at run time (see other bug)
>     That would allow for script manipulation, even though it's kind of dirty, it
>     might be useful in some cases.
> 
> - Obtaining results from external scripts
>     A way to pass things from external scripts would be the solution to all
>     problems. Something that is not implemented could be done in a bash or
>     python script instead. 
> 
> Cheers
> Lukas
ELOG V3.1.4-2e1708b5