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

[David Seikel]

On Wed, 13 Feb 2013 18:18:35 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Wed, 13 Feb 2013 18:18:24 +1000 David Seikel 
> said:
> 
> > On Wed, 13 Feb 2013 16:14:08 +0900 Carsten Haitzler (The Rasterman)
> >  wrote:
> > 
> > > On Sun, 3 Feb 2013 13:34:35 +1000 David Seikel 
> > > said:
> > > 
> > > > One year later ...
> > > > 
> > > > On Wed, 18 Jan 2012 21:26:55 +1000 David Seikel
> > > >  wrote:
> > > > 
> > > > > On Wed, 18 Jan 2012 18:36:21 +0900 Carsten Haitzler (The
> > > > > Rasterman)  wrote:
> > > > > 
> > > > > > get onto irc and i'll explain... i feel i'm repeating
> > > > > > myself.
> > > > > 
> > > > > After repeating ourselves on IRC once more, we came up with a
> > > > > workable plan that might make everyone happy.
> > > > > 
> > > > > 
> > > > > First step is to write edje functions for generically
> > > > > bundling up one or more Lua tables into a message, sending
> > > > > that message, then unpacking it again. This will be able to
> > > > > be done from edje, from C, and from Lua directly. Perhaps
> > > > > adding that as one more edje messege type.  This is for
> > > > > sending Lua tables between threads.  A later addition will be
> > > > > to send them through the 'net, probably as eet.
> > > > > 
> > > > > Host apps can register arbitrary functions with edje Lua,
> > > > > using a more generic version of the code I already wrote for
> > > > > letting edje register lua functions.  These host functions
> > > > > are by default not thread safe. Edje puts a wrapper function
> > > > > around the host app, and registers that wrapper function with
> > > > > Lua.  The wrapper function, when called from Lua, does this -
> > > > > 
> > > > > ecore_thread_main_loop_begin();
> > > > > call the host app callback();
> > > > > ecore_thread_main_loop_end();
> > > > > 
> > > > > The first alternative, which the host app must request, is
> > > > > for the wrapper function to use the table message functions
> > > > > to marshal the arguments, send it to the main thread, wait
> > > > > for the response (or do something else), then unmarshal the
> > > > > result before sending it back to Lua.
> > > > > 
> > > > > The second alternative, which the host app must REALLY
> > > > > request, is for the host app to say "I'm REALLY going out of
> > > > > my way to be threadsafe, just call me direct".  No edje
> > > > > wrapper function, BUT the host app still has to use edje to
> > > > > register this function.
> > > > > 
> > > > > The first two might be done this way -
> > > > > 
> > > > > host_cb = edje_lua2_functions_add(...);
> > > > > edje_lua2_function_marshal_set(host_cb, function);
> > > > > 
> > > > > The last one could be -
> > > > > 
> > > > > host_cb = edje_lua2_threadsafe_function_add(...);
> > > > > 
> > > > > Note the difference between _functions_ and _function_.  The
> > > > > first call registers an entire metatable full of functions,
> > > > > in the same way that edje does for it's functions.  These are
> > > > > the default sort of functions.  The second call references
> > > > > one of those previously registered functions, and makes it
> > > > > marshal arguments and results.  The third one registers a
> > > > > single function, but it could be added to an existing
> > > > > metatable registered by the first function.
> > > > > 
> > > > > Comments?
> > > > 
> > > > No one actually commented on this.  I suspect that most don't
> > > > care, and those that care figured raster and I had discussed it
> > > > to death and came up with the right solution.
> > > > 
> > > > Right now is time for me to consider starting to implement this.
> > > > I'm looking at the design of the next step in my virtual world
> > > > projects, and I think this will come in handy.  That's why I was
> > > > thinking about doing it before.  Now it's time to put my money
> > > > where my mouth is.
> > > > 
> > > > I'll think about it some more, with respect to the virtual world
> > > > stuff I want to implement now, and that I have already done.
> > > > See if it still fits into my plans, and how to actually go
> > > > about it all.  Then I'll report here and get stuck into more
> > > > Edje Lua code writing.
> > > > 
> > > > > BTW, since in my current project I'll be writing code to use
> > > > > luaproc for threading thousands of Lua scripts using worker
> > > > > threads and a queue, I can probably incorporate that into edje
> > > > > Lua to begin with.
> > > > 
> > > > This part has been done in that project I mentioned.  What I
> > > > actually ended up doing was to basically port luaproc to EFL.
> > > > This allowed me to throw away more than two thirds of luaproc
> > > > source code.  Most of what was thrown away was just luaproc's
> > > > own implementations of stuff that EFL implemented anyway.  The
> > > > rest was simplifying luaproc for my use case.
> > > > 
> > > > If I remember correctly, Raster wanted to thread more parts of
> > > > Edje.  I might be able to bring this work into Edje Lua such
>

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

[The Rasterman]

On Wed, 13 Feb 2013 18:18:24 +1000 David Seikel  said:

> On Wed, 13 Feb 2013 16:14:08 +0900 Carsten Haitzler (The Rasterman)
>  wrote:
> 
> > On Sun, 3 Feb 2013 13:34:35 +1000 David Seikel 
> > said:
> > 
> > > One year later ...
> > > 
> > > On Wed, 18 Jan 2012 21:26:55 +1000 David Seikel 
> > > wrote:
> > > 
> > > > On Wed, 18 Jan 2012 18:36:21 +0900 Carsten Haitzler (The
> > > > Rasterman)  wrote:
> > > > 
> > > > > get onto irc and i'll explain... i feel i'm repeating myself.
> > > > 
> > > > After repeating ourselves on IRC once more, we came up with a
> > > > workable plan that might make everyone happy.
> > > > 
> > > > 
> > > > First step is to write edje functions for generically bundling up
> > > > one or more Lua tables into a message, sending that message, then
> > > > unpacking it again. This will be able to be done from edje, from
> > > > C, and from Lua directly. Perhaps adding that as one more edje
> > > > messege type.  This is for sending Lua tables between threads.  A
> > > > later addition will be to send them through the 'net, probably as
> > > > eet.
> > > > 
> > > > Host apps can register arbitrary functions with edje Lua, using a
> > > > more generic version of the code I already wrote for letting edje
> > > > register lua functions.  These host functions are by default not
> > > > thread safe. Edje puts a wrapper function around the host app,
> > > > and registers that wrapper function with Lua.  The wrapper
> > > > function, when called from Lua, does this -
> > > > 
> > > > ecore_thread_main_loop_begin();
> > > > call the host app callback();
> > > > ecore_thread_main_loop_end();
> > > > 
> > > > The first alternative, which the host app must request, is for the
> > > > wrapper function to use the table message functions to marshal the
> > > > arguments, send it to the main thread, wait for the response (or
> > > > do something else), then unmarshal the result before sending it
> > > > back to Lua.
> > > > 
> > > > The second alternative, which the host app must REALLY request,
> > > > is for the host app to say "I'm REALLY going out of my way to be
> > > > threadsafe, just call me direct".  No edje wrapper function, BUT
> > > > the host app still has to use edje to register this function.
> > > > 
> > > > The first two might be done this way -
> > > > 
> > > > host_cb = edje_lua2_functions_add(...);
> > > > edje_lua2_function_marshal_set(host_cb, function);
> > > > 
> > > > The last one could be -
> > > > 
> > > > host_cb = edje_lua2_threadsafe_function_add(...);
> > > > 
> > > > Note the difference between _functions_ and _function_.  The first
> > > > call registers an entire metatable full of functions, in the same
> > > > way that edje does for it's functions.  These are the default
> > > > sort of functions.  The second call references one of those
> > > > previously registered functions, and makes it marshal arguments
> > > > and results.  The third one registers a single function, but it
> > > > could be added to an existing metatable registered by the first
> > > > function.
> > > > 
> > > > Comments?
> > > 
> > > No one actually commented on this.  I suspect that most don't care,
> > > and those that care figured raster and I had discussed it to death
> > > and came up with the right solution.
> > > 
> > > Right now is time for me to consider starting to implement this.
> > > I'm looking at the design of the next step in my virtual world
> > > projects, and I think this will come in handy.  That's why I was
> > > thinking about doing it before.  Now it's time to put my money
> > > where my mouth is.
> > > 
> > > I'll think about it some more, with respect to the virtual world
> > > stuff I want to implement now, and that I have already done.  See
> > > if it still fits into my plans, and how to actually go about it
> > > all.  Then I'll report here and get stuck into more Edje Lua code
> > > writing.
> > > 
> > > > BTW, since in my current project I'll be writing code to use
> > > > luaproc for threading thousands of Lua scripts using worker
> > > > threads and a queue, I can probably incorporate that into edje
> > > > Lua to begin with.
> > > 
> > > This part has been done in that project I mentioned.  What I
> > > actually ended up doing was to basically port luaproc to EFL.  This
> > > allowed me to throw away more than two thirds of luaproc source
> > > code.  Most of what was thrown away was just luaproc's own
> > > implementations of stuff that EFL implemented anyway.  The rest was
> > > simplifying luaproc for my use case.
> > > 
> > > If I remember correctly, Raster wanted to thread more parts of
> > > Edje.  I might be able to bring this work into Edje Lua such that
> > > the Edje Lua scripts are threaded in a worker queue.  When combined
> > > with the above table marshalling additions, plus using a few more
> > > things that have been added to EFL, I suspect I can get half of the
> > > remaining code to vanish as well.  It's not a lot of code now, 15
> > > K

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

