- User Since
- Aug 14 2013, 1:42 AM (400 w, 2 d)
Jul 26 2020
Jan 6 2019
Jan 5 2019
Jan 3 2019
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:.
Funny, I cannot reproduce with nano/vim. But systematically with neovim (nvim -u NONE).
Aug 22 2018
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.
Aug 21 2018
Oh wait... ecore code seems wrong
Well, it seems that
Aug 18 2018
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)
Aug 17 2018
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?
Aug 11 2018
Actually, on EFL commit c57b3912a5f65632e17b023d9c12ae6e1fcc819a, I still have this problem.
Aug 5 2018
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).
Aug 3 2018
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 .
Apr 6 2018
Mar 26 2018
Mar 25 2018
Mar 7 2018
Hi, not on this differential. I think you can safely close this one.
Feb 26 2018
Jan 23 2018
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 :/
Jan 15 2018
- 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.
Jan 13 2018
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.
Jan 10 2018
Jan 8 2018
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.
Jan 7 2018
Jan 6 2018
Jan 4 2018
Jan 3 2018
Jan 1 2018
Dec 31 2017
Dec 30 2017
Dec 29 2017
@netstar this time it is not thanks to me, someone made a fancy patch that happened to fix the build :)
Dec 28 2017
Fixed by some Christmas magic :)
Dec 27 2017
Dec 20 2017
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.
Dec 19 2017
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'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 :/
Dec 1 2017
Nov 22 2017
Nov 19 2017
Oct 28 2017
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.
Oct 27 2017
My grain of salt:
Oct 26 2017
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):
Oct 19 2017
While you are thinking, I re-open the issue, just so it does not get forgotten ;)
Oct 17 2017
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 (§22.214.171.124.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?
Oct 9 2017
Oct 8 2017
Oct 2 2017
Sep 23 2017
Sep 18 2017
Sep 4 2017
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
Sep 3 2017
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...
Sep 2 2017
Aug 22 2017
Aug 7 2017
Hi, seems to work fine on macOS 10.12 as well:
Jul 16 2017
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...
Mar 24 2017
@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.