Re: [E-devel] Using specifically written modules from Edje lua scripts.

[David S. <on...@gm...>]

On Sun, 8 Jan 2012 11:08:05 +0900 Carsten Haitzler (The Rasterman)
<ra...@ra...> wrote:

> On Sun, 8 Jan 2012 06:53:04 +1000 David Seikel <on...@gm...>
> said:
> 
> > On Sun, 8 Jan 2012 01:55:49 +1000 David Seikel <on...@gm...>
> > wrote:
> > 
> > > On Fri, 6 Jan 2012 20:32:30 +0900 Carsten Haitzler (The Rasterman)
> > > <ra...@ra...> wrote:
> > > 
> > > > On Thu, 5 Jan 2012 23:38:55 +1000 David Seikel
> > > > <on...@gm...> said:
> > > > 
> > > > > On Thu, 5 Jan 2012 16:43:29 +0900 Carsten Haitzler (The
> > > > > Rasterman) <ra...@ra...> wrote:
> > > > > 
> > > > > > On Mon, 2 Jan 2012 21:09:19 +1000 David Seikel
> > > > > > <on...@gm...> 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. :)

Ok, will do.

> > 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.

I just woke up, first email for the day.  Not quite grasping why this
will be any different between edje Lua API and random host app Lua API.
They still both gotta be threadsafe when we thread things.  Random host
app, being an EFL app, would have to be threadsafe if EFL is threaded.

The Host API stuff will go through the edje Lua API to do it's thing,
and the edje Lua API will have to be made threadsafe, so any other
thread issues will be the host apps plobrem.  Just like apps using
the rest of EFL.

Hell, the projects I'm working on now that need this host API stuff have
to be threadsafe anyway.  One of the design goals is to be able to run
thousands of scripts at once safely and quickly, while the rest of the
world code is busy chugging along.  That's why I'll be experimenting
with luaproc ansd LuaJIT.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.