[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Guidance needed on C# and Lua integration
- From: Andrew Starks <andrew.starks@...>
- Date: Mon, 20 Apr 2015 19:40:54 -0500
We are working on a project where Lua is the middle-wear that binds to
other languages. We do quite a bit of our application programming in
C# and our first binding to it.
Our current workflow is Lua 5.3 -> Managed C++ -> C#, but as my
colleague put it today, "We are interested in binding our library to
C#, not all of Lua to C#." Therefore, we are looking around.
It looks to me as though nLua (formerly LuaInterface) is the
leading way to use Lua and C#. Many of the examples show Lua in the
scripting role, but it appears that it may work well in both
1: We need Lua to be able to load C and Lua libraries with require.
2: We also need to be able to call delegates (and most likely other
objects) from Lua, but mostly C# is calling into Lua objects (I'm
using penlight's objects).
3: We use Lua 5.3
4: C#/Windows is not the only target language/platform.
Does anyone have experience with this or something similar? I'm
curious if anyone has tried using the "unsafe" keyword and just bound
Lua to C#, without an extensive wrapper. I'm also curious about any
I didn't see any 5.3 issues open on github, so I assume that it is not
on their map. I don't want to loose 64bit integers, but I am also
unsure of where the greatest uncertainty / pain lies, so I don't know
anything about whether forking the project to work with 5.3 is better
or dropping 5.3 is better... That question is better question for the
authors of the project, however. I mention it here, in case experience
has already had its say with someone here.
A JSON very-high-level binding is still being considered, but:
- The binding would be dead simple.
- This is pretty much done, but using it in C# is not *that* easy. It
feels a lot like writing the whole library again.
- we think that this will lead to too much maintenance.
- we'd have to re-implement the Lua object model that we've already
made in C#. (We may end up having to do that with nLua, too)
- Increased probability of low performance, or at least limited
- A proper integration would increase the possibility of extending
our library with C# delegates (uber-function pointers).