On 22/09/16 00:34, Cedric BAIL wrote:
> On Wed, Sep 21, 2016 at 1:46 AM, Tom Hacohen <t...@osg.samsung.com> wrote:
>> On 19/09/16 23:33, Cedric BAIL wrote:
>>> On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen <t...@stosb.com> wrote:
>>>> We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much
>>>> against it.
>>> There was a thread weeks ago. You indeed didn't take part of that
>>> discussion, but everyone else involved in that thread was ok. Actually
>>> the discussion evolved more into a what else to merge in. So their was
>>> an agreement before this email.
>> Sorry, I missed that thread. What was the topic?
> Merging eo, efl and ecore. Like in the title :-)
I remember that thread now, I misunderstood what you meant by merging
when you said it back then, and now with your promise inside lib/eo/ I
understand what you meant, and I'm very much against it.
Let me clarify what I mean compared to my understanding of what you
mean. What I mean is what I thought was discussed in that thread.
I'm fine with:
Linking everything into one big fat ugly libefl.so (would rather not,
but OKish with that).
Having Efl.h that includes Eo.h, Elementary.h and etc.
Having an efl_init() and an efl_shutdown() that call them all.
But if you think about it, it's essentially what we have in elementary.
It does all of the above except for the one binary linked together.
Which I'm mostly OK with (although see Marcel's comment about eo_debug
about which I forgot. Modularity has many advantages).
What I'm *not* OK with:
Creating interdependency between the libraries and essentially making
libefl.so Ecore 2.0. One place to store everything. Units make a lot of
sense, of the advantages have been discussed above. My eo_debug trick
(which is ready, I just need to enable it, again, see marcel's email for
details) requires this separation.
>>>> Eo is clean and hasn't been "polluted" by async, mainloop and etc. That's a
>>>> good thing. This makes our infrastructure easier to test.
>>> Please define "clean" as it is a bit abstract to me here. What I am
>>> looking for here is the minimal set of component I need to have
>>> something useful. Is Eo useful by itself ? With just Efl.Object ? Sure
>>> you could do C without the C library, but would you ?
>> You are right. Let's merge in Eina too.
> That was kind of the discussion. Argument against merging eina, from
> myself, is that we do have a lot of tool, just in tree, that do only
> depends on eina and not on anything else.
I'm also against that btw. If anything, I'm almost OK with merging Eo
and Eina. Or at least more OK than merging Eo up the stack, but even
that doesn't make sense to me.
>> Or without joking: people have been using Eo without ecore and without
>> Efl.Object. One example is Mike in E (reverted now because Eo was
>> undeclared stable). You'll probably end up using Ecore in the same app,
>> but again, everything you can say here you can say about Eina too.
> Do we have any example of an application that use Eo without Ecore or
> Efl today ?
edje_cc, expedite, erigo-cli, clouseau-launcher (not the gui) and etc,
all depend on Eo and not on graphics. As for Ecore: I'm actually not
sure, some probably use ecore for networking, but it doesn't matter,
that's just a convenience that happened to be relevant for this case.
Sort of: if you can afford to use something that makes your life a bit
easier, why not.
>> By "clean" I mean "isolated" or "untainted by its users up the stack".
>> (see next comment for more info).
>>> I think that your disagreement about merging is only and just because
>>> you do not want to make asynchronous request a core feature of EFL.
>>> The rest is mostly rhetoric. Could you please explain why you have so
>>> much resistance to it being rolled into more place in efl ?
>> That is exactly the reason (was I hiding it?), but not only, and one
>> example of not "clean".
>> A while back I was giving you some flack for not writing tests for a
>> component of the EFL and cited Eo as an example of getting high test
>> coverage. You then laughed it off and said something in the lines of
>> "it's easier to test because it's smaller and not async" or something
>> like that.
>> **THAT IS EXACTLY MY POINT.**
>> From my experience (and I guess the industry's collective experience),
>> having small separate units make quality assurance easier, units more
>> testable (because you can easily unit test) and the code easier to maintain.
> In my opinion there is a lot of code in Eo that is far from nice to
> read and easy to maintain. First example is how intricate our pointer
> infrastructure is in eo and how little it makes sense. I have to go
> back at eina_safepointer, but there is seriously no justification for
> that. Especially when it hasn't help us catch thread safety bugs for
> example. So I agree with your small unit, but small unit has nothing
> todo as per library, it has to do with how we divide things between
> functions and files.
No, it has everything to do with interconnectivity of components. Small
units mean: interdependency is allowed within that unit but not outside
Safepointer: that's a different topic. Maybe it belongs there. I'm not
sure. However, that's migrating things out of Eo and making it smaller,
which I'm happy with. :)
As for your case, ptr indirection is implemented in different source
files and has no interdependency, so it can be easily pulled out
OK, so Eo is less than perfect ergo we should make it worse? I don't see
your point. Yes, Eo has been made a bit uglier in the last few months.
It actually made it hard for me to keep track, but it sometimes happens
when you have a lot of contributions from various sources. However
because of its isolation, it remains well tested.
Re thread safety: Eo also hasn't helped us cure cancer, but it doesn't
mean it's not valuable. Also, it has, recent changes helped us find
thread issues, and Eo has been invaluable in findings bugs all across
the efl. I don't see your point here at all.
>>> As for the tests, I really don't like our eo tests. They are not
>>> really testing a clean scenario that is possible to guess, but just a
>>> mismatch of everything into one big C file. When something break
>>> there, you can't just rely on the name of the tests, or reading
>>> quickly the code to guess what's happening. Nop. You have to get
>>> hundred of lines of tests with little logical connection to each
>>> other. I have found them less than useful when developping (And some
>>> times buggy, as instead of testing a scenario that makes sense, they
>>> were just testing that the code was matching the tests). So I don't
>>> get your argument of making it easier to tests.
>> The Eo suite is a mixture of success-scenario, failure-scenario and
>> regression testing.
>> Success scenario: making sure an expected scenario works.
>> Failure scenario: making sure an expected scenario fails.
>> regression testing: making sure what we have stays the same.
>> Success scenarios would rarely need changing, only if you change
>> something drastic or make the code more strict. Failure would need to
>> change a bit more often, depending on how strict we make the code.
>> Regression testing will probably change often, as they are there so you
>> *understand* that you are changing behaviour, even if undocumented.
>> I'm not aware of any buggy tests, but do let me know if you find one,
>> and while at it, if possible, try and fix them.
> The tests for hot event was completely backward and wrong. Don't worry
> when I find a bugs I fix it.
OK? Mistakes happen.
>> You have to also remember, these tests have been with us through a few
>> Eo rewrites. They have been here from day 1. :)
> They would benefit from some cleanup for sure and to be closer to an unit
They are both unit and regression, as I said, they cover a lot. They
maybe could benefit from a cleanup, but they are still much better than
literally any other suite we have or ever had in the efl. Focus on
>>>> If you mean just compile them together, then there's no point in it.
>>>> I know why you want to do it, you want to do it because you put Efl.Future
>>>> inside libeo.so, but the correct thing to do is probably not to put it
>>> I don't want to just compile them together. I want to merge there
>>> headers. Make it just one library. Make efl.object, efl.future and
>>> efl.loop one core. Obviously because I want to see efl as providing a
>>> core asynchronous library with defined pattern. One asynchronous
>>> pattern is "events", which is like an UDP broadcast (default
>>> behavior)/multicast (with effort) solution. Efl.Future is more the
>>> equivalent of a TCP connection. I think providing one without the
>>> other is going to push for a world of broadcast solution which is not
>>> always the right pattern. Maybe we should remove events support from
>>> Eo to avoid this problem.
>> Of course also merging the headers. What I meant is: you want a cycle
>> dep. Mutual reliance.
> They need it. efl_future_link is the perfect example. How can you link
> the life time of a future to the one of an object without having that
> function in efl.object, where it belong.
Have a mixin/interface that implements the relevant interface for
objects that are loop aware (and thus can use promises). This is how it
should have been done, not sure what you are doing now.
>> It's not really a broadcast, because you need to register to listen.
> It is a broadcast. My computer receive all broadcasted packet on my
> network all the time, the same as an object will always receive events
> even if nobody is listening to it. Some, like animator, are
> implemented like multicast, where you have to actually register an
> event to get the signal propagated to the object.
Object will always receive events: you mean callback_call? That's some
definition of receiving events. The event is never really "emitted" if
no callback is registered. That's arguing about bullshit lingo though.
Events are not called. I have no idea what you are talking about.
>> Removing events from Eo is not the way to go. If you want an async
>> pattern, do it up the stack (even eolian) and encourage it there. People
>> who use the loop will use it. The same way people use Evas when they
>> want it (not trying to make a funny comment, literally, people include
>> Evas.h when they want to use it).
>> Quite a similar example that reveals better what I mean and see:
>> Let's assume we have a TCP class. You want to add HTTP support to the
>> EFL so you are adding an HTTP class that inherits from it. Now your
>> argument is that you want to merge them because you want to encourage
>> people to use HTTP and not roll their own protocol and arguing that if
>> not that so at least move the port_set (events) function somewhere else.
> Thanks for the example. You need TCP to build HTTP. If there wasn't
> TCP in the IP stack, you would reimplement it in every protocol up the
> stack on top of UDP. Would not be fun at all. FTP, SSH, HTTP over UDP
> ? With all the fun of trying to reinvent the session thing. My
> argument stand that you want to have a async request mecanism in efl,
> because you want all this protocol on top to rely cleanly on it and
> not reinvent a bad interface or make mistake.
Huh? I don't understand your example. You need TCP (Eo) to build HTTP,
and it's available for you. You are not reimplementing anything. FTP
would also inherit from TCP, it doesn't need to know about HTTP.
I'm really confused.
enlightenment-devel mailing list