- User Since
- Dec 2 2013, 11:58 AM (355 w, 6 d)
Mon, Sep 21
What you describe is definitly a bug which should be fixed yes.
Fri, Sep 18
Making the unregister in line 231 conditionally for not widgets should fix that.
Thu, Sep 17
Oh okay sorry - my brain fully worked in phabricator terminology there :(
@n3rdopolis can we just use your mail address nerdopolis <firstname.lastname@example.org> for landing this ?
You can get the raw diff just here by clicking above "download raw diff".
Mon, Sep 14
- This breaks legacy drop targets on none efl.ui.dnd elements.
- This breaks registering 2 events, unregistering 1 -> no event will be delivered anymore.
Thu, Sep 10
_layout_get_hyphenationwrap also needs to protect against wordbreaks beeing NULL (as its now checked before).
Mhm, there are a few things that are not right in the way it is done right now:
- false as argument to install_dir is deprecated, the entire configure file blog should be moved to the first if clause.
- the prefix of efl can be different to the prefix of gdb, (for me efl goes to /usr/local/ and gdb goes to /usr/, gdb loads /usr/local as well as /usr/), so dir_lib actaully needs to be gdb prefix here, not the one of efl.
Aug 29 2020
Thank you for your reply, i think the question here is if we want to cover our buildsystem for this usecase or not as this could get quite messy. @stefan_schmidt What would you say ?
Aug 19 2020
Just my two cents: I think the tests should unconditionally run with the respones files, and not only if PATH_MAX is too small, this way we can ensure that the respone file is tested on any maschine that runs the tests.
Aug 14 2020
Maybe as a quickfix it would be good to *not* call eina_file_close_from at all for now we only have that since 8 months. (And additionally, add a ok into the for loop)
Aug 13 2020
Mhm, there is more: if a application has 2 threads running, and the other thread is in a critical section in malloc when we are calling fork, eina_file_close_from will never come to call realloc, which ultimatly deadlocks the child process, deadlocking the parent process on the read call. (That is also something the links given by @eagleeye are suggesting)
Undependend from whatever the reason for this deadlock is:
Aug 10 2020
Mistake found, give me a few hours to run tests.
Aug 8 2020
mhm, this issue is a quite weird, libbuffer.so should be renamed by a post installation script.
Would you mind answering / doing the following:
- Share the log of your "ninja install" invocation ?
- Which distro are you on?
- Which meson version are you on ?
- Whats your process of building efl ?
Aug 6 2020
Seems good. Thx.
Aug 5 2020
add comments and a nicer for loop
But yeah, i will write more comments for the code there.
@kimcinoo should we adjust that behaviour in cycle ? (Same argument applies there)
rebase & commit message update
Okay, i will wait with landing.
I guess this diff is not about the concept, i will just load the old version of it.
Mhm yeah, that is true. But on a conceptual level i am not sure if it is a good idea to do this, as there is no assertion the correct audio & visual are done, and thats kind of the point of the extension...
Yeah sorry, i missed the assignment, look good to me. (I wont land, waiting for @jsuya.
Aug 4 2020
I think this is also a case for a eina_safety_on_null_return, as this should simply never happen.
can you make a safety check out of that ? I dont think we should continue there if access data is missing.
im is already checked in this function, and ensured to be none NULL.
eina_unicode_utf8_to_unicode can only return NULL on memory allocation, i think its better to have have a early return of NULL when udelim is NULL.
I dont think this is really what you want.
you can also just use eina_streq, which does NULL checking.
Aug 2 2020
Mhm :( yeah, now the times are not great anymore ... :|
471.34 msec task-clock:u # 0.964 CPUs utilized 0 context-switches:u # 0.000 K/sec 0 cpu-migrations:u # 0.000 K/sec 7,327 page-faults:u # 0.016 M/sec 1,513,816,860 cycles:u # 3.212 GHz 2,246,871,347 instructions:u # 1.48 insn per cycle 375,434,454 branches:u # 796.526 M/sec 4,104,794 branch-misses:u # 1.09% of all branches
mhm, there is *no* chance that fslider can be uninitializied ?
Jul 31 2020
This looks really nice otherwise :)
For the record:
Jul 29 2020
address review comments
Will update later or tomorrow :)
Jul 28 2020
Jul 27 2020
Jul 17 2020
I can do that if that helps anyone reviewing it. But its all the same ... :)
Jul 16 2020
Jul 6 2020
Mhm, can you elaborate why this is needed ?
As of right now, the package_c_args from the lib will be in package_c_args in meson.build:449, so i think this is currently unnessesary ? Where exactly was or is the missing symbol ?
Yeah time to remove it. https://i.pinimg.com/originals/28/5b/d8/285bd859271e26b94c3ce54881d0bddb.jpg
Jul 3 2020
Patch does not apply ...
Jul 1 2020
Note to myself, dont comment before awake: https://travis-ci.org/github/Enlightenment/efl/builds/703813078
Jun 30 2020
Jun 27 2020
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...
Jun 25 2020
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 :)
Jun 19 2020
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.
Jun 17 2020
This looks fine, however, this is a ecore hash implementation that hasn't been running for > 10 years ... should we just remove it ?
Jun 16 2020
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.
Jun 15 2020
Jun 14 2020
Jun 10 2020
@ali.alzyod since you have asked yesterday if there is anything. Does that ^ look like something you would be interested in ?
Jun 9 2020
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 ...