Indeed, works for me!
Fri, May 3
Tue, Apr 23
Mon, Apr 22
Apr 17 2019
Apr 10 2019
Apr 8 2019
Apr 6 2019
Apr 5 2019
Fixed with D8564 stack
Apr 4 2019
Apr 3 2019
I have pushed in my branch devs/cedric/mvvm a few patch that should solve this. I will push this to phab once the release cycle is done to not pollute things.
Apr 2 2019
This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.
Apr 1 2019
Mar 31 2019
Okay, we hit the weirdest thing that i have ever seen:
A little bit more information:
this is the error log of a failed eio-suite run: https://phab.enlightenment.org/P281
@cedric I think i have found today more of what could be possibily the fact why efl_io_model dies.
Mar 30 2019
I think this is releveant to the release when windows cannot be build with this ?
That is the debugging output i have added there, which shows not at all when eio suite times out on travis.
This does not hang anymore, it just seems to error, this is nice enough to close this i think.
Mar 29 2019
I would recommend putting printfs into the thread you're expecting to run (line by line) and then doing a test run through travis to see what happens.
That sounds rather strange indeed. I can't really think a reason why the listing would not start at all especially because other part of efl io are succeeding in there test. Are any of you able to reproduce the problem locally?
Okay, we have finally the output of a failing eio_suite, after looking briefly through it, is it possible that in some cases on our CI a thread is never executed ? I get 0 of my debugging output, which means, the code did not even start to list the content of '/tmp' which is rather weird IMO.
Yes~ thank you :)
I think this is resolved ?
Mar 28 2019
Given the fact that trais is acting really weird (still not building my patch with debugging output) what do you think about disabling them on travis for now ? DO you have issues locally ? I can try running it on a raspberryPI in a week ...
No, these patches 100% made things worse. Check https://travis-ci.org/Enlightenment/efl/builds not a single run has passed since they were landed and the issues are all related.
@Jaehyun_Cho this was actaully (almost) a one liner, i updated to revision.
Thank you! I think a new patch is required to change the current disabled calculation logic.
Okay, i think i agree with you, given the fact that one widget should always only be altered by one user ... I will update the revision.
Solving this issue is a one liner patch, i am just not too sure if we really want that. Consider this usecase:
I think we have 2 ways to resolve the counting problem.
Although I may not fully understand your point, but I understand why counting way is adapted here.
If a developer just wants to ensure something is disabled, but does not neccessarly want to make it impossible to have this enabled again until he thinks it is time to do so, then he can just check if it is already disabled before disabling the widget ... :)
This only applies to the eo-api not to legacy.
And we are DONE with this!