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.
indeed I missed that. But don't be that silly. Let me explain: I just added a project under PROTO/ named ldm with features X, Y and Z. Will you review it? probably not. 5 month later later I come back and replace all your Eo structs underneath you with my ldm structs, because this is the way I think is the right way. Will you complain? Of course you will. To worse, it was added together with the move of the tree to efl/. And I *DID* complain saying there was no reason to rush eobj in. Of course you didn't hear because a patch like eobj would be impossible to maintain out of tree. And as others pointed out, saying "this has been discussed on IRC and mailing list" and interpreting that like "it has been decided to do this way" is just silly. Lucas De Marchi ------------------------------------------------------------------------------ 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
