Am 05.09.2012 um 10:33 schrieb David Seikel <onef...@gmail.com>: > On Wed, 5 Sep 2012 10:21:43 +0200 Vincent Torri > <vincent.to...@gmail.com> wrote: > >> On Wed, Sep 5, 2012 at 10:07 AM, David Seikel <onef...@gmail.com> >> wrote: >>> On Tue, 4 Sep 2012 15:59:20 +0200 Leif Middelschulte >>> <leif.middelschu...@gmail.com> wrote: >>> >>>> Am 04.09.2012 um 14:35 schrieb David Seikel <onef...@gmail.com>: >>>> >>>>> 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-( >>>> Sounds like a nice thing for the future. >>>> Question remains though: Would you be willing to make those >>>> (minor?) adjustments, so it'll work with mac os mountain lion + >>>> brew ootb? Just until the lua jit stuff you're hacking on hits svn? >>> >>> I'll look at it when I next get some time to do EFL Lua stuff, but I >>> can't make any promises concerning Mac OS. I don't own a Mac, and >>> don't have a Hackintosh either, so I can't do any testing. I'll happily try it since it's as easy as trying to build the package ;) >>> >>> I came close to owning a Mac earlier this year. It was a toss up >>> between buying a Mac Mini for development, or buying an Android for >>> development. I had priced both options, they both came out to be >>> about the same amount of money. Which was about the amount of >>> money I had to spend, so I had to pick one. I picked the Android. >>> >>> I have no idea what you mean by "+ brew ootb". >> >> http://mxcl.github.com/homebrew/ > > Ah, some sort of third party Mac OS package manager. Yes, sorry. I should have added this information. So here's a short feature summary about it (if you care): Brew is a relatively young package manager for Mac OS, which means it can't compete with macports in the number of packages, yet has everything necessary to build efl. It uses github's infrastructure to collect packages from the community (via pull requests). It installs every package in a dedicated directory/prefix (so called 'cellar') and only creates symlinks back to /usr/local (by default). Plus it perfectly blends in with Mac OS developer tools (clang, llvm, libcurl, etc.). Think of arch user repository, but simpler and using git :) > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. > ------------------------------------------------------------------------------ > 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
------------------------------------------------------------------------------ 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
