check adds a NULL and this messes the format warning checks in the
check macro - so disable this warning where this is done - warning
noise we don't need.
this recurses the mainloop to a depth of 8, continually creating and
triggering timers as it progresses and tracking the states to ensure that
everything is working as expected regardless of depth
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10547
we need to also verify that timers will process out of order solely based
on their timestamps and ignoring whether they are "recently-added"
additionally verify the behavior of timer interval changing and re-instantiating
ref T8434
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10530
this verifies that:
* newly-created timers are not triggered in the next loop iteration
* newly-created timers can be triggered the second loop after created
* multiple timers can be triggered in a single loop iteration
* timers are effectively added to the pending timer list
ref T8434
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10516
Summary:
Timers are not called in the order they were registered.
Because when current timer is deleted, getting next timer is called twice.
Test Plan:
<error>
Timer1 expired after 0.001 seconds.
Timer3 expired after 0.001 seconds.
Timer5 expired after 0.001 seconds.
Timer7 expired after 0.001 seconds.
Timer2 expired after 0.001 seconds.
Timer6 expired after 0.001 seconds.
Timer4 expired after 0.001 seconds.
Timer8 expired after 0.001 seconds.
<correct>
Timer1 expired after 0.001 seconds.
Timer2 expired after 0.001 seconds.
Timer3 expired after 0.001 seconds.
Timer4 expired after 0.001 seconds.
Timer5 expired after 0.001 seconds.
Timer6 expired after 0.001 seconds.
Timer7 expired after 0.001 seconds.
Timer8 expired after 0.001 seconds.|
{F3268233}
Reviewers: Hermet, Jaehyun_Cho, zmike, SanghyeonLee
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl_tests
Differential Revision: https://phab.enlightenment.org/D6700
unit tests should test one thing only: testing timer accuracy and the
effectiveness of resetting a timer in the same test leads to timing issues,
so remove the timing component from the test
ref T6878
Differential Revision: https://phab.enlightenment.org/D6653
Summary:
a stack variable was incorrectly used here, along with some lazy timing
calcs which did not accurately measure the time for each timer iteration,
resulting in a test which intermittently failed in some cases
fix T6878
Reviewers: stefan_schmidt, bu5hm4n, ManMower
Reviewed By: ManMower
Subscribers: ManMower, cedric, #committers
Tags: #efl
Maniphest Tasks: T6878
Differential Revision: https://phab.enlightenment.org/D6256
individual tests should not need to explicitly call init/shutdown functions
in most cases, and many did not properly do this anyway
see followup commit which resolves some issues with eina tests
ref T6813
ref T6811
Reviewed-by: Stefan Schmidt <stefan@osg.samsung.com>
efl_check.h must be included and the EFL_START/END_TEST macros must be
used in place of normal START/END_TEST macros
timing is enabled when TIMING_ENABLED is set
https://phab.enlightenment.org/w/improve_tests/
Reviewed-by: Stefan Schmidt <stefan@osg.samsung.com>
This reverts commit 135154303b.
Revert "efl: move signal events from efl.loop to efl.app"
This reverts commit 3dbca39f98.
Revert "efl: add test suite for efl_app"
This reverts commit 3e94be5d73.
Revert "efl: create Efl.App class, the parent of Efl.Loop"
This reverts commit 28fe00b94e.
Go back to before efl.app because I think this should be done with
superclassing here not a parent object. reasons?
1. multiple loops per single thread make no sense. so if multilpe loop
objects they wont be contained in a single app object and then deleted
like this.
2. the app object is not really sharable in this design so it cant be
accessed from other threads
3. it makes it harder to get the main loop or app object (well 2 func
calls one calling the other and more typing. it is longer to type and
more work where it is not necessary, and again it can't work from
other threads unless we go duplicating efl.app per thread and then
what is the point of splittyign out the signal events from efl.loop
then?)
etc.
Summary:
This patch checks whether the callback function is valid or not.
Callback function must be set up for the class.
Test Plan: Execute test suite
Reviewers: cedric, raster, stefan, Jaehyun_Cho
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D5762
From time to time we run into trouble with this test. It goes over the, already
increased, limit on Jenkins. Most likely due to high load on the server. Neither
Cedric nor me have been able to pin this down on local runs and we already had
increased it from the initial 0.01 to 0.02 but just today we hit 0.38.
What we do now is to detect if we run on our jenkins and increase the allowed value
while having the intial lower value back for normal local runs.
This test has been failing on Jenkins again and again. After adding the debug
a while ago it now shows that the value is between 0.01 and 0.02 in all cases
I have seen. Relaxing the timeout here a bit to make it pass in situation where
our CI is under load.
It has been discussed on the ML (thread: "[RFC] rename efl_self") and
IRC, and has been decided we should rename it to this in order to avoid
confusion with the already established meaning of self which is very
similar to what we were using it for, but didn't have complete overlap.
Kudos to Marcel Hollerbach for initiating the discussion and
fighting for it until he convinced a significant mass. :)
This commit breaks API, and depending on compiler potentially ABI.
@feature
Now when dealing with pointer types, we will not get pointer to
pointer semantics in callbacks and eina_promise_owner_value_set
for Eina_Promise.
It will work as expected:
Eina_Promise_Owner* promise = eina_promise_add();
void* p = malloc(sizeof(T));
eina_promise_owner_value_set(promise, p, &free);