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

Reply via email to