On Tue, 25 Jun 2013 19:57:45 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> On Tue, 25 Jun 2013 19:40:03 +1000 David Seikel <onef...@gmail.com> > said: > > > On Tue, 25 Jun 2013 17:02:43 +0900 Carsten Haitzler (The Rasterman) > > <ras...@rasterman.com> wrote: > > > > > On Tue, 25 Jun 2013 11:36:10 +1000 David Seikel > > > <onef...@gmail.com> said: > > > > > > > On Tue, 25 Jun 2013 10:06:10 +0900 Cedric BAIL > > > > <cedric.b...@free.fr> wrote: > > > > > > > > > Right now only a thought exercice, but you can get info > > > > > there : https://phab.enlightenment.org/w/bob/ . > > > > > > > > Definitely something my LuaJIT experiments will be good for. > > > > > > > > "A daemon could be in charge of generating the JIT and thus > > > > sharing information across processes (Does LuaJIT allow for > > > > this?)." > > > > > > this is way too premature in terms of optimizing imho. sure - > > > having N apps all go run their own jit on the same bit of lua is > > > inefficient. having it jitted once and shared is much better. but > > > how do we share jitted code sensibly so it can be executed in N > > > places safely? we would need to share jitted code inside mmaped > > > shared memory segs mmaped to the same absolute addresses, unless > > > we modified the jit engine to use base address relative code > > > generation... ugh!. or we run it all in the server and ipc > > > results/input to and fro? ... hmm ewww... > > > > > > > If that means that some EFL based C code is generating and > > > > compiling Lua code, in response to commands from a socket, then > > > > yes. If that also includes running the results in a threaded > > > > way with message passing, then also yes (same daemon). I have > > > > these working already. Designed to deal with thousands of Lua > > > > scripts running at once, and using LuaJIT. I've mentioned this > > > > before. > > > > > > right now thoughts are along the lines of every object type > > > (widget? or part in edje) is really a bunch of lua to implement > > > it - or to calculate it and hand off to a "go implement this > > > state for me" code... > > > > > > what i'd like to see is for it to be easily parallelisable into > > > threads. so we can calculate lots of params/parts in parallel when > > > possible (independent calc paths - eg of 2 child branches before > > > parent has to look at results of children) etc. thus why calc vs > > > implement should be stages.. maybe lua tables with functions > > > (methods) to implement calc , implement, etc. etc. - don't know. > > > thought exercise atm. > > > > My point is that this sort of thing is not just a thought exercise > > for me, I've done a lot of the work already for another project. I > > was always keeping Edje Lua in mind when I did it though, thinking > > some of the work could apply there. Naturally I used EFL for this > > project. B-) > > > > It's a virtual world scripting engine. Second Life / OpenSim > > virtual worlds are made of 256 x 256 meter sims, with hundreds or > > thousands of these sims in any given world. Each sim might have > > several thousand LSL scripts running, and in a lot of cases most of > > those scripts are just multiple copies of the same dozen scripts. > > So I've been writing a daemon that generates Lua scripts > > (translated from pre existing LSL scripts), then compiles and runs > > them with LuaJIT, using a threaded worker queue with message > > passing system. Getting it to run fast and use minimal resources > > is important for this project. I don't want thousands of these > > same dozen scripts soaking up memory, I want one of each. > > > > This daemon will also run in the virtual world viewer, driving Edje > > UIs via Edje Lua. > > oh.. and we need to figure out how to sensibly "override" objects. > basically i can smell objects being very oo-like in that they > implement methods. unlike native we can not just totally override a > specific method on an object class (we want to only keep 1 instance > of a class for an object and not generate per actual object created > for efficiency) but we can "PATCH" a method. i assume we'd use a > metatable with functions stuffed into it to represent a class, for > the basics (please expound on this as u see fit and as to what u > think is good/bad!)... but we can ALSO do things like provide "slots" > or "hook points" within a function. let me do a very simple one > (please don't nitpick my poor lua :)): > > myclass = {} > > function myclass:new() > o = { left = 0; right = 0; size = 0} > -- slot:init-vals > self.__index = self > return setmetatable(o, self) > end > > function myclass:layout(obj) > -- slot:pre-calc > self.size = self.left + self.right > -- slot:post-calc > end > > ---------------- > > now let's say i'm a hacky arty ui person. i want to take the basic > object type "myclass" but simply add a third element to it - > otherwise keep the rest the same. i really want to "patch" the code > by inserting some code of my own in available slots like: > > slot:init-vals = "o.extra = 0" > slot:post-calc = "size.self += self.extra" > > so after "patching" the code becomes: > > myclass = {} > > function myclass:new() > o = { left = 0; right = 0; size = 0} > o.extra = 0; > -- slot:init-vals > self.__index = self > return setmetatable(o, self) > end > > function myclass:layout(obj) > -- slot:pre-calc > self.size = self.left + self.right > self.size += self.extra > -- slot:post-calc > end > > think of this as a very quick and easy way of inheriting a class and > then making just a few layout adjustments. that is just an idea i > have. use slots to insert code into. we could have replace blocks too > like: > > -- repbegin:name > ... > -- repend:name > > and so i can "replace" the logic of some named section of code with > my own. > > basically this won't be done in code btw.. i expect this would be > done in the bob editor/gui when someone wants to take an existing > object/collection/logic and just make some minor changes. they can > SAVE their changed class to their library of objects they get to use > and its always stores just as a delta (patchset of slot inserts or > replaces etc.) over its parent/source class. this is something we can > do in lua but not in c at runtime. this of course depends on the > internal vars that a slot insert or replace section replace being > constance/known. i would imagine that your bob files would ship the > lua with them... including parent classes you inherit from. only > "well defined and never to change in an incompatible way" classes > will ship with the bob install itself (saves space in bob files > shipping them). > > but up for debate. I'm not quite seeing the entire picture here, but I'm late to this party. Let me see if I have this straight. For EFL 2.0 Edje you want to replace .edc + Embryo with some sort of hybrid Lua. Also using Lua to replace some of the C bits of Edje. Using LuaJIT and automated parallelisation of the bits of Lua. With all the widgets and widget parts being entirely implemented in Lua. All the Lua is a bunch of snippets, with the structural snippets being part of the system, and insertable / overridable snippets being provided by the user. On top of this will be some sort of graphical GUI builder / snippet manager that lets you drill down to the underlaying Lua code. Correct me if I'm wrong. -- 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
------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
