|Age||Commit message (Collapse)||Author|
This reverts commit a57c7f751023fe1d1edeabbf8683574ac7497e5e.
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
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 :)
This reverts commit d6294fa22b88187e44391c1c8ca64b1ebdf14533.
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");
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 2373d5db5b4cd5dfe139aa2a10017ef61b28b5ce.
Revert "efl_task: remove env from this object"
This reverts commit c3d69f66a69c0def357a5c373a13343e1c01ff5d.
Revert "ecore: get rid of commands in efl_task."
This reverts commit 616381e9cfed41b83fef039b0e38c09b41fd3d7f.
Revert "ecore: here comes a command line object"
This reverts commit 48e5684b3c37b337edd7004e68fc0690b58a84e6.
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)
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.
Differential Revision: https://phab.enlightenment.org/D7510
each test case can run in parallel, so this provides a ~300% speedup
Depends on D5904
Maniphest Tasks: T6850
Differential Revision: https://phab.enlightenment.org/D5905
Depends on D5902
Maniphest Tasks: T6815
Differential Revision: https://phab.enlightenment.org/D5903
Depends on D5898
Maniphest Tasks: T6815
Differential Revision: https://phab.enlightenment.org/D5899
Depends on D5895
Maniphest Tasks: T6815
Differential Revision: https://phab.enlightenment.org/D5896
Summary: Depends on D5894
Differential Revision: https://phab.enlightenment.org/D5895
efl_check.h must be included and the EFL_START/END_TEST macros must be
used in place of normal START/END_TEST macros
timing is enabled when TIMING_ENABLED is set
Reviewed-by: Stefan Schmidt <email@example.com>
This reverts commit 135154303bea691c6f7f9472a5dec32d9103c38d.
Revert "efl: move signal events from efl.loop to efl.app"
This reverts commit 3dbca39f98288580c62a43c179ac11621433ec88.
Revert "efl: add test suite for efl_app"
This reverts commit 3e94be5d73256a7f5c02d3a9474173226be7beff.
Revert "efl: create Efl.App class, the parent of Efl.Loop"
This reverts commit 28fe00b94e55575c15684959b89a614d5a579309.
Go back to before efl.app because I think this should be done with
superclassing here not a parent object. reasons?
1. multiple loops per single thread make no sense. so if multilpe loop
objects they wont be contained in a single app object and then deleted
2. the app object is not really sharable in this design so it cant be
accessed from other threads
3. it makes it harder to get the main loop or app object (well 2 func
calls one calling the other and more typing. it is longer to type and
more work where it is not necessary, and again it can't work from
other threads unless we go duplicating efl.app per thread and then
what is the point of splittyign out the signal events from efl.loop
this moves existing tests out of the ecore suite and into a new one,
adds some checks to verify loop object parenting, and verifies compile
for Efl_Core.h and Efl_Net.h using EFL_NOLEGACY_API_SUPPORT