On Sun, 30 Dec 2012 13:24:06 -0200 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote:
> 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 :-( there definitely were people who said they were not in favor of this on IRC; I was one of them. saying "discussion happened in IRC and mailing lists" and then misrepresenting the amount of opposition from these channels is not a great way to prove a point. and yes, I can provide logs if that's really necessary. > > > > > > > > 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? :-/ > > there was no rfc. there was a SINGLE thread on the mailing list in early april titled "Eobj - Request for review/comments". and at that point, there were no use cases to review, only hypothetical cases. ------------------------------------------------------------------------------ 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
