On Wed, 19 Mar 2014 09:15:47 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> 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.
Yes but reusing the edje Lua stuff seems sane anyway. No duplication of
effort. No duplication of API (even if one is just a sub set of the
other), easier to maintain one set of stuff. Reusing the internal
helper functions I wrote in edje_lua2.c. Extending those helper
functions as we discussed a while ago to provide the Lua table
messaging stuff you wanted and thread safe Lua scripts for both
bindings. There's more in common than different, should be able to
leverage that. Once eolian support spreads to things like Elementary,
then that effort could also be leveraged to help out.
Just makes things easier and simpler all around if there's one base
for the Edje Lua sandboxed API that is shared with a non sandboxed API
binding. Otherwise the thing that was so fucking painful that no one
did anything for years gets to be twice as fucking painful. My point
all along is that it should only take small tweaks to the incoming EO
(soon EO2) and Eolian stuff to support doing this all properly with out
all the fucking pain. Seems the sane thing to do to me. B-)
My plan at the moment is to start writing that part of my "Grand Plan
that I dedicated my life to" project that will use this stuff, leaving
the actual interfacing to EFL bit until later. I'll probably make a few
temporary hard wired widget stubs for testing purposes. Eventually
I'll be needing to add the EFL bits we have been talking about. When
that time comes, I'll look at the state of EO, eolian, and Edje LuaJIT
FFI bindings. If it's not suitable for my purposes, then I now have a
backup plan of basically doing what I've been saying here, perhaps as a
patch for eolian, a new introspection library, and a new edje_lua3.c.
> > > > > 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.
>
>
--
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
------------------------------------------------------------------------------ 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