[David Seikel]

On Wed, 13 Feb 2013 16:14:08 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Sun, 3 Feb 2013 13:34:35 +1000 David Seikel 
> said:
> 
> > One year later ...
> > 
> > On Wed, 18 Jan 2012 21:26:55 +1000 David Seikel 
> > wrote:
> > 
> > > On Wed, 18 Jan 2012 18:36:21 +0900 Carsten Haitzler (The
> > > Rasterman)  wrote:
> > > 
> > > > get onto irc and i'll explain... i feel i'm repeating myself.
> > > 
> > > After repeating ourselves on IRC once more, we came up with a
> > > workable plan that might make everyone happy.
> > > 
> > > 
> > > First step is to write edje functions for generically bundling up
> > > one or more Lua tables into a message, sending that message, then
> > > unpacking it again. This will be able to be done from edje, from
> > > C, and from Lua directly. Perhaps adding that as one more edje
> > > messege type.  This is for sending Lua tables between threads.  A
> > > later addition will be to send them through the 'net, probably as
> > > eet.
> > > 
> > > Host apps can register arbitrary functions with edje Lua, using a
> > > more generic version of the code I already wrote for letting edje
> > > register lua functions.  These host functions are by default not
> > > thread safe. Edje puts a wrapper function around the host app,
> > > and registers that wrapper function with Lua.  The wrapper
> > > function, when called from Lua, does this -
> > > 
> > > ecore_thread_main_loop_begin();
> > > call the host app callback();
> > > ecore_thread_main_loop_end();
> > > 
> > > The first alternative, which the host app must request, is for the
> > > wrapper function to use the table message functions to marshal the
> > > arguments, send it to the main thread, wait for the response (or
> > > do something else), then unmarshal the result before sending it
> > > back to Lua.
> > > 
> > > The second alternative, which the host app must REALLY request,
> > > is for the host app to say "I'm REALLY going out of my way to be
> > > threadsafe, just call me direct".  No edje wrapper function, BUT
> > > the host app still has to use edje to register this function.
> > > 
> > > The first two might be done this way -
> > > 
> > > host_cb = edje_lua2_functions_add(...);
> > > edje_lua2_function_marshal_set(host_cb, function);
> > > 
> > > The last one could be -
> > > 
> > > host_cb = edje_lua2_threadsafe_function_add(...);
> > > 
> > > Note the difference between _functions_ and _function_.  The first
> > > call registers an entire metatable full of functions, in the same
> > > way that edje does for it's functions.  These are the default
> > > sort of functions.  The second call references one of those
> > > previously registered functions, and makes it marshal arguments
> > > and results.  The third one registers a single function, but it
> > > could be added to an existing metatable registered by the first
> > > function.
> > > 
> > > Comments?
> > 
> > No one actually commented on this.  I suspect that most don't care,
> > and those that care figured raster and I had discussed it to death
> > and came up with the right solution.
> > 
> > Right now is time for me to consider starting to implement this.
> > I'm looking at the design of the next step in my virtual world
> > projects, and I think this will come in handy.  That's why I was
> > thinking about doing it before.  Now it's time to put my money
> > where my mouth is.
> > 
> > I'll think about it some more, with respect to the virtual world
> > stuff I want to implement now, and that I have already done.  See
> > if it still fits into my plans, and how to actually go about it
> > all.  Then I'll report here and get stuck into more Edje Lua code
> > writing.
> > 
> > > BTW, since in my current project I'll be writing code to use
> > > luaproc for threading thousands of Lua scripts using worker
> > > threads and a queue, I can probably incorporate that into edje
> > > Lua to begin with.
> > 
> > This part has been done in that project I mentioned.  What I
> > actually ended up doing was to basically port luaproc to EFL.  This
> > allowed me to throw away more than two thirds of luaproc source
> > code.  Most of what was thrown away was just luaproc's own
> > implementations of stuff that EFL implemented anyway.  The rest was
> > simplifying luaproc for my use case.
> > 
> > If I remember correctly, Raster wanted to thread more parts of
> > Edje.  I might be able to bring this work into Edje Lua such that
> > the Edje Lua scripts are threaded in a worker queue.  When combined
> > with the above table marshalling additions, plus using a few more
> > things that have been added to EFL, I suspect I can get half of the
> > remaining code to vanish as well.  It's not a lot of code now, 15
> > KB.
> > 
> > To top it all off, I'll likely be bringing my LuaJIT work to Edje
> > Lua as well.  Not sure yet how to go about that, but I think it
> > would be preferable to have that as a compile time option.  If
> > LuaJIT is available, compile for it, otherwise co

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

[The Rasterman]

On Sun, 3 Feb 2013 13:34:35 +1000 David Seikel  said:

> One year later ...
> 
> On Wed, 18 Jan 2012 21:26:55 +1000 David Seikel 
> wrote:
> 
> > On Wed, 18 Jan 2012 18:36:21 +0900 Carsten Haitzler (The Rasterman)
> >  wrote:
> > 
> > > get onto irc and i'll explain... i feel i'm repeating myself.
> > 
> > After repeating ourselves on IRC once more, we came up with a workable
> > plan that might make everyone happy.
> > 
> > 
> > First step is to write edje functions for generically bundling up one
> > or more Lua tables into a message, sending that message, then
> > unpacking it again. This will be able to be done from edje, from C,
> > and from Lua directly. Perhaps adding that as one more edje messege
> > type.  This is for sending Lua tables between threads.  A later
> > addition will be to send them through the 'net, probably as eet.
> > 
> > Host apps can register arbitrary functions with edje Lua, using a more
> > generic version of the code I already wrote for letting edje register
> > lua functions.  These host functions are by default not thread safe.
> > Edje puts a wrapper function around the host app, and registers that
> > wrapper function with Lua.  The wrapper function, when called from
> > Lua, does this -
> > 
> > ecore_thread_main_loop_begin();
> > call the host app callback();
> > ecore_thread_main_loop_end();
> > 
> > The first alternative, which the host app must request, is for the
> > wrapper function to use the table message functions to marshal the
> > arguments, send it to the main thread, wait for the response (or do
> > something else), then unmarshal the result before sending it back to
> > Lua.
> > 
> > The second alternative, which the host app must REALLY request, is for
> > the host app to say "I'm REALLY going out of my way to be threadsafe,
> > just call me direct".  No edje wrapper function, BUT the host app
> > still has to use edje to register this function.
> > 
> > The first two might be done this way -
> > 
> > host_cb = edje_lua2_functions_add(...);
> > edje_lua2_function_marshal_set(host_cb, function);
> > 
> > The last one could be -
> > 
> > host_cb = edje_lua2_threadsafe_function_add(...);
> > 
> > Note the difference between _functions_ and _function_.  The first
> > call registers an entire metatable full of functions, in the same way
> > that edje does for it's functions.  These are the default sort of
> > functions.  The second call references one of those previously
> > registered functions, and makes it marshal arguments and results.  The
> > third one registers a single function, but it could be added to an
> > existing metatable registered by the first function.
> > 
> > Comments?
> 
> No one actually commented on this.  I suspect that most don't care, and
> those that care figured raster and I had discussed it to death and came
> up with the right solution.
> 
> Right now is time for me to consider starting to implement this.  I'm
> looking at the design of the next step in my virtual world projects,
> and I think this will come in handy.  That's why I was thinking about
> doing it before.  Now it's time to put my money where my mouth is.
> 
> I'll think about it some more, with respect to the virtual world stuff I
> want to implement now, and that I have already done.  See if it still
> fits into my plans, and how to actually go about it all.  Then I'll
> report here and get stuck into more Edje Lua code writing.
> 
> > BTW, since in my current project I'll be writing code to use luaproc
> > for threading thousands of Lua scripts using worker threads and a
> > queue, I can probably incorporate that into edje Lua to begin with.
> 
> This part has been done in that project I mentioned.  What I actually
> ended up doing was to basically port luaproc to EFL.  This allowed me
> to throw away more than two thirds of luaproc source code.  Most of what
> was thrown away was just luaproc's own implementations of stuff that EFL
> implemented anyway.  The rest was simplifying luaproc for my use case.
> 
> If I remember correctly, Raster wanted to thread more parts of
> Edje.  I might be able to bring this work into Edje Lua such that the
> Edje Lua scripts are threaded in a worker queue.  When combined with
> the above table marshalling additions, plus using a few more things that
> have been added to EFL, I suspect I can get half of the remaining code
> to vanish as well.  It's not a lot of code now, 15 KB.
> 
> To top it all off, I'll likely be bringing my LuaJIT work to Edje Lua
> as well.  Not sure yet how to go about that, but I think it would be
> preferable to have that as a compile time option.  If LuaJIT is
> available, compile for it, otherwise compile for ordinary LUa.  See my
> notes elsewhere for how much SPED LuaJIT brings.  B-)

