On Wed, 26 Jun 2013 12:40:55 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> On Tue, 25 Jun 2013 22:26:05 +1000 David Seikel <onef...@gmail.com> > said: > > > 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. > > actually not "hybrid lua". literally - lua. just bind lua to be able The examples you gave are Lua + some as yet unwritten preprocessor that parses Lua comments. Lua has no preprocessor, comments are supposed to be meaningles. Thus it is "hybrid Lua". B-) On the other hand, I wonder if we could just use ordinary function calls instead of these special comment bits? Let LuaJIT optimise out any empty functions, and any overhead if it's just a single use call? Effectively letting LuaJIT turn them into inline calls. I suspect LuaJIT could do that, and then we wont have to add to the Lua syntax. On the gripping hand, one of my goals with my LSL thingy was to allow mixed LSL / Lua code. The user sets a flag at the top of the script that says "this is mixed code", the translator translates anything that looks like LSL to Lua, and leaves the rest alone, assuming it's ordinary Lua. A similar technique could be used here. > 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). So Lua only defines the objects, but the plumbing underneath that deals with basic layout, rendering, and other stuff is still C? > > > 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. I suspect we would be better off doing it by hand. But as you said, no point prematurely optimising this part until we have the manual method working, then profile to see if it will help. > > 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). Would users of this GUI deal with Lua at all? Looks like I mostly got it right. B-) -- 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
