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. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