i like the idea of luajit. like.

as for thready stuff - i'd like to see the lua stuff divorced of specifically
having to be synchronous with respect to the app - thus the bundle tables up
as ipc to me seems the best 

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

[David Seikel]

On Sun, 8 Jan 2012 19:54:19 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Sun, 8 Jan 2012 19:35:01 +1000 David Seikel 
> said:
> 
> > Do we want to return the library version?
> > 
> > PACKAGE_VERSION?
> > 
> > edje_version?
> > 
> > EDJE_VERSION_MAJOR and EDJE_VERSION_MINOR?
> > 
> > EDJE_FILE_VERSION and EDJE_FILE_MINOR? Should those be bumped to
> > track Lua API changes to?
> > 
> > Something new like EDJE_EXTERNAL_TYPE_ABI_VERSION?  
> 
> probably a table with 2 numbers - major and minor version. no micro.
> 
> > And what about Lua version while we are at it?  I think access to
> > that was only introduced in Lua 5.2, and we already decided to not
> > go there.
> 
> no need - i suspect we will stick to 5.1 for a long time :)

Um, we ended up supporting Lua 5.2 anyway.  5.1 is still what we
recommend though.  LuaJIT is basically 5.1 with some of the 5.2
extensions, but done as a 5.1 compatible thing.

-- 
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
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

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

[David Seikel]

One year later ...

On Wed, 18 Jan 2012 21:26:55 +1000 David Seikel 
wrote:

> On Wed, 18 Jan 2012 18:36:21 +0900 Carsten Haitzler (The Rasterman)
>  wrote:
> 
> > get onto irc and i'll explain... i feel i'm repeating myself.
> 
> After repeating ourselves on IRC once more, we came up with a workable
> plan that might make everyone happy.
> 
> 
> First step is to write edje functions for generically bundling up one
> or more Lua tables into a message, sending that message, then
> unpacking it again. This will be able to be done from edje, from C,
> and from Lua directly. Perhaps adding that as one more edje messege
> type.  This is for sending Lua tables between threads.  A later
> addition will be to send them through the 'net, probably as eet.
> 
> Host apps can register arbitrary functions with edje Lua, using a more
> generic version of the code I already wrote for letting edje register
> lua functions.  These host functions are by default not thread safe.
> Edje puts a wrapper function around the host app, and registers that
> wrapper function with Lua.  The wrapper function, when called from
> Lua, does this -
> 
> ecore_thread_main_loop_begin();
> call the host app callback();
> ecore_thread_main_loop_end();
> 
> The first alternative, which the host app must request, is for the
> wrapper function to use the table message functions to marshal the
> arguments, send it to the main thread, wait for the response (or do
> something else), then unmarshal the result before sending it back to
> Lua.
> 
> The second alternative, which the host app must REALLY request, is for
> the host app to say "I'm REALLY going out of my way to be threadsafe,
> just call me direct".  No edje wrapper function, BUT the host app
> still has to use edje to register this function.
> 
> The first two might be done this way -
> 
> host_cb = edje_lua2_functions_add(...);
> edje_lua2_function_marshal_set(host_cb, function);
> 
> The last one could be -
> 
> host_cb = edje_lua2_threadsafe_function_add(...);
> 
> Note the difference between _functions_ and _function_.  The first
> call registers an entire metatable full of functions, in the same way
> that edje does for it's functions.  These are the default sort of
> functions.  The second call references one of those previously
> registered functions, and makes it marshal arguments and results.  The
> third one registers a single function, but it could be added to an
> existing metatable registered by the first function.
> 
> Comments?

No one actually commented on this.  I suspect that most don't care, and
those that care figured raster and I had discussed it to death and came
up with the right solution.

Right now is time for me to consider starting to implement this.  I'm
looking at the design of the next step in my virtual world projects,
and I think this will come in handy.  That's why I was thinking about
doing it before.  Now it's time to put my money where my mouth is.

I'll think about it some more, with respect to the virtual world stuff I
want to implement now, and that I have already done.  See if it still
fits into my plans, and how to actually go about it all.  Then I'll
report here and get stuck into more Edje Lua code writing.

> BTW, since in my current project I'll be writing code to use luaproc
> for threading thousands of Lua scripts using worker threads and a
> queue, I can probably incorporate that into edje Lua to begin with.

This part has been done in that project I mentioned.  What I actually
ended up doing was to basically port luaproc to EFL.  This allowed me
to throw away more than two thirds of luaproc source code.  Most of what
was thrown away was just luaproc's own implementations of stuff that EFL
implemented anyway.  The rest was simplifying luaproc for my use case.

If I remember correctly, Raster wanted to thread more parts of
Edje.  I might be able to bring this work into Edje Lua such that the
Edje Lua scripts are threaded in a worker queue.  When combined with
the above table marshalling additions, plus using a few more things that
have been added to EFL, I suspect I can get half of the remaining code
to vanish as well.  It's not a lot of code now, 15 KB.

To top it all off, I'll likely be bringing my LuaJIT work to Edje Lua
as well.  Not sure yet how to go about that, but I think it would be
preferable to have that as a compile time option.  If LuaJIT is
available, compile for it, otherwise compile for ordinary LUa.  See my
notes elsewhere for how much SPED LuaJIT brings.  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
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan___
enlightenment-devel mail

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

[David Seikel]

On Wed, 18 Jan 2012 18:36:21 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> get onto irc and i'll explain... i feel i'm repeating myself.

After repeating ourselves on IRC once more, we came up with a workable
plan that might make everyone happy.


First step is to write edje functions for generically bundling up one
or more Lua tables into a message, sending that message, then unpacking
it again. This will be able to be done from edje, from C, and from Lua
directly. Perhaps adding that as one more edje messege type.  This is
for sending Lua tables between threads.  A later addition will be to
send them through the 'net, probably as eet.

Host apps can register arbitrary functions with edje Lua, using a more
generic version of the code I already wrote for letting edje register
lua functions.  These host functions are by default not thread safe.
Edje puts a wrapper function around the host app, and registers that
wrapper function with Lua.  The wrapper function, when called from Lua,
does this -

ecore_thread_main_loop_begin();
call the host app callback();
ecore_thread_main_loop_end();

The first alternative, which the host app must request, is for the
wrapper function to use the table message functions to marshal the
arguments, send it to the main thread, wait for the response (or do
something else), then unmarshal the result before sending it back to
Lua.

The second alternative, which the host app must REALLY request, is for
the host app to say "I'm REALLY going out of my way to be threadsafe,
just call me direct".  No edje wrapper function, BUT the host app still
has to use edje to register this function.

The first two might be done this way -

host_cb = edje_lua2_functions_add(...);
edje_lua2_function_marshal_set(host_cb, function);

The last one could be -

host_cb = edje_lua2_threadsafe_function_add(...);

Note the difference between _functions_ and _function_.  The first call
registers an entire metatable full of functions, in the same way that
edje does for it's functions.  These are the default sort of
functions.  The second call references one of those previously
registered functions, and makes it marshal arguments and results.  The
third one registers a single function, but it could be added to an
existing metatable registered by the first function.

Comments?


BTW, since in my current project I'll be writing code to use luaproc for
threading thousands of Lua scripts using worker threads and a queue, I
can probably incorporate that into edje Lua to begin with.

-- 
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
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

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

[The Rasterman]

On Wed, 18 Jan 2012 19:04:06 +1000 David Seikel  said:

> Why does edje have to call the host callback from the thread when it's
> perfectly capable of calling other callbacks from the main thread?

to do that you have to marshall params and returns to the mainloop FROM the
thread from lua and back again with a synchronous messaging mechanism. i
mentioned that before. :)

