On Wed, 26 Jun 2013 22:03:53 +1000 David Seikel <onef...@gmail.com> said:
[...snip...] > > 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-) well ok - its not hybrid lua + some other lang. its simply string manipulation on the lua to insert or remove lines. using comments as markers is one way to do it. :) > 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. problem is the func then needs access to the stack frame/context... i was trying to keep it simple and just have it live in the same stack frame/namespace so it can re-use existing intermediate local vars/calcs etc. - i also don't trust luajit to have all these optimizations. it may or may not, but the point is to make it trivial for a gui designer to augment some logic - not to make this an exercise in comp sci design beauty. :) designers live in a copy & paste world... so i was thinking this works better for them (if they are forced into messing with code at all). :) > 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. i was thinking something much simpler... just line-by-line insert or replace of strings :) that simple. :) > > 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? umm the lua lays the objects out too, defines their states etc. - it has tyo go thru c to implement the state tho... or go thru c to query objects (eg query a textblock format geometry). at least thats my thought right now. if all it di was calc the params - it could just provide a table of object properties (size, position, visibility etc.) and then the table is taken in one big lump and on the c side it is walked over implementing the states in it.. thats is another option rather than the lua doing a direct call, but i have not thought up how the lua can query in the same way. > > > > > 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. sure. but i do want to have threads + a worker/job and message passing system in there from the ground up so you can spawn off workers in lua by hand at least. what should be transparent/automatic is another q entirely still atm. > > > 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? only advanced ones that want to create new custom derived objects of their own (or whole new ones from scratch). this means basically advanced designers or programmers when they find the current set of "bobjects" doesn't cover what they need. 99% of the time their needs will be met by just gluing existing bobjects into a meta-object (already combined - eg an table + image + label with label centered and both image and label inside the same table cell so parent table object min size is the combined min of label + image, and with any mouse press event changing the "presseD" property to true (and release to false), with the image object repsonding to this attached extra property by changing image file/state - should be configurable in the gui without any lua at this level). > 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. -- ------------- 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
