Summary:
object_find is more generic, so other mechanisms can also reuse the
code.
The object itself has to support the function, so there is no need for
eo_isa which would have a negative performance impact.
The base class implementation calls interface_get on the parent, so a
override of the function can just call the super function to continue in
the recursion.
Test Plan: just run the eo test suite
Reviewers: raster, tasn, jpeg
Reviewed By: tasn, jpeg
Subscribers: felipealmeida, netstar, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3909
this means that on loop_get on any obj as long as its a child of a
loop obj... it'll retunr that loop now. it will work. no more code
needed.
we can shortcut this with ui/gfx objects returning the mainloop
singletone.
so i've been doing some debugging and having a mem debugger that
preloads and tracks allocs means you need locks, but locks can do
nasty things after forks + threads.... esp if threads held locks.
this allows mem debugging with preloads easily and doesn't muck things
up.
This fixes a crash in ecore_init, calling a weak function from
libefl that was resolved to NULL.
So, here's a fun thing happening with GCC < 5.3. Since a1a506e13e
all EOAPI and EO class_get() functions are weak symbols. This means
that all APIs inside libefl.so are weak.
As a result, gcc linker with --as-needed skipped linking to libefl
since not a single strong symbol from libefl was required by
libecore. This is actually a bug in gcc linker since we do in fact
use symbols from libefl, just weak ones.
GCC 5.3 seems to be fixed, so people with GCC 5.3+ will not
experience any build/runtime issue. The current patch is
a workaround that bug, by artifically creating a strong symbol
required by ecore.
Other libraries than ecore might also need to call
__efl_internal_init, if they end up not being linked to libefl.
Add ecore_thread_promise_run function that returns a Promise
and runs function in another thread which you can set the
value on a Eina_Promise_Owner.
Eina_Promise* promise;
Ecore_Thread* thread = ecore_thread_promise_run
( &function_heavy, &cancellation_function, private_data,
sizeof(ValueType), &promise);
This calls function_heavy on another thread and returns
the Ecore_Thread and a Eina_Promise as an out-parameter.
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
this inits a new vpath object and adds it at priority 0 to the vpath
manager so you can use the vpath manager to create vpath file objects
and look things up.
@feature
Reverting this at Felipe's request following my email. There are many
things I strongly object to in this commit. I've touched the surface of
those on the ML (which doesn't work at the moment), though we need to
better discuss it.
The gist:
1. dlsym is a really bad hack that is not even needed.
2. I don't see why eo should even be aware of promises. It's not aware
of list, hash and etc.
3. The eolian changes were done wrong.
This should have been discussed and consulted before done, even if only
because of the amount of hacks it includes and the cross-domain (ecore,
eo and eolian) nature of it.
This reverts commit f9ba80ab33.
Add a promise object that allows Eolian interface to include promises
as a way to have asynchronous value return and composibility.
The usage is like this in a .eo file:
class Foo {
methods {
bar {
params {
promise: Promise<int>;
}
}
}
}
Which will create the following API interface:
void foo_bar(Ecore_Promise** promise);
and the equivalent declaration for implementation.
However, the API function will instantiate the Promise for the
user and the implementer of the class.
Cedric BAIL
Marcel Hollerbach
Carsten Haitzler
Tom Hacohen
Stefan Schmidt
Daniel Zaoui
Jean Guyomarc'h
Jean-Philippe Andre
Felipe Magno de Almeida
Mike Blumenkrantz