> > > > > I'd still want an additional ability to register a type 1)
> > > > > function to just call back on the same thread.  It would come
> > > > > with lots of documented warnings that it will screw things up
> > > > > in mysterious ways if used the wrong way, but then so does a
> > > > > lot of EFL. With power comes responsibility.
> > > > 
> > > > i really don't like this as it is unknown if it is called form a
> > > > thread or not (depends on edje version).
> > > 
> > > This is for the case where IT DOES NOT MATTER if it's called from a
> > > thread or not.  Such cases do exist, and they are far more
> > > efficient to
> > 
> > it absolutely matters 100%. it is irrelevant how many functions u
> > sandwich between app and lua - if they are called on the thread's
> > stack in the thread context, then that is bad. your proposal means
> > that we cannot thread edje's internals, or we have to make threaded
> > and non-threaded codepaths (more maintenance and bugs) and thus force
> > all edje objects with lua that u register exposed funcs to to never
> > run in a thread - thsu complexity.
> 
> In this one case, which you seem to have forgotten, it does not matter,
> coz it's a thread safe function anyway.  In this case we are dealing
> ONLY with a structure in the Lua state which is running in this same
> thread, or dealing with structures that are only dealt with in this
> same thread, or the thing is thread aware anyway and does the right
> thing (probably coz it's doing it's own threaded stuff). In this one
> case, doing things your way means that we suddenly complicate things by
> calling them from some other thread, which is what you are arguing
> against.

get onto irc and i'll explain... i feel i'm repeating myself.

> > > We provide enough protection for the Lua programmers, it's the C
> > > programmers that are registering these callbacks, they know how
> > > dangerous their language is and deal with it all the time.
> > 
> > no callbacks in any of efl (except the ecore_thread functions that
> > are run in a thread or the elm_store func that is run in a thread
> > very specifically) are called from a thread. it is a guarantee that
> > efl has. in fact from that thread u couldn't call any edje or evas
> > calls as they are not threadsafe. every other callback in efl is safe
> > in this regard (except for the very specific exceptions above because
> > both are very specifically designed to be in threads, but the
> > function exposing you propose are not specifically threaded).
> 
> So, what about the callbacks to Lua?  When the Lua is running in some
> thread coz we threaded edje, but edje calls it's resize function in a
> different thread?

edje wont. edje will turn it into a message. it's perfectly allowed to do this
internally. there is no requirement for them to be in the same thread.

> > > > > > this of course will add overhead to this. async messages are
> > > > > > much more desirable as they allow both sides to not block. :)
> > > > > 
> > > > > ONLY using messages is very undesirable from my point of view.
> > > > > I've seen the mess they can do when just a simple function call
> > > > > is needed. Messages have their uses, so do function calls.  I
> > > > > want me cake and eat it to.  lol
> > > > 
> > > > but messages provide the best abstraction for also allowing
> > > > efficiency and 2-way communication.
> > > 
> > > Message passing is not more efficient than direct function calls.
> > > Sometimes you need those direct function calls.
> > 
> > its LESS efficient, especially if you do it synchronously between 2
> > threads.
> 
> Sending a message has the overhead of at least two function calls,
> four if you want information to come back.  How is that more efficient
> than one function call?

messaging is less efficient than a direct call... but it SCALES. BUT it allows
for us to thread edje. not doing messaging means we are stuck with lua running
in the mainloop and i don't like that. we are paining ourselves into a corner
because of laziness with doing messages.

> I'm working on something right now that will involve Lua scripts
> running on separate threads, that will need to communicate to stuff
> running on other threads, and also just call functions on the same
> thread.  I'll have to figure out all the issues for this project
> anyway.  It uses eina for data structures, atd uses edje Lua only for a
> test harness.  The threaded Lua scripts in this project are not using
> edje.
> 
> This current project does lead into the one where I want to use this
> functionality.  It's the server side, so it already has t

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

[David Seikel]

On Wed, 18 Jan 2012 17:04:22 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Wed, 18 Jan 2012 15:47:43 +1000 David Seikel 
> said:
> 
> > On Wed, 18 Jan 2012 11:30:55 +0900 Carsten Haitzler (The Rasterman)
> >  wrote:
> > 
> > > On Mon, 9 Jan 2012 00:18:38 +1000 David Seikel 
> > > said:
> > > 
> > > > On Sun, 8 Jan 2012 22:10:45 +0900 Carsten Haitzler (The
> > > > Rasterman)  wrote:
> > > > 
> > > > > On Sun, 8 Jan 2012 21:46:29 +1000 David Seikel
> > > > >  said:
> > > > > 
> > 
> >  
> > > > > because all the other callbacks come from code controlled by
> > > > > efl. lua funcs come from code (script - lua) not controlled
> > > > > by efl.
> > > > 
> > > > The host app callbacks would be setup by edje Lua on behalf of
> > > > the host app (that was always my intention).  So the edje Lua
> > > > can register a wrapper function that it controls.  Lua calls the
> > > > wrapper function, which lets edje Lua decide what to do.  So it
> > > > becomes just like the other EFL callbacks, EFL is in control.
> > > 
> > > yes - BUT it's called FROM a thread because LUA calls the
> > > registered func. it has to be marshaled back to the main loop in
> > > a synchronous way.
> > 
> > LUA calls the registered function that is registered by edje, not
> > the one registered by the host app.  Edje then calls the host apps
> > callback.  Exactly the same as any other callback in EFL.  It's no
> > different.
> 
> yes - i know... and edje then calls the func registered by app and
> THUS its inside the thread that lua is running in. its VERY VERY VERY
> VERY different. the function is being called FROM a thread... and
> that means all child funcs are in that thread's context, on that
> threads stack.

Why does edje have to call the host callback from the thread when it's
perfectly capable of calling other callbacks from the main thread?

> > > > I'd still want an additional ability to register a type 1)
> > > > function to just call back on the same thread.  It would come
> > > > with lots of documented warnings that it will screw things up
> > > > in mysterious ways if used the wrong way, but then so does a
> > > > lot of EFL. With power comes responsibility.
> > > 
> > > i really don't like this as it is unknown if it is called form a
> > > thread or not (depends on edje version).
> > 
> > This is for the case where IT DOES NOT MATTER if it's called from a
> > thread or not.  Such cases do exist, and they are far more
> > efficient to
> 
> it absolutely matters 100%. it is irrelevant how many functions u
> sandwich between app and lua - if they are called on the thread's
> stack in the thread context, then that is bad. your proposal means
> that we cannot thread edje's internals, or we have to make threaded
> and non-threaded codepaths (more maintenance and bugs) and thus force
> all edje objects with lua that u register exposed funcs to to never
> run in a thread - thsu complexity.

In this one case, which you seem to have forgotten, it does not matter,
coz it's a thread safe function anyway.  In this case we are dealing
ONLY with a structure in the Lua state which is running in this same
thread, or dealing with structures that are only dealt with in this
same thread, or the thing is thread aware anyway and does the right
thing (probably coz it's doing it's own threaded stuff). In this one
case, doing things your way means that we suddenly complicate things by
calling them from some other thread, which is what you are arguing
against.

> > We provide enough protection for the Lua programmers, it's the C
> > programmers that are registering these callbacks, they know how
> > dangerous their language is and deal with it all the time.
> 
> no callbacks in any of efl (except the ecore_thread functions that
> are run in a thread or the elm_store func that is run in a thread
> very specifically) are called from a thread. it is a guarantee that
> efl has. in fact from that thread u couldn't call any edje or evas
> calls as they are not threadsafe. every other callback in efl is safe
> in this regard (except for the very specific exceptions above because
> both are very specifically designed to be in threads, but the
> function exposing you propose are not specifically threaded).

So, what about the callbacks to Lua?  When the Lua is running in some
thread coz we threaded edje, but edje calls it's resize function in a
different thread?

> > > > > this of course will add overhead to this. async messages are
> > > > > much more desirable as they allow both sides to not block. :)
> > > > 
> > > > ONLY using messages is very undesirable from my point of view.
> > > > I've seen the mess they can do when just a simple function call
> > > > is needed. Messages have their uses, so do function calls.  I
> > > > want me cake and eat it to.  lol
> > > 
> > > but messages provide the best abstraction for also allowing
> > > efficiency and 2-way communication.
> > 
> > Message passing is not more efficient than direct function calls.
> >

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

[The Rasterman]

On Wed, 18 Jan 2012 15:47:43 +1000 David Seikel  said:

