How much Python code are you proposing "someone" ports to Lua? ;-) On Wed, Nov 14, 2012 at 4:49 PM, Alek Paunov <alex@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx > 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? -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
