On Tue, 25 Jun 2013 22:26:05 +1000 David Seikel <[email protected]> said:
> On Tue, 25 Jun 2013 19:57:45 +0900 Carsten Haitzler (The Rasterman) > <[email protected]> wrote: > > > On Tue, 25 Jun 2013 19:40:03 +1000 David Seikel <[email protected]> > > said: > > > > > On Tue, 25 Jun 2013 17:02:43 +0900 Carsten Haitzler (The Rasterman) > > > <[email protected]> wrote: > > > > > > > On Tue, 25 Jun 2013 11:36:10 +1000 David Seikel > > > > <[email protected]> said: > > > > > > > > > On Tue, 25 Jun 2013 10:06:10 +0900 Cedric BAIL > > > > > <[email protected]> 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. actually not "hybrid lua". literally - lua. just bind lua to be able to "do things in the ui as needed". lua will deal with basic evas object types - it will implement things like elm entry's entry logic entirely in lua. you can build all the basic parts we have today with simple snippets of lua. box, table and containers also done in lua. we want to be able to expose data (mvc-like) to the lua from the "native side" - so a lua implemented part (object) can display a pie chart, bar graph, or anything it likes based on a table of inputs (for example). > Using LuaJIT and automated parallelisation of the bits of Lua. With automated - well maybe. as much as possible. there is a dependency graph (tree) that is implicit in any layout - or explict. different tree/graph paths can be walked in parallel to speed up computation. in theory. question is - is it worth it given we will have overhead of duplicating data between lua vm's and messaging between them? sure - worker threads so each thread is a vm instance on its own so it can directly pass and not duplicate within its own context is fine... just between them it gets a bit messy. i was wondering if such parallelization should perhaps be more explicitly done by hand in the lua itself by spawning off tasks when and if desired EXPLICITLY to a messaging/worker infra. > 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 yes - without slots and snippets, you have to re-implement any method you override entirely. this was an idea to cut down the work needed to do "i want that thing, but just with this 1 change!". making that change is forking and patching a derivative class - done as part of the gui builder infra. > GUI builder / snippet manager that lets you drill down to the > underlaying Lua code. yes. in fact it'd be all gui builder from the start. the lua building blocks are just building blocks designed to be used from the gui directly. objects with properties need to expose properties in an explicit way so the gui builder can provide gui controls for those properties (color, size, alignment - whatever it wants to expose). > 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. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
