On Sun, 8 Jan 2012 06:53:04 +1000 David Seikel <onef...@gmail.com> said:
> On Sun, 8 Jan 2012 01:55:49 +1000 David Seikel <onef...@gmail.com> > wrote: > > > On Fri, 6 Jan 2012 20:32:30 +0900 Carsten Haitzler (The Rasterman) > > <ras...@rasterman.com> wrote: > > > > > On Thu, 5 Jan 2012 23:38:55 +1000 David Seikel <onef...@gmail.com> > > > said: > > > > > > > On Thu, 5 Jan 2012 16:43:29 +0900 Carsten Haitzler (The Rasterman) > > > > <ras...@rasterman.com> wrote: > > > > > > > > > On Mon, 2 Jan 2012 21:09:19 +1000 David Seikel > > > > > <onef...@gmail.com> said: > > > > > > > > > > how will the lua be able to detect the api call is there safely > > > > > without totally ceasing functioning. > > > > > > > > That's a problem we will have to solve anyway. I said - > > > > > > i know. right now it can be a simple "needs version X of edje". for > > > api that is transient (may or may not be provided by app loading > > > edje file)... it's a different matter :) > > > > It's a different problem, but solving the general case solves them > > both. B-) > > > > > > > > Raster objected to this idea before, if I remember. His > > > > > > argument was, I think,"what if someone loads a Lua script > > > > > > theme that uses one of these new APIs, but they are not > > > > > > there?". We are gonna have that problem now, and with each > > > > > > subsequent release. Anyone running a theme that expects > > > > > > images, text, maps, and other stuff that I added to the last > > > > > > release, but using the edje release before, is gonna be sorely > > > > > > disappointed. It only had rectangles and timers. For the next > > > > > > release I expect to add textblock and sound support at least. > > > > > > > > (Glad I remembered your objection properly.) > > > > > > > > Since I plan to reuse the same infrastructure we already have, > > > > these new host app supplied functions will be in a table+metatable > > > > created to hold them. Like the existing image table+metatable and > > > > evas image functions that it holds. So just like an edje Lua > > > > script could now call - > > > > > > > > image.filled(true) > > > > > > > > and work fine with the current edje release, but fail on the > > > > previous release. In the future it could call - > > > > > > > > daves_funky_app.some_function(foo, "bar") > > > > > > > > or - > > > > > > > > textblock.textblock() > > > > > > > > or even - > > > > > > > > elementary.box() > > > > > > > > If they are using the current edje release, all are trying to use > > > > non existent API. So the same thing should happen in all cases. > > > > > > > > I think we can add a metatable to the environment, and use the > > > > usual mechanism for handling access to non existent data. That's > > > > what I'll be experimenting with to solve the problem for all > > > > cases. Once edje can safely detect the use of an undefined > > > > object, it should bitch, ignore any effort to call one of it's > > > > methods, and carry on. Actually, if I remember, any unassigned > > > > variable has the nil value, so perhaps we can add a metatable to > > > > that? > > > > > > well if we can have these calls safely return nils and not have lua > > > barf entirely... that'll be good ;) > > > > That's what I'll work on then. > > I put a metatable on nil. Works beautifully. Even the ancient > edje.spanky() code you put in a long time ago triggers it. An error > message is printed, the non existent function returns nil, and the > script keeps running. perfect! :) thats what we needed. of course we probably should add an edje.version() to be able now to detect older/newer edjes. :) if this returns nil.. they have 1.0 or 1.1 - no one used lua in 1.0 as we basically never documented it. :) > This will work for people using themes with new API on an old library > (images on the old release, textblocks on the current release if they > are added to the next release), using new functions on old API (for > instance, if we add an edje.textblock() function in the future, but > someone uses it with an old library), and host app provided API if not > running under the host app that provides it (which I will add soonish). now here comes the rub. given the way lua/embyro/edje programs are done now... we CAN farm this all off into threads. this is why i like the whole async messaging thing. adding direct api calls like this means we can't. or more specifically the api's provided by the app eithe3r may possibly be called from threads (highly unexpected and dangerous/tricky/bad) OR we need to handle these like they were synchronous messages back to the mainloop. this will make such things become relatively inefficient. i'm very loathe to do this kind of thing given the current clean separation allowing us to throw lots of threads at things to gain performance on more modern cpu's that are sprouting cores like pimples. this is particularly relevant on arm where we now have 4 core soc's and unlike x86, each core is significantly less powerful, so scaling across cores is very important. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
