Thank you!

Patch does not apply ...

thx.

Note to myself, dont comment before awake: https://travis-ci.org/github/Enlightenment/efl/builds/703813078

https://travis-ci.org/github/Enlightenment/efl

In D12034#229727, @felipealmeida wrote:

I don't want to install an application to be able to compile or download dependencies. This makes no sense at all IMO. If we're not going to have wrap dependencies, we still need to be able to tell where dependencies are without pkg-config. We have neither, and wrap dependencies is a meson feature which, IMO, helps a lot. Lots of other libraries use it (gstreamer for example). And this doesn't need to be on by default. I wouldn't need subprojects in Linux (though I've used subprojects for gstreamer when developing for it, and was much easier when using git versions).

Hi bu5hm4n.

I am not really a fan of using subprojects here either, not because subprojects per se are bad, but they dont fit the scheme of efl and how distros work. Just from the top of my head a idea on why i dont think its a good idea:

• In case we are having subprojects, we are defining the version of a dependency, not the min version of anything, the version itself is then defined, in case there is a CVE or some major bug, we need to proactivly reroll another release of efl bump versions etc.. Not sure we have the capacity in the release department for that CC @stefan_schmidt )
• Not all meson projects can be used as subprojects, some require external dependencies, in case some code compiler is compiled, cross compilation will fail.
• Sometimes wraps do disappear (example stb, there is still the entry in the wrapdb, but the wrap in gone) in case we ever rely on wrap, we also need to take a share on maintaining the wraps, or we might loose them
• Subprojects bring the harm of 2 providers, so in case zlib-wrap is now sucked in as a dependency instead of a libzlib.so on the system, then the subproject wlll be compiled, and with the next ninja install it will be installed. In case you use any other project doing the same thing, or the distro shipping zlib as standalone, you will end up in a ugly conflict...

With these two comments, then: should I split 6 and 8 into two other patches? For 6 because we can track this in an isolated patch, and for 8 because of possible opinion divergence.

Sounds good :) (If getting out 8 is too much work, i dont have a issue with first merging that if the rest of the stuff is coming in a next patch :))

First Half of the issue

I think you can just remove the _dep prefix from these 4 vars ... no big deal, there is really no thought behind that scheme, just make sure the names do not collide :)

Independend from if this is a good idea or not, things that are not clear to me:

• How to do that in eolian ? Every eolian API is defined with EOAPI, which is defined to be EAPI & EAPI_WEAK with this approach you either need to patch eolian to take the correct preprocessor directives (then eolian needs to guess in which lib it is), or you need to redefine EOAPI which is then reintroducing the thing you are trying to solve
• How to handle EAPI's in modules ?

1 / 2 / 3 / 4: fine for me.
We recently bumped min version to 0.50 so 5 & 7 Should hopefully work without issues.

This looks fine, however, this is a ecore hash implementation that hasn't been running for > 10 years ... should we just remove it ?

THats good.

Thank you. I checked upstream that we do not assigned parent_obj *ever* by hand. And we don't. Can you ensure the same in tizen ?

Yep, that now looks even better. Thank you :)

Looks good to me, thx.

I think you can go ahead and simply remove these efl_isa calls.

I cannot comment how it was with regards to backwards comp. but shoundn't this also check if the group is the same ?

Beside that little nitpick it seems fine to me.

@ali.alzyod since you have asked yesterday if there is anything. Does that ^ look like something you would be interested in ?

The code *is* the same, Add -O3 and you will just see that the code lines are not mapped to anything in asm. Even on the wegpage. The next example also gets eliminated the cos and sin calls.

Don't look at the times, take a look at objdump -S a.out the outputted asm is equivalent. Also take a look where the calls to clock are located. The time advantage you see is *not* coming from the different call. infact, the sin and cos calls are stripped out completly. As a mixture of inlining, dead code removal, and const folding removed it.

Well, you can transform the realize callbacks to real eo calls, and simply call them from gengrid / genlist, which will eliminate the need for the callback. However, this is not a priority for me, so feel free to do that.

@raster the problem with sqrt calls is that they do not get replaced in *all* compilers, clang on macos is not capable of doing that (i have no idea why). gcc on my raspi is also not doing it here ...

Additionally to what @raster said. Take objdump -a and check out the produced assembler when compiling something with -O3 you will see, that the two loops boil down to absolutely the same asm. Anyways, additionally, even with -O0 the speedup is so little that the bias is higher than the save up, which is more showing that this might save *something* but surely not enough to have an impact.

What i mean is: sqrt(a²+b²) / sqrt(2) can be written as sqrt(a²/2+b²/2).
Additionally if you cast a² and b² to a int, the compiler can reduce this to a shift, eliminating floating point division or mul operations totally, making this even lightweighter than before.
Even more micro optimizing you could write the whole thing as: sqrt((a*a)/2 + (b*b)/2) leaving out a func call, or instruction to floating point pow. This way things stay within none-floating-point op's making it less calc intensive.

Thx!

Thx!

Maybe even dragging it deeper into the formula, resulting in a int operation instead of float operation, maybe resulting in the compiler replacing it with a shift.

I think you can go ahead and drag the division by 2 into the first sqrt, keeping the 2, which is kind of more readable IMO.

I dont mind if we land this or not. But this is not really impacting anything, const folding covered the cases i checked, and if not, then the static double assignment will fail...

Did we ever encounter hanging of a test ?

@felipealmeida Can you take a look here

@felipealmeida Can you take a look here?

Seems to have been another commit that actually breaks it.

I have to say that i do not like eina_api.h. Why not just altering the current EAPI defitionions ?

https://travis-ci.org/github/Enlightenment/efl/builds/694222893

Oh right, i forgot about that ... sorry :/

https://phab.enlightenment.org/D11923 Can you check if this fixes the issue for you?

ooooooooh, do we use vgcommon directly in tests ?

Uuuuuuuuh we dont ? i think we should ?

While i agree on the meson-level, i am kind of wondering why this is needed, rlottie is already added as a dep by the vg loader, why is this additionally needed ?

Damn, i thought this is already landed... sorry :)

Seems to look fine. Lets see if it breaks for someone else ... (Its also kind of weird that there is a free func where you can tell to *not* free the node)

Thx.

I'll give it a look tomorrow :)

Okay cool, thank you :)

Yep, I did not see it until now :)

I really like this, just two things:

• Do you think this is a good idea right now ? i don't know what changes, should we have it already on CI ?
• Can we execute test-efl-one.py build at the end ? That will verify that nothing accidently drags in libeina or smth. like that when there was a build update.

Only this one thing :)

https://phab.enlightenment.org/D11892

Just checked, there is no header in efl/ that is required from eina ... maybe there was at some point and we got rid of it ?

update

https://travis-ci.org/github/Enlightenment/efl/builds/692050736

add a bit more eet