LuaJIT - an alternative for current Python C bindings (was: Re: raising warning flag on firewalld-default feature)

[M. Edward (Ed) Borasky]

How much Python code are you proposing "someone" ports to Lua? ;-)

On Wed, Nov 14, 2012 at 4:49 PM, Alek Paunov <alex at declera.com> wrote:
> On 12.11.2012 21:34, Steve Grubb wrote:
>>
>>
>> But the problem I see is a lot of libraries are wrapped by swig, which
>> leaks
>> memory like a sieve.  If swig didn't generate such leaky code, Python
>> based
>> daemons wouldn't be as scary.
>>
>
> IMHO, Python is one of the best ways to express management logic. As have
> stated elsewhere in the thread, from the footprint perspective, python-libs
> can be decomposed to something including much smaller python-libs-core. The
> remaining problem is the quality of part of the C bindings. Otherwise, it is
> great advantage for Fedora that huge part of the system tools are already
> polished in Python (my own experience is that the C code in many tools/libs
> shipped with Fedora is of relative poor quality, as already Miloslav
> explained).
>
> David Malcolm already has some real results addressing the Python bindings
> issues trough static analysis based on his great
> gcc-python-plugin/libcpychecker work. In the future, this machinery can be
> used for bug free bindings generation too.
>
> Another option for addressing this is ... to just get rid of part of them in
> their current form.
>
> LuaJIT 2.0 is a reimplementation of Lua scripting language, which has build
> the reputation of one of the fastest compilers (comparable only with gcc) in
> the course of his 3 years! beta cycle (2.0 final release was announced early
> this week)
>
> The size of luajit.so (interpreter + trace compiler + C parser for the FFI
> definitions) is 452088 bytes (on x86_64, for comparison sqlite3.so, which is
> a python requirement is 677672)
>
> Unlike other FFI implementations LuaJIT FFI works compiling the functions
> calls/C structs access to native code. Another difference is that the
> foreign C definitions are presented in native C syntax:
>
> http://luajit.org/ext_ffi_tutorial.html#zlib
>
> On top of this kind of FFI, LuaJIT already have bunch of library bindings -
> as instance the kernel ABI wrapper:
>
> https://github.com/justincormack/ljsyscall
>
> For a long time already Fedora ships lunatic-python (loading and bridging
> the Lua interpreter as python module)
>
> More recent and feature complete bridge is:
>
> https://github.com/scoder/lupa
>
> from the author of lxml module.
>
> So, to me it seems natural joining all above together to start thinking for
> replacing the classic python C bindings with thin textual or bytecode(*)
> LuaJIT/FFI shims in benefit of things with great set of dependencies like
> Anaconda (thanks to lupa, Lua objects behaves like Python ones in Python).
> The result will be order of magnitude easier for maintenance (towards the
> APIs evolution) and faster code.
>
> Furthermore, we can get LuaJIT for free, because it is full API/ABI
> compatible with current Fedora (PUC Rio) Lua 5.1, which is pulled by RPM
> anyway - we can just replace Lua with LuaJIT as RPM provider for F20.
>
> Kind Regards,
> Alek
>
> (*) Unlike original Lua, LuaJIT bytecode is portable across architectures.
>
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel



-- 
Twitter: http://twitter.com/znmeb; Computational Journalism Publishers
Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/

How the Hell can the lion sleep with all those people singing "A weem
oh way!" at the top of their lungs?