I can confirm it changes nothing ;)

yes. I made sure with -u NONE that it was not a fancy plugin that caused the problem. I'm using NVIM v0.3.1 by the way

Here is valgrind's log:

Okay, looks good to me.

Mhh.. it works for me. I've made a patch. Hopefully it will solve the problem.

Mhh,.. I'm actually not quite sure why just changing the initialization value in the constructor from -1 to 0 is not the way to go.

Oh wait... ecore code seems wrong

Well, it seems that

It crashed again this night... but there is too much eo stuff... What I can see is that the data field of Efl_Loop_Message is NULL (that's the final NULL ptr)

It is pretty hard to reproduce, as it usually happens over night (but not regularly). I'll investigate the next core dump.

I don't know if this will help, but ecore_cocoa_clipboard_set() (that calls evas_textblock_text_markup_to_utf8) is beta API (the whole cocoa clipboard API is). It was (badly) designed to be used by Elementary only. Maybe the caller of this function can run the evas_textblock_text_markup_to_utf8() first, and pass its output as the data parameter?

Actually, on EFL commit c57b3912a5f65632e17b023d9c12ae6e1fcc819a, I still have this problem.

I'd prefer to use unsigned x : 1; instead of bool x : 1;.
I personally am not a fan of bitfields, because of their undefined and implementation-defined behaviors and the fact they are not always well-handled by compilers (e.g. Diab).

This seems to have been fixed :)

+1 on this one!
Btw, I don't understand one would like to write a bool bitfield instead of using a proper integer type .

In T6768#113251, @indefini wrote:

Maybe most people want a roadmap, but they don't feel the need to participate to it?
or they might propose changes to it later?

Hi, not on this differential. I think you can safely close this one.

This is interesting. On my machine, results are always better, but I see you have a wider range of materials to test on :D
Also, sorry for taking to long to reply, but since I do not work professionally on the EFL, the time I can allocate to that sometimes changes without warning :/

• I didn't thought about vectorization taking more CPU. I'll have a look. But I've seen less time spent by frame.
• My _ are just visual separators, they have no meaning to the measure. You can see it as a non-secable whitespace

This is a first commit round addressing T6580. Please let me know what you think about it.
To measure the performance impact, I've used the following script: python3 ./run_bench.py. It spawns elementary_test with autobounce, and collects the results. It produces a final data.csv that aggregates the results. A mean is displayed on stdout at the end of the runs.

I've made some progress on the _eo_obj_pointer_get. I'm not really sure why there was two tables to reach the final pointer, but I now use only one table. So I end up with one less indirection. I managed to grab some more precious frames by using aggressive inlining of code per domain and a jump table with pointer to labels (I've always wanted to use that!!). And finally, I used the AVX2 vectorization to retrieve in one go the information from the Eo_Id.

the ptr indirection is hugely helpful in stability. i don't think we should drop it at all. we should get it to be faster though.

@netstar this time it is not thanks to me, someone made a fancy patch that happened to fix the build :)

Fixed by some Christmas magic :)

Yes, when I wrote EAPI, it is because EWAPI expands to EAPI and something else I don't remember.

If EAPI is not defined when those symbols are encountered, we are doomed.
In elc_ctxpopup.c for example (which includes elm_ctxpopup.eo.h, and therefore has the first DECLARATION of _ELM_CTXPOPUP_EVENT_DISMISSED) we already are outside of Elementary.h, so that's dead.

@raster sorry for breaking efl first, but 036cf62cc7bb1c5cb743f6d28f4b6c5fc024a414 broke the build on macOS.

And now:

And there are cyclic includes as well:

What was done in evas_font.h in D5419: Remove evas internal dependency from the evas_font module seems pretty weird to me. Why do we re-define EAPI there?

I have this:

I'll have a look at this, haven't built efl on mac for a while.
It would be much nicer if we had a meson build to speed up build time :/

Okay, now I better understand where you were going. How about the rationale: if you use a module, it is that you will use it (#include in C, import in python, something else in some other language). So if you do the following in C:

I can roll with that. A helper to sort out just the exit code would be nice.

My grain of salt:

Still seems weird to me. We (EFL) don't do anything with this value, I think this is really up to the user to pass whatever it wants. So int _seems_ more appropriate to me.
If we want to support anything, why not pass a void*? (this is a real suggesion) So one can do this (in python for instance):

While you are thinking, I re-open the issue, just so it does not get forgotten ;)

Bigger than an int, I'm not sure, since it is against the C standard. But my point here is that systems may (and do) return bigger than unsigned char.
Windows does (https://msdn.microsoft.com/en-us/library/windows/desktop/ms683189(v=vs.85).aspx).

But isn't that a bit too POSIX-specific? The C standards (§5.1.2.2.1) states it shall be an int. since int is compatible with unsigned char, why not being closer than the C standard rather than a specific implementation?

Sorry, but why is this an unsigned char instead of an int?

Lol. Found (at least for the edje_cc stuff). Commit will follow... shame...

and I got EINA ERROR: resource busy on mutex_destroy 0xblabhabl
Than it exits normally (seems legit, since we didn't join the right id
But I also don't have 100% clean code, since I've reworked this file a bit.

seems dreadful :D I'll try this out, though.
What really bugs me with this file is have the conditions are handled

Ahah here is the explaination of why eina_thread_join() does not return :

My take on the problem would "just" be memory corruption. Something that valgrind could easily spot, if it was available... But on the other hand that seems macOS 10.12 SPECIFIC. And I don't like that...
I've also noticed ununderstandable thread join behaviour (that were not present before). eina_thead_join() does not return in some cases, even though the thread did exit. Since the threads are joinable, the only reason I can think of is that there was an earlier memory corruption. Also, when lldb is fired up, eina_thread_join() always return! Yay!
I've suspected the eina_freeq for some time, but couldn't prove it's involvment. What is funny is that when graphics are involved (i.e. elementary), it's eina_module that goes rogue.

Nooooooooooooooooooooooooo... it spread to edje_cc making build break on master...............
and diff between efl-1.20 and master does not show anything suspiscious...

Hi, seems to work fine on macOS 10.12 as well:

I'm pretty sure git bisect will be of no use. The bug has been there for a loong time. Also, since the osx build has been broken multiple times, over large commit periods, bisecting is trumendeous hard.
I've actually tried to bisect at some point, but since I'm taking about 20 minutes to build efl (even with a lot of things disabled), I found this unfeasible.

@stefan_schmidt unfortunately valgrind seems to still not have decent macOS 10.12 support, making the thing still hard to pinpoint.
I don't know if the kludge is worth it, as I've experienced the crash in some situations even with the kludge on.
I'll spend some time today on this... hoping for the best...

@stefan_schmidt Here is the evil: https://git.enlightenment.org/core/efl.git/commit/?h=devs/jayji/kludge
Feel free to push it/rewrite the description if necessary.

We still have this as a release blocker here. Any chance we can narrow this down a bit?