glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [glob2-devel] Glob2 and Lua


From: Valentin Lorentz
Subject: Re: [glob2-devel] Glob2 and Lua
Date: Sun, 28 Dec 2014 11:32:01 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0

Hi,

I'm usually not a big fan of Lua as a language, but I have to admit this
is pretty impressive.
I just don't understand why you say glob would require recompiling Lua
with integer instead of doubles. Is it only for performance, or is there
another reason?

As a comparison, a lot of things can be serialized in Python, but it is
not to not being trustable (see the warning at [1]).

And sandboxing is far from being usable. Actually, there has been an
attempt to make a sandbox for CPython (the main Python interpreter), but
the author gave up. [2]
Pypy (a Python interpreter written in a subset of Python that can be
compiled) also has a sandbox mode, but it is not yet ready to be
embedded. [3]

[1] https://docs.python.org/3/library/pickle.html
[2] https://lwn.net/Articles/574215/
[3] http://pypy.readthedocs.org/en/latest/sandbox.html

Regards,
Val

On 28/12/2014 11:14, Stéphane Magnenat wrote:
> Hello,
> 
> I have had a look at the source code of Lua today, and it seems the
> easiest scripting system I have seen to date to embed into Glob2. In
> particular:
> - It is easy to call co-routines from the host side, so that would fit
> very well our use case for scripting units, buildings and the map.
> - Although Lua 5.2 uses double as numbers by default, we can compile Lua
> to use integers for numbers (providing a small rewrite of the math
> library).
> - It is easy to remove some default libraries, so we can sandbox Lua
> inside Glob2 (and use things like the glob2 virtual file system for IO
> if we want, etc.)
> - We can serialize the entire lua_State* using the ERIS distribution of
> Lua [1].
> 
> With that in mind, we can imagine an architecture in which every unit,
> building and map has a Lua_state* (i.e. a full Lua VM) and a co-routine
> handling its behaviour. These would be loaded from a Lua source code
> file, so they would be very easy to change without having to know about
> (or recompile) the core C++ engine. In addition, it would force us to
> define a clean (and documented) interface about what is provided to the
> behaviour script. This will typically be a set of values and functions.
> 
> What do you think?
> 
> cheers,
> 
> Stéphane
> 
> [1] https://github.com/fnuecke/eris
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]