[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lua idea
- From: Rena <hyperhacker@...>
- Date: Mon, 9 Apr 2012 06:17:05 -0600
On Mon, Apr 9, 2012 at 05:44, steve donovan <steve.j.donovan@gmail.com> wrote:
> On Mon, Apr 9, 2012 at 8:03 AM, Rena <hyperhacker@gmail.com> wrote:
>> Of course from there the idea quickly morphs into "what if we didn't
>> need to write a library at all, and could just call the functions from
>> Lua directly", which is what Alien and such do... need to look into
>> those I guess.
>
> So you need a compiler... and here enters LuaJIT, where Lua + ffi is
> often going to be faster than Lua + C extension. LJ also has a most
> cool feature (relevant to this discussion) where it will compile Lua
> modules as object files which can be linked with the executable.
>
> BTW, it would be a cool idea if a group of people could collect
> references to LuaJIT FFI-bindings on the wiki, plus optimization tips,
> since it's often not obvious what flies and what crawls. Definitely
> sufficient material there for a collaborative open-book.
>
> steve d.
>
Yes, LuaJIT has another nice FFI... but then you depend on LuaJIT.
Wasn't there a project to provide the same interface to native Lua?
The more I think about the idea, the more I realize I'm not totally
sure what I want it to be, other than a way to make binding to C
libraries less clunky (the code for such bindings can be terribly
repetitive) without adding more dependencies to the scripts that use
them. Maybe that could just be a preprocessor or something that
compiles to C, but even then, compiling C libraries can be a huge pain
in the rear compared to native Lua modules.
Maybe best to take this to a new topic...
--
Sent from my toaster.