> On Wed, 18 Jan 2012 11:30:55 +0900 Carsten Haitzler (The Rasterman)
>  wrote:
> 
> > On Mon, 9 Jan 2012 00:18:38 +1000 David Seikel 
> > said:
> > 
> > > On Sun, 8 Jan 2012 22:10:45 +0900 Carsten Haitzler (The Rasterman)
> > >  wrote:
> > > 
> > > > On Sun, 8 Jan 2012 21:46:29 +1000 David Seikel 
> > > > said:
> > > > 
> 
>  
> > > > because all the other callbacks come from code controlled by efl.
> > > > lua funcs come from code (script - lua) not controlled by efl.
> > > 
> > > The host app callbacks would be setup by edje Lua on behalf of the
> > > host app (that was always my intention).  So the edje Lua can
> > > register a wrapper function that it controls.  Lua calls the
> > > wrapper function, which lets edje Lua decide what to do.  So it
> > > becomes just like the other EFL callbacks, EFL is in control.
> > 
> > yes - BUT it's called FROM a thread because LUA calls the registered
> > func. it has to be marshaled back to the main loop in a synchronous
> > way.
> 
> LUA calls the registered function that is registered by edje, not the
> one registered by the host app.  Edje then calls the host apps
> callback.  Exactly the same as any other callback in EFL.  It's no
> different.

yes - i know... and edje then calls the func registered by app and THUS its
inside the thread that lua is running in. its VERY VERY VERY VERY different.
the function is being called FROM a thread... and that means all child funcs
are in that thread's context, on that threads stack.

> > > I'd still want an additional ability to register a type 1) function
> > > to just call back on the same thread.  It would come with lots of
> > > documented warnings that it will screw things up in mysterious ways
> > > if used the wrong way, but then so does a lot of EFL. With power
> > > comes responsibility.
> > 
> > i really don't like this as it is unknown if it is called form a
> > thread or not (depends on edje version).
> 
> This is for the case where IT DOES NOT MATTER if it's called from a
> thread or not.  Such cases do exist, and they are far more efficient to

it absolutely matters 100%. it is irrelevant how many functions u sandwich
between app and lua - if they are called on the thread's stack in the thread
context, then that is bad. your proposal means that we cannot thread edje's
internals, or we have to make threaded and non-threaded codepaths (more
maintenance and bugs) and thus force all edje objects with lua that u register
exposed funcs to to never run in a thread - thsu complexity.

> just call the function direct.  It comes with a big warning, and if
> it's not used right, then the programmer gets spanked.  We can't
> protect programmers from all their foolishness.  I don't think we
> should straight jacket them for their own protection.

we can't just start making magic function callbacks that may or may not be
called from threads - it breeds inconsistency in the api and it is a very core
feature that you want here.

> We provide enough protection for the Lua programmers, it's the C
> programmers that are registering these callbacks, they know how
> dangerous their language is and deal with it all the time.

no callbacks in any of efl (except the ecore_thread functions that are run in a
thread or the elm_store func that is run in a thread very specifically) are
called from a thread. it is a guarantee that efl has. in fact from that thread
u couldn't call any edje or evas calls as they are not threadsafe. every other
callback in efl is safe in this regard (except for the very specific
exceptions above because both are very specifically designed to be in threads,
but the function exposing you propose are not specifically threaded).

> > > > this of course will add overhead to this. async messages are much
> > > > more desirable as they allow both sides to not block. :)
> > > 
> > > ONLY using messages is very undesirable from my point of view.  I've
> > > seen the mess they can do when just a simple function call is
> > > needed. Messages have their uses, so do function calls.  I want me
> > > cake and eat it to.  lol
> > 
> > but messages provide the best abstraction for also allowing
> > efficiency and 2-way communication.
> 
> Message passing is not more efficient than direct function calls.
> Sometimes you need those direct function calls.

its LESS efficient, especially if you do it synchronously between 2 threads.

> I program in LSL, where you have to do this sort of message passing all
> the time.  Trust me, sometimes you don't want to mess with that
> complicated shit, you just want a simple, fast function call.

but that creates a problem for edje - a big one.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive o

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

[David Seikel]

On Wed, 18 Jan 2012 11:30:55 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Mon, 9 Jan 2012 00:18:38 +1000 David Seikel 
> said:
> 
> > On Sun, 8 Jan 2012 22:10:45 +0900 Carsten Haitzler (The Rasterman)
> >  wrote:
> > 
> > > On Sun, 8 Jan 2012 21:46:29 +1000 David Seikel 
> > > said:
> > > 

 
> > > because all the other callbacks come from code controlled by efl.
> > > lua funcs come from code (script - lua) not controlled by efl.
> > 
> > The host app callbacks would be setup by edje Lua on behalf of the
> > host app (that was always my intention).  So the edje Lua can
> > register a wrapper function that it controls.  Lua calls the
> > wrapper function, which lets edje Lua decide what to do.  So it
> > becomes just like the other EFL callbacks, EFL is in control.
> 
> yes - BUT it's called FROM a thread because LUA calls the registered
> func. it has to be marshaled back to the main loop in a synchronous
> way.

LUA calls the registered function that is registered by edje, not the
one registered by the host app.  Edje then calls the host apps
callback.  Exactly the same as any other callback in EFL.  It's no
different.

> > I'd still want an additional ability to register a type 1) function
> > to just call back on the same thread.  It would come with lots of
> > documented warnings that it will screw things up in mysterious ways
> > if used the wrong way, but then so does a lot of EFL. With power
> > comes responsibility.
> 
> i really don't like this as it is unknown if it is called form a
> thread or not (depends on edje version).

This is for the case where IT DOES NOT MATTER if it's called from a
thread or not.  Such cases do exist, and they are far more efficient to
just call the function direct.  It comes with a big warning, and if
it's not used right, then the programmer gets spanked.  We can't
protect programmers from all their foolishness.  I don't think we
should straight jacket them for their own protection.

We provide enough protection for the Lua programmers, it's the C
programmers that are registering these callbacks, they know how
dangerous their language is and deal with it all the time.

> > > this of course will add overhead to this. async messages are much
> > > more desirable as they allow both sides to not block. :)
> > 
> > ONLY using messages is very undesirable from my point of view.  I've
> > seen the mess they can do when just a simple function call is
> > needed. Messages have their uses, so do function calls.  I want me
> > cake and eat it to.  lol
> 
> but messages provide the best abstraction for also allowing
> efficiency and 2-way communication.

Message passing is not more efficient than direct function calls.
Sometimes you need those direct function calls.

I program in LSL, where you have to do this sort of message passing all
the time.  Trust me, sometimes you don't want to mess with that
complicated shit, you just want a simple, fast function call.

-- 
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
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

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

[The Rasterman]

On Mon, 9 Jan 2012 00:18:38 +1000 David Seikel  said:

> On Sun, 8 Jan 2012 22:10:45 +0900 Carsten Haitzler (The Rasterman)
>  wrote:
> 
> > On Sun, 8 Jan 2012 21:46:29 +1000 David Seikel 
> > said:
> > 
> > > If I remember, edje Lua puts everything into the Lua state, with no
> > > globals.  So it should be threadsafe to start with.  If not, it will
> > > have to be made threadsafe anyway when edje goes threaded.
> > > 
> > > 1)
> > > 
> > > The host function might deal purely with some data structure that is
> > > internal to the script.  This means it's userdata (or perhaps just
> > > plain Lua data) attached to the Lua state.  This should be
> > > inherently thread safe as per 0).  This could be inefficient if
> > > dealt with via messages.
> > 
> > it still violates efl's position of always calling back to the
> > mainloop. trust me - its HORRIBLE to call back from threads. it
> > really is. don't do it.
> 
> In this particular case there is no worries, but see below.

there is if internals of edje start using threads. i'd love not to have to
maintain both a threaded and non-threaded path. this is just maintenance hell.
we have too much of this in efl as-is. if there is an internally threaded bit
of edje then the lua code will run from a thread and all functions exposed to
lua are called from that thread, and thus this is an issue.

> > because all the other callbacks come from code controlled by efl. lua
> > funcs come from code (script - lua) not controlled by efl.
> 
> The host app callbacks would be setup by edje Lua on behalf of the host
> app (that was always my intention).  So the edje Lua can register a
> wrapper function that it controls.  Lua calls the wrapper function,
> which lets edje Lua decide what to do.  So it becomes just like the
> other EFL callbacks, EFL is in control.

yes - BUT it's called FROM a thread because LUA calls the registered func. it
has to be marshaled back to the main loop in a synchronous way.

> > my problem is that by making lua extensible by functions provided
> > from the app, these functions must, by efl convention, be called from
> > the mainloop and thus you must implement them as synchronous ipc (if
> > we add threads) thus you have to marshall/unmarshall params/returns
> > down pipes. if you are going to do this you shoudl just do it all to
> > begin with that way and simply have the write/read right next to
> > eachother.
> 
> Or get the Lua call to go through EFL as I mentioned above.  That's the
> safe callback register method for most host app functions.

unless edje then ALSO marshals it back to the mainloop (which makes it a
synchronous message/reply), it is called form the thread.

