On Sun, Dec 30, 2012 at 12:51 PM, Carsten Haitzler <ras...@rasterman.com>wrote:
> On Sun, 30 Dec 2012 09:55:10 -0200 Lucas De Marchi > <lucas.demar...@profusion.mobi> said: > > > On Sun, Dec 30, 2012 at 9:49 AM, Carsten Haitzler <ras...@rasterman.com> > > wrote: > > > On Sun, 30 Dec 2012 09:27:40 -0200 Lucas De Marchi > > > <lucas.demar...@profusion.mobi> said: > > > > > >> On Sat, Dec 29, 2012 at 10:32 PM, Carsten Haitzler < > ras...@rasterman.com> > > >> wrote: > > >> > 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. > > >> > > >> People tend to work in several projects. Having one IDE for each one > > >> is just insane. I myself work in projects from bootloader and kernel > > >> to a handful of userspace projects. VIM fits my needs for all of them. > > >> You are not convincing anyone to use a shiny new IDE built with EFL > > >> just because EFL needs some weird tooling. > > >> > > >> > > > >> > the extra eo layer underneath a thin c call layer is unavoidable as > > >> > that's needed for compat (abi/api) anyway. > > >> > > >> but we have been told this is *only* for compat. Not for new calls. > > > > > > it's not for new calls AFTER 2.0 - until then we maintain an api that > looks, > > > feels and works like the existing. at 2.0 the current api will be put > out to > > > pasture. it will WORK, but it may also break and get nothing new. > > > > > >> > > > >> > the alternative is "rip all of eo out and don't do it" which imho is > > >> > > >> I like this alternative sooooo much :-) > > >> > > >> > unacceptable the other way - code using efl stays messy and > > >> > inconsistent. we > > >> > > >> so you are saying it has been messy all these years? And all the other > > >> similar libs are messy too, since they don't have anything similar to > > >> these macros. > > > > > > no - i'm saying that its messy because we dont have a consistent object > > > model from bottom to top. we don't have a consistent callback > mechanism. we > > > don't have a consistent way of gluing objects together for auto cleanup > > > that lives below evas (evas is way too high for this). > > > > > >> > have no path forwards to improve things and unify efl. reality is > day in > > >> > and > > >> > > >> we sure can improve things without eo. this is what we have being > > >> doing all these years. > > > > > > and in the end it'll result in what eo is. another layer in the > backtrace. > > > another object model. another layer of indirection. i spent time > looking at > > > gobject. i spent time looking at what we have in evas. i decided > gobject was > > > just not going to cut it. eo is a different take on the object thing. > this > > > was discussed both on irc and in mailing lists quite a long time ago > now. > > > the time for discussing it is over. you're too late. > > > > > > the thing to do now is ... how to IMPROVE it. how to move forward and > make > > > maximum use of the tools at hand. > > > > > >> > 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. > > >> > > >> We could very well ship a single libefl.so with NO need of eo for > > >> doing that. We could do this right now or have done this even before > > >> efl 1.0. This is no argument in favor or contrary to eo adoption. > > > > > > my point is they see a single unit that is fractured and vastly > different in > > > each area. and they complain. they can't recycle knowledge (callback > > > prototypes, apis' for adding/deleting callbacks, ability to bind > objects > > > together or not etc.). this puts in that model. we need to also place > in as > > > much of a single point of object allocation and management as we > possibly > > > can. eo does that. one of our big problems now after you take away > memory > > > used by image and font data is actually objects. edje objects. evas > object > > > and others. being able o track and detail who uses what. who is tied > to who > > > etc will help us lean this down. it will help us make existing objects > > > smaller. eo allows us now to make the larger objects like evas possibly > > > composite objects from smaller elements. with a pointer indirection > layer > > > (id's) we can also do memory compaction. i spent a while looking at > memory > > > allocation map dumps of e17 after it runs for a bit. fragmentation is a > > > major issue. we easily get to 50%+ fragmentation - half the memory in > terms > > > of pages we have resident, are unused. if we can compact that at > certain > > > intervals... we will gain memory. the id thing also allow for safety as > > > already mentioned. > > > > > > as i said - the time for discussing this is over. that time was like > 6-24 > > > months ago.the time now is to see what we can do to make things better > and > > > make maximum use of our new tools. > > > > > > If you point me to a single mailing list thread on the matter of how > > this was designed with people giving opinions on it and concluding > > this was the way to go, you maybe can say I'm too late. IMO it's not > > too late until the day we release 1.8. > > i shall start with a single one: 'Subject: [E-devel] Eobj - Request for > review/comments' in april 2012. > > you were conspicuously absent from comments. so was gustavo. it's a bit > late now > to want to comment and change the course of everything. :) > > my irc logs show discussions in february 27 2012 about it on #edevelop. > > i know we've ben tossing about ideas of how to do some more unified oosin > efl > for long before that. it got a lot more concreat early last year. > indeed i did not reply to ML, however I listed the problems that could happen, and happened, via IRC and in person many times. I was ignored, then I just did the wait-n-see, maybe I would be proved wrong and I was the naive, that didn't happen :-( > > > I don't want to be the boring guy complaining on this. But I can't > > agree neither on the reasons why this went in, nor how it went in. For > > me eo is just raping C and all the problems pointed out should be > > fixed elsewhere. > > there was an rfc. it was not slid in quietly without your knowing. you > chose to > not look or participate. either way too late. i've already covered many > points > behind eo. there are a lot. eo is a result of real needs and problems. it's solving problems by creating more problems? :-/ -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ 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
