Re: [E-devel] memory allocation perf

2016-09-30 Thread The Rasterman
On Fri, 30 Sep 2016 09:10:29 +0900 Carsten Haitzler (The Rasterman)
 said:

> so for a while now i've been mumbling about possibly pulling in a custom
> memory allocator (generic one intended to replace malloc/calloc/realloc/free)
> because of various reasons.
> 
> 1. move memory allocated for efl away from "apps" so the chances of walking
> over your memory segment into an efl one and corrupting it go down (at least
> app vs efl becomes a bigger device).
> 
> 2. pointer recycling from libc now won't interfere with efl. i mean if app
> mallocs something, then frees it, then keeps using it and happens to not
> crash, but an efl malloc now recycles it then app scribbles over efl memory -
> we crash and hunt bugs that are not ours. to be 100% fair this applies the
> other way too (ie efl is bad and messes up app memory) and also applies to #1
> above
> 
> 3. we can drop memory usage significantly on 64bit but actually having 32bit
> pointers *IF* we have our own allocator (for a lot of out memory usage). if we
> force memory to be 8 byte aligned we can still allocate up to 32gb of data.
> 64gb if we force 16 byte alignment. how do we do this? realptr = (smallptr <<
> 3)
> + mem_base; or ... realptr = (smallptr << 4) + mem_base; ... make a small
> macro that just does this to resolve a "full" pointer from the "small
> pointer". in fact if we have multiple domains/regions as long as you know the
> region the "smallptr" came from you can access as much mem as u like by
> splitting. tbh 32 or 64gb of ram just for our data structures is "enough".
> i'd still use libc for large chunks ... like images or fonts etc. - though
> these days we dont even use malloc for most of those. we use mmap. we can
> extend smallptr even more. 16bit ptrs? (any single domain can access then
> 512k or 1mb of data, so as long as our overall needs for that type are within
> that size then we can cut ptrs down even more). and as we all know - smaller
> mem footrpint actually tends to increase speed too thanks to better cache
> coherency. we can still have full "64bit" pointers too. we can easily move
> over just by changing 1 ptr's type to a new typedef and then watch the
> compile errors and "fix them" with a macro. so moving over should be
> straightforward and safe if done "one thing at a time".
> 
> 4. as a bonus round, looking around on how to build such an allocator i ran
> across jemalloc. http://jemalloc.net/ ... specifically i saw:
> 
> https://www.facebook.com/notes/facebook-engineering/scalable-memory-allocation-using-jemalloc/480222803919
> 
> and now really recently:
> 
> https://lists.freedesktop.org/archives/mesa-dev/2016-September/130009.html
> 
> we are actually very "malloc heavy" in efl. we malloc and free LOTS of things.
> we've move many things to mempools but we still are malloc heavy. so moving to
> jemalloc COULD really help us. we cant just wholesale move all of efl over at
> once. i think we have to move over very carefully one "thing" at a time. also
> there is the issue of relying on an external jemalloc or shipping a copy.
> 
> i think we'd need to ship a copy. why? if we want to do 32bit ptrs or 16bit
> ptrs on a 64bit system (ore 32 bit too where the 32bit ptrs would just compile
> out to nothing, and 16bit ptrs still work), we'd need to change jemalloc a
> bit. we'd need to NOT have just malloc/calloc/realloc/free replacements but
> need something like:
> 
> // some time at startup/init efl wouldinternally make some domains for itself:
> domain = eina_mem_domain_new(EINA_MEM_DOMAIN_FULL);
> domain2 = eina_mem_domain_new(EINA_MEM_DOMAIN_32);
> domain3 = eina_mem_domain_new(EINA_MEM_DOMAIN_16);
> 
> //...
> // and later on when we allocate memory we determine which domain to allocate
> // from depending on needs
> fullptr = eina_mem_malloc(domain, size);
> eina_mem_free(domain, fullptr);
> //...
> smallptr = eina_mem_malloc32(domain2, size);
> eina_mem_free32(domain2, smallptr);
> //...
> tinyptr = eina_mem_malloc16(domain3, size);
> eina_mem_free16(domain3, tinyptr);
> 
> 
> so we'd always have to pass in the domain the mem comes from. i only see the
> need for a single "32bit" domain for general efl allocation EXCEPT where we
> explicitly expose data through the api that the api user should be calling
> free () on. so since we only need one domain across efl in general we can
> bury this as a macro so it becomes:
> 
> smallptr = EFL_MALLOC(size);
> 
> to make moving over easier. yes. every ptr has to be moved one at a time. the
> 16bit domains are more tricky due to  their small size of total amount of
> memory they can store. i suspect we might create several 16bit domains and
> split data between them as needed. e.g. imagine a single 16bit domain JUST for
> eo callback entries/nodes. will all out callback needs for nay app fit in a
> single 1mb memory chunk? ... to be thought about.
> 
> anyway. in order to be able to have domains, we will have to likely dig into
> jemalloc and 

[EGIT] [tools/edi] master 01/01: files: tidy code to be easier to read

2016-09-30 Thread Andy Williams
ajwillia-ms pushed a commit to branch master.

http://git.enlightenment.org/tools/edi.git/commit/?id=97e2192a2bb339fc52b2289e44181129e9b2a2b7

commit 97e2192a2bb339fc52b2289e44181129e9b2a2b7
Author: Andy Williams 
Date:   Fri Sep 30 21:47:05 2016 +0100

files: tidy code to be easier to read

Thanks for the tip, vtorri
---
 src/lib/edi_build_provider_make.c | 35 ---
 1 file changed, 8 insertions(+), 27 deletions(-)

diff --git a/src/lib/edi_build_provider_make.c 
b/src/lib/edi_build_provider_make.c
index 730dd82..a0daa1e 100644
--- a/src/lib/edi_build_provider_make.c
+++ b/src/lib/edi_build_provider_make.c
@@ -33,36 +33,17 @@ _make_project_supported(const char *path)
 }
 
 static Eina_Bool
-_make_file_hidden_is(const char *relative)
+_make_file_hidden_is(const char *file)
 {
-   int len;
-
-   if (!relative || strlen(relative) == 0)
+   if (!file || strlen(file) == 0)
  return EINA_FALSE;
 
-   len = strlen(relative);
-   if (relative[len-1] == 'o' && len >= 2)
- {
-if (relative[len-2] == '.')
-  return EINA_TRUE;
-else
-  {
-if ((relative[len-2] == 's' || relative[len-2] == 'l') &&
-  len >= 3 && relative[len-3] == '.')
-  return EINA_TRUE;
-  }
- }
-   if (relative[len-1] == 'a' && len >= 2)
- {
-if (relative[len-2] == '.')
-  return EINA_TRUE;
-else
-  {
-if ((relative[len-2] == 'l') &&
-  len >= 3 && relative[len-3] == '.')
-  return EINA_TRUE;
-  }
- }
+   if (eina_str_has_extension(file, "o") || eina_str_has_extension(file, "so") 
||
+   eina_str_has_extension(file, "lo"))
+ return EINA_TRUE;
+   if (eina_str_has_extension(file, "a") || eina_str_has_extension(file, "la"))
+ return EINA_TRUE;
+
return EINA_FALSE;
 }
 

-- 




Re: [E-devel] [YAPT] Chaining promises

2016-09-30 Thread Cedric BAIL
Hi,

Le 30 sept. 2016 07:51, "Jean-Philippe André"  a écrit :
> Here's a question about promise chaining. C being what it is, it's harder
> to define a series like p.then().then() than it is in JS. And I can't find
> any good example in EFL code.
>
> Let's consider an abstract chain that I'll define as "download, unzip,
> show". (eg. download a zip file, unzip it and set the file on an image
> object).
>
>
> All of these are async, we don't care about the result of show. I don't
> understand how the chain should be written:
>
> main_func(url) {
>   Efl_Future *f1 = download_url(url);
>   Efl_Future *f2 = efl_future_then(f1, _down_cb, ...,  NULL);
>   efl_future_then(f2, _unzip_cb, ..., image);
> }
>
> // So far I think we're ok
>
> void _down_cb(null, event) {
>Efl_Promise *next = event->info->next;
>Efl_Future *f3 = _async_unzip(event->infodata);
>efl_future_then(f3, _unzip_cb2, .., next);
> }
>
> // I'm already getting confused with next, f2 and f3. Something is odd.