> I'd still want an additional ability to register a type 1) function to
> just call back on the same thread.  It would come with lots of
> documented warnings that it will screw things up in mysterious ways if
> used the wrong way, but then so does a lot of EFL. With power comes
> responsibility.

i really don't like this as it is unknown if it is called form a thread or not
(depends on edje version).

> > this of course will add overhead to this. async messages are much more
> > desirable as they allow both sides to not block. :)
> 
> ONLY using messages is very undesirable from my point of view.  I've
> seen the mess they can do when just a simple function call is needed.
> Messages have their uses, so do function calls.  I want me cake and eat
> it to.  lol

but messages provide the best abstraction for also allowing efficiency and
2-way communication.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

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

[David Seikel]

On Sun, 8 Jan 2012 21:57:47 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Sun, 8 Jan 2012 21:07:43 +1000 David Seikel 
> said:
> 
> > On Sun, 8 Jan 2012 19:54:19 +0900 Carsten Haitzler (The Rasterman)
> >  wrote:
> > 
> > > On Sun, 8 Jan 2012 19:35:01 +1000 David Seikel 
> > > said:
> > > 
> > > > Do we want to return the library version?
> > > > 
> > > > PACKAGE_VERSION?
> > > > 
> > > > edje_version?
> > > > 
> > > > EDJE_VERSION_MAJOR and EDJE_VERSION_MINOR?
> > > > 
> > > > EDJE_FILE_VERSION and EDJE_FILE_MINOR? Should those be bumped to
> > > > track Lua API changes to?
> > > > 
> > > > Something new like EDJE_EXTERNAL_TYPE_ABI_VERSION?  
> > > 
> > > probably a table with 2 numbers - major and minor version. no
> > > micro.
> > 
> > Yes, but which of the above is the source of these two numbers?
> > Who's version are we actually reporting?
> 
> EDJE_VERSION_[MAJOR,MINOR]
> 

#define EDJE_VERSION_MAJOR 1
#define EDJE_VERSION_MINOR 0

Hmmm, should that minor number be 1?

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

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

[David Seikel]

On Sun, 8 Jan 2012 22:10:45 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Sun, 8 Jan 2012 21:46:29 +1000 David Seikel 
> said:
> 
> > If I remember, edje Lua puts everything into the Lua state, with no
> > globals.  So it should be threadsafe to start with.  If not, it will
> > have to be made threadsafe anyway when edje goes threaded.
> > 
> > 1)
> > 
> > The host function might deal purely with some data structure that is
> > internal to the script.  This means it's userdata (or perhaps just
> > plain Lua data) attached to the Lua state.  This should be
> > inherently thread safe as per 0).  This could be inefficient if
> > dealt with via messages.
> 
> it still violates efl's position of always calling back to the
> mainloop. trust me - its HORRIBLE to call back from threads. it
> really is. don't do it.

In this particular case there is no worries, but see below.

> > 2)
> > 
> > That userdata in 1) might involve things that happen in other
> > threads of the host app.  Then it's up to the host app to deal with
> > it's own threading problems.  Not our problem.
> 
> totally app issue.

Exactly.

> > 3)
> > 
> > The host function might deal with EFL stuff.  This is a case where
> > it would be better to have more EFL API in the edje Lua, or use
> > messages. Messages is a usual method in EFL anyway.  So what we are
> > doing already works for this case.
> 
> that's our job to make al these extra helping apis then :)

No worries.

> > 4)
> > 
> > The host function might deal with it's own internal data structures.
> > This I think is the problem you see?  If it's not a threadsafe host
> > app, then things can go horribly wrong when host functions are
> > unexpectedly called from some random edje thread.
> 
> correct.
> 
> > Wont the same problems happen when some host function EFL callback
> > is unexpectedly called from some random EFL thread?
> 
> it never is currently. adding your externally provided lua functions
> will STOP us from being able to put lua execution into a thread. it
> will always have to be inline in the mainloop and that is a big
> limitation.
> 
> messaging solves this problem.
> 
> > So the same solutions could be used.  Host API functions are really
> > just another callback system.  The host registers it's callbacks
> > with edje Lua, edje Lua calls them back.  Why is this different
> > from the rest of EFL using registered callbacks?
> 
> because all the other callbacks come from code controlled by efl. lua
> funcs come from code (script - lua) not controlled by efl.

The host app callbacks would be setup by edje Lua on behalf of the host
app (that was always my intention).  So the edje Lua can register a
wrapper function that it controls.  Lua calls the wrapper function,
which lets edje Lua decide what to do.  So it becomes just like the
other EFL callbacks, EFL is in control.

> my problem is that by making lua extensible by functions provided
> from the app, these functions must, by efl convention, be called from
> the mainloop and thus you must implement them as synchronous ipc (if
> we add threads) thus you have to marshall/unmarshall params/returns
> down pipes. if you are going to do this you shoudl just do it all to
> begin with that way and simply have the write/read right next to
> eachother.

Or get the Lua call to go through EFL as I mentioned above.  That's the
safe callback register method for most host app functions.

I'd still want an additional ability to register a type 1) function to
just call back on the same thread.  It would come with lots of
documented warnings that it will screw things up in mysterious ways if
used the wrong way, but then so does a lot of EFL. With power comes
responsibility.

> this of course will add overhead to this. async messages are much more
> desirable as they allow both sides to not block. :)

ONLY using messages is very undesirable from my point of view.  I've
seen the mess they can do when just a simple function call is needed.
Messages have their uses, so do function calls.  I want me cake and eat
it to.  lol

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

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

[The Rasterman]

On Sun, 8 Jan 2012 21:46:29 +1000 David Seikel  said:

> On Sun, 8 Jan 2012 19:52:50 +0900 Carsten Haitzler (The Rasterman)
>  wrote:
> 
> > On Sun, 8 Jan 2012 18:54:12 +1000 David Seikel 
> > said:
> > 
> > > 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.
> > 
> > incorrect. if efl is threaded host ap does not need to be threadsafe.
> > that is my point. such a requirement would be onerous and wrong as
> > the host doesnt know if edje is threaded or not. it shouldn't need to
> > know.
> > 
> > > 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.
> > 
> > thats not the issue - its that the call from lua (in edje) to host
> > app happens directly as a function call, thus is lua is running as a
> > thread, the call in host spac happens inside a thread created by
> > edje. this is unacceptable. it must be MARSHALLED back to the
> > mainloop - thus synchronous ipc calls.
> > 
> > > 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.
> > 
> > well this isnt really about your apps - but the general case - if its
> > a general api made available, then the calls TO the host app must
> > happen in the main loop context (thread) not another. all things must
> > be marshalled back to the mainloop. thus why the messaging/signal api
> > is much better here as it is a messaging api, not a call api.
> 
> I understand now, I think.
> 
> The host app itself may be multi threaded, so we do need to cater for
> this.  We also have to cater for those cases where it does not matter,
> and those cases where a messaging API is a bad choice.  We would have
> to make sure that edje Lua itself is threadsafe first.

if host app is threaded or not - all callbacks to the host should happen in the
mainloop. anything else is pretty much wrong. (very very very rare exceptions,
and this is not one as it is a general purpose communication path).

> 0)
> 
> Lua scripts themselves can be run on different threads, it all happens
> via the Lua state, which is just a pointer to everything.  luaproc is a
> system of running lots of scripts in worker threads, where each worker
> thread peels the next ready Lua script of the ready queue, runs it
> until it yields, then slaps it on the bottom of the run queue.  I'll be
> experimenting with that soon.

yes - but when lua calls back to a function provided by c - that function must
run in the mainloop (or be lock-stepped with the mainloop - abysmal performance
for doing lots of calls unbatched, same with synchronous messaging).

> If I remember, edje Lua puts everything into the Lua state, with no
> globals.  So it should be threadsafe to start with.  If not, it will
> have to be made threadsafe anyway when edje goes threaded.
> 
> 1)
> 
> The host function might deal purely with some data structure that is
> internal to the script.  This means it's userdata (or perhaps just
> plain Lua data) attached to the Lua state.  This should be inherently
> thread safe as per 0).  This could be inefficient if dealt with via
> messages.

it still violates efl's position of always calling back to the mainloop. trust
me - its HORRIBLE to call back from threads. it really is. don't do it.

> 2)
> 
> That userdata in 1) might involve things that happen in other threads
> of the host app.  Then it's up to the host app to deal with it's own
> threading problems.  Not our problem.

totally app issue.

> 3)
> 
> The host function might deal with EFL stuff.  This is a case where it
> would be better to have more EFL API in the edje Lua, or use messages.
> Messages is a usual method in EFL anyway.  So what we are doing already
> works for this case.

that's our job to make al these extra helping apis then :)

