Summary:
Patch from a series of patches to rename EAPI symbols to specific
library DSOs.
= The Rationale =
This patch is from a series of patches to rename EAPI symbols to
specific library DSOs.
EAPI was designed to be able to pass
`__attribute__ ((visibility ("default")))` for symbols with
GCC, which would mean that even if -fvisibility=hidden was used
when compiling the library, the needed symbols would get exported.
MSVC __almost__ works like GCC (or mingw) in which you can
declare everything as export and it will just work (slower, but
it will work). But there's a caveat: global variables will not
work the same way for MSVC, but works for mingw and GCC.
For global variables (as opposed to functions), MSVC requires
correct DSO visibility for MSVC: instead of declaring a symbol as
export for everything, you need to declare it as import when
importing from another DSO and export when defining it locally.
With current EAPI definitions, we get the following example
working in mingw and MSVC (observe it doesn't define any global
variables as exported symbols).
Example 1:
dll1:
```
EAPI void foo(void);
EAPI void bar()
{
foo();
}
```
dll2:
```
EAPI void foo()
{
printf ("foo\n");
}
```
This works fine with API defined as __declspec(dllexport) in both
cases and for gcc defining as
`__atttribute__((visibility("default")))`.
However, the following:
Example 2:
dll1:
```
EAPI extern int foo;
EAPI void foobar(void);
EAPI void bar()
{
foo = 5;
foobar();
}
```
dll2:
```
EAPI int foo = 0;
EAPI void foobar()
{
printf ("foo %d\n", foo);
}
```
This will work on mingw but will not work for MSVC. And that's why
LIBAPI is the only solution that works for MSVC.
Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com>
Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
Reviewers: jptiz, lucas, vtorri, woohyun
Reviewed By: jptiz, lucas, vtorri
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12203
Summary:
EFL_CALLBACKS_ARRAY_DEFINE reorders the callbacks according to
efl_callbacks_cmp. efl_callbacks_cmp compares the address of the desc
field, which depends on the memory layout generated by the linker.
To make the test run deterministically, we define the array of callbacks
manually.
Reviewers: vtorri, felipealmeida, raster
Reviewed By: raster
Subscribers: cedric, #reviewers, #committers, jptiz, felipealmeida
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12043
please note, not the return type, but the function.
When appending __attribute__((const)) to a function, the compiler is
told that its enough to call this function once in a function.
This is quite often happening when we are efl_data_scope_get and
efl_super in a function that is different from a implemented function.
The compiler now starts to remove the calls that aggressivly that we
need to ensure that these calls are not removed, which means, the static
function calls, and the eo init are now checking the return value of
these functions, to ensure that they are called.
Please note that you now have to be carefull when your app calls
eo_shutdown, if it does so, you *must* call it at the end of a function,
or never call class_get after that anymore.
Overall this improves elm test runs 0.1s which is fair i guess, the main
thing that is faster is textrendering, where is also the point where
this is the most beneficial.
Please note, this replaces 42 occurences of double _class_get() ... THAT
is a sign!
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Reviewed-by: Daniel Kolesa <daniel@octaforge.org>
Differential Revision: https://phab.enlightenment.org/D12057
Revert "eo: redo vtable mro creation"
This reverts commit b05110609b.
Revert "eo: add a generic memory allocation tracking method"
This reverts commit 44071e3102.
Revert "eo: rework vtable allocation scheme"
This reverts commit 3bd16a46f1.
Revert "eo: do not allocate extension if deleting"
This reverts commit 64f7edc7fc.
This seems to breal vector rendering in lottie:
From: Hermet Park <hermetpark@gmail.com>
To: Enlightenment developer list <enlightenment-devel@lists.sourceforge.net>
Subject: Re: [E-devel] [EGIT] [core/efl] master 02/05: eo: rework
vtable allocation scheme
This patch occurs memory corruption, vector crashes :(
Here is a sample if you'd like to see it.
https://phab.enlightenment.org/F3858944
Summary:
with this commit a new way of allocating vtables arrived.
The old mechnism was to allocate a table big enough to carry *all*
functions at once, in order to not allocate that much memory for
functions that are not implemented on a specific klass, dichchains have
been used, which can be seens as a 2D matrix, where columns are only
allocated if min 1 entry needs to be written, this may have been a good
way to allocate back in the day when all this with eo started, however,
it showed to not pay off.
With this new way, we allocate a array of arrays. the first lvl array is
carrying enough slots, that *all* up to the time defined
interfaces/classes/abstracts/mixins can be implemented. The second lvl
array then has exactly the size of the defined APIs. The second lvl
array is obviously only allocated if needed.
When comparing the two methods, i messured two things, the usage based
on memory allocation for vtable-way-1 and vtable-way-2. Additionally, i
checked the overall memory usage of elementary_test using pmap. The
first messurement is a little bit more exact. The second messurement is
more biased, but captures the whole picture.
Memory allocation tracking:
vtable-way-1 - vtable-way-2 = 74680 Byte
Pmap memory tracking:
vtable-way1 - vtable-way-2 = 217088 Byte
The second messurement shows a bigger impact, likely because this is
also showing off all the sideeffects that we are taking place due to
fewer allocations.
Depends on D11524
Reviewers: zmike, tasn, stefan_schmidt, woohyun, cedric, raster
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11535
that is usefull esp. on parts.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11462
This patch introduce a small hash (64 or 32bits) that cache all existing
Efl_Event_Description callback handler registered on an object. It slightly
reduce the time needed to do an unecessary call and cost just a few bytes
per object.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10475
Summary: we need to include evil_private.h so that some symbols are declared
Test Plan: compilation
Reviewers: raster, zmike, cedric
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9129
Some user code may want to track an object ownership in regard to whether it is
kept by just one owner or shared between many owners.
This is specially true for code provided by bindings to other programming
languages, where different kinds of resource management may take place.
The event `ownership,unique` is triggered whenever the object refcount goes
from two to one, as a signal that it has just one owner from now on.
The event `ownership,shared` is triggered whenever the object refcount goes
from one to two, as a signal that it has multiple owners from now on.
It will not trigger when further increasing the refcount to any value beyond
two.
We also add benchmarks for sharing (i.e. increasing the refcount) and them
unsharing objects, in order to evaluate the performance impact of this patch.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8678
Getter are usually not modifying there object. This is going to put a strong
limit on what a getter property for MVVM is, as it will prevent any side
effect on getting a property from a View.
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D7969
Summary:
the DFS tree walk was accidently stopped by a too early return
statement. We should only return if we found a reflection entry, if not,
then we should continue our search
Depends on D7996
Reviewers: cedric, zmike, q66, segfaultxavi
Reviewed By: cedric, zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7997
Summary:
this enables tests with the fallback implementation of EO.
Depends on D7924
Reviewers: stefan_schmidt, cedric, zmike, segfaultxavi
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7931
As in the previous commit explained, we want to get rid of class
functions in eo, and make them just c functions right away.
This commit removes the class parameter from the eo_class_function_set
call, and adjusts the tests to not depend on class functions anymore.
Class functions are now not tested anymore, tests that used them as a
way to test *things* are adjusted to test them now with object
functions, tests that just tested the working of class functions are
dropped.
This fixes T7675.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D7902
this checks that eo-dbg is also working in the same manner as normal eo
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D7911
this adds support in eo to generate a reflection API. To get the actaul
reflection to the klass, the API efl_class_reflection_table_set needs to
be called, the table in the end can be generated by eolian. Reflection
API is inherited by the extended class. This means, if you have two
reflection tables, first, the most upperst is called, then the next
lower one is called.
For now this API accepts NULL setter or getter, and will ignore them
silently when they are called.
fix T7681
Differential Revision: https://phab.enlightenment.org/D7879
The next commit will bring support for something like reflection. This
commit prepares the whole tree for getting another argument in
efl_class_functions_set.
ref T7681
Differential Revision: https://phab.enlightenment.org/D7882
this enables an app or a platform to add an override for a given class,
then return a different object when that class is created. the benefit is
that a class can be internally customized by the app without needing to
modify upstream versions of that class
@feature
fix T7516
Reviewed-by: Marcel Hollerbach <marcel-hollerbach@t-online.de>
Differential Revision: https://phab.enlightenment.org/D7702
This build was never complete and also was not maintained probebly.
It is also dropped in favour of meson which is cool, merged, works & is fast.
Differential Revision: https://phab.enlightenment.org/D7010
Summary:
when the compiler is instructed that symbols are local by default. Then
the testsuite will fail, due to eo_test_general.c including the
indirection header, which uses the ERR macro, which needs the
_eo_log_dom symbol.
Depends on D7145
Reviewers: netstar, zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7147
a new shiny buildtool that currently completes in the total of ~ 4 min..
1 min. conf time
2:30 min. build time
Where autotools takes:
1:50 min. conf time
3:40 min. build time.
meson was taken because it went quite good for enlightenment, and is a traction gaining system that is also used by other mayor projects. Additionally, the DSL that is defined my meson makes the configuration of the builds a lot easier to read.
Further informations can be gathered from the README.meson
Right now, bindings & windows support are missing.
It is highly recommented to use meson 0.48 due to optimizations in meson
that reduced the time the meson call would need.
Co-authored-by: Mike Blumenkrantz <zmike@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7012
Depends on D7011
The function simply checks if the object is finalized and not
started to be invalidated or invalidated.
Differential Revision: https://phab.enlightenment.org/D6723
Summary:
there is now invalidated & invalidating.
invalidated returns true when all children are invalidated, and the
object is / was requested to be invalidated.
invalidating return true when the object is called to be invalidated but
not all children are invalidated yet. However, the object is garanteed
to be invalidated in near future.
Reviewers: zmike
Reviewed By: zmike
Subscribers: cedric
Tags: #efl, #do_not_merge
Differential Revision: https://phab.enlightenment.org/D6722
failing to call this prior to the thread invocation would result in a CRI
from class initialization in a thread
ref T7003
Differential Revision: https://phab.enlightenment.org/D6333
Summary: I accidently broke the test suite, due to missing rebuilds.
Reviewers: zmike, devilhorns
Reviewed By: zmike
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6421
Summary:
build with this disabled is just not working as the thread model of eo
falls apart. The threadmodel is required to have eo_id, as it decoded
the thread information in the eo_id, which is not working without eo_id.
This also fixes the testcases that have never been executed due to the
fact of the missing HAVE_EO_ID
fix T6610
Depends on D6327
Reviewers: devilhorns, zmike
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Maniphest Tasks: T6610
Differential Revision: https://phab.enlightenment.org/D6328
checks if a object is really freed, even under error conditions.
The test suite now has the following timing:
TC TIME Eo general: 0.035713
SUITE TIME(8227) Eo: 0.036046
Differential Revision: https://phab.enlightenment.org/D6253
Felipe Magno de Almeida
Carsten Haitzler
Wander Lairson Costa
Marcel Hollerbach
Stefan Schmidt
Cedric Bail
Vincent Torri
Vitor Sousa
Mike Blumenkrantz
Marcel Hollerbach
Cedric BAIL
Mike Blumenkrantz