Yes, that's why there is some function (I don't have the code at end), to
feed a future into a promise. This connection take care of propagating the
value to the next promise. It avoid having to setup your own callback to do
so as you did in this example.

> void _unzip_cb(data, event) {
>Image *image = data;
>show(image);
> }
>
> void _unzip_cb2(data, event) {
>Efl_Promise *p2 = data;
>efl_promise_value_set(p3, NULL, NULL); // --> calls unzip_cb
> }
>
>
> So my questions:
> 1. Is this above code correct?

Yes.

> 2. (How) are we ensuring that the chain eventually resolves?

You mean, that if you don't set anything on the next promise, nothing will
happen ? There is nothing there we can do I think, as everything being
asynchronous, we can't know if there is a good reason that the value hasn't
been set after we leave the callback.

Possible hack for this is to unref the next promise. If the callback hasn't
refed it nor set a failure/value, it will trigger an error and trigger a
failure on the next future. Doable, but not sure if the value.do you think
it's worth it ?

> 3. Couldn't this be made in a simpler way? unzip_cb2 is really just an
> automatic resolve of another promise/future.

Yes, as said before, chaining imply we should be able to set a future as a
value on a promise.

> In unzip_cb, if I ignore "next", f2 will never come to completion.
>
> So here's a proposal:
>
> 1. Get rid of info->next. Instead:
>
> Efl_Promise *p2 = efl_promise_next(event->object);
>
> That way, EFL knows that the developer has not ignored the promise. The
> developer must then call efl_promise_value/error_set at some point, sync
or
> async.

This can not work.every set of callback need a different next promise
otherwise only one of them can really use it. For the same reason, multiple
st if callback are useful, we need to associate multiple next promise.

> If the callback doesn't call efl_promise_next, EFL knows that the "next"
> promise will never come to completion, ever. In that case, EFL
> automatically calls efl_promise_value_set(next, NULL, NULL) to keep
walking
> the chain. (Another idea is to instead cancel it).

See above proposition to do the same and still have multiple callback.

> According to [ https://promisesaplus.com/ ], if onResolve is not a
function
> (success_cb is NULL), then p2 is fullfilled with the same value as p1. So
I
> guess we would just call _unzip_cb directly in the above example.

Yes, that's something I plan to handle, setting null function well just
propagate the value/error/process down the chain.

> Without efl_promise_next() the callback must always handle "next". Failure
> to do so will break all chains, and leak. The value of "next" can be set
> inside _efl_loop_future_success.

Yes, but it's kind of a false problem anyway. If you set expect a future
and never get it triggered and you're the one who is in charge of the
promise, you have maximum 2 places where you may have forgotten to set a
value/trigger a failure. We can improve the detection as proposed above,
but I don't think it's a real problem.

> 2. (raster's idea) Get rid of event->info
>
> Similarly, use efl_promise_value_get() instead of event->info->value. That
> way we can implement stealing with efl_promise_value_steal(,
)
> and keep the symmetry with value_get().

I am not a fan of area stealing value. It may create slight problem with
multiple callback and other user have to be aware of what you're doing
(order if registering callback also matters in that case). So I would think
that if you want the ability to steal a value, we should actually have a
different efl_future_steal that allow only one callback and prevent any
other efl_future_then to be registered (and trigger an error if any are).
Which means, that value get is pretty much unnecessary. We can have it, as
it solve the issue we have by reusing efl_event_cb (but maybe we should try
to solve that instead of going around it).

> In that case, 

[EGIT] [core/enlightenment] master 01/01: force shape queue when gadget util ctxpopups change visibility

2016-09-30 Thread Mike Blumenkrantz
discomfitor pushed a commit to branch master.

http://git.enlightenment.org/core/enlightenment.git/commit/?id=b47b3cd75f0631f8ae3d92637b2db6e21da866a9

commit b47b3cd75f0631f8ae3d92637b2db6e21da866a9
Author: Mike Blumenkrantz 
Date:   Fri Sep 30 12:59:10 2016 -0400

force shape queue when gadget util ctxpopups change visibility

fixes some input region issues in x11
---
 src/bin/e_gadget.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/bin/e_gadget.c b/src/bin/e_gadget.c
index ee44819..1b208b3 100644
--- a/src/bin/e_gadget.c
+++ b/src/bin/e_gadget.c
@@ -1523,6 +1523,12 @@ e_gadget_util_layout_style_init(Evas_Object *g, 
Evas_Object *style)
return prev;
 }
 
+static void
+_gadget_util_ctxpopup_visibility(void *data EINA_UNUSED, Evas *e EINA_UNUSED, 
Evas_Object *obj EINA_UNUSED, void *event_info EINA_UNUSED)
+{
+   e_comp_shape_queue();
+}
+
 E_API void
 e_gadget_util_ctxpopup_place(Evas_Object *g, Evas_Object *ctx, Evas_Object 
*pos_obj)
 {
@@ -1552,7 +1558,11 @@ e_gadget_util_ctxpopup_place(Evas_Object *g, Evas_Object 
*ctx, Evas_Object *pos_
 elm_ctxpopup_direction_priority_set(ctx, ELM_CTXPOPUP_DIRECTION_RIGHT, 
ELM_CTXPOPUP_DIRECTION_LEFT, 0, 0);
  }
evas_object_move(ctx, x, y);
+   evas_object_event_callback_add(ctx, EVAS_CALLBACK_SHOW, 
_gadget_util_ctxpopup_visibility, NULL);
+   evas_object_event_callback_add(ctx, EVAS_CALLBACK_HIDE, 
_gadget_util_ctxpopup_visibility, NULL);
evas_object_smart_callback_call(zgc->site->layout, "gadget_site_popup", 
ctx);
+   if (evas_object_visible_get(ctx))
+ e_comp_shape_queue();
 }
 
 static void

-- 




[EGIT] [tools/eflete] master 03/03: project manager2: do not print error message

2016-09-30 Thread Vyacheslav Reutskiy
rimmed pushed a commit to branch master.

http://git.enlightenment.org/tools/eflete.git/commit/?id=da8a9943d426678fa30bfbe13b29162b0cb6e98b

commit da8a9943d426678fa30bfbe13b29162b0cb6e98b
Author: Vyacheslav Reutskiy 
Date:   Fri Sep 30 16:38:57 2016 +0300

project manager2: do not print error message

It's bad practic - print error for user in progess line. Now we
will check the return value from ecore_exe. This may more simple
and not cofuse user.

Change-Id: Idf7bcbe4106a997516a33ad1bb7d88c87102d061
---
 src/bin/project_manager/project_manager2.c | 28 
 1 file changed, 28 deletions(-)

diff --git a/src/bin/project_manager/project_manager2.c 
b/src/bin/project_manager/project_manager2.c
index f28ad5b..2131078 100644
--- a/src/bin/project_manager/project_manager2.c
+++ b/src/bin/project_manager/project_manager2.c
@@ -521,26 +521,6 @@ _exe_output_handler(void *data,
 }
 
 static Eina_Bool
-_exe_error_handler(void *data,
-   int type __UNUSED__,
-   void *event_info)
-{
-   int i;
-   Ecore_Exe_Event_Data *exe_err_msg = (Ecore_Exe_Event_Data *)event_info;
-   Project_Process_Data *ppd = data;
-
-   for (i = 0; exe_err_msg->lines[i].line != NULL; i++)
- {
-if (!strncmp(exe_err_msg->lines[i].line, "ERROR: ", sizeof("ERROR: ")))
-  {
- _end_send(ppd);
-  }
- }
-
-   return ECORE_CALLBACK_DONE;
-}
-
-static Eina_Bool
 _exporter_finish_handler(void *data,
  int type __UNUSED__,
  void *event_info __UNUSED__)
@@ -754,7 +734,6 @@ _project_open_internal(Project_Process_Data *ppd)
ecore_exe_pipe_run(cmd, FLAGS, NULL);
 
ppd->data_handler = ecore_event_handler_add(ECORE_EXE_EVENT_DATA, 
_exe_output_handler, ppd);
-   ppd->error_handler = ecore_event_handler_add(ECORE_EXE_EVENT_ERROR, 
_exe_error_handler, ppd);
ppd->del_handler = ecore_event_handler_add(ECORE_EXE_EVENT_DEL, 
_exporter_finish_handler, ppd);
 
free(file_dir);
@@ -914,7 +893,6 @@ _project_import_edj(Project_Process_Data *ppd)
 eina_strbuf_free(strbuf);
 
 ppd->data_handler = ecore_event_handler_add(ECORE_EXE_EVENT_DATA, 
_exe_output_handler, ppd);
-ppd->error_handler = ecore_event_handler_add(ECORE_EXE_EVENT_ERROR, 
_exe_error_handler, ppd);
 ppd->del_handler = ecore_event_handler_add(ECORE_EXE_EVENT_DEL, 
_edje_pick_finish_handler, ppd);
  }
