summaryrefslogtreecommitdiff
path: root/src/tests/ecore/efl_app_suite.h (follow)
AgeCommit message (Collapse)Author
2019-02-12Revert "Revert command line array object because it's broken by design"Marcel Hollerbach
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 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 :)
2019-02-12Revert "Revert the env object because it's broken portability - please redo"Marcel Hollerbach
This reverts commit d6294fa22b88187e44391c1c8ca64b1ebdf14533.
2019-02-12Revert the env object because it's broken portability - please redoCarsten Haitzler (Rasterman)
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 2373d5db5b4cd5dfe139aa2a10017ef61b28b5ce. Revert "efl_task: remove env from this object" This reverts commit c3d69f66a69c0def357a5c373a13343e1c01ff5d.
2019-02-12Revert command line array object because it's broken by designCarsten Haitzler (Rasterman)
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) { 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.
2019-02-12ecore: here comes a command line objectMarcel Hollerbach
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
2019-02-12ecore: here comes a env objectMarcel Hollerbach
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
2018-04-10tests: split efl_app promise tests into separate test casesMike Blumenkrantz
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
2018-04-10tests: move ecore promise tests into efl_app_suiteMike Blumenkrantz
Summary: ref T6815 Depends on D5902 Reviewers: stefan_schmidt Subscribers: cedric Maniphest Tasks: T6815 Differential Revision: https://phab.enlightenment.org/D5903
2018-04-10tests: move efl_loop_fd tests into efl_app_suiteMike Blumenkrantz
Summary: ref T6815 Depends on D5898 Reviewers: stefan_schmidt Subscribers: cedric Maniphest Tasks: T6815 Differential Revision: https://phab.enlightenment.org/D5899
2018-04-10tests: move disabled efl loop timer test into efl_app_suiteMike Blumenkrantz
Summary: ref T6815 Depends on D5895 Reviewers: stefan_schmidt Subscribers: cedric Maniphest Tasks: T6815 Differential Revision: https://phab.enlightenment.org/D5896
2018-04-10tests: split efl_loop tests out of efl_app_suite.cMike Blumenkrantz
Summary: Depends on D5894 Reviewers: stefan_schmidt Subscribers: cedric Differential Revision: https://phab.enlightenment.org/D5895
2018-04-05tests: add instrumentation to existing tests to find slow testsMike Blumenkrantz
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 https://phab.enlightenment.org/w/improve_tests/ Reviewed-by: Stefan Schmidt <stefan@osg.samsung.com>
2018-03-03put efl app test back with mods to match app as superclassCarsten Haitzler (Rasterman)
2018-03-03Revert "cxx: Fix manual code after efl_app change."Carsten Haitzler (Rasterman)
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 like this. 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 then?) etc.
2018-02-26efl: add test suite for efl_appMike Blumenkrantz
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