On Wed, 5 Sep 2012 20:54:16 +1000 David Seikel <onef...@gmail.com> wrote:
> On Wed, 5 Sep 2012 12:39:14 +0200 Leif Middelschulte > <leif.middelschu...@gmail.com> wrote: > > > 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 :) > > I'll just get it to work here under Linux. Mac OS packaging is > someone else's job to deal with. I applied a patch provided in another thread, and just committed it now. Let me know if that solves your Mac problems. -- 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
------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
