This seems to have been gone a long time ago and only references left
that have not been disturbing the build. Time to clean up!
Signed-off-by: Stefan Schmidt <s.schmidt@samsung.com>
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10793
This has not been used for a while and is not even buildable after our
switch to meson. It was a niche to start with given that it needed the
PS3 OS to run on. I asked for any remaining users at EDD and on the list
but heard nothing. Time to remove.
Signed-off-by: Stefan Schmidt <s.schmidt@samsung.com>
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10778
Summary:
Value types are already assumed to be stored by pointer (e.g.
`int val = *(node->data);`)
This commit just changes the current usage of the `ptr` modifier in the
ptr, not affecting the parser.
Reviewers: q66, segfaultxavi, bu5hm4n, felipealmeida
Reviewed By: q66
Subscribers: cedric, #reviewers, #committers, brunobelo
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10769
close all fd's starting at a given fd and then leving out an exception
list specially passed, if any. useful for fork+exec. this uses it in
efl's fork+exec paths.
@feat
When timer is not created, a crash occurs.
For example, when user create ecore timer in the pthread..
Of course this is not the correct usage, but printing ERR message is enough.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10714
`efl_access_action_actions_get`
the list is created by `eina_list_append`
`efl_ui_format_values_set`
the accessor is freed in that function.
`efl_ui_format_values_get`
The accessor is created by `eina_inarray_accessor_new`
`efl_core_command_line_command_access`
The accessor is created by `eina_array_accessor_new`
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10720
It is impossible to reuse iterator after `EINA_ITERATOR_FOREACH`(`eina_iterator_next`).
E.g.
```
eina_init();
eina_file_dir_list("/home/", EINA_FALSE, _print_cb, NULL);
it = eina_file_ls("/home/");
EINA_ITERATOR_FOREACH(it, f_name)
{
printf("%s\n", f_name);
eina_stringshare_del(f_name);
}
EINA_ITERATOR_FOREACH(it, f_name)
{
printf("Again %s\n", f_name);
eina_stringshare_del(f_name);
}
eina_iterator_free(it);
```
`Agian ...` is never printed.
Therefore, iterator always need `@move` tag to avoid unexpected behavior without
any error message.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10719
The upper mask is the one that should actually move as the gap is between the lower and
the upper mask when removing an element from the array.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10632
The composite model was erroneously giving the reference to a children composited model
instead of the origianl children which made it impossible for the composited model
to delete the right child.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10631
The children removal event is happening on the parent model, so access
values directly.
T8358
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10623
Summary:
Instead of a getter with an explicit return type, change it to be a
single-valued property.
The eolian C generator takes care of making this single value the actual
return value of the C function.
This also makes these properties able to be reflected on.
The stack properties returns just a pointer and not a new ref, so no
@move needed.
Beta properties will be handled in a future commit.
Depends on D10601
Reviewers: segfaultxavi, bu5hm4n, q66, cedric
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers, brunobelo, felipealmeida
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10602
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