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.
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
There may be extraneous slashes that are contained in the returned
generated directories (because they were put there in environment
variables). Since we test with string comparison, some tests would fail
due to different environment setups.
we have some duplication of errors between Eina_Error and errno.h,
however we should use Eina_Error to extend the traditional errno.h
system.
then change eina_error_msg_register() and
eina_error_msg_static_register() to return a magic bit to state the
number was registered, and on other functions test this bit in order
to operate on registered values, otherwise fallback to errno.h, such
as strerror().
It also deprecates 2 clear duplicated errors:
- EINA_ERROR_OUT_OF_MEMORY -> ENOMEM
- EINA_ERROR_TIMEOUT -> ETIMEDOUT
There are two details when using strerror():
- old behavior did not return strings for non-error, such as
"Success" or "Unknown error ${N}"
- thread-safety issues: since we must be thread safe, then use
strerror_r() and eina_stringshare_add() that value, keeping a hash
of cached values
fill in the padding of mesages (10 bytes) with something so valgrinds
can be happy and use vlatiole for msgs count as the msgs num should
have been incremented already before the msg sned is done and main
thread/loop gets the msg
this should make ecore_imf testable with empty env vars also meaning
no env var and the make check test will now ensuree this is set to
exactly test this.
This test is stalling. Locally as well as on Jenkins. I tried to bisect it
without any luck. Even running it from the 1.17 release it does no longer work
so i guess it is some change coming from a pulse update on my system. I have
version 7.1 here. As we have no-one working actively on ecore_audio I disable
the test here and we can track the problem on T4018.
Cancelling a promise will fulfill it but won't actually free the memory. This
memory is under custody of the owner, who must either call value_set or
error_set to finish it.