This was not really useful and against the Eolian guidelines.
While I promised I won't break things until the 27th, I was ill
(still am), so I'm giving myself a 1 day pass. :P
While unrefing twice works, it's cleaner to unref the ref we
have and delete normally. It will handle parnet detachments in
a nicer way, and is just more correct.
This is another cleanup in perparation for the Eo stable release.
This is no longer needed thanks to the proper error reporting with
eo_constructor()'s new return value.
The finalizer change cleans it up a bit so it catches more cases/issues.
This also means that the finalizer cleans up the object in all cases,
and not only some.
@feature.
From now on, constructors should return a value, usually the object
being worked on, or NULL (if the constructor failed). This can also
be used for implementing singletons, by just always returning the same
object from the constructor.
This is one of the final steps towards stabilizing Eo.
@feature
Instead of "@in type name;" we now use "@in name: type;". This change
is done because of consistency with the rest of Eolian; pretty much
every other part of Eolian syntax uses the latter form.
This is a big breaking change in the .eo format, so please update your
.eo files accordingly and compile Elementary together with the EFL.
@feature
This is a convenience macro to be used by the common pattern of getting
a part and then immediately calling functions on it. For example,
without this macro, you'd have to write code like:
Eo *part;
eo_do(obj, part = efl_part_name_get("partname"));
eo_do(part, a_set(7));
while using the helper function trims it to:
eo_do_part(obj, efl_part_name_get("partname"), a_set(7));
@feature
Remove it from the constructors section.
This was wrong. This place is for functions that are allowed to be
passed to eo_add() and should be used by bindings to create
constructors.
This is wrong for both cases, as this should always be called, not
optional.
Also remove the redundant legacy: null.
This is following a last review and a discussion on IRC. Eo has been
stable (apart of a decision a few months ago to support more compilers)
for a long while. Developers are already using it for a while, and it's
stupid to break it for them anyway, so we might as well make this
promise now. There are no plans to change it anymore, and it's been
heavily used and tested throughout the EFL for a few releases now.
I'm tagging it as a feature, although it's not, I'm doing it for the
automatic changelog generation. :)
@feature.
As discussed on IRC and ML. We are in a feature freeze phase, and this
patch is not essential. Furthermore, this patch was never discussed.
This reverts commit 537c7fe9e3.
Summary: Had a chat with raster to understand the behavior of these two functions in the IRC. Thought it might be helpful if added in the documentation itself. So updated it accordingly.
Reviewers: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2083
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This affects eo_do() and eo_add() that used to use the ({}) GCCism.
Following a discussion with Peter de Ridder after my talk at FOSDEM,
we've decided to reopen the GCCism (works with other gcc compatible
compilers like clang and intelc) discussion, and after a bit of back and
forth it was decided to make things more portable, at the cost of ease
of use.
For example:
if (eo_do(obj, visible_get()))
is no longer allowed, the portable alternative
Eina_Bool tmp;
if (eo_do_ret(obj, tmp, visible_get()))
is to be used instead.
However:
eo_do(obj, a = a_get(), b = b_get(), bool_set(!bool_get))
are still allowed and OK.
eo_do(obj, if (a_get()) return;);
is no longer allowed, but:
eo_do(obj, if (a_get()) something());
is still allowed.
For clarity, this commit only incorporates the Eo changes, and not the
EFL changes to make the efl conform with this change.
Thanks again to Peter de Ridder for triggering this important discussion
which led to this change.
The header.id was masked before using it as index in the _eo_classes
array and was not unmasked when used.
It hasn't caused segfault (by sheer luck) but was wrong.
@fix
Before this fix, when a deletion was invoked twice on an object, a
wrong message ("...You wrongly call eo_unref() within a destructor...")
was printed. This was caused by the del_triggered flag that was not
resetted when the destruction finished.
This patch fixes this behavior by printing the right message on a double
deletion.
So I don't really understand why the code was not there before, but it resulted
in my experiment of making a combobox for elementary just impossible. Now it
work at least.
In some cases, invalid object ids (e.g 0x1) would pass validation and
represent completely different objects (0x80...01). This happened because
we weren't properly checking a given object id is actually an object id.
@fix.
For some reason, they were normal functions instead of eo functions,
which makes them harder to bind, less safe, and just wrong.
This commit fixes that.
Now it's more clear and consistent. This commit complements the previous
eo_add commit (a7560dbc61).
Now eo_add should be matched with eo_del
eo_ref with eo_unref
eo_add_ref with eo_unref + eo_del
Essentially, the change is that if you have the ref to an object, you
need to unref it. Thus making ref/unref unneeded for most people who use
things (carefully) in c. If however, you would like to delete an object
previously created by you, you should eo_del (counter-part to eo_add).
It's still recommended you ref/unref when dealing with objects in
scopes, as you can't know when an object might just get deleted as a
by-product of another call.
This fixes an issue found by JackDanielZ.
Before this change eo_add() used to create an object with 1 ref, and if
the object had a parent, a second ref.
Now, eo_add() always returns an object with 1 ref, and eo_add_ref()
preserves the old behaviour (for bindings).
eo_unref now un-parents if refcount is 0, and eo_del() is an alias for
eo_unref (will change to be a way to ensure an object is dead and goes
to zombie-land even if still refed).
This moves the mainloop check inside the function. There was never need
for it to be in client code (i.e a header/macro).
This is better suited inside eo_do_start because this is a macro some
bindings have to re-implement, and we definitely don't want it to be any
more complicated than it has to be.
This breaks ABI and makes elm 1.12 depend on efl 1.11. This is not an issue
as because of eolian and interfaces it's already the case.
eina_tls_get is really slow, having a fast path for the main loop does really
help us right now. It is also unlikely that slowing down a little bit the use
of eo in thread is going to have any impact on application speed any time soon.
I win a +10% on expedite benchmark compared to without.
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This enables checking if an object is being created, or has already been
finalized. This is useful in functions that you want to allow
only during the creation phase (i.e inside the eo_add()).
Comp objects are rare, and since we allow using classes as interfaces,
we end up allocating a lot of memory for something we don't even use.
That's why it was a linked list in the first place, and that's why it
should remain a list.
This is almost a complete revert. I reverted the code itself, and the
intent (use of array instead of list), but not the tests, or the new
return value added to comp_detach, which is useful.
This reverts commit ef09ef7489.
This function lets you hook at the end of eo_add and override it for a
class. This is essentially the first step towards killing custom
constructors. Instead of having a custom constructor, you should just
do:
eo_add(CLASS, parent, a_set(3), b_set("eou"));
eo_constructor is called at the beginning for pre-init things.
eo_finalize is called at the end, for actually finalizing and doing
things. This cleans up the API and possibly saves a lot of things that
would have been stupid and slow in the past, like loading an elm widget
with an existing theme, and then changing the theme.
** This breaks Eo ABI, please recompile elementary and everything else that
creates eo objects.
@feature
Match function names when the API pointer is out of range.
Reviewed by TAsn and modified according to his comments :)
Differential Revision: https://phab.enlightenment.org/D876
We check _current_table for NULL, and then populate it (it's a global)
through another function, but we don't really check it's not NULL before
using it, we just assume because of an indirect other variable.
This confused coveritiy, can confuse humans too, and in general risky
(if something changes).
CID 1039419
Coverity found the issue, but it's an issue we've already fixed in the
past. I don't know how it got lost, but it seems like someone did a bad
merge. Probably when migrating to Eo2.
This reverts commit 831c20464d.
this fixes and eo2 problem where when callstack grows (or shrinks)
and realloc nas to relocate memory, the frame ptrs like fptr become
invalid and all sorts of hell ensues.
this uses mmap so blowing the stack will segv, not scribble over
memory, also its separated from malloc heap, and now big enough to not
need to size ... ever (1024 entries).
due to recent changes a lot of objects are now NULL (correctly) and eo
complains on access of them. it's simply too noisy adding too many
if's all through code, so let's just make eo be sensible here.
It's now completely valid to do:
a = eo_do(obj, a_get());
or:
b = eo_do(obj, a_set(1), b_get());
Also, the default return value for eo2 functions is now also returned
when the object is invalid, not just when the object does not match
class.
It's a small refactor that fixed both issues at once.
@feature
@fix
create/destroy tls key (_eo2_call_stack_key) at eo_init()/eo_shutdown().
use _eo2_call_stack_get() to allocate the stack when required.
register _eo2_call_stack_free() as eina_tls_cb_new() delete callback.
eo_class_new() returns NULL on error in _eo2_class_funcs_set().
it covers: NULL API func, API redefined, dich func override,
overriding non-existing fct.
as op descs are sorted, we can't output fct indexes in error msgs, but
as they are sorted using api_fct as key, we can detect multiple usage of
the same api_fct which leads to an unpredictable call to whatever is
returned by _eo2_api_op_id_get()->_eo2_api_desc_get().
it is still possible to instanciate an object of a not well defined class.
"void func(void)" != "void func()" !
The former is a func that accepts 0 parameters.
The latter is a func that accepts variable number of parameters.
Watch out.
a mixin class must not inherit
- _eo2_api_desc_get()
accept NULL klass param
EO_CLASS_TYPE_REGULAR_NO_INSTANT is an acceptable extension class type for
- _eo2_class_funcs_set() do not shout if parent is NULL
there is no more difference in class or regular functions prototypes and definitions
- eo2_api_op_id_get() uses _eo_is_a_class() at runtime
- add 'void *class_data EINA_UNUSED' parameter to eo2_base class functions
- Eo2_Op_Call_Data.klass is kept only for eo2_hook_call_pre end eo2_hook_call_post,
but could be removed easily
in the EPAI, don't show that Eo* could be IDs.
in the implementation, use klass_id and obj_id
if you know or want it to be a class or an object,
use eo_id in general cases.
We want to have normal functions as non-default constructors, not va_arg
ones. What we should do is split the object creation to two parts again.
The creation, the constructing (changes using the macro) and the
verification/end part that checks the constructor has been called.
This reverts commit 2ff2ce1894f173b306a896bda595e1a7768c074d.
to protect us against bad use of break, goto, return ... in eo2_do,
we use __attribute__((cleanup(eo2_do_end))) to ensure that eo2_do_end()
is called whatever.
at class elaboration, sort the op descriptions using the function pointer.
when calling a function, do a dichotomic search in the
class op descriptions to find the corresponding OP_ID,
then keep it in a static variable.
All classes are allowed, because all classes can be used as interfaces in
order to override behaviour. This is especially needed for mixins and broke
the eo2 tests.
Tom Hacohen
Daniel Kolesa
Cedric BAIL
Jaehwan Kim
Srivardhan Hebbar
Nicolas Aguirre
Daniel Zaoui
Avi Levin
Jérémy Zurcher
Mike Blumenkrantz
Daniel Kolesa
Jean Guyomarc'h
Cedric BAIL
Jean-Philippe Andre
Guillaume Friloux
Carsten Haitzler
Cedric Bail
Lukasz Stanislawski
Cedric Bail