On Tue, 4 Sep 2012 13:24:27 +0200 Leif Middelschulte <leif.middelschu...@gmail.com> wrote:
> as some distributions and Mac OS' (home)brew package manager already > ship lua >=5.2, it might be time to make the code compatible. > > The functions which aren't available anymore: > > _luaL_register > Module and luaL_register deprecated, replaced by luaL_newlib and > luaL_setfuncs. > > _lua_objlen > lua_objlen has become lua_rawlen with a very slight change in > behaviour, lua_len and luaL_len have been addded. The length > function(s) changed between Lua 5.0 and 5.1, and they've changed > again between 5.1 and 5.2-work3. What used to be calledlua_objlen in > 5.1 was been renamed to lua_rawlen, with the only difference in > behaviour being that lua_rawlen no longer calculates the length of a > number by taking the string representation of it; it just returns > zero. The new lua_len function behaves exactly like the length > operator in Lua code, and the new luaL_len function behaves in a > similar way but returns the result as an integer rather than on the > stack (and throws an error if the length is not a number). > > I'm not familiar with the behavior edje expects, so I'm asking for > anybody who's familiar with it to add a conditional define to edje's > configure.ac, corresponding code to edje's code and changelog+NEWS(?) > to maintain vtorri's sanity :) We discussed this last year and came to the conclusion that moving to 5.2 was not a good idea at the time. It might be time to look at that again, things progress. Since then I have spent some time experimenting with LuaJIT 2, which is Lua 5.1 with some 5.2 features, plus lots and lots of JIT speed, and some speed, as well as red speed stripes for that extra bit of raw speed. Did I mention it's fast? I also added luaproc into the mix, but ended up rewriting most of luaproc. By "rewriting" I mean "throwing out most of it, replacing a few of the removed bits with EFL, and massaging the rest to suit my purposes". Well, half of luaproc just implemented stuff we already had in EFL. My experiments with LuaJIT 2 + what's left of luaproc are not finished yet, but so far I like what I have. Only one part of LuaJIT 2 I want to replace, and that's the memory allocator. Simply coz it does not handle setting memory size limits per script like we do in Edje Lua. Which is also important for the non Edje project I have been using as a test bed. Apart from being generally regarded as the worlds fastest script language interpreter, LuaJIT 2 offers one important thing that I think might be great for EFL - it very easily wraps existing C libraries, turning them into Lua API. This part I've not experimented with yet, but I have high hopes. Now while I have no problem with detecting an OS installed Lua 5.1/5.2 and adjusting the compile to suit, I'd like to suggest a different approach. Basically do something similar to what we did with Small/Pawn -> Embryo. Not such a drastic fork though, but keeping more or less in sync with upstream of LuaJIT 2, and having our own copy in SVN. Replace the LuaJIT 2 memory allocator with an Eina one, and implement our memory size per script limit. Lua, like Small/Pawn and Embryo, is tiny. That's one of the reasons we picked it for EFL. Lua is designed to be embedded, so it's quite happy not being a system library. The reason none of this Lua experimentation has been seen here in EFL land is that my experiments where on another project. Using EFL, with an eye to using my experience with EFL's Lua code, but not actually related to EFL. https://github.com/onefang/SledjHamr look at the experimental branch, and then the LuaSL directory. Or look at https://github.com/onefang/SledjHamr/tree/experimental/LuaSL for the lazy. It's an implementation of the Second Life LSL scripting language made for OpenSim, but using Lua and C (instead of C#), with EFL as the major support libraries. Basically it converts LSL into Lua, with the option of using pure Lua, then passes the result to LuaJIT 2. Luaproc (or what's left of it) is used to scale the result up to the thousands of event driven scripts running at once that virtual worlds with user written scripts requires. Since I did that with an eye to using my experience in EFL's Lua code, there's some similarities with the EFL Lua bindings Raster and I wrote. It's not a drop in replacement, but I think I can make the switch. I wanted to finish my experiments and have it working nicely, with some benchmarks and useful figures, before I hit EFL coders with the idea of using LuaJIT 2. Wanted to get a good handle on what I'm talking about before putting it through the grill of trying to get it into EFL. Right now, I still want to experiment with the LuaJIT C library binding mechanism before even deciding if it's good enough for EFL. That was six months ago. I've been too busy with other things since, and the coder I was relying on to get the next step done vanished. Guess I'll have to learn C# and interface with the OpenSim code myself. B-( -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