else
@@ -1028,7 +1006,6 @@ _project_import_edc(void *data)
ecore_exe_pipe_run(buf, FLAGS, NULL);
 
ppd->data_handler = ecore_event_handler_add(ECORE_EXE_EVENT_DATA, 
_exe_output_handler, ppd);
-   ppd->error_handler = ecore_event_handler_add(ECORE_EXE_EVENT_ERROR, 
_exe_error_handler, ppd);
ppd->del_handler = ecore_event_handler_add(ECORE_EXE_EVENT_DEL, 
_finish_from_edje_cc, ppd);
 
return last_error;
@@ -1252,7 +1229,6 @@ pm_group_source_code_export(Project *project,
ecore_exe_pipe_run(buf, FLAGS, NULL);
 
ppd->data_handler = ecore_event_handler_add(ECORE_EXE_EVENT_DATA, 
_exe_output_handler, ppd);
-   ppd->error_handler = ecore_event_handler_add(ECORE_EXE_EVENT_ERROR, 
_exe_error_handler, ppd);
ppd->del_handler = ecore_event_handler_add(ECORE_EXE_EVENT_DEL, 
_group_export_finish_handler, ppd);
 
return last_error;
@@ -1283,7 +1259,6 @@ pm_project_source_code_export(Project *project,
ecore_exe_pipe_run(buf, FLAGS, NULL);
 
ppd->data_handler = ecore_event_handler_add(ECORE_EXE_EVENT_DATA, 
_exe_output_handler, ppd);
-   ppd->error_handler = ecore_event_handler_add(ECORE_EXE_EVENT_ERROR, 
_exe_error_handler, ppd);
ppd->del_handler = ecore_event_handler_add(ECORE_EXE_EVENT_DEL, 
_group_export_finish_handler, ppd);
 
return last_error;
@@ -1368,7 +1343,6 @@ pm_project_develop_export(Project *project,
ecore_exe_pipe_run(eina_strbuf_string_get(cmd), FLAGS, NULL);
 
ppd->data_handler = ecore_event_handler_add(ECORE_EXE_EVENT_DATA, 
_exe_output_handler, ppd);
-   ppd->error_handler = ecore_event_handler_add(ECORE_EXE_EVENT_ERROR, 
_exe_error_handler, ppd);
ppd->del_handler = ecore_event_handler_add(ECORE_EXE_EVENT_DEL, 
_develop_export_finish_handler, ppd);
 
return last_error;
@@ -1411,7 +1385,6 @@ _release_export_finish_handler(void *data,
ecore_exe_pipe_run(eina_strbuf_string_get(buf), FLAGS, NULL);
 
ppd->data_handler = ecore_event_handler_add(ECORE_EXE_EVENT_DATA, 
_exe_output_handler, ppd);
-   ppd->error_handler = ecore_event_handler_add(ECORE_EXE_EVENT_ERROR, 
_exe_error_handler, ppd);
ppd->del_handler = ecore_event_handler_add(ECORE_EXE_EVENT_DEL, 
_release_export_build_finish_handler, ppd);
 
eina_strbuf_free(buf);
@@ -1449,7 +1422,6 @@ pm_project_release_export(Project *project,
ecore_exe_pipe_run(buf, FLAGS, NULL);
 
ppd->data_handler = ecore_event_handler_add(ECORE_EXE_EVENT_DATA, 
_exe_output_handler, ppd);
-   ppd->error_handler = 

[EGIT] [tools/eflete] master 02/03: splash: start animation only after setup success

2016-09-30 Thread Vyacheslav Reutskiy
rimmed pushed a commit to branch master.

http://git.enlightenment.org/tools/eflete.git/commit/?id=5d50e27cea512d7e8bd8bf11d23fb101ee643e65

commit 5d50e27cea512d7e8bd8bf11d23fb101ee643e65
Author: Vyacheslav Reutskiy 
Date:   Fri Sep 30 16:31:12 2016 +0300

splash: start animation only after setup success

Change-Id: Ibea59a917f3befb1118366ee2d9f3544ded118e4
---
 data/themes/default/widgets/inwin.edc | 3 ++-
 src/bin/ui/splash.c   | 8 +++-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/data/themes/default/widgets/inwin.edc 
b/data/themes/default/widgets/inwin.edc
index 783b5e9..c96bfe0 100644
--- a/data/themes/default/widgets/inwin.edc
+++ b/data/themes/default/widgets/inwin.edc
@@ -792,7 +792,8 @@ group { name: "elm/win/inwin/splash";
}
programs {
   program { name: "load";
- signal: "load";
+ signal: "start";
+ source: "eflete";
  action: STATE_SET "visible" 0.0;
  transition: LINEAR 0.3;
  target: "bg";
diff --git a/src/bin/ui/splash.c b/src/bin/ui/splash.c
index 2c8ce19..e61628b 100644
--- a/src/bin/ui/splash.c
+++ b/src/bin/ui/splash.c
@@ -60,7 +60,13 @@ _on_setup(void *data __UNUSED__,
   const char *emission __UNUSED__,
   const char *source __UNUSED__)
 {
-   if (sdata.setup) sdata.setup(sdata.data, sdata.status);
+   if (sdata.setup)
+ if (!sdata.setup(sdata.data, sdata.status))
+   {
+  elm_layout_signal_emit(sdata.win, "end", "eflete");
+  return;
+   }
+   elm_layout_signal_emit(sdata.win, "start", "eflete");
 }
 
 Evas_Object *

-- 




[EGIT] [tools/eflete] master 01/03: tabs: check the return value from project manager

2016-09-30 Thread Vyacheslav Reutskiy
rimmed pushed a commit to branch master.

http://git.enlightenment.org/tools/eflete.git/commit/?id=924f3f05f72df0bb03dd9069eb078bca72b62eaa

commit 924f3f05f72df0bb03dd9069eb078bca72b62eaa
Author: Vyacheslav Reutskiy 
Date:   Fri Sep 30 16:30:44 2016 +0300

tabs: check the return value from project manager

Change-Id: I6bfe93cec217e4e1f6209ba2c5cabc1f3090ad6d
---
 src/bin/ui/tab_home_import_edc.c |  6 --
 src/bin/ui/tab_home_import_edj.c | 16 +---
 src/bin/ui/tab_home_new.c| 16 +---
 src/bin/ui/tab_home_open.c   |  4 +++-
 4 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/src/bin/ui/tab_home_import_edc.c b/src/bin/ui/tab_home_import_edc.c
index 9817e9a..ec3e3f3 100644
--- a/src/bin/ui/tab_home_import_edc.c
+++ b/src/bin/ui/tab_home_import_edc.c
@@ -382,16 +382,18 @@ static Eina_Bool
 _setup_open_splash(void *data __UNUSED__, Splash_Status status __UNUSED__)
 {
Eina_Bool ret = true;
+   PM_Project_Result result;
Eina_Strbuf *flags = _edje_cc_opt_build();
 
eina_strbuf_reset(tab_edc.log);
-   if (!pm_project_import_edc(elm_entry_entry_get(tab_edc.name),
+   result = pm_project_import_edc(elm_entry_entry_get(tab_edc.name),
   elm_entry_entry_get(tab_edc.path),
   elm_entry_entry_get(tab_edc.edc),
   eina_strbuf_string_get(flags),
   _progress_print,
   _progress_end,
-  _edc.meta))
+  _edc.meta);
+   if (PM_PROJECT_SUCCESS != result)
  ret = false;
 
eina_strbuf_free(flags);
diff --git a/src/bin/ui/tab_home_import_edj.c b/src/bin/ui/tab_home_import_edj.c
index 8e80934..304ea0a 100644
--- a/src/bin/ui/tab_home_import_edj.c
+++ b/src/bin/ui/tab_home_import_edj.c
@@ -437,13 +437,15 @@ static Eina_Bool
 _setup_open_splash(void *data __UNUSED__, Splash_Status status __UNUSED__)
 {
Eina_Bool ret = true;
-   if (!pm_project_import_edj(elm_entry_entry_get(tab_edj.name),
-  elm_entry_entry_get(tab_edj.path),
-  elm_entry_entry_get(tab_edj.edj),
-  tab_edj.widget_list,
-  progress_print,
-  _progress_end,
-  _edj.meta))
+   PM_Project_Result result;
+   result = pm_project_import_edj(elm_entry_entry_get(tab_edj.name),
+  elm_entry_entry_get(tab_edj.path),
+  elm_entry_entry_get(tab_edj.edj),
+  tab_edj.widget_list,
+  progress_print,
+  _progress_end,
+  _edj.meta);
+   if (PM_PROJECT_SUCCESS != result)
  ret = false;
 
return ret;
diff --git a/src/bin/ui/tab_home_new.c b/src/bin/ui/tab_home_new.c
index e600203..edae7c7 100644
--- a/src/bin/ui/tab_home_new.c
+++ b/src/bin/ui/tab_home_new.c
@@ -453,6 +453,7 @@ _setup_open_splash(void *data __UNUSED__, Splash_Status 
status __UNUSED__)
Eina_Strbuf *edc, *flags;
Eina_Stringshare *edc_path;
FILE *fp;
+   PM_Project_Result result;
 
if (!eina_file_mkdtemp("eflete_project_XX", _dir))
  {
@@ -480,13 +481,14 @@ _setup_open_splash(void *data __UNUSED__, Splash_Status 
status __UNUSED__)
eina_strbuf_append_printf(flags, "-id \"%s/template/images\" -sd 
\"%s/template/sounds\" -v",
  ap.path.edj_path, ap.path.edj_path);
 
-   if (!pm_project_import_edc(elm_entry_entry_get(tab_new.name),
-  elm_entry_entry_get(tab_new.path),
-  edc_path,
-  eina_strbuf_string_get(flags),
-  progress_print,
-  _progress_end,
-  _new.meta))
+   result = pm_project_import_edc(elm_entry_entry_get(tab_new.name),
+  elm_entry_entry_get(tab_new.path),
+  edc_path,
+  eina_strbuf_string_get(flags),
+  progress_print,
+  _progress_end,
+  _new.meta);
+   if (PM_PROJECT_SUCCESS != result)
  ret = false;
 
eina_strbuf_free(flags);
diff --git a/src/bin/ui/tab_home_open.c b/src/bin/ui/tab_home_open.c
index 9bf85fa..1ae6373 100644
--- a/src/bin/ui/tab_home_open.c
+++ b/src/bin/ui/tab_home_open.c
@@ -47,10 +47,12 @@ _setup_open_splash(void *data, Splash_Status status 
__UNUSED__)
 {
Eina_Bool ret = true;
Eina_Stringshare *path = data;
+   PM_Project_Result result;
 
assert(path != NULL);
 
-   if (!pm_project_open(path, progress_print, _tabs_progress_end, NULL))
+   result = pm_project_open(path, progress_print, 

[EGIT] [editors/vim-configs] master 01/01: Eo: Add ref tag.

2016-09-30 Thread Tom Hacohen
tasn pushed a commit to branch master.

http://git.enlightenment.org/editors/vim-configs.git/commit/?id=8a6682cb492cf1b739160374713ac0968b72b3fd

commit 8a6682cb492cf1b739160374713ac0968b72b3fd
Author: Tom Hacohen 
Date:   Fri Sep 30 15:08:42 2016 +0100

Eo: Add ref tag.
---
 syntax/eo.vim | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/syntax/eo.vim b/syntax/eo.vim
index 1b0ac17..d3bee08 100644
--- a/syntax/eo.vim
+++ b/syntax/eo.vim
@@ -23,7 +23,7 @@ syn keywordeoClassBodyLabels legacy_prefix eo_prefix 
event_prefix data conta
 syn keywordeoClassBodyBlockOpener properties methods events constructors 
implements contained
 
 syn keywordeoInnerBlockOpener set get keys values params contained
-syn keywordeoTypeClass const own free contained
+syn keywordeoTypeClass const own free ref contained
 syn keywordfunctionKeywords constructor destructor finalize virtual legacy
 syn keywordeoStatements return
 

-- 




[EGIT] [tools/eflete] master 03/04: exporter: extend the return value

2016-09-30 Thread Vyacheslav Reutskiy
rimmed pushed a commit to branch master.

http://git.enlightenment.org/tools/eflete.git/commit/?id=8a1464913f05cc123b656008b61be907fccb6d91

commit 8a1464913f05cc123b656008b61be907fccb6d91
Author: Vyacheslav Reutskiy 
Date:   Fri Sep 30 09:07:01 2016 +0300

exporter: extend the return value

Now exporter return the error code accordingly to error.

Change-Id: I7955ee478ba989fc8db7c0720ae6d218eabdd9bf
---
 src/bin/exporter/eflete_exporter.c | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/src/bin/exporter/eflete_exporter.c 
b/src/bin/exporter/eflete_exporter.c
index 4e2cf0e..361005e 100644
--- a/src/bin/exporter/eflete_exporter.c
+++ b/src/bin/exporter/eflete_exporter.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include "group_manager_resources.h"
+#include "project_manager2_data.h"
 #include "string_common.h"
 
 #ifdef HAVE_CONFIG_H
@@ -40,7 +41,7 @@ static Ecore_Job *sounds_job = NULL;
 static Ecore_Job *fonts_job = NULL;
 static Ecore_Job *source_job = NULL;
 
-static int exit_status = EXIT_SUCCESS;
+static PM_Project_Result exit_status = PM_PROJECT_SUCCESS;
 
 static const Ecore_Getopt options = {
PACKAGE_NAME,
@@ -81,7 +82,7 @@ _digist_get(int v)
 }
 
 static void
-_terminate(void)
+_terminate(PM_Project_Result error)
 {
char buf[256];
 
@@ -104,7 +105,7 @@ _terminate(void)
  ecore_file_recursive_rm(buf);
 
ecore_job_del(source_job);
-   exit_status = EXIT_FAILURE;
+   exit_status = error;
ecore_main_loop_quit();
 }
 
@@ -128,7 +129,7 @@ _images_resources_export(void *data __UNUSED__)
 if (!ecore_file_mkpath(buf))
   {
  fprintf(stderr, "ERROR: Failed create path %s for export images", 
buf);
- _terminate();
+ _terminate(PM_PROJECT_EXPORT_CREATE_PATH_FAILED);
  return;
   }
  }
@@ -148,7 +149,7 @@ _images_resources_export(void *data __UNUSED__)
  if (!eina_file_copy(name, buf, EINA_FILE_COPY_PERMISSION | 
EINA_FILE_COPY_XATTR, NULL, NULL))
{
   fprintf(stderr, "ERROR: Could not copy image '%s'\n", name);
-  _terminate();
+  _terminate(PM_PROJECT_EXPORT_COPY_FILE_FAILED);
   return;
}
   }
@@ -158,7 +159,7 @@ _images_resources_export(void *data __UNUSED__)
  if (id < 0)
{
   fprintf(stderr, "ERROR: Image have wrong id %i\n", id);
-  _terminate();
+  _terminate(PM_PROJECT_EXPORT_WRONG_IMAGE_ID);
   return;
}
  snprintf(buf, strlen("edje/images/") + (_digist_get(id) + 1) + 1,
@@ -173,7 +174,7 @@ _images_resources_export(void *data __UNUSED__)
  if (!evas_object_image_save(img, buf, NULL, NULL))
{
   fprintf(stderr, "ERROR: Image does not save, error: %s\n", 
evas_load_error_str(evas_object_image_load_error_get(img)));
-  _terminate();
+  _terminate(PM_PROJECT_EXPORT_SAVE_IMAGE_FAILED);
   return;
}
   }
@@ -204,7 +205,7 @@ _sounds_resources_export(void *data __UNUSED__)
 if (!ecore_file_mkpath(buf))
   {
  fprintf(stderr, "ERROR: Failed create path %s for export sounds", 
buf);
- _terminate();
+ _terminate(PM_PROJECT_EXPORT_CREATE_PATH_FAILED);
  return;
   }
  }
@@ -223,14 +224,14 @@ _sounds_resources_export(void *data __UNUSED__)
 if (!(f = fopen(buf, "wb")))
   {
  fprintf(stderr, "ERROR: Could not export sound '%s'. File does 
not open.\n", sound_file);
- _terminate();
+ _terminate(PM_PROJECT_EXPORT_SAVE_SAMPLE_FAILED);
  return;
   }
 if (fwrite(eina_binbuf_string_get(sound_bin),
eina_binbuf_length_get(sound_bin), 1, f) != 1)
   {
  fprintf(stderr, "ERROR: Could not export sound '%s', Unable to 
write file.\n", sound_file);
- _terminate();
+ _terminate(PM_PROJECT_EXPORT_SAVE_SAMPLE_FAILED);
  fclose(f);
  return;
   }
@@ -264,7 +265,7 @@ _fonts_resources_export(void *data __UNUSED__)
 if (!ecore_file_mkpath(buf))
   {
  fprintf(stderr, "ERROR: Failed create path %s for export 
fonts.\n", buf);
- _terminate();
+ _terminate(PM_PROJECT_EXPORT_CREATE_PATH_FAILED);
  return;
   }
  }
@@ -281,7 +282,7 @@ _fonts_resources_export(void *data __UNUSED__)
 if (!font)
   {
  fprintf(stderr, "ERROR: Unable to read font '%s' from '%s'.\n", 
buf, sedj);
- _terminate();
+ _terminate(PM_PROJECT_EXPORT_READ_EDJ_FONT_FAILED);
  goto exit;
   }
 snprintf(buf, strlen(spath) + 

[EGIT] [tools/eflete] master 01/04: project manager2: add return value

2016-09-30 Thread Vyacheslav Reutskiy
rimmed pushed a commit to branch master.

http://git.enlightenment.org/tools/eflete.git/commit/?id=b3156626fc4b6489724baf4fb8e14b33e41d704b

commit b3156626fc4b6489724baf4fb8e14b33e41d704b
Author: Vyacheslav Reutskiy 
Date:   Thu Sep 29 17:57:43 2016 +0300

project manager2: add return value

Extend results enum PM_Project_Result. Now project manager APIs
return the enum value, it's helps show to user more detail info
in case of any error.

Change-Id: I42ad6c7ef07f496f636cc5f96c41902de11a2d97
---
 src/bin/project_manager/project_manager2.c | 290 +++--
 src/bin/project_manager/project_manager2.h |  58 +++---
 2 files changed, 185 insertions(+), 163 deletions(-)

diff --git a/src/bin/project_manager/project_manager2.c 
b/src/bin/project_manager/project_manager2.c
index 7482a32..417829e 100644
--- a/src/bin/project_manager/project_manager2.c
+++ b/src/bin/project_manager/project_manager2.c
@@ -41,6 +41,7 @@
   ECORE_EXE_PIPE_ERROR | ECORE_EXE_PIPE_ERROR_LINE_BUFFERED
 
 static Eet_Compression compess_level = EET_COMPRESSION_HI;
+static PM_Project_Result last_error = PM_PROJECT_LAST;
 
 struct _Project_Process_Data
 {
@@ -48,8 +49,6 @@ struct _Project_Process_Data
PM_Project_Progress_Cb func_progress;
/** The end callback. See #PM_Project_End_Cb. */
PM_Project_End_Cb func_end;
-   /** The project process result. */
-   PM_Project_Result result;
/** The user data. */
void *data;
/** The new project, was created in the Project process. This pointer will 
be
@@ -157,7 +156,7 @@ _project_process_data_cleanup(Project_Process_Data *ppd)
free(ppd);
 }
 
-__UNUSED_RESULT__ static Eina_Bool
+__UNUSED_RESULT__ static PM_Project_Result
 _project_special_group_add(Project *project)
 {
Eina_Bool ret = true;
@@ -167,8 +166,9 @@ _project_special_group_add(Project *project)
 
assert(project != NULL);
 
+   last_error = PM_PROJECT_SUCCESS;
if (edje_file_group_exists(project->saved_edj, EFLETE_INTERNAL_GROUP_NAME))
- return true;
+ return last_error;
 
groups = edje_file_collection_list(project->saved_edj);
ecore_evas = ecore_evas_buffer_new(0, 0);
@@ -179,7 +179,7 @@ _project_special_group_add(Project *project)
if (!editor_internal_group_add(obj))
  {
 CRIT("Could not add Eflete spec group");
-ret = false;
+last_error = PM_PROJECT_ADD_SPEC_GROUP_FAILED;
  }
you_shall_pass_editor_signals(NULL);
 
@@ -193,9 +193,9 @@ static Project *
 _project_create(Project_Process_Data *ppd)
 {
Project *pro;
-   Eina_Bool error = false;
char buf[PATH_MAX];
 
+   last_error = PM_PROJECT_SUCCESS;
_project_descriptor_init(ppd);
 
snprintf(buf, sizeof(buf), "%s/%s", ppd->path, ppd->name);
@@ -206,9 +206,9 @@ _project_create(Project_Process_Data *ppd)
else
  {
 ERR("Could't create a project folder!");
-error = true;
+last_error = PM_PROJECT_CREATE_PRO_FAILED;
+return NULL;
  }
-   if (error) return NULL;
 
pro = (Project *)mem_calloc(1, sizeof(Project));
pro->version = PROJECT_FILE_VERSION;
@@ -220,7 +220,12 @@ _project_create(Project_Process_Data *ppd)
snprintf(buf, sizeof(buf), "%s/%s/%s.pro", ppd->path, ppd->name, ppd->name);
pro->pro_path = eina_stringshare_add(buf);
pro->ef = eet_open(buf, EET_FILE_MODE_READ_WRITE);
-   DBG("Create a specific project file '%s': %s", buf, error ? "failed" : 
"success");
+   if (!pro->ef)
+ {
+CRIT("Failed to create a pro file '%s'", buf);
+last_error = PM_PROJECT_CREATE_PRO_FAILED;
+goto exit;
+ }
pro->pro_fd = -1;
ecore_file_mkdir(pro->develop_path);
snprintf(buf, sizeof(buf), "%s/images", pro->develop_path);
@@ -231,10 +236,12 @@ _project_create(Project_Process_Data *ppd)
ecore_file_mkdir(buf);
 
if (!eet_data_write(pro->ef, ppd->eed_project, PROJECT_FILE_KEY, pro, 
compess_level))
- error = true;
+ last_error = PM_PROJECT_WRITE_PRO_FAILED;
 
_pm_project_descriptor_shutdown(ppd);
-   if (error)
+
+exit:
+   if (PM_PROJECT_SUCCESS != last_error)
  {
 ERR("Could't create a .pro file! ")
 eina_stringshare_del(pro->name);
@@ -248,10 +255,9 @@ _project_create(Project_Process_Data *ppd)
return pro;
 }
 
-__UNUSED_RESULT__ static Eina_Bool
+__UNUSED_RESULT__ static PM_Project_Result
 _project_dummy_sample_add(Project *project)
 {
-   Eina_Bool ret = true;
char buf[PATH_MAX];
Eina_List *list, *l;
Evas_Object *obj;
@@ -260,6 +266,7 @@ _project_dummy_sample_add(Project *project)
 
assert(project != NULL);
 
+   last_error = PM_PROJECT_SUCCESS;
list = edje_file_collection_list(project->saved_edj);
ecore_evas = ecore_evas_buffer_new(0, 0);
obj = edje_edit_object_add(ecore_evas_get(ecore_evas));
@@ -273,7 +280,7 @@ _project_dummy_sample_add(Project *project)
 if (!strcmp(data, EFLETE_DUMMY_SAMPLE_NAME))
   {
  

[EGIT] [tools/eflete] master 02/04: project manager2: add header with data defines

2016-09-30 Thread Vyacheslav Reutskiy
rimmed pushed a commit to branch master.

http://git.enlightenment.org/tools/eflete.git/commit/?id=d8e424d4ba5611fe0f52b673a8342df9e768db50

commit d8e424d4ba5611fe0f52b673a8342df9e768db50
Author: Vyacheslav Reutskiy 
Date:   Fri Sep 30 12:18:27 2016 +0300

project manager2: add header with data defines

This allow use only project manager data structures in the eflete
exporter.

Change-Id: Ic99229bbe877b9d5cfa0c99883405ebb41bcc3be
---
 src/bin/Makefile.am |   1 +
 src/bin/project_manager/project_manager2.c  |   3 +-
 src/bin/project_manager/project_manager2.h  | 148 +--
 src/bin/project_manager/project_manager2_data.h | 188 
 4 files changed, 191 insertions(+), 149 deletions(-)

diff --git a/src/bin/Makefile.am b/src/bin/Makefile.am
index 5cbf68b..475aa8c 100644
--- a/src/bin/Makefile.am
+++ b/src/bin/Makefile.am
@@ -30,6 +30,7 @@ EXTRA_DIST = \
project_manager/group_manager.h \
project_manager/group_manager_resources.h \
project_manager/project_manager2.h \
+   project_manager/project_manager2_data.h \
project_manager/resource_manager.h \
resource_manager/resource_manager2.h \
resource_manager/resource_manager_private.h \
diff --git a/src/bin/project_manager/project_manager2.c 
b/src/bin/project_manager/project_manager2.c
index 417829e..f28ad5b 100644
--- a/src/bin/project_manager/project_manager2.c
+++ b/src/bin/project_manager/project_manager2.c
@@ -533,7 +533,6 @@ _exe_error_handler(void *data,
  {
 if (!strncmp(exe_err_msg->lines[i].line, "ERROR: ", sizeof("ERROR: ")))
   {
- last_error = PM_PROJECT_EXPORT_RESOURCE_FAILED;
  _end_send(ppd);
   }
  }
@@ -552,7 +551,7 @@ _exporter_finish_handler(void *data,
 
if (exporter_exit->exit_code != 0)
  {
-last_error = PM_PROJECT_EXPORT_RESOURCE_FAILED;
+last_error = exporter_exit->exit_code;
 _end_send(ppd);
 return ECORE_CALLBACK_DONE;
  }
diff --git a/src/bin/project_manager/project_manager2.h 
b/src/bin/project_manager/project_manager2.h
index fab6d87..20b38d6 100644
--- a/src/bin/project_manager/project_manager2.h
+++ b/src/bin/project_manager/project_manager2.h
@@ -32,87 +32,9 @@
  * Of these files is .pro file, main Eflete project file. This file consist all
  * information about project in the current folder.
  */
-
 #include "eflete.h"
 #include "resource_manager2.h"
-
-/* don't forget to update on major changes */
-#define PROJECT_FILE_VERSION 5
-
-/**
- * @struct _Project
- *
- * Main struct of 'Project' in the Eflete. It struct consist a data of a opened
- * project.
- * Eflete project term - it's a eet file with extension '.pro', which consist
- * all techical information about project.
- *
- * @ingroup ProjectManager
- */
-struct _Project
-{
-   /* version of project file */
-   int version;
-   /** File descriptor of open "*.pro" file. Needed for keep that file locked*/
-#ifdef _WIN32
-   HANDLE pro_fd;
-#else
-   int pro_fd;
-#endif
-   /** The project name */
-   Eina_Stringshare *name;
-   /** project path */
-   Eina_Stringshare *pro_path;
-   /** the .pro file descriptor */
-   Eet_File *ef;
-   /** this is worrking file, all changes are happened in this file. */
-   Eina_Stringshare *dev;
-   /** ecore evas buffer for project objects */
-   Ecore_Evas *ecore_evas;
-   /** edje_edit_object for global operations */
-   Evas_Object *global_object;
-   /** this is saved file. */
-   Eina_Stringshare *saved_edj;
-
-   /** path where will be saved the develop edj file */
-   Eina_Stringshare *develop_path;
-   /** compile options for release edj file. see edje_cc reference */
-   Eina_Stringshare *release_options;
-
-   struct {
-  Eina_List *groups;
-  Eina_List *tones;
-  Eina_List *sounds;
-  Eina_List *images;
-  Eina_List *image_sets;
-  Eina_List *fonts;
-  Eina_List *colorclasses;
-  Eina_List *styles;
-  Eina_List *global_data;
-   } RM; /* rename to resource_manager,
-this is just to make coding simplier. easier and faster */
-
-   Eina_List *groups;
-   Eina_List *images;
-   Eina_List *image_sets;
-   Eina_List *sounds;
-   Eina_List *tones;
-   Eina_List *fonts;
-   Eina_List *colorclasses;
-   Eina_List *styles;
-   Eina_List *global_data;
-
-   Eina_File *mmap_file; /**< mmaped dev file*/
-
-   Eina_List *nsimage_list;
-
-#ifdef HAVE_ENVENTOR
-   Enventor_Data *enventor;
-#endif
-
-   Eina_Bool changed : 1;
-   Eina_Bool close_request : 1;
-};
+#include "project_manager2_data.h"
 
 /**
  * @enum _Build
@@ -131,80 +53,12 @@ enum _Build
 };
 
 /**
- * @enum _PM_Project_Result
- *
- * The Project process result, it's means result of all project process: 
import,
- * new project creation, save, etc.
- *
- * @ingroup ProjectManager
- */
-enum _PM_Project_Result
-{
-   PM_PROJECT_SUCCESS = 0,
-   PM_PROJECT_CANCEL,
-   

[EGIT] [tools/eflete] master 04/04: project manager2: delete never used enum

2016-09-30 Thread Vyacheslav Reutskiy
rimmed pushed a commit to branch master.

http://git.enlightenment.org/tools/eflete.git/commit/?id=48aa58d2cd51ae6f870bca63fb1d9655f9ca2372

commit 48aa58d2cd51ae6f870bca63fb1d9655f9ca2372
Author: Vyacheslav Reutskiy 
Date:   Fri Sep 30 14:22:53 2016 +0300

project manager2: delete never used enum

Change-Id: I3f8a6f234434d960968574448df879b1f2424c38
---
 src/bin/project_manager/project_manager2.h | 22 --
 1 file changed, 22 deletions(-)

diff --git a/src/bin/project_manager/project_manager2.h 
b/src/bin/project_manager/project_manager2.h
index 20b38d6..e1e16bb 100644
--- a/src/bin/project_manager/project_manager2.h
+++ b/src/bin/project_manager/project_manager2.h
@@ -37,28 +37,6 @@
 #include "project_manager2_data.h"
 
 /**
- * @enum _Build
- *
- * The build options.
- *
- * @ingroup ProjectManager
- */
-enum _Build
-{
-   /** all unsed data will be saved in the resulting file. */
-   BUILD_DEVELOP,
-   /** resulting file is optimizated, all unused data excluted from file */
-   BUILD_RELEASE,
-   BUILD_LAST
-};
-
-/**
- * @typedef Build
- * @ingroup ProjectManager
- */
-typedef enum _Build Build;
-
-/**
  * Create a new project which based on the imported edj file.
  *
  * @param name The name of new project;

-- 




Re: [E-devel] EFL interface, what's left to be done

2016-09-30 Thread Tom Hacohen
On 24/09/16 02:59, Cedric BAIL wrote:
> On Thu, Sep 22, 2016 at 4:35 AM, Tom Hacohen  wrote:
>> On 22/09/16 00:34, Cedric BAIL wrote:
>>> On Wed, Sep 21, 2016 at 1:46 AM, Tom Hacohen  wrote:
 On 19/09/16 23:33, Cedric BAIL wrote:
> On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen  wrote:
>> We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much
>> against it.
>
> There was a thread weeks ago. You indeed didn't take part of that
> discussion, but everyone else involved in that thread was ok. Actually
> the discussion evolved more into a what else to merge in. So their was
> an agreement before this email.

 Sorry, I missed that thread. What was the topic?
>>>
>>> Merging eo, efl and ecore. Like in the title :-)
>>
>> I remember that thread now, I misunderstood what you meant by merging
>> when you said it back then, and now with your promise inside lib/eo/ I
>> understand what you meant, and I'm very much against it.
>>
>> Let me clarify what I mean compared to my understanding of what you
>> mean. What I mean is what I thought was discussed in that thread.
>> I'm fine with:
>> Linking everything into one big fat ugly libefl.so (would rather not,
>> but OKish with that).
>> Having Efl.h that includes Eo.h, Elementary.h and etc.
>> Having an efl_init() and an efl_shutdown() that call them all.
>
> With EFL_MAIN, you don't need anymore to do any _init/_shutdown. Just
> for reference.
>
>> But if you think about it, it's essentially what we have in elementary.
>> It does all of the above except for the one binary linked together.
>> Which I'm mostly OK with (although see Marcel's comment about eo_debug
>> about which I forgot. Modularity has many advantages).
>>
>> What I'm *not* OK with:
>> Creating interdependency between the libraries and essentially making
>> libefl.so Ecore 2.0. One place to store everything. Units make a lot of
>> sense, of the advantages have been discussed above. My eo_debug trick
>> (which is ready, I just need to enable it, again, see marcel's email for
>> details) requires this separation.
>
> Saw it, it's neat. Question, why limitting it to eo ? Would be quite
> useful to also turn on more debug in eina, no ?
>
> 

Would maybe be useful for others. In addition, I retract my previous 
statement, there's no reason why it wouldn't work (I elaborated a bit 
more in my email from a few minutes ago).

>
 Or without joking: people have been using Eo without ecore and without
 Efl.Object. One example is Mike in E (reverted now because Eo was
 undeclared stable). You'll probably end up using Ecore in the same app,
 but again, everything you can say here you can say about Eina too.
>>>
>>> Do we have any example of an application that use Eo without Ecore or
>>> Efl today ?
>>
>> edje_cc, expedite, erigo-cli, clouseau-launcher (not the gui) and etc,
>> all depend on Eo and not on graphics. As for Ecore: I'm actually not
>> sure, some probably use ecore for networking, but it doesn't matter,
>> that's just a convenience that happened to be relevant for this case.
>> Sort of: if you can afford to use something that makes your life a bit
>> easier, why not.
>
> All of the above example do use ecore and where kind of my point.
>
 By "clean" I mean "isolated" or "untainted by its users up the stack".
 (see next comment for more info).

> I think that your disagreement about merging is only and just because
> you do not want to make asynchronous request a core feature of EFL.
> The rest is mostly rhetoric. Could you please explain why you have so
> much resistance to it being rolled into more place in efl ?

 That is exactly the reason (was I hiding it?), but not only, and one
 example of not "clean".

 A while back I was giving you some flack for not writing tests for a
 component of the EFL and cited Eo as an example of getting high test
 coverage. You then laughed it off and said something in the lines of
 "it's easier to test because it's smaller and not async" or something
 like that.
 **THAT IS EXACTLY MY POINT.**
  From my experience (and I guess the industry's collective experience),
 having small separate units make quality assurance easier, units more
 testable (because you can easily unit test) and the code easier to 
 maintain.
>>>
>>> In my opinion there is a lot of code in Eo that is far from nice to
>>> read and easy to maintain. First example is how intricate our pointer
>>> infrastructure is in eo and how little it makes sense. I have to go
>>> back at eina_safepointer, but there is seriously no justification for
>>> that. Especially when it hasn't help us catch thread safety bugs for
>>> example. So I agree with your small unit, but small unit has nothing
>>> todo as per library, it has to do with how we divide things between
>>> functions and files.
>>
>> No, it 

Re: [E-devel] EFL interface, what's left to be done

2016-09-30 Thread Tom Hacohen
On 24/09/16 10:07, marcel-hollerb...@t-online.de wrote:
> On Fri, Sep 23, 2016 at 06:59:14PM -0700, Cedric BAIL wrote:
>> On Thu, Sep 22, 2016 at 4:35 AM, Tom Hacohen  wrote:
>>> On 22/09/16 00:34, Cedric BAIL wrote:
 On Wed, Sep 21, 2016 at 1:46 AM, Tom Hacohen  wrote:
> On 19/09/16 23:33, Cedric BAIL wrote:
>> On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen  wrote:
>>> We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much
>>> against it.
>>
>> There was a thread weeks ago. You indeed didn't take part of that
>> discussion, but everyone else involved in that thread was ok. Actually
>> the discussion evolved more into a what else to merge in. So their was
>> an agreement before this email.
>
> Sorry, I missed that thread. What was the topic?

 Merging eo, efl and ecore. Like in the title :-)
>>>
>>> I remember that thread now, I misunderstood what you meant by merging
>>> when you said it back then, and now with your promise inside lib/eo/ I
>>> understand what you meant, and I'm very much against it.
>>>
>>> Let me clarify what I mean compared to my understanding of what you
>>> mean. What I mean is what I thought was discussed in that thread.
>>> I'm fine with:
>>> Linking everything into one big fat ugly libefl.so (would rather not,
>>> but OKish with that).
>>> Having Efl.h that includes Eo.h, Elementary.h and etc.
>>> Having an efl_init() and an efl_shutdown() that call them all.
>>
>> With EFL_MAIN, you don't need anymore to do any _init/_shutdown. Just
>> for reference.
>>
>>> But if you think about it, it's essentially what we have in elementary.
>>> It does all of the above except for the one binary linked together.
>>> Which I'm mostly OK with (although see Marcel's comment about eo_debug
>>> about which I forgot. Modularity has many advantages).
>>>
>>> What I'm *not* OK with:
>>> Creating interdependency between the libraries and essentially making
>>> libefl.so Ecore 2.0. One place to store everything. Units make a lot of
>>> sense, of the advantages have been discussed above. My eo_debug trick
>>> (which is ready, I just need to enable it, again, see marcel's email for
>>> details) requires this separation.
>>
>> Saw it, it's neat. Question, why limitting it to eo ? Would be quite
>> useful to also turn on more debug in eina, no ?
>
> For the same reason as why there are different log domains, if i have a issue
> with eo ref stuff, i would not like to get the complete output of ecore/eina.
>

First of all, as Carsten said, we can solve it with domains, but also, 
as long as we don't create inter-dependency between ecore and Eo, that 
is keep Eo isolated even if in the same binary (which is what I care 
about), then we could just ld_preload a debug libeo.so that would only 
modify eo.

--
Tom


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[EGIT] [tools/edi] master 01/02: config: update defaults since elm_code_widget fixed width marker

2016-09-30 Thread Andy Williams
ajwillia-ms pushed a commit to branch master.

http://git.enlightenment.org/tools/edi.git/commit/?id=1fe95db05fa5d4889b7fe18b70bbe15caad8b33e

commit 1fe95db05fa5d4889b7fe18b70bbe15caad8b33e
Author: Andy Williams 
Date:   Thu Sep 29 20:02:38 2016 +0100

config: update defaults since elm_code_widget fixed width marker
---
 src/bin/edi_config.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/bin/edi_config.c b/src/bin/edi_config.c
index 0088111..6601e8b 100644
--- a/src/bin/edi_config.c
+++ b/src/bin/edi_config.c
@@ -450,7 +450,7 @@ _edi_project_config_load()
_edi_project_config->gui.bottomopen = EINA_FALSE;
_edi_project_config->gui.bottomtab = 0;
 
-   _edi_project_config->gui.width_marker = 81;
+   _edi_project_config->gui.width_marker = 80;
_edi_project_config->gui.tabstop = 8;
_edi_project_config->gui.toolbar_hidden = EINA_FALSE;
 

-- 




[EGIT] [tools/edi] master 02/02: files: Also ignore .a and .la for a make project

2016-09-30 Thread Andy Williams
ajwillia-ms pushed a commit to branch master.

http://git.enlightenment.org/tools/edi.git/commit/?id=8b7fbed43b52984f2181a7fb2878d3e6751fc87d

commit 8b7fbed43b52984f2181a7fb2878d3e6751fc87d
Author: Andy Williams 
Date:   Fri Sep 30 10:34:11 2016 +0100

files: Also ignore .a and .la for a make project
---
 src/lib/edi_build_provider_make.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/src/lib/edi_build_provider_make.c 
b/src/lib/edi_build_provider_make.c
index 9f26962..730dd82 100644
--- a/src/lib/edi_build_provider_make.c
+++ b/src/lib/edi_build_provider_make.c
@@ -52,6 +52,17 @@ _make_file_hidden_is(const char *relative)
   return EINA_TRUE;
   }
  }
+   if (relative[len-1] == 'a' && len >= 2)
+ {
+if (relative[len-2] == '.')
+  return EINA_TRUE;
+else
+  {
+if ((relative[len-2] == 'l') &&
+  len >= 3 && relative[len-3] == '.')
+  return EINA_TRUE;
+  }
+ }
return EINA_FALSE;
 }
 

-- 




[EGIT] [tools/enventor] master 01/01: fix an incorrect API usage.

2016-09-30 Thread Hermet Park
hermet pushed a commit to branch master.

http://git.enlightenment.org/tools/enventor.git/commit/?id=721f69bbd45f977d5c27f6f900b6f33deeb40ec7

commit 721f69bbd45f977d5c27f6f900b6f33deeb40ec7
Author: Hermet Park 
Date:   Fri Sep 30 17:32:29 2016 +0900

fix an incorrect API usage.

Previous api call for directory check is not proper.
Fixed to the proper API.

This was noticed by ecore_file_path_dir_exists() bug fix.
---
 src/bin/newfile.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/bin/newfile.c b/src/bin/newfile.c
index 3ef4dbe..4b2c0bc 100644
--- a/src/bin/newfile.c
+++ b/src/bin/newfile.c
@@ -74,7 +74,7 @@ templates_get(new_data *nd)
char buf[PATH_MAX];
snprintf(buf, sizeof(buf), "%s/templates", elm_app_data_dir_get());
 
-   if (!ecore_file_path_dir_exists(buf))
+   if (!ecore_file_is_dir(buf))
  {
 EINA_LOG_ERR(_("Cannot find templates folder! \"%s\""), buf);
 return;

-- 




[EGIT] [tools/enventor] master 01/01: syntax color: These keywords shouldn't be added here.

2016-09-30 Thread Hermet Park
hermet pushed a commit to branch master.

http://git.enlightenment.org/tools/enventor.git/commit/?id=5b67f50283795100f005b545ed73ce064f5e9177

commit 5b67f50283795100f005b545ed73ce064f5e9177
Author: Hermet Park 
Date:   Fri Sep 30 16:52:50 2016 +0900

syntax color: These keywords shouldn't be added here.
---
 data/color/edc.src | 2 --
 1 file changed, 2 deletions(-)

diff --git a/data/color/edc.src b/data/color/edc.src
index fa1eabc..a618e51 100644
--- a/data/color/edc.src
+++ b/data/color/edc.src
@@ -247,7 +247,6 @@ group "syntax_color_group" struct {
  value "val" string: "00";
  group "keys" list {
 value "key" string: "anim";
-value "key" string: "blur";
 value "key" string: "cancel_anim";
 value "key" string: "cancel_timer";
 value "key" string: "custom_state";
@@ -260,7 +259,6 @@ group "syntax_color_group" struct {
 value "key" string: "get_state_val";
 value "key" string: "get_state";
 value "key" string: "get_text";
-value "key" string: "padding_set";
 value "key" string: "round";
 value "key" string: "run_program";
 value "key" string: "set_float";

-- 




[EGIT] [tools/enventor] master 01/01: syntax color: updated list.

2016-09-30 Thread Hermet Park
hermet pushed a commit to branch master.

http://git.enlightenment.org/tools/enventor.git/commit/?id=eb983b21d5dc70a1b19fa0cec2c505dca4814990

commit eb983b21d5dc70a1b19fa0cec2c505dca4814990
Author: Hermet Park 
Date:   Fri Sep 30 16:49:56 2016 +0900

syntax color: updated list.
---
 data/color/edc.src | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/data/color/edc.src b/data/color/edc.src
index a7e5b73..fa1eabc 100644
--- a/data/color/edc.src
+++ b/data/color/edc.src
@@ -40,6 +40,8 @@ group "syntax_color_group" struct {
 value "key" string: "externals";
 value "key" string: "external";
 value "key" string: "fill";
+value "key" string: "filters";
+value "key" string: "filter";
 value "key" string: "fonts";
 value "key" string: "gradient";
 value "key" string: "group";
@@ -98,6 +100,7 @@ group "syntax_color_group" struct {
 value "key" string: "border";
 value "key" string: "center";
 value "key" string: "clip_to";
+value "key" string: "code";
 value "key" string: "color2";
 value "key" string: "color3";
 value "key" string: "color_class:";
@@ -107,9 +110,11 @@ group "syntax_color_group" struct {
 value "key" string: "effect";
 value "key" string: "ellipsis";
 value "key" string: "entry_mode";
+value "key" string: "file";
 value "key" string: "fixed";
 value "key" string: "focal";
 value "key" string: "font";
+value "key" string: "hid";
 value "key" string: "ignore_flags";
 value "key" string: "image";
 value "key" string: "inherit";
@@ -242,6 +247,7 @@ group "syntax_color_group" struct {
  value "val" string: "00";
  group "keys" list {
 value "key" string: "anim";
+value "key" string: "blur";
 value "key" string: "cancel_anim";
 value "key" string: "cancel_timer";
 value "key" string: "custom_state";
@@ -254,6 +260,7 @@ group "syntax_color_group" struct {
 value "key" string: "get_state_val";
 value "key" string: "get_state";
 value "key" string: "get_text";
+value "key" string: "padding_set";
 value "key" string: "round";
 value "key" string: "run_program";
 value "key" string: "set_float";

-- 




[EGIT] [tools/eflete] master 01/01: Project manager: fix build break in window.

2016-09-30 Thread Jaehwan Kim
jaehwan pushed a commit to branch master.

http://git.enlightenment.org/tools/eflete.git/commit/?id=3fa4b5d75318f4f1a56a5357dcb3dd73e98e2021

commit 3fa4b5d75318f4f1a56a5357dcb3dd73e98e2021
Author: Jaehwan Kim 
Date:   Fri Sep 30 16:44:38 2016 +0900

Project manager: fix build break in window.

@fix
---
 src/bin/project_manager/project_manager2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/bin/project_manager/project_manager2.c 
b/src/bin/project_manager/project_manager2.c
index 0f7dd7a..7482a32 100644
--- a/src/bin/project_manager/project_manager2.c
+++ b/src/bin/project_manager/project_manager2.c
@@ -627,7 +627,7 @@ _project_open_internal(Project_Process_Data *ppd)
 /* really this case is unlickly, but we need handle it */
 ERR("Project file already locked by another application");
 #ifdef _WIN32
-CloseHandle(fd);
+CloseHandle(pro_fd);
 #else
 if (pro_fd != -1)
   close(pro_fd);

-- 




[EGIT] [tools/eflete] master 01/01: Resource manager: add NULL checking.

2016-09-30 Thread Jaehwan Kim
jaehwan pushed a commit to branch master.

http://git.enlightenment.org/tools/eflete.git/commit/?id=a37124b9548def37f4790a1ca7b09dd88918542f

commit a37124b9548def37f4790a1ca7b09dd88918542f
Author: Jaehwan Kim 
Date:   Fri Sep 30 14:36:23 2016 +0900

Resource manager: add NULL checking.

@fix
---
 src/bin/resource_manager/resource_manager_build.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/bin/resource_manager/resource_manager_build.c 
b/src/bin/resource_manager/resource_manager_build.c
index 19abc66..4753249 100644
--- a/src/bin/resource_manager/resource_manager_build.c
+++ b/src/bin/resource_manager/resource_manager_build.c
@@ -105,7 +105,8 @@ _state_dependency_load(Project *pro, Group2 *group, Part2 
*part, State2 *state)
res = resource_manager_find(pro->RM.image_sets, state->normal);
  else
res = resource_manager_find(pro->RM.images, state->normal);
- _resource_usage_resource_add((Resource2 *)state, res);
+ if (res)
+   _resource_usage_resource_add((Resource2 *)state, res);
   }
 
 EINA_LIST_FOREACH(state->tweens, l2, res)
@@ -292,7 +293,8 @@ _group_dependency_load(Project *pro, Group2 *group)
  {
 main_group_name = edje_edit_group_aliased_get(group->edit_object, 
group->common.name);
 used = resource_manager_find(pro->RM.groups, main_group_name);
-_resource_usage_resource_add((Resource2 *)group, used);
+if (used)
+  _resource_usage_resource_add((Resource2 *)group, used);
 
 edje_edit_string_free(main_group_name);
 
@@ -349,7 +351,8 @@ _resource_dependency_load(Project *pro)
 EINA_LIST_FOREACH(set_images, l2, set_image_name)
   {
  used = resource_manager_find(pro->RM.images, set_image_name);
- _resource_usage_resource_add(res, used);
+ if (used)
+   _resource_usage_resource_add(res, used);
   }
 edje_edit_string_list_free(set_images);
  }

--