Summary:
if there is a none beta class, then this class should not depend on beta
classes in parameters / event types / return types, parent inherits.
This adds this validation, so we can start to slowly to unbeta more and
more classes.
Reviewers: q66, zmike, cedric, segfaultxavi
Reviewed By: q66
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7999
this is done inorder to ensure that noone ever thinks of creating theire
own app/loop object.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D7982
strings often enough are generated e.g. via "%s/%s" or "%i" or similar
etc. ... i have poitned to examples, so move to make all strings
consistently stringshared, fix a bug added to the efl thread code
where it accessed and freed array even tho array was consumed (but not
strings) in the set, and the code used free to consume not
stringshare_del. fix other code and tests to match
EXCTLY the kind of bugs and mistakes with this kind of design that i
said would happen more often just happened...
Until this commit eo did class functions as part of the vtable, which
enabled those functions to be overwritten in classes inheriting another
class. However in task T7675 we decided that this is not really good for
bindings, as most OOP languages do not support this sort of feature.
After this commit eolian realizes class function completly outside of
the vtable, the c-symbol that is the class funciton is now just directly
redirecting to a implementation, without the involvement of the vtable.
This also means a change to the syntax created by eo:
Calling before:
class_function(CLASS_A);
Calling after:
class_function();
Implementation before:
class_function(const Eo *obj, void *pd) { ... }
Implementation after:
class_function(void) { ... }
This fixes T7675.
Co-authored-by: lauromauro <lauromoura@expertisesolutions.com.br>
Reviewed-by: Daniel Kolesa <daniel@octaforge.org>
Differential Revision: https://phab.enlightenment.org/D7901
This reverts commit a57c7f7510.
I pretty much hate to just revert your revert, but you failed to read my
replies, and failed to understand what i was talking about.
And YES we talked at fosdem about the platform issue, and do you
remember my answer, that back in time this might be the case, today is
different freebsd suppoerts setenv, and for windows we have a setenv
implementation in evil. And yes, vtorri also created a issue how bad and
evil this commit is, however, i still fail to see the issue since setenv
unsetenv and clearenv usages are taken as needed. (T7693)
The ownership question is answered in
https://phab.enlightenment.org/D7516#137367.
Can we please get into a state of technical discussions, and not *oh
shit, i am going to revert this* this has been in review for a long
time, a lots of people have tested it, we discussed things on it, and
there was 3 weeks of no reply from you.
The issues that exist will be dealed with. Feel free to create tasks if
you want :)
setenv and unsetenv are not portable. i explained to you at fosdem
there are issues and it's why i used putenv in the original
implementation and even though it's a pain (the string tou pass to
putenv is a pointer used literallt from there on in and you get it
from getenv, thus making ownership a pain -this is a libc issue we
can't readily solve). use putenv like the original code. then put it
back in. vtorri now has windows porting issues with the setenv use. i
knew there was a reason that still existed...
in addition your in_sync stuff is broken. psuedocode:
// assuming BLAGH env is not set to anything here
c = efl_core_env_get(global_env, "BLAH");
...
putenv("BLAH=10");
...
c = efl_core_env_Get(global_env, "BLAH");
i will get NULL in both cases for c ... but i should get "10" for the
2nd in reality. reality is lots of code across application code and
libraries will at times mess with the environment. it has to work with
this. the prior implementation did work with this.
Revert "ecore: here comes a env object"
This reverts commit 2373d5db5b.
Revert "efl_task: remove env from this object"
This reverts commit c3d69f66a6.
Revert "ecore: get rid of commands in efl_task."
This reverts commit 616381e9cf.
Revert "ecore: here comes a command line object"
This reverts commit 48e5684b3c.
1. this is broken:
EOLIAN static const char*
_efl_core_command_line_command_get(const Eo *obj EINA_UNUSED, Efl_Core_Command_Line_Data *pd)
{
return eina_strdup(pd->string_command);
}
it returns a const char * BUT it duplicates it on return. no. a big
fat honking NO. return a char * or don't duplicate. pick.
2. _efl_core_command_line_command_array_set() is broken by design. it
accepts an array of strings, but the strings are owned by the caller
who creates the array (requiring they free them up themselves after
this call) but the array becomes owned by the callee. the code here frees the
incoming array but doesn't care about the string content of it. it's
leak heaven waiting to happen (or bugs when someone wants to access
the array they create to walk it to free the strings they put into it
after it is set).
i brought this up and it was dismissed. now exactly he issue i brought
up is there with mixed ownership and the added complexity as well as
transfer of some ownership but not others.
go back and think about this so it isn't broken by design.
the mixin for now can carry a command, which can be setted as an string.
The string is then parsed again, this is done in order to make sure that
everything that needs escaping really is escaped or parsed correctly.
Differential Revision: https://phab.enlightenment.org/D7516
the env object can be used to alter and edit the content of environment
variables. Additionally, the class efl.core.env can be used to to setup
a not applied set of environment variables, which then can be applied
later (in the future) to set it directly to a spawned process for
example, or as a general key/data storage. A efl.core.env object can
also be forked off, which makes it easy to customize predefined objects.
ref T7514
Differential Revision: https://phab.enlightenment.org/D7510
I forgot to spin the sub-loop, so this was previously just a test to verify
that the IDLE callback was working.
now this spins the sub-loop on the idle callback and tests the idle enter
callback to verify that the main loop is being iterated
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Differential Revision: https://phab.enlightenment.org/D7874
having multiple loops which interact is a valid use case that should be
tested to ensure functionality
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Differential Revision: https://phab.enlightenment.org/D7868
ecore_audio does define format and source, those are then used in some
leave classes, ecore_audio is only used in the tests, and should not be
used externally. Therefore make it abstract.
The other missing implementations are in the leave classes,
They are resolved with providing empty implementations, since no format
switching is supported.
ref T5719
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D7782
This brings in the possibility to receive the app object from bindings.
With the app object you can listen to pause / args / terminate / resume
events.
fix T7509
Differential Revision: https://phab.enlightenment.org/D7480
Summary:
In the case when you have multiple future in flight related to one object, you
couldn't use the previous version of efl_future_then. Now all function calls
take a void* pointer that allow multiple future to have their private data
request data accessible in all the callback.
This should not break released API as Eo.h is not released yet and so
was efl_future_Eina_FutureXXX_then.
Depends on D7332
Reviewers: felipealmeida, segfaultxavi, vitor.sousa, SanghyeonLee, bu5hm4n
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7472
Differential Revision: https://phab.enlightenment.org/D7379
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
Summary:
This reverts commit 4917910b49.
4917910b break backward compatibility.
Reproduction:
void pipe_handler(...);
pipe = ecore_pipe_add(pipe_handler, NULL);
ecore_pipe_write(pipe, NULL, 0);
Because of the null check condition, pipe_handler isn't called after 4917910b.
Some apps behavior which is written to expected to call pipe_handler was broken.
also, this patch fixed segfault during build on Windows
Test Plan: make on Windows
Reviewers: raster, zmike, vtorri
Reviewed By: zmike, vtorri
Subscribers: woohyun, cedric, #reviewers, #committers, zmike, vtorri
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6824
Summary:
Timers are not called in the order they were registered.
Because when current timer is deleted, getting next timer is called twice.
Test Plan:
<error>
Timer1 expired after 0.001 seconds.
Timer3 expired after 0.001 seconds.
Timer5 expired after 0.001 seconds.
Timer7 expired after 0.001 seconds.
Timer2 expired after 0.001 seconds.
Timer6 expired after 0.001 seconds.
Timer4 expired after 0.001 seconds.
Timer8 expired after 0.001 seconds.
<correct>
Timer1 expired after 0.001 seconds.
Timer2 expired after 0.001 seconds.
Timer3 expired after 0.001 seconds.
Timer4 expired after 0.001 seconds.
Timer5 expired after 0.001 seconds.
Timer6 expired after 0.001 seconds.
Timer7 expired after 0.001 seconds.
Timer8 expired after 0.001 seconds.|
{F3268233}
Reviewers: Hermet, Jaehyun_Cho, zmike, SanghyeonLee
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl_tests
Differential Revision: https://phab.enlightenment.org/D6700
unit tests should test one thing only: testing timer accuracy and the
effectiveness of resetting a timer in the same test leads to timing issues,
so remove the timing component from the test
ref T6878
Differential Revision: https://phab.enlightenment.org/D6653
Summary:
this caused DSO linker issues when enabled and was only testing
init+shutdown for a deprecated component which has not been actively developed
in some time
Reviewers: devilhorns, ManMower, bu5hm4n
Reviewed By: devilhorns, ManMower
Subscribers: bu5hm4n, ManMower, cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6539
Summary:
these tests will fail if run with root permission, so avoid checking them
when run as root
ref T7094
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T7094
Differential Revision: https://phab.enlightenment.org/D6534
Summary:
ibus module will refuse to load if DISPLAY is not set, so avoid failing
for no reason in this case
Depends on D6433
Reviewers: ManMower, bu5hm4n, devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6434
Summary:
these tests explicitly call ecore_imf_init, so they must call ecore_imf_shutdown
even on failure cases to avoid propagating their failure to subsequent tests
ref T7085
Reviewers: ManMower, bu5hm4n, devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T7085
Differential Revision: https://phab.enlightenment.org/D6433
Summary:
tcase_name() was added in 0.11.0 (2016), which is still not widely enough
distributed to rely upon without version checks
Reviewers: stefan_schmidt, ManMower, devilhorns
Reviewed By: ManMower
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6260
Summary:
this is mainly to handle the case of ecore-file, which fetches external
resources during the test and requires an active network connection which
may fail to resolve/connect/download during the test. if this particular test
fails then it is almost certainly a network issue
a future patch should implement some form of http server to remove the
dependency on external network resources
also probably all test suites should have timeout timers just in case
fix T6950
Depends on D6205
Reviewers: stefan_schmidt, cedric
Reviewed By: cedric
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T6950
Differential Revision: https://phab.enlightenment.org/D6206
Summary:
a stack variable was incorrectly used here, along with some lazy timing
calcs which did not accurately measure the time for each timer iteration,
resulting in a test which intermittently failed in some cases
fix T6878
Reviewers: stefan_schmidt, bu5hm4n, ManMower
Reviewed By: ManMower
Subscribers: ManMower, cedric, #committers
Tags: #efl
Maniphest Tasks: T6878
Differential Revision: https://phab.enlightenment.org/D6256
This reverts commit 2fb5cc3ad0.
Most of this change where wrong as they didn't affect the destruction
of the object. efl_add_ref allow for manual handling of the lifecycle
of the object and make sure it is still alive during destructor. efl_add
will not allow you to access an object after invalidate also efl.parent.get
will always return NULL once the object is invalidated.
Differential Revision: https://phab.enlightenment.org/D6062
Summary:
each test case can run in parallel, so this provides a ~300% speedup
ref T6850
Depends on D5904
Reviewers: stefan_schmidt
Subscribers: cedric
Maniphest Tasks: T6850
Differential Revision: https://phab.enlightenment.org/D5905
Summary:
these aren't tested so don't init/shutdown for every test
ref T6850
Depends on D5903
Reviewers: stefan_schmidt
Subscribers: cedric
Maniphest Tasks: T6850
Differential Revision: https://phab.enlightenment.org/D5904
Summary:
* check inside thread callbacks whether thread has been canceled
* clean up (global) objects
* wait for threads to die before exiting each test
ref T6851
Depends on D5889
Reviewers: stefan_schmidt
Subscribers: cedric
Maniphest Tasks: T6851
Differential Revision: https://phab.enlightenment.org/D5890
Marcel Hollerbach
Carsten Haitzler
Mike Blumenkrantz
Cedric BAIL
Cedric BAIL
Yeongjong Lee
Hosang Kim
Mike Blumenkrantz