Summary:
OK, so, ALL interpolator parameters were called "factor" and the docs
literally said "First factor, Second factor, ..."
After diving into the actual implementation, proper names (and types) for the
parameters were found and proper docs written.
I am afraid I could not make any sense of the Divisor interpolator code. Those
docs still need writing.
Test Plan: Everything still builds and passes tests. No functional changes.
Reviewers: zmike, cedric, bu5hm4n, Jaehyun_Cho
Reviewed By: bu5hm4n
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10603
This leverage the new infrastructure from Eo that provide a scheduler for any event
attached to any object.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10481
As we do not rely on legacy Ecore Event directly anymore, we do not
need to mind the shutting down of EFL.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10477
if a legacy timer callback returns false, the timer is deleted. in the
case where the legacy timer is deleted inside the callback while the same
timer is ticking recursively, however, the deletion must be deferred until
the outer-most frame of the timer's callstack has returned from the callback
in order to avoid improperly handling the timer
@fix
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10545
if the currently-processed timer is recursively deleted (efl_del) while
it is inside the timer tick event callback, we must correctly handle this
case:
* in the place where a timer's inlist is de-linked, we must check to see
if the timer is the current timer and then update that pointer with the next
timer in the list
* in the post-tick part of timer processing, we must NOT update the current timer
pointer if we detect that it has been updated recursively
this fixes processing of timers in the mainloop to trigger more than one legacy timer
per mainloop iteration and likely has some (positive) impact on mainloop throughput
@fix
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10515
Sometimes message is appended when message queue is walking.
In this case, newly added messages are not filtered.
So I add message pending queue for filtering message.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10459
Summary:
this is mainly useful for unit testing, but unsetting values should not be
treated as an error
Reviewers: segfaultxavi
Reviewed By: segfaultxavi
Subscribers: segfaultxavi, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10412
Summary:
this is always a pointer to a stack variable
CID 1405799
Reviewers: cedric
Reviewed By: cedric
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10444
Summary:
it's possible that _ecore_get_epoll_fd() can return -1, so ensure that we
correctly handle this
CID 1383850
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10394
Summary:
it seems like this was intended to be handled already, but somehow it wasn't...
ref T8321
Depends on D10358
Reviewers: cedric
Reviewed By: cedric
Subscribers: bu5hm4n, cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8321
Differential Revision: https://phab.enlightenment.org/D10359
Summary:
This is not the end of fixing eolian errors. I need to keep fixing
more.
Test Plan:
1. export EOLIAN_ENFORCE_SINCE=1
2. ninja
Reviewers: q66, segfaultxavi, zmike, bu5hm4n, Jaehyun_Cho
Reviewed By: segfaultxavi, Jaehyun_Cho
Subscribers: Jaehyun_Cho, stefan_schmidt, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10370
Lots of EO files had the same information at the property and set/get level.
Removed the redundant bits, and moved to the property level the common ones.
Set and Get documentation should be used only to clarify setter-only or
getter-only behavior.
I'm afraid but this breaks the mono bindings too close to a release.
This also fixes the missing docs errors by adding a lot of inconsistent
placeholder text ("No description supplied.", "TBD") which will make
finding them later on more complicated.
I was the one that asked for this feature but it is not critical at this
point, so I suggest we explore some refinements (like T8291) before landing
this patch in its current state.
This reverts commit 2946cb3c32.
The things that require docs include classes, variables, typedecls,
events and methods/properties. Implements, params, returns, parts
and struct/enum fields don't require them.
Empty/whitespace only string does not count as documentation.
see the _eina_thread_internal() function
r = c->func((void*) c->data, eina_thread_self());
The second param has been missed in ecore_thread_worker, ecore_direct_worker functions.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10073
Summary:
Eolian supports reporting the defaults for parameters and return values, but in some
places we have been writing this information in the documentation instead.
This patch moves it to its proper place, where documentation generators can pick it up
and render it in a consistent manner.
Ref T8171
Reviewers: zmike, bu5hm4n, lauromoura
Reviewed By: lauromoura
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8171
Differential Revision: https://phab.enlightenment.org/D10051
this adds 4 more signal handling fds and loops over them for reading/writing
signal info in order to handle more signals when the buffer of one (or more)
pipes is full
also update the unit test to verify that we are receiving all the events without
dropping any and bump the number of signals to 2000 since we should now be able to
handle that many
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10027
if any efl-based process receives a bunch of signals in a short period of
time, it will deadlock in the signal handler. this is unavoidable given the
current signal handling architecture
by setting nonblock, we can at least avoid deadlocking even if it means we'll
be losing signal events
@fix
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10025
we couldn't have multilpe listeners before. now we can. better this
way. have to do this now because i can't mark efl task as @beta
without taking out massive wads of efl with it.
Summary:
the following commits did not correctly add super calls to the destructor,
resulting in a massive number of build errors as well as some unit test failures
ref e51699afbc
ref 38be95b0b6
Reviewers: raster, lauromoura
Reviewed By: lauromoura
Subscribers: lauromoura, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9902