> 4)
> 
> The host function might deal with it's own internal data structures.
> This I think is the problem you see?  If it's not a threadsafe host app,
> then things can go horribly wrong when host functions are unexpectedly
> called from some random edje thread.

correct.

> Wont the same problems happen when some host function EFL callback is
> unexpectedly called from some random EFL thread?

it never is currently. adding your externally provided lua functions will STOP
us from being able to put lua execution into a thread. it will always have to
be inline in the mainloop and that is a big limit

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

[The Rasterman]

On Sun, 8 Jan 2012 21:07:43 +1000 David Seikel  said:

> On Sun, 8 Jan 2012 19:54:19 +0900 Carsten Haitzler (The Rasterman)
>  wrote:
> 
> > On Sun, 8 Jan 2012 19:35:01 +1000 David Seikel 
> > said:
> > 
> > > Do we want to return the library version?
> > > 
> > > PACKAGE_VERSION?
> > > 
> > > edje_version?
> > > 
> > > EDJE_VERSION_MAJOR and EDJE_VERSION_MINOR?
> > > 
> > > EDJE_FILE_VERSION and EDJE_FILE_MINOR? Should those be bumped to
> > > track Lua API changes to?
> > > 
> > > Something new like EDJE_EXTERNAL_TYPE_ABI_VERSION?  
> > 
> > probably a table with 2 numbers - major and minor version. no micro.
> 
> Yes, but which of the above is the source of these two numbers?  Who's
> version are we actually reporting?

EDJE_VERSION_[MAJOR,MINOR]

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

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

[Cedric BAIL]

On Sun, Jan 8, 2012 at 12:46 PM, David Seikel  wrote:
> On Sun, 8 Jan 2012 19:52:50 +0900 Carsten Haitzler (The Rasterman)
>  wrote:
>
>> On Sun, 8 Jan 2012 18:54:12 +1000 David Seikel 
>> said:
>>
>> > 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.
>>
>> incorrect. if efl is threaded host ap does not need to be threadsafe.
>> that is my point. such a requirement would be onerous and wrong as
>> the host doesnt know if edje is threaded or not. it shouldn't need to
>> know.
>>
>> > 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.
>>
>> thats not the issue - its that the call from lua (in edje) to host
>> app happens directly as a function call, thus is lua is running as a
>> thread, the call in host spac happens inside a thread created by
>> edje. this is unacceptable. it must be MARSHALLED back to the
>> mainloop - thus synchronous ipc calls.
>>
>> > 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.
>>
>> well this isnt really about your apps - but the general case - if its
>> a general api made available, then the calls TO the host app must
>> happen in the main loop context (thread) not another. all things must
>> be marshalled back to the mainloop. thus why the messaging/signal api
>> is much better here as it is a messaging api, not a call api.
>
> I understand now, I think.
>
> The host app itself may be multi threaded, so we do need to cater for
> this.  We also have to cater for those cases where it does not matter,
> and those cases where a messaging API is a bad choice.  We would have
> to make sure that edje Lua itself is threadsafe first.
>
> 0)
>
> Lua scripts themselves can be run on different threads, it all happens
> via the Lua state, which is just a pointer to everything.  luaproc is a
> system of running lots of scripts in worker threads, where each worker
> thread peels the next ready Lua script of the ready queue, runs it
> until it yields, then slaps it on the bottom of the run queue.  I'll be
> experimenting with that soon.
>
> If I remember, edje Lua puts everything into the Lua state, with no
> globals.  So it should be threadsafe to start with.  If not, it will
> have to be made threadsafe anyway when edje goes threaded.
>
> 1)
>
> The host function might deal purely with some data structure that is
> internal to the script.  This means it's userdata (or perhaps just
> plain Lua data) attached to the Lua state.  This should be inherently
> thread safe as per 0).  This could be inefficient if dealt with via
> messages.
>
> 2)
>
> That userdata in 1) might involve things that happen in other threads
> of the host app.  Then it's up to the host app to deal with it's own
> threading problems.  Not our problem.
>
> 3)
>
> The host function might deal with EFL stuff.  This is a case where it
> would be better to have more EFL API in the edje Lua, or use messages.
> Messages is a usual method in EFL anyway.  So what we are doing already
> works for this case.
>
> 4)
>
> The host function might deal with it's own internal data structures.
> This I think is the problem you see?  If it's not a threadsafe host app,
> then things can go horribly wrong when host functions are unexpectedly
> called from some random edje thread.
>
> Wont the same problems happen when some host function EFL callback is
> unexpectedly called from some random EFL thread?
>
> So the same solutions could be used.  Host API functions are really
> just another callback system.  The host registers it's callbacks with
> edje Lua, edje Lua calls them back.  Why is this different from the
> rest of EFL using registered callbacks?
>
> Only 4) is a problem, unless I've missed a use case?  Please add more
> if I did.
>
>
>
> BTW, I brought up my apps as it WILL be dealing with thread issues.  So
> it might make for a good test of my proposed addition.  Without my
> addition, people writing scripts for my apps will have to write two
> scripts, one that deals with the GUI, and sends messages to the other
> one.  Considering some of my hard limits on this project (existing
> stuff I have to work with, this is not being designed from scratch),
> that's not acceptable for me.  I'd have to come up with something else,
> and not use edje Lua.

Short answer and just guiding to EFL thread infrastructure. As you are
using som

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

[David Seikel]

On Sun, 8 Jan 2012 19:52:50 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Sun, 8 Jan 2012 18:54:12 +1000 David Seikel 
> said:
> 
> > 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.
> 
> incorrect. if efl is threaded host ap does not need to be threadsafe.
> that is my point. such a requirement would be onerous and wrong as
> the host doesnt know if edje is threaded or not. it shouldn't need to
> know.
> 
> > 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.
> 
> thats not the issue - its that the call from lua (in edje) to host
> app happens directly as a function call, thus is lua is running as a
> thread, the call in host spac happens inside a thread created by
> edje. this is unacceptable. it must be MARSHALLED back to the
> mainloop - thus synchronous ipc calls.
> 
> > 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.
> 
> well this isnt really about your apps - but the general case - if its
> a general api made available, then the calls TO the host app must
> happen in the main loop context (thread) not another. all things must
> be marshalled back to the mainloop. thus why the messaging/signal api
> is much better here as it is a messaging api, not a call api.

I understand now, I think.

The host app itself may be multi threaded, so we do need to cater for
this.  We also have to cater for those cases where it does not matter,
and those cases where a messaging API is a bad choice.  We would have
to make sure that edje Lua itself is threadsafe first.

0)

Lua scripts themselves can be run on different threads, it all happens
via the Lua state, which is just a pointer to everything.  luaproc is a
system of running lots of scripts in worker threads, where each worker
thread peels the next ready Lua script of the ready queue, runs it
until it yields, then slaps it on the bottom of the run queue.  I'll be
experimenting with that soon.

If I remember, edje Lua puts everything into the Lua state, with no
globals.  So it should be threadsafe to start with.  If not, it will
have to be made threadsafe anyway when edje goes threaded.

1)

The host function might deal purely with some data structure that is
internal to the script.  This means it's userdata (or perhaps just
plain Lua data) attached to the Lua state.  This should be inherently
thread safe as per 0).  This could be inefficient if dealt with via
messages.

2)

That userdata in 1) might involve things that happen in other threads
of the host app.  Then it's up to the host app to deal with it's own
threading problems.  Not our problem.

3)

The host function might deal with EFL stuff.  This is a case where it
would be better to have more EFL API in the edje Lua, or use messages.
Messages is a usual method in EFL anyway.  So what we are doing already
works for this case.

4)

The host function might deal with it's own internal data structures.
This I think is the problem you see?  If it's not a threadsafe host app,
then things can go horribly wrong when host functions are unexpectedly
called from some random edje thread.

Wont the same problems happen when some host function EFL callback is
unexpectedly called from some random EFL thread?

So the same solutions could be used.  Host API functions are really
just another callback system.  The host registers it's callbacks with
edje Lua, edje Lua calls them back.  Why is this different from the
rest of EFL using registered callbacks?

Only 4) is a problem, unless I've missed a use case?  Please add more
if I did.



BTW, I brought up my apps as it WILL be dealing with thread issues.  So
it might make for a good test of my proposed addition.  Without my
addition, people writing scripts for my apps will have to write two
scripts, one that deals with the GUI, and sends messages to the other
one.  Considering some of my hard limits on this project (existing
stuff I have to work with, this is not being designed from scratch),
that's not acceptable for me.  I'd have to come up with something else,
and not use edje Lua.

-- 
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
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you 

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

[David Seikel]

