Am 20.09.2012 um 07:58 schrieb David Seikel <onef...@gmail.com>: > 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. I'll try it with the next release, thanks :) > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. > ------------------------------------------------------------------------------ > 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
------------------------------------------------------------------------------ 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
