On Wed, 19 Mar 2014 04:56:46 +1000 David Seikel <onef...@gmail.com> said:
> On Tue, 18 Mar 2014 18:09:44 +0900 Carsten Haitzler (The Rasterman)
> <ras...@rasterman.com> wrote:
>
> > On Tue, 18 Mar 2014 15:44:55 +1000 David Seikel <onef...@gmail.com>
> > said:
> >
> > > On Tue, 18 Mar 2014 14:08:01 +0900 Carsten Haitzler (The Rasterman)
> > > <ras...@rasterman.com> wrote:
> > >
> > > > On Tue, 18 Mar 2014 13:52:30 +1000 David Seikel
> > > > <onef...@gmail.com> said:
> > > >
> > > > > On Tue, 18 Mar 2014 12:42:18 +0900 Carsten Haitzler (The
> > > > > Rasterman) <ras...@rasterman.com> wrote:
> > > > >
> > > > > > On Mon, 17 Mar 2014 23:14:15 +1000 David Seikel
> > > > > > <onef...@gmail.com> said:
> > > > > >
> > > > > > > On Mon, 17 Mar 2014 12:16:34 +0900 Carsten Haitzler (The
> > > > > > > Rasterman) <ras...@rasterman.com> wrote:
> > > > > > >
> > > > > > > > On Mon, 17 Mar 2014 11:56:38 +1000 David Seikel
> > > > > > > > <onef...@gmail.com> said:
> > > > > > > >
> > > > > > > > > On Mon, 17 Mar 2014 10:08:35 +0900 Carsten Haitzler (The
> > > > > > > > > Rasterman) <ras...@rasterman.com> wrote:
> > > > > > > > >
> > > > > > > > > > On Mon, 17 Mar 2014 09:59:10 +0900 Cedric BAIL
> > > > > > > > > > <cedric.b...@free.fr> said:
> > > > > > > > > >
> > > > > > > > > > > On Mon, Mar 17, 2014 at 9:14 AM, Carsten Haitzler
> > > > > > > > > > > <ras...@rasterman.com> wrote:
> > > > > > > > > > > > On Mon, 17 Mar 2014 02:50:18 +1000 David Seikel
> > > > > > > > > > > > <onef...@gmail.com> said:
> > > > > > > > > > > >> On Tue, 11 Mar 2014 20:13:07 +1000 David Seikel
> > > > > > > > > > > >> <onef...@gmail.com> wrote:
> > > > > > > > > > > >> > On Tue, 11 Mar 2014 09:46:26 +0000 Tom Hacohen
> > > > > > > > > > > >> > <tom.haco...@samsung.com> wrote:
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > > On 11/03/14 09:22, David Seikel wrote:
> > > > > > > > > > > >> > > > On Tue, 11 Mar 2014 16:20:37 +0900 Carsten
> > > > > > > > > > > >> > > > Haitzler (The Rasterman)
> > > > > > > > > > > >> > > > <ras...@rasterman.com> wrote:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >> so now we're getting more into eo... it's
> > > > > > > > > > > >> > > >> time to look at 3 things that turn up on
> > > > > > > > > > > >> > > >> my profiles of things that are NOT
> > > > > > > > > > > >> > > >> expedite.
> > > > > > > > > > > >> > > >>
> > > > > > > > > > > >> > > >> 8.21% elementary_test
> > > > > > > > > > > >> > > >> libeo.so.1.9.99 [.] eo_do_internal
> > > > > > > > > > > >> > > >> 7.77% elementary_test
> > > > > > > > > > > >> > > >> libeo.so.1.9.99 [.] _ev_cb_call
> > > > > > > > > > > >> > > >> 3.03% elementary_test
> > > > > > > > > > > >> > > >> libeo.so.1.9.99 [.] eo_data_scope_get
> > > > > > > > > > > >> > > >>
> > > > > > > > > > > >> > > >> this is a pretty simply test. open elm
> > > > > > > > > > > >> > > >> test. scroll to bottom, scroll back to
> > > > > > > > > > > >> > > >> top. close. almost 20% of our cpu is
> > > > > > > > > > > >> > > >> spent in the above 3 calls. it's time to
> > > > > > > > > > > >> > > >> cut this down... a LOT.
> > > > > > > > > > > >> > > >>
> > > > > > > > > > > >> > > >> so i am looking at _ev_cb_call() and
> > > > > > > > > > > >> > > >> callbacks in general. this is a single
> > > > > > > > > > > >> > > >> linked list of cb's for ALL cb's for an
> > > > > > > > > > > >> > > >> object. we filter out cb's not matching
> > > > > > > > > > > >> > > >> the callback type (desc) as we walk the
> > > > > > > > > > > >> > > >> list. this of course causes us to do a
> > > > > > > > > > > >> > > >> lot of cache misses and hunt through a
> > > > > > > > > > > >> > > >> lot of memory to then... do nothing.
> > > > > > > > > > > >> > > >>
> > > > > > > > > > > >> > > >> imho this needs to be restructured to...
> > > > > > > > > > > >> > > >>
> > > > > > > > > > > >> > > >> 1. have fewer linked list nodes. that
> > > > > > > > > > > >> > > >> means instead of:
> > > > > > > > > > > >> > > >>
> > > > > > > > > > > >> > > >> node (cb) -> node (cb2) -> node
> > > > > > > > > > > >> > > >> (cb3) ...
> > > > > > > > > > > >> > > >>
> > > > > > > > > > > >> > > >> what might be better is:
> > > > > > > > > > > >> > > >>
> > > > > > > > > > > >> > > >> node (cb1,cb2,cb3,cb4,cb5,cb6,cb7,cb8)
> > > > > > > > > > > >> > > >> -> node (cb9,cb10,cb11,cb12) ...
> > > > > > > > > > > >> > > >>
> > > > > > > > > > > >> > > >> ie bigger buckets with more cb's per
> > > > > > > > > > > >> > > >> buckets, fewer links. possibly have a cb
> > > > > > > > > > > >> > > >> "optimizer" that figures out if the cb
> > > > > > > > > > > >> > > >> list has been changed since it last
> > > > > > > > > > > >> > > >> optimized and then might group all cb's
> > > > > > > > > > > >> > > >> into a flat array (if cb's are removed,
> > > > > > > > > > > >> > > >> array is split at that point and
> > > > > > > > > > > >> > > >> fragments until the next optimize call).
> > > > > > > > > > > >> > > >> this should save a little memory too.
> > > > > > > > > > > >> > > >>
> > > > > > > > > > > >> > > >> 2. but much more important here is to
> > > > > > > > > > > >> > > >> divide cb's into type specific
> > > > > > > > > > > >> > > >> lists/arrays so we don't walk tonnes of
> > > > > > > > > > > >> > > >> cb's we then filter out, and to have a
> > > > > > > > > > > >> > > >> fast "select" to select the appropriate
> > > > > > > > > > > >> > > >> list to walk for that event (as we call 1
> > > > > > > > > > > >> > > >> event at a time only - but all cb's for
> > > > > > > > > > > >> > > >> that event).
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > That sounds like a great idea.
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >> 3. global freeze_count AND object freeze
> > > > > > > > > > > >> > > >> count is checked in the inner loop per
> > > > > > > > > > > >> > > >> walk, and not outside the loop before even
> > > > > > > > > > > >> > > >> beginning a walk! these should at least be
> > > > > > > > > > > >> > > >> checked first to abort any callback list
> > > > > > > > > > > >> > > >> walk that we KNOW will all fail. we know
> > > > > > > > > > > >> > > >> the desc is unfreezable direct from the
> > > > > > > > > > > >> > > >> input desc and don't need to use the
> > > > > > > > > > > >> > > >> cb->items.item.desc.
> > > > > > > > > > > >> > > >>
> > > > > > > > > > > >> > > >> ... comments?
> > > > > > > > > > > >> > > >>
> > > > > > > > > > > >> > > >> now eo_data_scope_get()... i can't find
> > > > > > > > > > > >> > > >> much to imptove here... the mixin path
> > > > > > > > > > > >> > > >> isn't hit often and data_sizes are
> > > > > > > > > > > >> > > >> notmally > 0... so some way to oprimize:
> > > > > > > > > > > >> > > >>
> > > > > > > > > > > >> > > >> if
> > > > > > > > > > > >> > > >> (EINA_LIKELY((klass->desc->data_size > 0)
> > > > > > > > > > > >> > > >> && (klass->desc->type !=
> > > > > > > > > > > >> > > >> EO_CLASS_TYPE_MIXIN))) return ((char *)
> > > > > > > > > > > >> > > >> obj)
> > > > > > > > > > > >> > > >> + _eo_sz + klass->data_offset;
> > > > > > > > > > > >> > > >>
> > > > > > > > > > > >> > > >> is most likely what's needed... but there
> > > > > > > > > > > >> > > >> isn't much there. :)
> > > > > > > > > > > >> > > >>
> > > > > > > > > > > >> > > >> now eo_do_internal()... i think we need to
> > > > > > > > > > > >> > > >> wait for eo2... TOM!
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > I finally have some time this week (unless
> > > > > > > > > > > >> > > > a client wants me to be busy) to look at
> > > > > > > > > > > >> > > > this eo stuff, and now you tell me that
> > > > > > > > > > > >> > > > eo2 is coming? lol
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > I'll be going over all the old emails I
> > > > > > > > > > > >> > > > have marked, try to learn how eo works, and
> > > > > > > > > > > >> > > > consider if it can be used for the Edje Lua
> > > > > > > > > > > >> > > > stuff. I think it's either eo for Lua
> > > > > > > > > > > >> > > > bindings, or LuaJIT FFI. Manually writing
> > > > > > > > > > > >> > > > the Edje Lua bindings is obviously not so
> > > > > > > > > > > >> > > > good, I kinda balked at all those text
> > > > > > > > > > > >> > > > APIs.
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > Eo2 is known to be coming for about half a
> > > > > > > > > > > >> > > year now...
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > Like I said, I had marked a bunch of eo related
> > > > > > > > > > > >> > emails to be read, so it's likely I missed
> > > > > > > > > > > >> > seeing eo2 mentioned. After reading your other
> > > > > > > > > > > >> > reply on this thread, perhaps I should wait
> > > > > > > > > > > >> > another half a year for eo2? B-)
> > > > > > > > > > > >>
> > > > > > > > > > > >> OK, I went over my backlog of emails, and
> > > > > > > > > > > >> studied eo and eolian a bit. Seems like it would
> > > > > > > > > > > >> work to use eolian to generate the edje_lua2.c
> > > > > > > > > > > >> bindings. I'm guessing it could work like this -
> > > > > > > > > > > >>
> > > > > > > > > > > >> Add a --lua option to eolian that generates lua
> > > > > > > > > > > >> bindings similar to what is in edje_lua2.c.
> > > > > > > > > > > >> Adding lua_generator.c/h files to eolian. I'm
> > > > > > > > > > > >> not sure if we should continue to wrap the
> > > > > > > > > > > >> legacy functions, or wrap eo_add() and eo_do()
> > > > > > > > > > > >> directly.
> > > > > > > > > > > >
> > > > > > > > > > > > actually the intent is to make a whole new binary
> > > > > > > > > > > > (eolian-lua) most likely - same for c++ or
> > > > > > > > > > > > anything else, not add an option to eolian.
> > > > > > > > > > >
> > > > > > > > > > > Why not ? Having one binary and multiple backend
> > > > > > > > > > > would make sharing infrastructure easier and reduce
> > > > > > > > > > > the need for us to release any public API for
> > > > > > > > > > > Eolian until a few release from now. I do not see
> > > > > > > > > > > the win in splitting binary that will have the same
> > > > > > > > > > > command line and do the same job except at the last
> > > > > > > > > > > stage when they output the file.
> > > > > > > > > >
> > > > > > > > > > given that the c++ eolian binding generator is in
> > > > > > > > > > c++... and that d5 (q66) insists the lua bindings
> > > > > > > > > > generator is far easier to write in lua... they're
> > > > > > > > > > going to be different binaries.
> > > > > > > > >
> > > > > > > > > Well, if q66 is writing it, then maybe, but I was
> > > > > > > > > looking at it with the intention of writing it myself.
> > > > > > > > > I'd prefer to do what Cedric said.
> > > > > > > >
> > > > > > > > well his intent is to generate LUA - lua that uses luajit
> > > > > > > > ffi to call native directly.
> > > > > > > >
> > > > > > > > > > also eolian that generates the original c stubs vs a
> > > > > > > > > > bindings generator are vastly different purposes. they
> > > > > > > > > > may read the same eo file src but they produce
> > > > > > > > > > entirely different things.
> > > > > > > > >
> > > > > > > > > ... and ...
> > > > > > > > >
> > > > > > > > > > unless the newly generated lua is 100% compatible
> > > > > > > > > > with the old. no .. we can't rip it out. you can only
> > > > > > > > > > create a new parallel api.
> > > > > > > > >
> > > > > > > > > My intention IS to generate C that is 100% compatible
> > > > > > > > > with the old edje_lua2.c code. In the same way that
> > > > > > > > > eolian is currently being used to replace C code. Not
> > > > > > > > > entirely different at all, they both generate C stubs
> > > > > > > > > from the same .eo files, the C stubs wrap the same eo
> > > > > > > > > functions. Makes sense to me to clone the eo1
> > > > > > > > > generator, but have it output slightly different C code.
> > > > > > > >
> > > > > > > > then you'll have to create a new set of eo files and thus
> > > > > > > > classes that 1:1 match the current edje lua api, and then
> > > > > > > > have these generate c... and thats very much different to
> > > > > > > > what q66 was planning. i think you're creating a custom
> > > > > > > > generator for edje lua here with custom eo classes exposed
> > > > > > > > from edje to the edje lua. :)
> > > > > > >
> > > > > > > Why are new classes needed?
> > > > > >
> > > > > > example:
> > > > > >
> > > > > > edje lua:
> > > > > >
> > > > > > _elua_geom() / obj:geom(x, y, w, h)
> > > > > >
> > > > > > eo:
> > > > > >
> > > > > > geometry_set() / geometry_get()
> > > > > >
> > > > > > it's geometry even not geom. so any methods generated are
> > > > > > going to usse geometry. it's listed as a property so thus in
> > > > > > c/c++ it'll get
> > > > > >
> > > > > > eo_do(obj, evas_obj_geometry_set(x, y, w, h),
> > > > > > evas_obj_geometry_get(&x, &y, &w, &h));
> > > > > >
> > > > > > and
> > > > > >
> > > > > > obj->geometry_set(x, y, w, h);
> > > > > > obj->geometry_get(&x, &y, &w, &h);
> > > > > >
> > > > > > (actuallly not sure if in c++ we'll add evas_obj_ or not)
> > > > > >
> > > > > > so in lua either u get full methods for both
> > > > > >
> > > > > > obj:geometry_set(x, y, w, h);
> > > > > > obj:geometry_get(...); // unsure
> > > > > >
> > > > > > (also not sure of evas_obj_)
> > > > > >
> > > > > > or you expose it as a table property (not sure here).. but no
> > > > > > matter what.. geom != geometry. in edje lua it's obj:geom(x,
> > > > > > y, w, h); or geom = obj:geom();
> > > > > >
> > > > > > so just starting there the method/property naming doesn't
> > > > > > match. you'll find this is the case everywhere. they won't
> > > > > > match.
> > > > >
> > > > > OK, so that explains parallel API, which can still be done by
> > > > > cloning and tweaking the eo1 generator C file and adding --lua
> > > > > to eolian. Where there is differences, mark the old manual
> > > > > stuff as deprecated, but keep it around for a bit.
> > > >
> > > > correct. also you'll need to care about any namespace collisions
> > > > - i haven't checked, but yes - adding a parallel api is what u'll
> > > > need to do.
> > > >
> > > > ALSO... catch. this will ALSO require you override the standard
> > > > classes because edje lua abstracts geometry to be object relative
> > > > where eo api is canvas relative global geometry for starters. yu
> > > > cant expose layer_set in edje as u cant have layers inside
> > > > objects... you can't expose apis that allow you to create objects
> > > > then get them out of the sandbox.
> > >
> > > Wouldn't LuaJIT FFI have that exact same problem?
> > >
> > > The sandbox is your idea, I never liked it. I'm might have to do an
> > > entirely separate set of Lua bindings just so I can use EFL from Lua
> > > outside of the sandbox. :-P
> >
> > edje sandbox == objects are constrained to the edj object. they have
> > to be for security and sanity. otherwise they will brek the bounds of
> > their object (go outside the tree) become untrackable (they have to
> > be tracked for deletion) etc.
> >
> > a lua runtime is for writing APPS. so they should work this way - the
> > app is in charge. edje is for making skins and themes. not for
> > writign apps. a theme is a data file like a jpeg etc. - and thus it
> > needs sandboxing and security.
> >
> > ultimately lua runtimes will need sandboxing in terms of access
> > OUTSIDE of the process or its windows - eg can it list other clients
> > on the display? can it access files outside some special subtrees in
> > the fs etc. etc. - edje objects can't access anything at all like
> > this so re heavily sandboxed by default and must remain so.. as they
> > are data files, not applications. a theme should not be able to read,
> > delete or otherwise files. it should have no network access at all
> > etc. etc. because you don't want a surprise when a theme starts
> > sending off your email to some remote server etc. - as it's
> > unexpected that a THEME can do this. code on the other has is
> > expected to be able to do these things.
> >
> > > Would be nice to use the EO infrastructure for both sets of
> > > bindings.
> > >
> > > I've considered adding a DONT_SANDBOX_ME_IN define to edje_lua2.c
> > > that defaults to false, then compiling two versions, the non
> > > sandboxed version being an optional thing for those that want it.
> > > Dunno yet, still considering my options. Though by the looks of it
> > > I'm running out of options.
> >
> > this goes against everything edje is. edje is a safe playground for
> > designers/skinners/themers to modify a ui and for users to have no
> > unexpected surprises. everything is cleaned up properly. objects stay
> > within their tree and cant go deleting outside objects etc. etc. etc.
>
> Yes, that goes against everything Edje is, but what I want is to run
> Lua code outside of Edje that can access all the EFL goodness. This
> basically means two sets of Lua bindings, one inside Edje that is
> sandboxed, one outside that isn't sandboxed. Writing everything twice
> seems like a big waste of time to me.
then you dont want the lua api that is in edje. you want full bindings capable
of running full apps, just as a subset of your app.
> > > > reality is that what you probably will end up doing is simply
> > > > converting the current edje lua code maybe to use eo to generate
> > > > the same api's and then maintain just an eo file plus the c
> > > > implementation and the lua bindings then are auto generated from
> > > > that.
> > >
> > > Well, I still think there's no need to maintain separate .eo files.
> > >
> > > > but again - now you are going to generate the c code for the
> > > > bindings, not luajit ffi as the plan is for now for lua runtime.
> > >
> > > I still think the eolian route would be easier to implement, and
> > > easier to maintain. But if you are sure q66 is gonna do the LuaJIT
> > > FFI thing (third time I've asked), then by all means, I'll drop
> > > this and move on.
> >
> > i've repeated it often enough - he says that's how he plans on doing
> > it.
>
> OK, I'll leave this in q66s hands now. But if I don't see any progress
> by the time I need it, I'll write things my way. B-)
>
> > > Dunno if LuaJIT FFI would perform faster though. Would need to
> > > benchmark that.
> >
> > it probably would.
> >
> > > > > If q66 is gonna do his version, then I'll just drop this idea
> > > > > entirely, no need to debate it. B-)
> > > > >
> > > > > > > Currently ealion produces this from the existing
> > > > > > > evas_line.eo files -
> > > > > > >
> > > > > > > EAPI void
> > > > > > > evas_object_line_xy_set(Evas_Object *obj, Evas_Coord x1,
> > > > > > > Evas_Coord y1, Evas_Coord x2, Evas_Coord y2) {
> > > > > > > eo_do((Eo *) obj, evas_obj_line_xy_set(x1, y1, x2, y2));
> > > > > > > return ;
> > > > > > > }
> > > > > > >
> > > > > > > EAPI void
> > > > > > > evas_object_line_xy_get(const Evas_Object *obj, Evas_Coord
> > > > > > > *x1, Evas_Coord *y1, Evas_Coord *x2, Evas_Coord *y2) {
> > > > > > > eo_do((Eo *) obj, evas_obj_line_xy_get(x1, y1, x2, y2));
> > > > > > > return ;
> > > > > > > }
> > > > > > >
> > > > > > > And the relevant part of edje_lua2.c is currently -
> > > > > > >
> > > > > > > static int _elua_line_xy(lua_State *L)
> > > > > > > {
> > > > > > > Edje_Lua_Obj *obj = (Edje_Lua_Obj *)lua_touserdata(L, 1);
> > > > > > > Edje_Lua_Evas_Object *elo = (Edje_Lua_Evas_Object *)obj;
> > > > > > > Evas_Coord x1, y1, x2, y2;
> > > > > > >
> > > > > > > if (!_elua_isa(obj, _elua_evas_line_meta)) return 0;
> > > > > > >
> > > > > > > if (_elua_scan_params(L, 2, "%x1 %y1 %x2 %y2", &x1, &y1,
> > > > > > > &x2, &y2) > 0)
> > > > > > > {
> > > > > > > evas_object_line_xy_set(elo->evas_obj, x1, y1, x2,
> > > > > > > y2); }
> > > > > > > evas_object_line_xy_get(elo->evas_obj, &x1, &y1, &x2,
> > > > > > > &y2); _elua_ret(L, "%x1 %y1 %x2 %y2", x1, y1, x2, y2);
> > > > > > >
> > > > > > > return 1;
> > > > > > > }
> > > > > > >
> > > > > > > Most of that is boilerplate that's common to the rest of the
> > > > > > > bindings. What's left is the same as what eolian already
> > > > > > > outputs, the specific function names and the argument
> > > > > > > types/names. There's no need for custom EO classes here,
> > > > > > > or a new set of .eo files. Just copy the existing eo
> > > > > > > generator, and tweak it a little should work fine.
> > > > > > >
> > > > > > > What q66 is planning seems like a LOT more work. And as
> > > > > > > Cedric mentioned, duplicates work that is already being
> > > > > > > done by eolian.
> > > > > > >
> > > > > > > > > There's nothing wrong with the way edje_lua2.c works,
> > > > > > > > > it's just a pain writing all that boiler plate C code
> > > > > > > > > for the actual bindings.
> > > > > > > >
> > > > > > > > totally agree. and thus it becomes a pain to maintain,
> > > > > > > > extend etc. etc. :)
> > > > > > >
> > > > > > > So something needs to be done. If q66 is planning to do his
> > > > > > > version using LuaJIT FFI then I guess I don't need to do
> > > > > > > it. I can leave it up to him, and go poke at Bob or
> > > > > > > something else. Unless he has plans for Bob to?
> > > > > > >
> > > > > > > --
> > > > > > > A big old stinking pile of genius that no one wants
> > > > > > > coz there are too many silver coated monkeys in the world.
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > A big old stinking pile of genius that no one wants
> > > > > coz there are too many silver coated monkeys in the world.
> > > >
> > > >
> > >
> > >
> > > --
> > > A big old stinking pile of genius that no one wants
> > > coz there are too many silver coated monkeys in the world.
> >
> >
>
>
> --
> 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
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
