For reference, I have presented some talks on this topic at the last few EPICS meetings.
So far I have implemented the following.
o A Lua-based CA server event filtering system where a small Lua snippet in the channel name postfix serves as the filter
o A Lua-based IOC shell, callable from the legacy IOC shell, which can also invoke all of the registered IOC shell commands
o A Lua-based scripting record, where Lua provides a comprehensive feature set, compared to CALC.
Thanks for your interest,
> -----Original Message-----
> From: email@example.com [mailto:core-talk-
> firstname.lastname@example.org] On Behalf Of Ben Franksen
> Sent: Thursday, February 23, 2017 3:00 PM
> To: email@example.com
> Subject: Why we want Lua on the IOC
> Some people (Ralph?) mentioned that embedding Lua on EPICS IOCs might be
> a good idea, perhaps even as a replacement for the iocsh. Prompted by
> this I have been reading up on Lua, which, until now, I had dismissed as
> yet another boring dynamically typed imperative/OO language (yawn). I
> was wrong.
> Yes, the language is procedural, imperative, with some OO features,
> nothing spectacular. But it does have a number of features that make it
> particularly suitable for EPICS. First of all, it has been designed from
> the ground up for embedding in a host program. It is very small and
> light-weight, so could easily run on 'real' IOCs, even on small devices.
> Its language features have been carefully selected to offer only what
> can be easily interacted with from a host program written in C. The
> language itself is extremely simple, very much suitable for users who
> are not professional programmers (constrast that with Unix shell
> programming). The syntax is not whitespace (layout) sensitive, allowing
> to write and execute simple programs on a terminal without any advanced
> line-editing features; yet semicolons between statements are optional
> (like in Eiffel, if anyone rembers that one). It has first class and
> anonymous functions but provides syntactic sugar for the conventional
> style of (named) function definitions. Registering C functions for Lua
> (from the host program) is a straight forward exercise, requiring less
> boilerplate than for the iocsh. Lua supports one and only one structured
> data type, the table, which is enough for programming inside Lua. The
> host program can add abstract data types and can even overload operators
> or table key selection for them, giving users an OO-like API due to
> support for first class functions.
> Given appropriate support from the host (EPICS base) it could be used to
> write simple "EPICS scripts" to be executed directly by the (Lua) shell,
> for instance to access and manipulate the database (static and dynamic);
> or one could conditionally configure a driver with different parameters,
> depending on a configuration option; or start sequencer programs in a
> loop. I would even consider adding a sequencer-like extension.
> The only downside I can see at the moment (others will surely provide
> more) is that strings must be quoted, which is a bit inconventient for
> an interactive shell. (At least, as in Perl and in contrast to Python,
> you can use identifiers (barewords in Perl speak) as table keys.)
> Helmholtz-Zentrum Berlin für Materialien und Energie GmbH
> Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher
> Forschungszentren e.V.
> Aufsichtsrat: Vorsitzender Dr. Karl Eugen Huthmacher, stv. Vorsitzende Dr.
> Jutta Koch-Unterseher
> Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas Frederking
> Sitz Berlin, AG Charlottenburg, 89 HRB 5583
> Hahn-Meitner-Platz 1
> D-14109 Berlin
- Re: Why we want Lua on the IOC Kevin Peterson
- Navigate by Date:
Re: memory leak after unloading of ca.lib Michael Davidsaver
RE: memory leak after unloading of ca.lib Hill, Jeff
- Navigate by Thread:
Re: memory leak after unloading of ca.lib Xiaoqiang Wang
Re: Why we want Lua on the IOC Kevin Peterson