summaryrefslogtreecommitdiff
path: root/src/tests/emile (follow)
AgeCommit message (Collapse)Author
2019-05-02emile_test_base64: Fix memory leakChristopher Michael
Summary: Coverity reports that we leak 'str' here, so change the call from eina_strbuf_reset to eina_strbuf_free Fixes CID1400815 @fix Depends on D8780 Reviewers: raster, cedric, zmike, bu5hm4n, segfaultxavi Reviewed By: segfaultxavi Subscribers: segfaultxavi, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D8781
2019-05-02emile_test_base64: Fix resource leakChristopher Michael
Summary: Coverity reports that we leak 'buffer' here so add a call to eina_binbuf_free Fixes CID1400820 @fix Depends on D8779 Reviewers: raster, cedric, zmike, bu5hm4n, segfaultxavi Reviewed By: segfaultxavi Subscribers: segfaultxavi, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D8780
2019-05-02emile_test_base64: Fix resource leakChristopher Michael
Summary: Coverity reports that we leak the storage returned from eina_binbuf_new here, so lets add a call to eina_binbuf_free before we exit Fixes CID1400852 @fix Depends on D8776 Reviewers: raster, cedric, zmike, bu5hm4n, segfaultxavi Reviewed By: segfaultxavi Subscribers: segfaultxavi, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D8777
2019-05-02emile_test_base64: Fix resource leakChristopher Michael
Summary: Coverity reports that we leak the storage of variable 'decoded' here, so lets add a call to eina_binbuf_free Fixes CID1400868 @fix Depends on D8774 Reviewers: raster, cedric, zmike, bu5hm4n, segfaultxavi Reviewed By: segfaultxavi Subscribers: segfaultxavi, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D8775
2019-05-02emile_test_base64: Fix resource leakChristopher Michael
Summary: Coverity reports that we leak storage of variable 'str' here, so call eina_strbuf_free Fixes CID1401062 @fix Depends on D8762 Reviewers: raster, cedric, zmike, bu5hm4n, segfaultxavi Reviewed By: segfaultxavi Subscribers: segfaultxavi, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D8763
2018-12-20cmake: remove!Marcel Hollerbach
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
2018-11-09emile test - fix dtata struct init missing initted fields - warnCarsten Haitzler (Rasterman)
2018-10-02here comes mesonMarcel Hollerbach
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
2018-04-05tests: move to using checked fixtures for all test suitesMike Blumenkrantz
individual tests should not need to explicitly call init/shutdown functions in most cases, and many did not properly do this anyway see followup commit which resolves some issues with eina tests ref T6813 ref T6811 Reviewed-by: Stefan Schmidt <stefan@osg.samsung.com>
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>
2017-02-03ifdef RUN_IN_TREE logic.Gustavo Sverzut Barbieri
This logic is only needed for autotools, cmake will replicate the installation file structure and thus eina_prefix works out of box.
2017-01-26cmake: add emile and EFL_OPTION_BACKEND()Gustavo Sverzut Barbieri
Add emile and with that EFL_OPTION_BACKEND() to support choosing among different backends for something, in emile's case it's crypto backend (gnutls, openssl or none).
2016-02-16Test rework #16: EmileVincent Torri
2016-01-07emile: move all eina_str_base64 to emile_base64.Cedric BAIL
2015-05-07emile: add emile_suite_build function to separate creation of test suite.vivek
Summary: Signed-off-by: vivek <vivek.ellur@samsung.com> Reviewers: cedric Reviewed By: cedric Subscribers: cedric Differential Revision: https://phab.enlightenment.org/D2319 Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
2015-04-29emile: only disable tests timeout on Windows.Cedric BAIL
2015-03-17emile: fix coding style with ecrustify.Cedric BAIL
2015-03-17emile: initial introduction of Emile.Cedric BAIL
The intent of Emile is to be the common layer for serialisation, compression and ciphering. It will expose the library we currently use internally to an easier use from the outside (like gcrypt and lz4). It should improve portability. Instead of pushing JSON, XML and what's not to Eina, I do think that they will fit better in Emile. As for the naming of Emile, you will need to be French and say : "Un quoi ?" "Un serializer !" Regarding why it is put there in the stack. Right now there is two users of compression (eet and terminology), two users of cipher library (eet and ecore_con) and a few handful of user for serialization (eina, eet, efreet, ecore_con, ...). So the choice was quite simple, it needed to be below Eet. Now it could have been on top of Eo or integrated into Eina. One of the use case I am thinking of, is to compress Eo object when a canvas get hidden/minized. For that it require Eo to use that library and it can't be a higher level object. And with current implementation of Eo it is perfectly possible to implement such idea. So not at Eo level. As for Eina, I am starting to think it is getting to much things in its namespace. I do believe that infact Eina_Simple_XML and Eina_File should after all have landed in their own library. That's why I am putting the current logic in a new library. It is going to expand, I want it to provide an few SAX like parser for JSON, Eet_Data and protobuf with also an API like Eet_Data to directly feed those value into a C structure without using a DOM at all. It would also be the right place to experiment and benchmark for a new Eet_Data format that could be more efficient to use. So at the end, and due to how I see things going and being used, I do think it is better of in its own library.