On Sun, 8 Jan 2012 19:54:19 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Sun, 8 Jan 2012 19:35:01 +1000 David Seikel 
> said:
> 
> > Do we want to return the library version?
> > 
> > PACKAGE_VERSION?
> > 
> > edje_version?
> > 
> > EDJE_VERSION_MAJOR and EDJE_VERSION_MINOR?
> > 
> > EDJE_FILE_VERSION and EDJE_FILE_MINOR? Should those be bumped to
> > track Lua API changes to?
> > 
> > Something new like EDJE_EXTERNAL_TYPE_ABI_VERSION?  
> 
> probably a table with 2 numbers - major and minor version. no micro.

Yes, but which of the above is the source of these two numbers?  Who's
version are we actually reporting?

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

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

[The Rasterman]

On Sun, 8 Jan 2012 18:54:12 +1000 David Seikel  said:

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

incorrect. if efl is threaded host ap does not need to be threadsafe. that is
my point. such a requirement would be onerous and wrong as the host doesnt know
if edje is threaded or not. it shouldn't need to know.

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

thats not the issue - its that the call from lua (in edje) to host app happens
directly as a function call, thus is lua is running as a thread, the call in
host spac happens inside a thread created by edje. this is unacceptable. it
must be MARSHALLED back to the mainloop - thus synchronous ipc calls.

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

well this isnt really about your apps - but the general case - if its a general
api made available, then the calls TO the host app must happen in the main loop
context (thread) not another. all things must be marshalled back to the
mainloop. thus why the messaging/signal api is much better here as it is a
messaging api, not a call api.

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

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

[The Rasterman]

On Sun, 8 Jan 2012 19:35:01 +1000 David Seikel  said:

> Do we want to return the library version?
> 
> PACKAGE_VERSION?
> 
> edje_version?
> 
> EDJE_VERSION_MAJOR and EDJE_VERSION_MINOR?
> 
> EDJE_FILE_VERSION and EDJE_FILE_MINOR? Should those be bumped to track
> Lua API changes to?
> 
> Something new like EDJE_EXTERNAL_TYPE_ABI_VERSION?  

probably a table with 2 numbers - major and minor version. no micro.

> And what about Lua version while we are at it?  I think access to that
> was only introduced in Lua 5.2, and we already decided to not go
> there.

no need - i suspect we will stick to 5.1 for a long time :)

> There may be more, still waking up.  lol
> 
> -- 
> 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


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

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

[David Seikel]

On Sun, 8 Jan 2012 11:08:05 +0900 Carsten Haitzler (The Rasterman)
 wrote:

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

Do we want to return the library version?

PACKAGE_VERSION?

edje_version?

EDJE_VERSION_MAJOR and EDJE_VERSION_MINOR?

EDJE_FILE_VERSION and EDJE_FILE_MINOR? Should those be bumped to track
Lua API changes to?

Something new like EDJE_EXTERNAL_TYPE_ABI_VERSION?  

And what about Lua version while we are at it?  I think access to that
was only introduced in Lua 5.2, and we already decided to not go
there.

There may be more, still waking up.  lol

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

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

[David Seikel]

On Sun, 8 Jan 2012 11:08:05 +0900 Carsten Haitzler (The Rasterman)
 wrote:

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

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

[The Rasterman]

On Sun, 8 Jan 2012 07:04:38 +1000 David Seikel  said:

> On Sun, 8 Jan 2012 06:53:04 +1000 David Seikel 
> wrote:
> 
> > On Sun, 8 Jan 2012 01:55:49 +1000 David Seikel 
> > wrote:
> > 
> > > On Fri, 6 Jan 2012 20:32:30 +0900 Carsten Haitzler (The Rasterman)
> > >  wrote:
> > > 
> > > > On Thu, 5 Jan 2012 23:38:55 +1000 David Seikel 
> > > > said:
> > > > 
> > > > > On Thu, 5 Jan 2012 16:43:29 +0900 Carsten Haitzler (The
> > > > > Rasterman)  wrote:
> > > > > 
> > > > > > On Mon, 2 Jan 2012 21:09:19 +1000 David Seikel
> > > > > >  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.
> > 
> > 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).
> 
> I'll commit as soon as I can get past this - 
> 
> svn: Commit failed (details follow):
> svn: Network connection closed unexpectedly
> 
> All the rest of my 'net is working fine, including email obviously.

works fine for me... :/

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

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

[The Rasterman]

On Sun, 8 Jan 2012 06:53:04 +1000 David Seikel  said:

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

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

[David Seikel]

On Sun, 8 Jan 2012 06:53:04 +1000 David Seikel 
wrote:

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

I'll commit as soon as I can get past this - 

svn: Commit failed (details follow):
svn: Network connection closed unexpectedly

All the rest of my 'net is working fine, including email obviously.

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

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

[David Seikel]

On Sun, 8 Jan 2012 01:55:49 +1000 David Seikel 
wrote:

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

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

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

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

[David Seikel]

On Fri, 6 Jan 2012 20:32:30 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Thu, 5 Jan 2012 23:38:55 +1000 David Seikel 
> said:
> 
> > On Thu, 5 Jan 2012 16:43:29 +0900 Carsten Haitzler (The Rasterman)
> >  wrote:
> > 
> > > On Mon, 2 Jan 2012 21:09:19 +1000 David Seikel 
> > > 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.

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

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

[The Rasterman]

On Thu, 5 Jan 2012 23:38:55 +1000 David Seikel  said:

> On Thu, 5 Jan 2012 16:43:29 +0900 Carsten Haitzler (The Rasterman)
>  wrote:
> 
> > On Mon, 2 Jan 2012 21:09:19 +1000 David Seikel 
> > 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 :)

> > > 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 ;)

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

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

[David Seikel]

On Thu, 5 Jan 2012 16:43:29 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Mon, 2 Jan 2012 21:09:19 +1000 David Seikel 
> 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 -

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

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

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

[The Rasterman]

On Mon, 2 Jan 2012 21:09:19 +1000 David Seikel  said:

how will the lua be able to detect the api call is there safely without totally
ceasing functioning.

> Now that my last lot of Lua work has been a run away success (works for
> me, still dunno if anyone else uses it), it's time for me to move to
> the next big Lua project of mine.  Actually, the second next one, but
> they are related.
> 
> What I would like to add to edje Lua is the ability for the host
> application to provide new functions for the Lua script to be able to
> call.  Also, for the host app to be able to directly call Lua script
> provided functions (like the current move, resize, signal. etc).  Yes we
> have signals and messages for communicating with the host app, but
> sometimes a direct function call makes much more sense.
> 
> We are actually half way there.  Anticipating that there would be way
> more edje and evas stuff to add to the edje Lua API in the future, I
> created generic wrapper functions to make that easier.  Implementing
> this would mean exposing those static functions, and writing more of
> these generic wrapper stuff.
> 
> Lua already provides a mechanism for this sort of thing, but we
> currently sandbox that out.  We can provide a very limited version of
> the package module, that only lets the Lua script load modules that the
> host app explicitly provides.  This keeps edje Lua in it's strictly
> sandboxed state.
> 
> 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.
> 
> Now that the edje Lua stuff is more fleshed out, it will be actually
> useful, I expect people to actually start using it.  No one bothered
> before, coz rectangles are very limited.  So definitely for the next
> release we will need a generic solution to that problem.  And probably
> backport it to the current release.  Not much harder to go from there
> to what I want.
> 
> One use of this is to let elementary add Lua support for it's widgets.
> At the moment, elementary is not a dependency of edje, so this sort of
> thing would be the way to do that.  After the big library merge, that
> might not be a problem.  Though I for one would still prefer to be able
> to use edje+lua+evas without elementary on embedded projects.
> 
> My next two big Lua projects are - server side and then client side Lua
> scripting support for Second Life (SL) style virtual worlds.  This will
> bring the same sort of thing that WoW has to more open virtual worlds -
> Lua client side scripting.  SL already has it's own server side
> scripting language, I'll be making a Lua based version of that which
> will need to be compatible at the function API level.  Then I'll want to
> make a completely new client side version, but it will have to be more
> or less compatible at the API level with the server API.  So client side
> Lua scripting will have to be a mixture of functions that match the
> server side functions, and edje Lua calls to drive the UI.  Messages and
> signals just wont cut it for that, it will have to be functions.  Coz
> the API functions is what existing server side scripters are used to.
> 
> Before anyone argues that SL client side functions would have to send
> messages to server side anyway, I'll point out that some of the server
> side functions have purely client side results, and not just the UI
> related ones.  These sort of functions, when implemented as client side
> scripting API, will not involve the server at all, just trigger
> existing client side functions.  Simple Lua wrappers around those
> existing functions will work the best.  Exactly in the same way that
> I've been adding simple Lua wrappers around edje and evas functions.
> 
> -- 
> 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


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