This brings in the possibility to receive the app object from bindings.
With the app object you can listen to pause / args / terminate / resume
events.
fix T7509
Differential Revision: https://phab.enlightenment.org/D7480
Summary:
In the case when you have multiple future in flight related to one object, you
couldn't use the previous version of efl_future_then. Now all function calls
take a void* pointer that allow multiple future to have their private data
request data accessible in all the callback.
This should not break released API as Eo.h is not released yet and so
was efl_future_Eina_FutureXXX_then.
Depends on D7332
Reviewers: felipealmeida, segfaultxavi, vitor.sousa, SanghyeonLee, bu5hm4n
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7472
Differential Revision: https://phab.enlightenment.org/D7379
a new shiny buildtool that currently completes in the total of ~ 4 min..
1 min. conf time
2:30 min. build time
Where autotools takes:
1:50 min. conf time
3:40 min. build time.
meson was taken because it went quite good for enlightenment, and is a traction gaining system that is also used by other mayor projects. Additionally, the DSL that is defined my meson makes the configuration of the builds a lot easier to read.
Further informations can be gathered from the README.meson
Right now, bindings & windows support are missing.
It is highly recommented to use meson 0.48 due to optimizations in meson
that reduced the time the meson call would need.
Co-authored-by: Mike Blumenkrantz <zmike@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7012
Depends on D7011
Summary:
This reverts commit 4917910b49.
4917910b break backward compatibility.
Reproduction:
void pipe_handler(...);
pipe = ecore_pipe_add(pipe_handler, NULL);
ecore_pipe_write(pipe, NULL, 0);
Because of the null check condition, pipe_handler isn't called after 4917910b.
Some apps behavior which is written to expected to call pipe_handler was broken.
also, this patch fixed segfault during build on Windows
Test Plan: make on Windows
Reviewers: raster, zmike, vtorri
Reviewed By: zmike, vtorri
Subscribers: woohyun, cedric, #reviewers, #committers, zmike, vtorri
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6824
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:
this caused DSO linker issues when enabled and was only testing
init+shutdown for a deprecated component which has not been actively developed
in some time
Reviewers: devilhorns, ManMower, bu5hm4n
Reviewed By: devilhorns, ManMower
Subscribers: bu5hm4n, ManMower, cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6539
Summary:
these tests will fail if run with root permission, so avoid checking them
when run as root
ref T7094
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T7094
Differential Revision: https://phab.enlightenment.org/D6534
Summary:
ibus module will refuse to load if DISPLAY is not set, so avoid failing
for no reason in this case
Depends on D6433
Reviewers: ManMower, bu5hm4n, devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6434
Summary:
these tests explicitly call ecore_imf_init, so they must call ecore_imf_shutdown
even on failure cases to avoid propagating their failure to subsequent tests
ref T7085
Reviewers: ManMower, bu5hm4n, devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T7085
Differential Revision: https://phab.enlightenment.org/D6433
Summary:
tcase_name() was added in 0.11.0 (2016), which is still not widely enough
distributed to rely upon without version checks
Reviewers: stefan_schmidt, ManMower, devilhorns
Reviewed By: ManMower
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6260
Summary:
this is mainly to handle the case of ecore-file, which fetches external
resources during the test and requires an active network connection which
may fail to resolve/connect/download during the test. if this particular test
fails then it is almost certainly a network issue
a future patch should implement some form of http server to remove the
dependency on external network resources
also probably all test suites should have timeout timers just in case
fix T6950
Depends on D6205
Reviewers: stefan_schmidt, cedric
Reviewed By: cedric
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T6950
Differential Revision: https://phab.enlightenment.org/D6206
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
This reverts commit 2fb5cc3ad0.
Most of this change where wrong as they didn't affect the destruction
of the object. efl_add_ref allow for manual handling of the lifecycle
of the object and make sure it is still alive during destructor. efl_add
will not allow you to access an object after invalidate also efl.parent.get
will always return NULL once the object is invalidated.
Differential Revision: https://phab.enlightenment.org/D6062
Summary:
each test case can run in parallel, so this provides a ~300% speedup
ref T6850
Depends on D5904
Reviewers: stefan_schmidt
Subscribers: cedric
Maniphest Tasks: T6850
Differential Revision: https://phab.enlightenment.org/D5905
Summary:
these aren't tested so don't init/shutdown for every test
ref T6850
Depends on D5903
Reviewers: stefan_schmidt
Subscribers: cedric
Maniphest Tasks: T6850
Differential Revision: https://phab.enlightenment.org/D5904
Summary:
* check inside thread callbacks whether thread has been canceled
* clean up (global) objects
* wait for threads to die before exiting each test
ref T6851
Depends on D5889
Reviewers: stefan_schmidt
Subscribers: cedric
Maniphest Tasks: T6851
Differential Revision: https://phab.enlightenment.org/D5890
Summary:
this function is just a wrapper, avoid downloading the same file
multiple times
ref T6853
Depends on D5885
Reviewers: stefan_schmidt
Subscribers: cedric
Maniphest Tasks: T6853
Differential Revision: https://phab.enlightenment.org/D5886
Summary:
while it may be the case that we do not control example.com, it is also
the case that loading anything from enlightenment.org takes 10+ seconds
longer (at minimum) than loading example.com
ref T6853
Depends on D5884
Reviewers: stefan_schmidt
Subscribers: cedric
Maniphest Tasks: T6853
Differential Revision: https://phab.enlightenment.org/D5885
Summary:
unit tests should verify only small pieces of functionality to ensure
that they are testing what they claim to be testing
fix T6852
Depends on D5882
Reviewers: stefan_schmidt
Subscribers: cedric
Maniphest Tasks: T6852
Differential Revision: https://phab.enlightenment.org/D5883
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>
1 test was wrong. it didn't wait for the thread to exit before checking
msg count recieved. fixed. race condition here.
also reduce the sheer message counts sent - it makes the suite take a
lot longer than is sane and als consume massive amounts of log space
in /tmp as a result.
rthe ecore file download test was downloading from sf.net ... and i
noticed sf.net refusing thus the ecore tests suite failing... i
changes it to grab a file (rss.php which is disabled for us but there)
so at least enlightenment.org has it.
better would be to spawn a webserver and test against that locally.
but thats a whole other level of work.
so the MAIN loop is actually an efl.app object. which inherits from
efl.loop. the idea is that other loops in threads will not be efl.app
objects. thread on the creator side return an efl.thread object.
inside the thread, like the mainloop, there is now an efl.appthread
object that is for all non-main-loop threads.
every thread (main loop or child) when it spawns a thread is the
parent. there are i/o pipes from parnet to child and back. so parents
are generally expected to, if they want to talk to child thread, so
use the efl.io interfaces on efl.thread, and the main loop's elf.app
class allows you to talk to stdio back to the parent process like the
efl.appthread does the same using the efl.io interfaces to talk to its
parent app or appthread. it's symmetrical
no tests here - sure. i have been holding off on tests until things
settle. that's why i haven't done them yet. those will come back in a
subsequent commit
for really quick examples on using this see:
https://phab.enlightenment.org/F2983118https://phab.enlightenment.org/F2983142
they are just my test code for this.
Please see this design document:
https://phab.enlightenment.org/w/efl-loops-threads/
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.
this moves existing tests out of the ecore suite and into a new one,
adds some checks to verify loop object parenting, and verifies compile
for Efl_Core.h and Efl_Net.h using EFL_NOLEGACY_API_SUPPORT
Summary:
This patch checks for the valid types.
As mentioned API reference documentation, user must know its type before hand.
The type should be chedked like previous efl version and ecore_event_type_flush_internal()
Test Plan: Execute a ecore test suite.
Reviewers: cedric, raster, jpeg, stefan_schmidt, Jaehyun_Cho
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5776
Summary:
This patch checks for the valid Ecore_Fd_Handler_Flags.
The flags should be checked like previous verion because
There are no default handlings in case of out of Ecore_Fd_Handler enum values in other funcs.
Test Plan: Execute a test case
Reviewers: cedric, raster, jpeg, stefan, Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5775
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
- Add missing ecore_shutdown
- Reinstate supposedly silly test case (see previous commits, the main
loop object can in fact die cleanly).
- Disable really silly test cases (inner main loops aren't meant to
work)
Summary:
The ptr_null/nonnull were added in the 0.11 version of libcheck. The
required version in configure.ac is 0.9.10 (some distros still use this
old one).
Reviewers: felipealmeida, stefan_schmidt
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5220
ecore_test_ecore_thread_eina_thread_queue_t6 failed often for me.
eina_thread_queue_wait() was returning NULL.
I believe this is because the test case ended abruptly without
waiting for the threads to finish. Indeed, both threads tried
hard to reach 10000 messages but it didn't make sense for them
both to reach this value, only one would end there.
This patch adds an exit message sent by thread 1 to the two other
threads, and all threads are waited upon using a single semaphore.
Note: This also renames some functions to match their test case
number.
@raster
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.
While running ecore_suite, I, some times, see a failure in the thread queue test,
sadly I can't reproduce it while just executing :
CK_RUN_CASE=Eina_Thread_Queue ./tests/ecore/ecore_suite
as per mailing list discussion about dropping xcb support now. it
hasn't been complete for a long time, thus not recommented for being
turned on. as we are moving to a wayland world xcbmakes even less
sense. as agreed, time to clean up a bit and remove a distraction as
well as not well tested code. this also updates po's too.
@feature
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.
Cedric BAIL
Marcel Hollerbach
Cedric BAIL
Yeongjong Lee
Hosang Kim
Mike Blumenkrantz
Mike Blumenkrantz
Stefan Schmidt
Carsten Haitzler
Myoungwoon Roy, Kim
Vincent Torri
Lauro Moura
Jean-Philippe Andre
Gustavo Sverzut Barbieri
Guilherme Iscaro
Vitor Sousa