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