On Sat, 29 Dec 2012 13:06:25 -0200 Henrique Dante <hda...@profusion.mobi> said:
> On Sat, Dec 29, 2012 at 12:48 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Fri, 28 Dec 2012 22:31:18 +0000 Michael Blumenkrantz > > <michael.blumenkra...@gmail.com> said: > > > >> On Fri, 28 Dec 2012 20:17:14 -0200 > >> Lucas De Marchi <lucas.demar...@profusion.mobi> wrote: > >> > >> > Hey! > >> > > >> > I'd like to start a discussion about eo and its usage in EFL. I got > >> > very frustrated on how it was merged regardless the opinion of the > >> > other EFL developers. IMO it could make some sense in elementary, but > >> > not in the core like ecore, evas, edje. > >> > > >> > Asking around I discovered I was not the only one.... rather the > >> > opposite - everyone I asked hates how it's done. Recently I had to > >> > review some patches to elementary, adding the systray support. My eyes > >> > were bleeding. I will enlist here some reasons in no particular order. > >> > Surely there are more... others are welcome to fill them here. > >> > > >> > - We replaced the function calls with eo_do(func()). Now, take an > >> > application and imagine all ecore_*, evas_*, elm_* functions replaced > >> > with eo_do(func()). This is not just ugly... it's impractical to use. > >> > > >> > - eo_do() is the userspace incarnation of ioctl() - search on LKML to > >> > see how it's hated there. > >> > >> it does make me consider entering one of those code obfuscation contests... > >> > >> > > >> > - *every* "function" in a backtrace comes with the > >> > _eo_dov_internal()/_eo_op_internal() companion - besides polluting the > >> > bt, for sure they have a cost. And I saw no benchmarks on mailing list > >> > after the addition of eo. One might think that since *I* am > >> > complaining, *I* should provide them, but I think it's exactly the > >> > opposite - people who added this thing should make sure it's now the > >> > same or better than it was before. > >> > >> backtraces with eo are the reason I don't see myself ever switching to the > >> 1.8 branch. as for benchmarks, I saw some supposed numbers thrown around > >> during early eo development which claimed that it "was slower, but not that > >> much slower, and worth it for the gains" > >> > >> > > >> > - If we really needed this level of OO in ecore, evas, edje, we'd be > >> > better off using C++ or inventing our own language to fit our needs > >> > instead of doing what we are doing now. > >> > > >> > - why is it any better than the smart object we had all these years? > >> > Why not improve that instead of replacing with eo? > >> > > >> > - run elementary_test with EINA_LOG_LEVELS=5 and see the > >> > construction/destruction party > >> > >> not to mention the spam just from running e > >> > >> > > >> > - Despite raster arguing this is not an API break, I strongly believe > >> > it is. It broke compilation of lots of c++ applications (I'll not > >> > repeat myself here... in the mailing list there are my other arguments > >> > why it is an api breakage) > >> > > >> > > >> > > >> > My opinion is to revert the whole thing, but I'm sure this would be a > >> > major task after the surgery to put it in was made. I'd at least like > >> > the people responsible for it to answer the points above, and people > >> > who like me think this is all crap to step up and say so. > >> > > >> > > >> > > >> > Lucas De Marchi > >> > > >> > >> depressing though it may be to think about, I have to agree with your > >> points. I'm not saying it needs to be reverted, but I don't see any > >> benefit to keeping it unless the goal was to reduce my commits to the > >> afflicted areas to near zero. > >> > >> while it's impressive that all of the eo stuff was added with relatively > >> little breakage (as opposed to my expectations), the idea of having to > >> learn what is essentially a different programming language in order to > >> work on efl internals again in trunk is really demotivating. maybe I'll > >> become the kwo of the 1.7 branch? > > > > fair enough. it's a change. it's not a change i wanted. it's a change that > > was NEEDED. needed because once you go beyond the scope of us few efl devs, > > you hit a wall of developers who can take our api - documented or not, with > > examples or > > Hello, from a new developer pespective, I think Eo is creating an > unwelcome encapsulation of the API, that's usually neither expected > nor wanted in C. It's replacing simple function calls with message > building with handles and varargs. The way I see it, new C application > developers from the community (as opposed to employees required to > work on EFL) which could potentially choose EFL as a toolkit, would > avoid it, not be attracted to it. > > While developing with Eo I also noticed that it breaks cscope usage. > Whenever I wanted to jump to the definition of some method call, I > reached a macro in the include file instead. Then I had to use the > method ID to do a new search, this time not by definition, but by > usage in class definitions. The other way doesn't work well either: > single stepping in gdb to find out the code path or looking at a > backtrace are both polluted with Eo calls. In general single stepping > on an efl method call should take 5 seconds, but with Eo it may take 5 > minutes. Main negative conclusion about this is that there's no > trivial way to find out what an Eo call does, and this will discourage > new developers from reading code. if you see a bt with eo stuff - ignore the eo stuff and just skip to the bit that does the real work. can't fix that without patching gdb. not sure it'd be wise either. can't do much about cscope except write better tools or patch cscope itself. fyi - we plan to make better tools. we've been tossing about making our own ide. this is where we get to be able to solve things like this. the extra eo layer underneath a thin c call layer is unavoidable as that's needed for compat (abi/api) anyway. the alternative is "rip all of eo out and don't do it" which imho is unacceptable the other way - code using efl stays messy and inconsistent. we have no path forwards to improve things and unify efl. reality is day in and out people turn up looking at efl as a single unit. not as a collection of separate libraries. they expect it tobe a single unity with a single model and after years of that eo is a way of sliding that in without breaking what we aleady have. it's a path forwards. there is an eventual idea that we can move to a single libefl.so (with libeina.so/libevas.so etc. being simply thin c api wrapper libs on top), because this simply is what people are asking for. maybe not YOU, but i'd say 9 out of 10 think this way, and expect this and want it. > > not, and then just fall over tehmselves and end up wasting our time by the > > bucket load in the process. you never experienced it so you never felt or sw > > the pain. you were insulated. this change is some of that insualtion not > > able to continue and something has to leak. it has to give. if this > > demotivates you, then i guess, so be it. continuing as we were would have > > demotivated me to the point of giving up. it also *HAS* deotivated a dozen+ > > other people. so we lose either way. > > > > without eo peolpe doing bindings do them the hard way - forever. eo provides > > for introspection and documentation. > > > > without eo we have our "17 ways to a callback". maybe you don't get annoyed > > by this, but i do. i keep having to try remember "ok, which prototype was > > that callback? i know its void *data... then what? what does it return?". > > eo tries to unify callbacks... AND document them at runtime even (for > > introspection purposes). this makes it insanely easier to build a gui > > builder and make language bindings. > > > > without eo we still have the danger that code messes up and you accidetnally > > access an invalid pointer... nd then segv. and hen you should know the > > wonders of this... you get a complaint "e crashes!"... and you get no usefl > > backtrace from the user (or not even a backtrace at all). object > > indirectiona and ids stop that. or more accurately, bring the likelihood of > > it so close to zero it may as well be. something has to stomp over the > > object id table to make this hapen and if we mmap the ob id table in its > > own memory mapping, then the chances of an errant write to this memroy are > > very close to nil - you cao't walk of the end of your malloc()ed segment > > into it. it has pages padding it. it's in address range never exposed, so > > no one actually holds pointer values to the table EXCEPT for a very small > > sliver in eo. this table isn't there right now. but the plan was to slide > > it in and have it there. crashes now go down dramatically. invalid accesses > > are safe and detectable without signal trapping. this holds tr not just for > > e17 but for everything using efl. > > > > without eo we have to handle cleanup of attached things like timers, > > animators and just random "extra stuff" you ay attach to an object (eg an > > edje object) where you don't want to go make a whole smart obj (class) for > > it - you just wanted to stick on a timer to time out in N sec and then do > > something. but you now have to handle all the cases of if the oject is > > deleted before timer expires. if timer expores, ensure the timer handle > > attached to obj is nulled out, and you have to attach it somehow. with eo > > you can just create and attach and "walk away" and the rest is handled. it > > lowers the bar to making objects like this easily and safely, saving you > > time. > > > > right now eo looks bad to you because you see the downsides only and make > > use of none of the upsides. that's part of the transition. i think it's > > good to air this as to a lot of devs they are unaware of why eo is there, > > and what caused its ned to become reality, and what you get in return. > > until its actually being made use of evrywhere, it won't reach full > > potential, but if its not being used at all (which is pretty much the case > > at the moment) all it has is apparent and real downsides (longer bt's call > > overhead++ etc.). > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > > ------------------------------------------------------------------------------ > > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > > MVPs and experts. SALE $99.99 this month only -- learn more at: > > http://p.sf.net/sfu/learnmore_122912 > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122912 > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
