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

2016-09-20 Thread Jean-Philippe André
Hi Cedric,

On 20 September 2016 at 06:05, Cedric BAIL  wrote:

> Hello everyone,
>
> So this email is going over what is left to be done to call EFL
> interface done. Most of this require still discussion also. Here it
> goes :
>
> - Merge Eo, Efl and Ecore
> - Make efl_uri_set/efl_file_set asynchronous
> - Convert Ecore_Exe to the new efl_io API
> - Fixup efl/interface/*.eo to all be in the correct namespace
> - Disable installation of evas/canvas/evas*.eo
> - Convert edje to become efl_canvas_layout
> - Update Edje with the new Text API
> - Convert elm_layout to become efl_ui_layout
> - Convert elm_widget to be an efl_ui_object of some sort
> - Update all efl data model to use efl_future/efl_promise
> - Add proper View and Controller for Genlist/Gengrid (see D3952 for some
> ideas)
> - There is still a large amount of .eo in elementary that are in elm
> namespace. This shouldn't be installed nor appear anywhere in the
> hierarchy.
> - Finish porting some of the widget to Efl.Ui namespace (photocam,
> index, entry, button, calendar, clock, menu, ...). This needs to be
> clarified with some pending patch in phab.
>
> This are quite a large todo list to be done with, hopefully it will...
>

- evas smart objects
Evas smart objects are a stable legacy API but their equivalent in EO is
horrible. Efl.Canvas.Group is not an acceptable replacement in its current
form. All the methods this class defines are poorly defined overrides over
the basic object functions (show, hide, etc...). I've started some work in
this direction but it's tedious and risky. The alternative is to have no
API for custom smart objects.

- elm_widget
elm widget was and still is an unstable / private API. I don't think
cleaning up this API is in the scope of our interfaces work, right now.

- text part API
Textblock now has a new shiny eo api but edje_object and elm_layout still
define _part_text_ APIs. This needs to be transformed to Efl.Part.

- efl.ui.window + elm_conformant
Ideally window should have merged in the features of conformant so we avoid
this extra awkward widget. Window was supposed to handle what conformant
does. The reality is that no work towards that goal has been done yet.

-- 
Jean-Philippe André
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [EGIT] [core/efl] master 01/01: eina/ecore: allow threads to be canceled, use in ecore_con.

2016-09-20 Thread Jean-Philippe André
Hi Gustavo,

On 21 September 2016 at 07:11, Carsten Haitzler 
wrote:

> On Tue, 20 Sep 2016 12:17:50 -0300 Gustavo Sverzut Barbieri
>  said:
>
> > On Tue, Sep 20, 2016 at 11:18 AM, Carsten Haitzler  >
> > wrote:
> > > On Tue, 20 Sep 2016 08:16:21 -0300 Gustavo Sverzut Barbieri
> > >  said:
> > >
> > >> On Tue, Sep 20, 2016 at 5:51 AM, Jean-Philippe André <
> j...@videolan.org>
> > >> wrote:
> > >> > Hi Gustavo,
> > >> >
> > >> > On 14 September 2016 at 13:55, Gustavo Sverzut Barbieri
> > >> >  wrote:
> > >> >
> > >> >> HEADS UP -- BINDINGS:
> > >> >>
> > >> >> If you wish to expose the new "cancellable" property, or cope with
> > >> >> naughty users or 3rd party deps that may call
> > >> >> pthread_setcancelstate(PTHREAD_CANCEL_ENABLE), please register
> your
> > >> >> cleanup functions with:
> > >> >>
> > >> >>EINA_THREAD_CLEANUP_PUSH(cb, ctx); // will call cb() on
> > >> >> pthread_cancel()/ecore_thread_cancel()/eina_thread_cancel()
> > >> >>call_user();
> > >> >>EINA_THREAD_CLEANUP_POP(EINA_TRUE); // will call cb() on clean
> exit
> > >> >>
> > >> >> If different functions are desired:
> > >> >>
> > >> >>EINA_THREAD_CLEANUP_PUSH(cb, ctx); // will call cb() on
> > >> >> pthread_cancel()/ecore_thread_cancel()/eina_thread_cancel()
> > >> >>call_user();
> > >> >>EINA_THREAD_CLEANUP_POP(EINA_FALSE); // will NOT call cb() on
> clean
> > >> >> exit
> > >> >>another_cb(ctx);
> > >> >>
> > >> >> This is recommended if you expose ecore_thread to your users. If
> you
> > >> >> don't, then you do not need to do anything.
> > >> >
> > >> >
> > >> > pthread_cancel did (does?) not exist on Android, by design choice.
> bionic
> > >> > isn't posix in that regard.
> > >> > One way or another, I remember that using cancel is actually quite
> hard,
> > >> > because you need to be very careful about the cleanup.
> > >> >
> > >> > So I wonder if adding cancel like pthread here is the best choice?
> > >> > Note that I understand the need and don't have any good alternative
> :)
> > >>
> > >> Hi jpeg, thanks for letting me know.
> > >>
> > >> When we port to bionic we should then take one choice:
> > >>
> > >>  - let the thread hang there for a while, the new code I'm doing based
> > >> on this concept shouldn't break, it will just consume few more
> > >> resources for a while. (== #ifdef)
> > >
> > > i'd say do this all the time. cancellation otherwise is way too hard
> AND its
> > > non-portable. this is an api in eina that is non-portable and that
> means we
> > > have to try make it work on other platforms... if we keepit.
> >
> > by default the thread cancellation is disabled. You have to manually
> > enable that and live with the pain, If you wish.
> >
> > I've used new efl_net code to test that, simulate what our users that
> > loves thread would do... indeed it simplifies the code a lot to use a
> > thread and do procedural programming (see ecore_con.c, socks stuff).
> > The single detail to remember is to EINA_THREAD_CLEANUP_PUSH()/POP()
> > and take care to not return in the middle, since it wouldn't execute
> > the POP(EINA_TRUE) -- if you want to always cleanup.
> >
> > The portability part can be done, like vlc did. And that is said to
> > work on Windows, seems Android is the only one not doing it.
>

Funny you would mention VLC. The first implementation of vlc_thread_cancel
on Android relied on a signal which would hopefully interrupt the blocking
syscall in the thread to cancel. From my memories, this basically just did
the job. Not sure which drawbacks it had effectively, but at the time, Remi
had mentionned using futex instead.

The current code uses futex indeed. What I can't figure out is how this
interrupts blocking syscalls.
Honestly I don't understand how that code works now :( If someone can
enlighten me?

I also don't get how syscalls are interrupted on Windows.


not portable to android. the problem is we have an eina thread api that is
> not
> portable. this is not an internal implementation detail. it's a public api
> that
> is not portable. no. no non-portable api's anymore. DEFINITELY if they
> completely fail based on platform. if its "its a bit slower on another
> platform
> as that feature doesnt exist so we emulate" then fine.
>
> we used to be linux/unix only. over the years we've had to become
> portable. now
> we have to make portable the top priority.
>
> if it's not portable then don't support it. deal with it some other way.



>
> > >>  - use pthread_kill() with an unused signal and use a signal
> > >> handler... this can be a full wrapper like the one in videolan.org,
> or
> > >> just to generate EINTR like I proposed in my first discussion.
> > >
> > > this would be a far better workaround. :)
> >
> > doesn't work on Windows :-(
>
> then hang until timeout hit. use another thread in the pool. :)
>

This assumes that the syscalls will timeout.

Anyhow. pthread_cancel is something that in practice is very hard to deal
with properly. Variable and state cleanup

[EGIT] [core/efl] master 01/01: edje edje_cc_out: use strncpy().

2016-09-20 Thread ChunEon Park
hermet pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=6de3b2c5d36993cf3dbe94e8fbefd04043f91740

commit 6de3b2c5d36993cf3dbe94e8fbefd04043f91740
Author: Hermet Park 
Date:   Wed Sep 21 15:19:19 2016 +0900

edje edje_cc_out: use strncpy().

This change is not much meaningful but avoids an annoying coverity 
detection.
---
 src/bin/edje/edje_cc_out.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/bin/edje/edje_cc_out.c b/src/bin/edje/edje_cc_out.c
index 90a8e41..cf9a831 100644
--- a/src/bin/edje/edje_cc_out.c
+++ b/src/bin/edje/edje_cc_out.c
@@ -4036,9 +4036,10 @@ data_process_string(Edje_Part_Collection *pc, const char 
*prefix, char *s, void
int quote, escape;
 
keyl = strlen(prefix) + 2;
-   key = alloca(keyl + 1);
+   int key_len = keyl + 1;
+   key = alloca(key_len);
if (!key) return;
-   strcpy(key, prefix);
+   strncpy(key, prefix, key_len);
strcat(key, ":\"");
quote = 0;
escape = 0;

-- 




[EGIT] [core/efl] master 01/01: edje edje_embryo: use strncpy().

2016-09-20 Thread ChunEon Park
hermet pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=06bd8dcf330fe31891475c92aa340d4886f47e2b

commit 06bd8dcf330fe31891475c92aa340d4886f47e2b
Author: Hermet Park 
Date:   Wed Sep 21 15:03:11 2016 +0900

edje edje_embryo: use strncpy().

This change is not meaningful but avoids an annoying coverity detection.
---
 src/lib/edje/edje_embryo.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/lib/edje/edje_embryo.c b/src/lib/edje/edje_embryo.c
index bb46310..c09c3ff 100644
--- a/src/lib/edje/edje_embryo.c
+++ b/src/lib/edje/edje_embryo.c
@@ -1553,10 +1553,9 @@ _edje_embryo_fn_get_text(Embryo_Program *ep, Embryo_Cell 
*params)
   }
 else
   {
- char *ss;
-
- ss = alloca(strlen(s) + 1);
- strcpy(ss, s);
+ int size = strlen(s) + 1;
+ char *ss = alloca(size);
+ strncpy(ss, s, size);
  ss[params[3] - 1] = 0;
  SETSTR(ss, params[2]);
   }

-- 




[EGIT] [core/efl] master 01/01: edje/edje_cc: use strncpy() instead of strcpy().

2016-09-20 Thread ChunEon Park
hermet pushed a commit to branch master.

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

commit ab1a72f5e7df6fe0adef54bdcddd9867a2ebe3a6
Author: Hermet Park 
Date:   Wed Sep 21 13:30:44 2016 +0900

edje/edje_cc: use strncpy() instead of strcpy().

strncpy() is better for security.
Also, this change avoids annoying coverity detection.
---
 src/bin/edje/edje_cc_parse.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/bin/edje/edje_cc_parse.c b/src/bin/edje/edje_cc_parse.c
index 525c71d..efabe22 100644
--- a/src/bin/edje/edje_cc_parse.c
+++ b/src/bin/edje/edje_cc_parse.c
@@ -391,7 +391,7 @@ next_token(char *p, char *end, char **new_p, int *delim)
  l = sscanf(tmpstr, "%*s %i \"%[^\"]\"", &nm, fl);
  if (l == 2)
{
-  strcpy(file_buf, fl);
+  strncpy(file_buf, fl, sizeof(file_buf));
   line = nm;
   file_in = file_buf;
}

-- 




[EGIT] [core/efl] master 01/01: evas engine: correct null check

2016-09-20 Thread ChunEon Park
hermet pushed a commit to branch master.

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

commit ff7511ae123bbaaefcd716edc2aabf57a9139da8
Author: Hermet Park 
Date:   Wed Sep 21 13:16:36 2016 +0900

evas engine: correct null check

check null first, before access it.
---
 src/modules/evas/engines/gl_generic/evas_engine.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/modules/evas/engines/gl_generic/evas_engine.c 
b/src/modules/evas/engines/gl_generic/evas_engine.c
index 5d0d465..5c5417f 100644
--- a/src/modules/evas/engines/gl_generic/evas_engine.c
+++ b/src/modules/evas/engines/gl_generic/evas_engine.c
@@ -1724,8 +1724,9 @@ eng_gl_surface_direct_renderable_get(void *data, 
Evas_Native_Surface *ns, Eina_B
Evas_Engine_GL_Context *gl_context;
Evas_GL_Image *sfc = surface;
 
+   if (!re) return EINA_FALSE;
EVGLINIT(data, EINA_FALSE);
-   if (!re || !ns) return EINA_FALSE;
+   if (!ns) return EINA_FALSE;
if (!evgl_native_surface_direct_opts_get(ns, &direct_render, 
&client_side_rotation, override))
  return EINA_FALSE;
 

-- 




[EGIT] [core/efl] master 01/01: Revert "evas engine: return as soon as possible if the surface or context is not valid."

2016-09-20 Thread ChunEon Park
hermet pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=545161d9546d1a80ca5ffd31cbc3b4d0cae335f8

commit 545161d9546d1a80ca5ffd31cbc3b4d0cae335f8
Author: Hermet Park 
Date:   Wed Sep 21 13:06:18 2016 +0900

Revert "evas engine: return as soon as possible if the surface or context 
is not valid."

This reverts commit 2f158ebe65cc3d007c1eae0e25590f092931ee25.

misunderstood ^ operator.
pinged by jpeg.

previous code was correct.
---
 src/modules/evas/engines/software_generic/evas_engine.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/modules/evas/engines/software_generic/evas_engine.c 
b/src/modules/evas/engines/software_generic/evas_engine.c
index 361..62ad71a 100644
--- a/src/modules/evas/engines/software_generic/evas_engine.c
+++ b/src/modules/evas/engines/software_generic/evas_engine.c
@@ -3655,14 +3655,18 @@ eng_gl_make_current(void *data EINA_UNUSED, void 
*surface, void *context)
 
_tls_check();
 
-   if ((!sfc) || (!ctx))
+   if ((!sfc) ^ (!ctx))
  {
 ERR("Evas GL on SW engine does not support surfaceless contexts.");
+return 0;
+ }
 
-// Unset surface/context
+   // Unset surface/context
+   if ((!sfc) && (!ctx))
+ {
 eina_tls_set(gl_current_ctx_key, NULL);
 eina_tls_set(gl_current_sfc_key, NULL);
-return 0;
+return 1;
  }
 
// Initialize Context if it hasn't been.

-- 




[EGIT] [core/efl] master 01/01: evas engine: return as soon as possible if the surface or context is not valid.

2016-09-20 Thread ChunEon Park
hermet pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=2f158ebe65cc3d007c1eae0e25590f092931ee25

commit 2f158ebe65cc3d007c1eae0e25590f092931ee25
Author: Hermet Park 
Date:   Wed Sep 21 12:24:49 2016 +0900

evas engine: return as soon as possible if the surface or context is not 
valid.

And later, the surface and context are accessed.
So both of arguments should be valid necessarily.
---
 src/modules/evas/engines/software_generic/evas_engine.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/src/modules/evas/engines/software_generic/evas_engine.c 
b/src/modules/evas/engines/software_generic/evas_engine.c
index 62ad71a..361 100644
--- a/src/modules/evas/engines/software_generic/evas_engine.c
+++ b/src/modules/evas/engines/software_generic/evas_engine.c
@@ -3655,18 +3655,14 @@ eng_gl_make_current(void *data EINA_UNUSED, void 
*surface, void *context)
 
_tls_check();
 
-   if ((!sfc) ^ (!ctx))
+   if ((!sfc) || (!ctx))
  {
 ERR("Evas GL on SW engine does not support surfaceless contexts.");
-return 0;
- }
 
-   // Unset surface/context
-   if ((!sfc) && (!ctx))
- {
+// Unset surface/context
 eina_tls_set(gl_current_ctx_key, NULL);
 eina_tls_set(gl_current_sfc_key, NULL);
-return 1;
+return 0;
  }
 
// Initialize Context if it hasn't been.

-- 




Re: [E-devel] Efl_Promise and Efl_Future

2016-09-20 Thread Felipe Magno de Almeida
On Sun, Sep 18, 2016 at 3:35 AM, Davide Andreoli  wrote:
> 2016-09-18 4:30 GMT+02:00 Felipe Magno de Almeida <
> felipe.m.alme...@gmail.com>:
>> On Sep 17, 2016 3:53 AM, "Davide Andreoli"  wrote:

[snip]

>> The problem with callbacks is not difficult to implement, but difficult to
>> free the void* data. It needs two function pointers and the void* data to
>> implement correctly and generally. Not that I'm against per se, but
>> lifetime is the real problem.
>
> Indeed the lifetime of the *void data is the trickiest part, a free_data_cb
> seems to me the most "correct" way to handle this, not only for bindings
> but also for C code.
>
> Can you explain me how promises solve this problem? where the user is
> expected to free the *data in C? in both the success/failure callbacks?

Promises are not generic, so their lifetime is known. The user frees it in
success/failure callback, yes.

> What about chained promises?

Chained promises are multiple promises, so each success/failure callback
that is registered must free its void* data in its own success/failure callback.

Note that the void* data is in this case in efl_promise_then, and not in
efl_promise_value_set, the last one has a free callback for the value.

[snip]

Regards,
-- 
Felipe Magno de Almeida

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


[EGIT] [core/efl] master 01/01: eo-cxx: Add progress to future and promise

2016-09-20 Thread Felipe Magno de Almeida
felipealmeida pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=10293e652055a5e741f3b9f87c14e7919bb2d267

commit 10293e652055a5e741f3b9f87c14e7919bb2d267
Author: Felipe Magno de Almeida 
Date:   Tue Sep 20 23:30:13 2016 -0300

eo-cxx: Add progress to future and promise
---
 src/bindings/cxx/eo_cxx/eo_future.hh   | 199 +
 src/bindings/cxx/eo_cxx/eo_promise.hh  | 121 --
 src/bindings/cxx/eo_cxx/eo_promise_meta.hh |  44 +++
 src/tests/eo_cxx/eo_cxx_test_promise.cc|  40 ++
 4 files changed, 285 insertions(+), 119 deletions(-)

diff --git a/src/bindings/cxx/eo_cxx/eo_future.hh 
b/src/bindings/cxx/eo_cxx/eo_future.hh
index 7154b5f..fbab965 100644
--- a/src/bindings/cxx/eo_cxx/eo_future.hh
+++ b/src/bindings/cxx/eo_cxx/eo_future.hh
@@ -116,17 +116,15 @@ struct shared_future_common
Efl_Future* _future;
 };
   
-template 
-struct shared_future_1_type : private shared_future_common
+template 
+struct shared_future_1_type : shared_future_common
 {
typedef shared_future_common _base_type;
 
using _base_type::_base_type;
-   using _base_type::swap;
-   using _base_type::valid;
-   using _base_type::native_handle;
-   using _base_type::wait;
-   typedef _base_type::native_handle_type native_handle_type;
+   shared_future_1_type() = default;
+   shared_future_1_type(shared_future_common const& other)
+ : _base_type(other) {}
 
T get() const
{
@@ -162,20 +160,17 @@ struct shared_future_1_type : private shared_future_common
   wait_state->cv.notify_one();
}
 
-   typedef shared_future_1_type _self_type;
+   typedef shared_future_1_type _self_type;
 };
 
 template 
-struct shared_race_future_1_type : private shared_future_common
+struct shared_race_future_1_type : shared_future_common
 {
typedef shared_future_common _base_type;
 
using _base_type::_base_type;
-   using _base_type::swap;
-   using _base_type::valid;
-   using _base_type::native_handle;
-   using _base_type::wait;
-   typedef _base_type::native_handle_type native_handle_type;
+   shared_race_future_1_type(_base_type const& other)
+ : _base_type(other) {}
 
T get() const
{
@@ -211,20 +206,18 @@ struct shared_race_future_1_type : private 
shared_future_common
   wait_state->cv.notify_one();
}
 
-   typedef shared_future_1_type _self_type;
+   typedef shared_race_future_1_type _self_type;
 };
-  
+
 template 
-struct shared_future_varargs_type : private shared_future_common
+struct shared_future_varargs_type : shared_future_common
 {
typedef shared_future_common _base_type;
 
using _base_type::_base_type;
-   using _base_type::swap;
-   using _base_type::valid;
-   using _base_type::native_handle;
-   using _base_type::wait;
-   typedef _base_type::native_handle_type native_handle_type;
+   shared_future_varargs_type() = default;
+   shared_future_varargs_type(_base_type const& other)
+ : _base_type(other) {}
 
typedef std::tuple tuple_type;
 
@@ -314,17 +307,59 @@ struct shared_future_varargs_type : private 
shared_future_common
 }
 
 template 
-struct shared_future : private std::conditional>::type>, _impl::shared_future_varargs_type>::type
+struct shared_future : private
+  std::conditional
+  <
+sizeof...(Args) == 1
+, _impl::shared_future_1_type>::type>
+, typename std::conditional
+  <_impl::is_progress>::type>::value
+  , typename std::conditional
+
+ , _impl::shared_future_varargs_type
+ >::type
+   , _impl::shared_future_varargs_type
+   >::type
+  >::type
 {
-   typedef typename std::conditional>::type>, _impl::shared_future_varargs_type>::type 
_base_type;
-
+   typedef typename
+  std::conditional
+  <
+sizeof...(Args) == 1
+, _impl::shared_future_1_type
+, typename std::conditional
+  <_impl::is_progress>::type>::value
+  , typename std::conditional
+
+ , _impl::shared_future_varargs_type
+ >::type
+   , _impl::shared_future_varargs_type
+   >::type
+  >::type
+ _base_type;
+   typedef typename _impl::progress_param::type progress_param_type;
+   typedef typename _impl::progress_type::type 
progress_type;
+   typedef typename _base_type::native_handle_type native_handle_type;
using _base_type::_base_type;
using _base_type::swap;
using _base_type::valid;
using _base_type::get;
using _base_type::wait;
using _base_type::native_handle;
-   typedef typename _base_type::native_handle_type native_handle_type;
+
+   shared_future() = default;
+   template 
+   shared_future(shared_future const& other
+ , typename std::enable_if<_impl::is_progress_param_compatible
+ ::type>::value>::type* = nullptr)
+ : _base_type(static_cast< _impl::shared_future_common const&>(other))
+   {
+   }
+
+   template 
+   friend struct shared_future;
 };
 
 template 
@@ -350,7 +385,119 @@ template 
 struct is_race_future> : std::true_t

Re: [E-devel] [EGIT] [core/efl] master 02/02: ecore_con, elput: fix warnings

2016-09-20 Thread Gustavo Sverzut Barbieri
On Tue, Sep 20, 2016 at 8:26 PM, Bruno Dilly  wrote:
> cedric pushed a commit to branch master.
>
> http://git.enlightenment.org/core/efl.git/commit/?id=a3fba57b2616f78fbdab7b43ac8e8aea7c56475b
>
> commit a3fba57b2616f78fbdab7b43ac8e8aea7c56475b
> Author: Bruno Dilly 
> Date:   Tue Sep 20 16:13:25 2016 -0700
>
> ecore_con,elput: fix warnings
>
> Summary:
> elput: fix warning for unused write result
>  ecore_con: fix warning for unused asprintf result
>
> Reviewers: iscaro, devilhorns, cedric
>
> Reviewed By: cedric
>
> Subscribers: cedric, seoz, jpeg
>
> Differential Revision: https://phab.enlightenment.org/D4308
>
> Signed-off-by: Cedric BAIL 
> ---
>  src/lib/ecore_con/ecore_con.c | 15 +++
>  src/lib/elput/elput_logind.c  | 14 +-
>  2 files changed, 24 insertions(+), 5 deletions(-)
>
> diff --git a/src/lib/ecore_con/ecore_con.c b/src/lib/ecore_con/ecore_con.c
> index cc17fe8..cb66b27 100644
> --- a/src/lib/ecore_con/ecore_con.c
> +++ b/src/lib/ecore_con/ecore_con.c
> @@ -4487,11 +4487,18 @@ _efl_net_ip_connect_async_run(void *data, 
> Ecore_Thread *thread EINA_UNUSED)
>   * parameter must be a URL with schema, otherwise it won't
>   * return anything.
>   */
> -char *url;
> +Eina_Stringshare *url;
>
> -asprintf(&url, "%s://%s:%s", d->protocol == IPPROTO_UDP ? "udp" : 
> "tcp", host, port);
> -proxies = ecore_con_libproxy_proxies_get(url);
> -free(url);
> +url = eina_stringshare_printf("%s://%s:%s", d->protocol == 
> IPPROTO_UDP ? "udp" : "tcp", host, port);
> +if (!url)
> +  {
> + ERR("Could not assemble URL");
> +  }
> +else
> +  {
> + proxies = ecore_con_libproxy_proxies_get(url);
> + eina_stringshare_del(url);
> +  }

why are you using stringshare here?

 - this is used only once, share makes no benefit.

 - this is used from thread, not sure eina stringshare is thread safe.

if it's complaining about asprintf() on some weirdo platform, we can
malloc + memcpy the pieces



-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

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


[EGIT] [core/efl] master 01/02: edje_decc: modified fclose location

2016-09-20 Thread JunsuChoi
jaehyun pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=8f66497acac27ef9bf53026429fa221b7e2a3f27

commit 8f66497acac27ef9bf53026429fa221b7e2a3f27
Author: JunsuChoi 
Date:   Tue Sep 20 23:23:29 2016 +0900

edje_decc: modified fclose location

modified fclose location. because of file pointer can become NULL.

Signed-off-by: Jaehyun Cho 
---
 src/bin/edje/edje_decc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/bin/edje/edje_decc.c b/src/bin/edje/edje_decc.c
index 2f5fe96..fdbc903 100644
--- a/src/bin/edje/edje_decc.c
+++ b/src/bin/edje/edje_decc.c
@@ -566,9 +566,9 @@ output(void)
 {
if (fwrite(data, data_size, 1, f) != 1)
  ERR("Could not write sound: %s", strerror(errno));
+   fclose(f);
 }
   else ERR("Could not open for writing sound: %s: %s", out1, 
strerror(errno));
-  fclose(f);
   }
   }
  }

-- 




[EGIT] [core/efl] master 02/02: edje_edit : add null check and close eet

2016-09-20 Thread JunsuChoi
jaehyun pushed a commit to branch master.

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

commit bed6c84afb2694d3a1186c6878b9338503f55021
Author: JunsuChoi 
Date:   Tue Sep 20 23:34:17 2016 +0900

edje_edit : add null check and close eet

Signed-off-by: Jaehyun Cho 
---
 src/lib/edje/edje_edit.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/src/lib/edje/edje_edit.c b/src/lib/edje/edje_edit.c
index f3381fa..65e490c 100644
--- a/src/lib/edje/edje_edit.c
+++ b/src/lib/edje/edje_edit.c
@@ -1675,6 +1675,11 @@ edje_edit_group_copy(Evas_Object *obj, const char 
*group_name, const char *copy_
  }
snprintf(buf, sizeof(buf), "edje/collections/%d", e->id);
epc = eet_data_read(eetf, _edje_edd_edje_part_collection, buf);
+   if (!epc)
+ {
+eet_close(eetf);
+return EINA_FALSE;
+ }
 
/* Search first free id */
id = -1;
@@ -1703,7 +1708,11 @@ edje_edit_group_copy(Evas_Object *obj, const char 
*group_name, const char *copy_
 
/* Create structs */
de = _alloc(sizeof(Edje_Part_Collection_Directory_Entry));
-   if (!de) return EINA_FALSE;
+   if (!de)
+ {
+eet_close(eetf);
+return EINA_FALSE;
+ }
 
/* Init Edje_Part_Collection_Directory_Entry */
de->id = id;

-- 




[EGIT] [core/efl] master 01/02: elm_progressbar: show status when unit_format_func is set

2016-09-20 Thread Sungtaek Hong
cedric pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=03882d558824f657f5c5a54fcd2d632eafeafd87

commit 03882d558824f657f5c5a54fcd2d632eafeafd87
Author: Sungtaek Hong 
Date:   Tue Sep 20 16:07:18 2016 -0700

elm_progressbar: show status when unit_format_func is set

Summary:
 - elm,state,units,visible signal is emitted only when
   unit is set, but not when unit_format_func is set.
 - Since default unit has been set, this signal is emitted
   but signal will not be emitted after unit is set to NULL.

Test Plan:
 1. Create a progressbar.
 2. elm_progressbar_unit_format_set(obj, NULL);
 3. set unit_format_func by elm_progressbar_unit_format_function_set()
and observe elm.text.status part visible.

Reviewers: Hermet, jpeg, cedric

Reviewed By: cedric

Subscribers: D-TAU, eunue, conr2d, cedric, jpeg

Differential Revision: https://phab.enlightenment.org/D4210

Signed-off-by: Cedric BAIL 
---
 src/lib/elementary/elm_progressbar.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/src/lib/elementary/elm_progressbar.c 
b/src/lib/elementary/elm_progressbar.c
index e8d4bea..57f33bb 100644
--- a/src/lib/elementary/elm_progressbar.c
+++ b/src/lib/elementary/elm_progressbar.c
@@ -211,7 +211,7 @@ _elm_progressbar_elm_widget_theme_apply(Eo *obj, 
Elm_Progressbar_Data *sd)
if (sd->pulse_state)
  elm_layout_signal_emit(obj, "elm,state,pulse,start", "elm");
 
-   if ((sd->units) && (!sd->pulse))
+   if (((sd->units) || (sd->unit_format_func)) && (!sd->pulse))
  elm_layout_signal_emit(obj, "elm,state,units,visible", "elm");
 
if (_is_horizontal(sd->orientation))
@@ -439,19 +439,13 @@ _elm_progressbar_efl_ui_progress_progress_value_get(Eo 
*obj EINA_UNUSED, Elm_Pro
 EOLIAN static void
 _elm_progressbar_efl_ui_progress_unit_format_set(Eo *obj, Elm_Progressbar_Data 
*sd, const char *units)
 {
+   const char *sig;
ELM_WIDGET_DATA_GET_OR_RETURN(obj, wd);
 
eina_stringshare_replace(&sd->units, units);
-   if (units)
- {
-elm_layout_signal_emit(obj, "elm,state,units,visible", "elm");
-edje_object_message_signal_process(wd->resize_obj);
- }
-   else
- {
-elm_layout_signal_emit(obj, "elm,state,units,hidden", "elm");
-edje_object_message_signal_process(wd->resize_obj);
- }
+   sig = (units) ? "elm,state,units,visible" : "elm,state,units,hidden";
+   elm_layout_signal_emit(obj, sig, "elm");
+   edje_object_message_signal_process(wd->resize_obj);
 
_units_set(obj);
elm_layout_sizing_eval(obj);
@@ -572,10 +566,15 @@ elm_progressbar_unit_format_get(const Elm_Progressbar 
*obj)
 EAPI void
 elm_progressbar_unit_format_function_set(Elm_Progressbar *obj, 
progressbar_func_type func, progressbar_freefunc_type free_func)
 {
+   const char *sig;
ELM_PROGRESSBAR_DATA_GET(obj, sd);
+   ELM_WIDGET_DATA_GET_OR_RETURN(obj, wd);
 
sd->unit_format_func = func;
sd->unit_format_free = free_func;
+   sig = (func) ? "elm,state,units,visible" : "elm,state,units,hidden";
+   elm_layout_signal_emit(obj, "elm,state,units,visible", "elm");
+   edje_object_message_signal_process(wd->resize_obj);
 
_units_set(obj);
elm_layout_sizing_eval(obj);

-- 




[EGIT] [core/efl] master 02/02: ecore_con,elput: fix warnings

2016-09-20 Thread Bruno Dilly
cedric pushed a commit to branch master.

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

commit a3fba57b2616f78fbdab7b43ac8e8aea7c56475b
Author: Bruno Dilly 
Date:   Tue Sep 20 16:13:25 2016 -0700

ecore_con,elput: fix warnings

Summary:
elput: fix warning for unused write result
 ecore_con: fix warning for unused asprintf result

Reviewers: iscaro, devilhorns, cedric

Reviewed By: cedric

Subscribers: cedric, seoz, jpeg

Differential Revision: https://phab.enlightenment.org/D4308

Signed-off-by: Cedric BAIL 
---
 src/lib/ecore_con/ecore_con.c | 15 +++
 src/lib/elput/elput_logind.c  | 14 +-
 2 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/src/lib/ecore_con/ecore_con.c b/src/lib/ecore_con/ecore_con.c
index cc17fe8..cb66b27 100644
--- a/src/lib/ecore_con/ecore_con.c
+++ b/src/lib/ecore_con/ecore_con.c
@@ -4487,11 +4487,18 @@ _efl_net_ip_connect_async_run(void *data, Ecore_Thread 
*thread EINA_UNUSED)
  * parameter must be a URL with schema, otherwise it won't
  * return anything.
  */
-char *url;
+Eina_Stringshare *url;
 
-asprintf(&url, "%s://%s:%s", d->protocol == IPPROTO_UDP ? "udp" : 
"tcp", host, port);
-proxies = ecore_con_libproxy_proxies_get(url);
-free(url);
+url = eina_stringshare_printf("%s://%s:%s", d->protocol == IPPROTO_UDP 
? "udp" : "tcp", host, port);
+if (!url)
+  {
+ ERR("Could not assemble URL");
+  }
+else
+  {
+ proxies = ecore_con_libproxy_proxies_get(url);
+ eina_stringshare_del(url);
+  }
  }
 
EINA_THREAD_CLEANUP_PUSH((Eina_Free_Cb)ecore_con_libproxy_proxies_free, 
proxies);
diff --git a/src/lib/elput/elput_logind.c b/src/lib/elput/elput_logind.c
index 5d97a02..abe4a38 100644
--- a/src/lib/elput/elput_logind.c
+++ b/src/lib/elput/elput_logind.c
@@ -276,7 +276,19 @@ _logind_device_release(Elput_Manager *em, uint32_t major, 
uint32_t minor)
 static void
 _logind_pipe_write_fd(Elput_Manager *em, int fd)
 {
-   write(em->input.pipe, &fd, sizeof(int));
+   int ret;
+
+   while (1)
+ {
+ret = write(em->input.pipe, &fd, sizeof(int));
+if (ret < 0)
+  {
+ if ((errno == EAGAIN) || (errno == EINTR))
+   continue;
+ WRN("Failed to write to input pipe");
+  }
+break;
+ }
close(em->input.pipe);
em->input.pipe = -1;
 }

-- 




Re: [E-devel] Efl.Net and libproxy

2016-09-20 Thread The Rasterman
On Tue, 20 Sep 2016 11:59:45 -0300 Gustavo Sverzut Barbieri
 said:

> On Tue, Sep 20, 2016 at 1:54 AM, Carsten Haitzler 
> wrote:
> > On Tue, 20 Sep 2016 01:08:48 -0300 Gustavo Sverzut Barbieri
> >  said:
> >
> >> On Mon, Sep 19, 2016 at 8:44 PM, Carsten Haitzler 
> >> wrote:
> >> > On Mon, 19 Sep 2016 11:31:58 -0300 Gustavo Sverzut Barbieri
> >> >  said:
> >> >
> >> >> Hi all,
> >> >>
> >> >> Today I did commit support for libproxy in ecore_con's new API,
> >> >> Efl.Net.Dialer.Tcp, Efl.Net.Dialer.Http and Efl.Net.Dialer.Websocket
> >> >> (implicit from HTTP).
> >> >
> >> > ummm i just am looking now (i have a lot of catching up to do). can you
> >> > undo the changes to configure.ac and make this a dlopen/dlsym approach?
> >> > well use eina_module. look a the old curl eina_module approach. look at
> >> > what i did in ecore_audio too. in fact i need to look over all the efl
> >> > net code, but you want to use emile for ssl stuff and eina_module for
> >> > curl too there too (i haven't looked yet). there are very good reasons
> >> > to do all of this.
> >>
> >> I've checked what you did for curl, since I use that and need more symbols.
> >>
> >> my question and concern are just:
> >>  - not being able to compile without libproxy. If we always detect,
> >> should we remove --enable-libproxy from configure.ac?
> >
> > yes. it moves to runtime not compile-time. several reasons:
> >
> > 1. makes compiling simpler. people dont have to find dependencies and those
> > -dev/devel pkgs too. if they add libproxy later after building efl magically
> > the feature works without a rebuild.
> > 2. speed up startup time with less linking going on for apps especially for
> > features they may never use
> > 3. saves memory - symbol tables and dirtying private pages to do the symbol
> > fixups is expensive. i nuked like 320k or so before 1.18 release of actual
> > real memory usage that was dirty pages from rarely used libraries.features.
> > it's expensive and so only load in if/when needed to save this cost. this
> > cost is private pages PER PROCESS using efl so it multiples and is not a
> > one-off cost.
> > 4. the idea of isolating such costs into a proxy daemon/process probably is
> > a good thing and that saves adding the above cost for any process then
> > needing to do proxy pac file parsing etc. and isolates the cost into a
> > single daemon.
> 
> I was asking if we should offer a way to not even try runtime detection.

and do what instead? you mean just link libproxy into the efl daemon proxy
binary?

> >>  - I ask the above because libproxy is a monster, it will pull in a JS
> >> loader, glib, C++... all of that, per process. If using pacrunner
> >> (from connman guys) you can just link with libdbus, less bad.
> >
> > in GENERAL go for a dlopen(eina_module) style approach, BUT if a daemon
> > makes sense, then do that.
> 
> It's not something that excludes the other. Actually the opposite if
> we do the proper way.
> 
>  - efl does libproxy dlopen, so doesn't link to that library (simple
> API but heavy in dependency)

but the moment we do any network stuff we bloat out memory usage then. have 10
apps needing to do network stuff. 10x bloatage. :)

>  - efl could recommend pacrunner's libproxy until we do our own, a big
> improvement - zero work

doing our own is less work. just use libproxy IN an efl binary - just like is
there right now but in the lib... move to binary but connect to it (if connect
fails, exec then keep trying to connect every 0.1 sec until there).

>  - efl could provide its own libproxy.so, like
> /usr/lib/enlightenment/libproxy.so which would talk to our own server
> (which can be built to use system's libproxy, which in turn can be the
> official one or pacrunner's drop-in replacement). Our dlopen() can
> prefer that version.

just the above. no systemd. no dbus. nothing but a basic local unix socket
which efl.net already does. it's all there. efreetd works this way already.

>  - we can employ LD_PRELOAD tricks in Enlightenment to force loading
> our libproxy.so instead of the system. Our daemon must be started
> without it, of course :-)
> 
> 
> >it makes more sense for us to do our own daemon for efl
> > like efreet. dbus is not a good solution for this.
> 
> agreed, the API is simple so a pure unix socket can do, protocol is:
> 
> send: 
> recv:  []:proxy2>
> 
> as libproxy IS blocking and they explicitly recommend to be called
> from a thread, our code will be simple send/recv calls, no other
> libraries to pollute our users.

yup. just re-use efl.net internally to connect to an efl.net.proxy binary. if
connect fails, launch binary and set up timer to retry connect until connected.
when connected, send req just like above, with reply coming back. perfect. :)
re-use that connection for every proxy request and the daemon will deal with
it. really simple.

LATER we can also add pacrunner support too. we can at runtime USE this if it
is there, if not, use our own as above.


Re: [E-devel] [EGIT] [core/efl] master 01/01: eina/ecore: allow threads to be canceled, use in ecore_con.

2016-09-20 Thread The Rasterman
On Tue, 20 Sep 2016 12:17:50 -0300 Gustavo Sverzut Barbieri
 said:

> On Tue, Sep 20, 2016 at 11:18 AM, Carsten Haitzler 
> wrote:
> > On Tue, 20 Sep 2016 08:16:21 -0300 Gustavo Sverzut Barbieri
> >  said:
> >
> >> On Tue, Sep 20, 2016 at 5:51 AM, Jean-Philippe André 
> >> wrote:
> >> > Hi Gustavo,
> >> >
> >> > On 14 September 2016 at 13:55, Gustavo Sverzut Barbieri
> >> >  wrote:
> >> >
> >> >> HEADS UP -- BINDINGS:
> >> >>
> >> >> If you wish to expose the new "cancellable" property, or cope with
> >> >> naughty users or 3rd party deps that may call
> >> >> pthread_setcancelstate(PTHREAD_CANCEL_ENABLE), please register your
> >> >> cleanup functions with:
> >> >>
> >> >>EINA_THREAD_CLEANUP_PUSH(cb, ctx); // will call cb() on
> >> >> pthread_cancel()/ecore_thread_cancel()/eina_thread_cancel()
> >> >>call_user();
> >> >>EINA_THREAD_CLEANUP_POP(EINA_TRUE); // will call cb() on clean exit
> >> >>
> >> >> If different functions are desired:
> >> >>
> >> >>EINA_THREAD_CLEANUP_PUSH(cb, ctx); // will call cb() on
> >> >> pthread_cancel()/ecore_thread_cancel()/eina_thread_cancel()
> >> >>call_user();
> >> >>EINA_THREAD_CLEANUP_POP(EINA_FALSE); // will NOT call cb() on clean
> >> >> exit
> >> >>another_cb(ctx);
> >> >>
> >> >> This is recommended if you expose ecore_thread to your users. If you
> >> >> don't, then you do not need to do anything.
> >> >
> >> >
> >> > pthread_cancel did (does?) not exist on Android, by design choice. bionic
> >> > isn't posix in that regard.
> >> > One way or another, I remember that using cancel is actually quite hard,
> >> > because you need to be very careful about the cleanup.
> >> >
> >> > So I wonder if adding cancel like pthread here is the best choice?
> >> > Note that I understand the need and don't have any good alternative :)
> >>
> >> Hi jpeg, thanks for letting me know.
> >>
> >> When we port to bionic we should then take one choice:
> >>
> >>  - let the thread hang there for a while, the new code I'm doing based
> >> on this concept shouldn't break, it will just consume few more
> >> resources for a while. (== #ifdef)
> >
> > i'd say do this all the time. cancellation otherwise is way too hard AND its
> > non-portable. this is an api in eina that is non-portable and that means we
> > have to try make it work on other platforms... if we keepit.
> 
> by default the thread cancellation is disabled. You have to manually
> enable that and live with the pain, If you wish.
> 
> I've used new efl_net code to test that, simulate what our users that
> loves thread would do... indeed it simplifies the code a lot to use a
> thread and do procedural programming (see ecore_con.c, socks stuff).
> The single detail to remember is to EINA_THREAD_CLEANUP_PUSH()/POP()
> and take care to not return in the middle, since it wouldn't execute
> the POP(EINA_TRUE) -- if you want to always cleanup.
> 
> The portability part can be done, like vlc did. And that is said to
> work on Windows, seems Android is the only one not doing it.

not portable to android. the problem is we have an eina thread api that is not
portable. this is not an internal implementation detail. it's a public api that
is not portable. no. no non-portable api's anymore. DEFINITELY if they
completely fail based on platform. if its "its a bit slower on another platform
as that feature doesnt exist so we emulate" then fine.

we used to be linux/unix only. over the years we've had to become portable. now
we have to make portable the top priority.

if it's not portable then don't support it. deal with it some other way.

> >>  - use pthread_kill() with an unused signal and use a signal
> >> handler... this can be a full wrapper like the one in videolan.org, or
> >> just to generate EINTR like I proposed in my first discussion.
> >
> > this would be a far better workaround. :)
> 
> doesn't work on Windows :-(

then hang until timeout hit. use another thread in the pool. :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


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


Re: [E-devel] Efl.Net and libproxy

2016-09-20 Thread Gustavo Sverzut Barbieri
damn raster... I had to do so I could check.

dlopen -> in git.

server and libproxy.so wrapper, attached with the basics, I'm not
doing all the cumbersome details to get a single process running and
spawn it from libproxy.so wrapper without a race condition.

I'd simplify all of that by using dbus with acquiring a name in the
session bus and let that entity control it. Also would let the dbus
daemon set isolation, like not inheriting current processes limits,
namespaces and all.

however as you dislike that, be my guest :-D

 gcc -o efl-proxy-resolver libproxy-efl-server.c `pkg-config --cflags
--libs ecore eina efl eo libproxy-1.0`
 gcc -shared -o libproxy-efl.so libproxy-efl.c `pkg-config --cflags
eina` -lpthread

(note libproxy.so doesn't link with eina)

EINA_LOG_LEVELS=efl-proxy-resolver:4 ./efl-proxy-resolver &
LD_PRELOAD=libproxy-efl.so proxy http://google.com

/usr/bin/proxy is a test tool provided by libproxy. the server should
print it's serving requests.


On Tue, Sep 20, 2016 at 11:59 AM, Gustavo Sverzut Barbieri
 wrote:
> On Tue, Sep 20, 2016 at 1:54 AM, Carsten Haitzler  
> wrote:
>> On Tue, 20 Sep 2016 01:08:48 -0300 Gustavo Sverzut Barbieri
>>  said:
>>
>>> On Mon, Sep 19, 2016 at 8:44 PM, Carsten Haitzler 
>>> wrote:
>>> > On Mon, 19 Sep 2016 11:31:58 -0300 Gustavo Sverzut Barbieri
>>> >  said:
>>> >
>>> >> Hi all,
>>> >>
>>> >> Today I did commit support for libproxy in ecore_con's new API,
>>> >> Efl.Net.Dialer.Tcp, Efl.Net.Dialer.Http and Efl.Net.Dialer.Websocket
>>> >> (implicit from HTTP).
>>> >
>>> > ummm i just am looking now (i have a lot of catching up to do). can you 
>>> > undo
>>> > the changes to configure.ac and make this a dlopen/dlsym approach? well 
>>> > use
>>> > eina_module. look a the old curl eina_module approach. look at what i did 
>>> > in
>>> > ecore_audio too. in fact i need to look over all the efl net code, but you
>>> > want to use emile for ssl stuff and eina_module for curl too there too (i
>>> > haven't looked yet). there are very good reasons to do all of this.
>>>
>>> I've checked what you did for curl, since I use that and need more symbols.
>>>
>>> my question and concern are just:
>>>  - not being able to compile without libproxy. If we always detect,
>>> should we remove --enable-libproxy from configure.ac?
>>
>> yes. it moves to runtime not compile-time. several reasons:
>>
>> 1. makes compiling simpler. people dont have to find dependencies and those
>> -dev/devel pkgs too. if they add libproxy later after building efl magically
>> the feature works without a rebuild.
>> 2. speed up startup time with less linking going on for apps especially for
>> features they may never use
>> 3. saves memory - symbol tables and dirtying private pages to do the symbol
>> fixups is expensive. i nuked like 320k or so before 1.18 release of actual
>> real memory usage that was dirty pages from rarely used libraries.features.
>> it's expensive and so only load in if/when needed to save this cost. this 
>> cost
>> is private pages PER PROCESS using efl so it multiples and is not a one-off
>> cost.
>> 4. the idea of isolating such costs into a proxy daemon/process probably is a
>> good thing and that saves adding the above cost for any process then needing 
>> to
>> do proxy pac file parsing etc. and isolates the cost into a single daemon.
>
> I was asking if we should offer a way to not even try runtime detection.
>
>
>>>  - I ask the above because libproxy is a monster, it will pull in a JS
>>> loader, glib, C++... all of that, per process. If using pacrunner
>>> (from connman guys) you can just link with libdbus, less bad.
>>
>> in GENERAL go for a dlopen(eina_module) style approach, BUT if a daemon makes
>> sense, then do that.
>
> It's not something that excludes the other. Actually the opposite if
> we do the proper way.
>
>  - efl does libproxy dlopen, so doesn't link to that library (simple
> API but heavy in dependency)
>
>  - efl could recommend pacrunner's libproxy until we do our own, a big
> improvement - zero work
>
>  - efl could provide its own libproxy.so, like
> /usr/lib/enlightenment/libproxy.so which would talk to our own server
> (which can be built to use system's libproxy, which in turn can be the
> official one or pacrunner's drop-in replacement). Our dlopen() can
> prefer that version.
>
>  - we can employ LD_PRELOAD tricks in Enlightenment to force loading
> our libproxy.so instead of the system. Our daemon must be started
> without it, of course :-)
>
>
>>it makes more sense for us to do our own daemon for efl
>> like efreet. dbus is not a good solution for this.
>
> agreed, the API is simple so a pure unix socket can do, protocol is:
>
> send: 
> recv: 
> 
>
> as libproxy IS blocking and they explicitly recommend to be called
> from a thread, our code will be simple send/recv calls, no other
> libraries to pollute our users.
>
>
>
>> supporting pacrunner later
>> of course is doable, but i would not do this out of the box because 

[EGIT] [core/efl] master 01/04: eet: set alpha_texture for ETC1+Alpha

2016-09-20 Thread Sungtaek Hong
cedric pushed a commit to branch master.

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

commit b437bfb3feee9db3b523a8d3c8deb3bc20b1aaa8
Author: Sungtaek Hong 
Date:   Tue Sep 20 14:20:48 2016 -0700

eet: set alpha_texture for ETC1+Alpha

Summary:
alpha_texture need to be set EINA_TRUE to support ETC1+Alpha

@fix

Test Plan:
Create an EDC file with png image with Alpha.
   compress image with ETC1 and ETC2.
   Observe Alpha is properly applied in both case.

Reviewers: jpeg, Hermet, cedric

Reviewed By: cedric

Subscribers: conr2d

Differential Revision: https://phab.enlightenment.org/D4307

Signed-off-by: Cedric BAIL 
---
 src/lib/eet/eet_image.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/lib/eet/eet_image.c b/src/lib/eet/eet_image.c
index 38a0bdc..1da7985 100644
--- a/src/lib/eet/eet_image.c
+++ b/src/lib/eet/eet_image.c
@@ -855,6 +855,7 @@ eet_data_image_etc1_compressed_convert(int *size,
 etc_block_size = 8;
 num_planes = 2; // RGB and Alpha
 header[5] = 3;
+alpha_texture = EINA_TRUE;
 codec = "ETC1+Alpha";
 break;
   default: abort();

-- 




[EGIT] [core/efl] master 03/04: atspi: fix state macros

2016-09-20 Thread Piotr Ganicz
cedric pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=445b3587e321c74fa23c401dda567dd5b27257b8

commit 445b3587e321c74fa23c401dda567dd5b27257b8
Author: Piotr Ganicz 
Date:   Tue Sep 20 14:44:53 2016 -0700

atspi: fix state macros

Summary:
This patch changes the value of 1 to 1ULL in STATE_TYPE macros
to signal the compiler that the value must be considered
as a unsigned long long, it has to be done cause state_set variable
can be longer than 32 bits.

This patch is moved. Orginal commit hash:
a559e473c21c8da7c4e5a87b9c8583ce519cc35e

Change-Id: Ida89f3be185736f61543d37010d0f5cb8d80a751

Reviewers: cedric, stanluk

Subscribers: cedric, jpeg

Differential Revision: https://phab.enlightenment.org/D4260

Signed-off-by: Cedric BAIL 
---
 src/lib/elementary/elm_interface_atspi_accessible.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/lib/elementary/elm_interface_atspi_accessible.h 
b/src/lib/elementary/elm_interface_atspi_accessible.h
index 929216b..5116983 100644
--- a/src/lib/elementary/elm_interface_atspi_accessible.h
+++ b/src/lib/elementary/elm_interface_atspi_accessible.h
@@ -13,17 +13,17 @@
 /*
  * Sets a particilar state type for given state set.
  */
-#define STATE_TYPE_SET(state_set, type)   (state_set|= (1L << type))
+#define STATE_TYPE_SET(state_set, type)   (state_set|= (1ULL << type))
 
 /**
  * Unsets a particilar state type for given state set.
  */
-#define STATE_TYPE_UNSET(state_set, type) (state_set &= ~(1L << type))
+#define STATE_TYPE_UNSET(state_set, type) (state_set &= ~(1ULL << type))
 
 /**
  * Gets value of a particilar state type for given state set.
  */
-#define STATE_TYPE_GET(state_set, type)   (state_set & (1L << type))
+#define STATE_TYPE_GET(state_set, type)   (state_set & (1ULL << type))
 
 /**
  * Free Elm_Atspi_Attributes_List

-- 




[EGIT] [core/efl] master 04/04: atspi: fix parent-child relationship for elm_list and elm_toolbar

2016-09-20 Thread Piotr Ganicz
cedric pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=2cc7be3743890b3c25ebf69a9ee4aa839d366827

commit 2cc7be3743890b3c25ebf69a9ee4aa839d366827
Author: Piotr Ganicz 
Date:   Tue Sep 20 14:46:11 2016 -0700

atspi: fix parent-child relationship for elm_list and elm_toolbar

Summary:
This patch provides proper parent-child relationship for elm_list and 
elm_toolbar
while atsapi_mode is set for icon and end element.

This patch is moved from:
bf188e59431ad9c4ca877b2632884d3d430de6b1

Change-Id: Iae855aacf29bef3808a0b5ec159f46cbf0f4539d

Reviewers: stanluk, cedric

Reviewed By: cedric

Subscribers: cedric, jpeg

Differential Revision: https://phab.enlightenment.org/D4259

Signed-off-by: Cedric BAIL 
---
 src/lib/elementary/elm_list.c| 6 ++
 src/lib/elementary/elm_toolbar.c | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/src/lib/elementary/elm_list.c b/src/lib/elementary/elm_list.c
index e126500..9c0cbbc 100644
--- a/src/lib/elementary/elm_list.c
+++ b/src/lib/elementary/elm_list.c
@@ -2301,6 +2301,12 @@ _item_new(Evas_Object *obj,
VIEW(it) = edje_object_add(evas_object_evas_get(obj));
edje_object_update_hints_set(VIEW(it), 1);
 
+   if (_elm_config->atspi_mode)
+   {
+   if (it->icon) elm_interface_atspi_accessible_parent_set(it->icon, 
eo_it);
+   if (it->end) elm_interface_atspi_accessible_parent_set(it->end, eo_it);
+   }
+
/* access */
if (_elm_config->access_mode == ELM_ACCESS_MODE_ON)
  _access_widget_item_register(it, EINA_TRUE);
diff --git a/src/lib/elementary/elm_toolbar.c b/src/lib/elementary/elm_toolbar.c
index 767b8b5..f73fd59 100644
--- a/src/lib/elementary/elm_toolbar.c
+++ b/src/lib/elementary/elm_toolbar.c
@@ -2492,6 +2492,9 @@ _item_new(Evas_Object *obj,
 
icon_obj = elm_icon_add(VIEW(it));
 
+   if (_elm_config->atspi_mode)
+   if (icon_obj) elm_interface_atspi_accessible_parent_set(icon_obj, 
eo_it);
+
if (_elm_config->access_mode == ELM_ACCESS_MODE_ON)
  _access_widget_item_register(it);
 

-- 




[EGIT] [core/efl] master 02/04: eet: fix memory leak

2016-09-20 Thread jiin.moon
cedric pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=8272d1492796657978c5591971768d37d4e15a7e

commit 8272d1492796657978c5591971768d37d4e15a7e
Author: jiin.moon 
Date:   Tue Sep 20 14:22:33 2016 -0700

eet: fix memory leak

Summary:
If ef is null, have to return before _set_material_to_eet_file_from_mesh 
api.
New momory will be allocated in the api.

Subscribers: cedric, jpeg

Differential Revision: https://phab.enlightenment.org/D4305

Signed-off-by: Cedric BAIL 
---
 src/modules/evas/model_savers/eet/evas_model_save_eet.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/src/modules/evas/model_savers/eet/evas_model_save_eet.c 
b/src/modules/evas/model_savers/eet/evas_model_save_eet.c
index a5878dc..c752dd3 100644
--- a/src/modules/evas/model_savers/eet/evas_model_save_eet.c
+++ b/src/modules/evas/model_savers/eet/evas_model_save_eet.c
@@ -156,6 +156,14 @@ evas_model_save_file_eet(const Evas_Canvas3D_Mesh *mesh,
eet_init();
 
ef = eet_open(file, EET_FILE_MODE_WRITE);
+   if (ef == NULL)
+ {
+ERR("Opening of file is failed.");
+free(eet_mesh);
+free(eet_header);
+eet_shutdown();
+return;
+ }
 
_file_descriptor = _evas_canvas3d_eet_file_get();
 
@@ -181,15 +189,6 @@ evas_model_save_file_eet(const Evas_Canvas3D_Mesh *mesh,
_set_material_to_eet_file_from_mesh(eet_mesh, eet_header, f);
_set_frame_to_eet_file_from_mesh(eet_mesh);
 
-   if (ef == NULL)
- {
-ERR("Opening of file is failed.");
-free(eet_mesh);
-free(eet_header);
-
-goto on_error;
- }
-
eet_file->mesh = eet_mesh;
eet_file->header = eet_header;
 

-- 




[EGIT] [core/efl] master 01/01: Evas: Don't access members of a null struct. Fixes T4616

2016-09-20 Thread Stephen Houston
okra pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=61b66338a948d98a3b90ad48b323855f69aca52c

commit 61b66338a948d98a3b90ad48b323855f69aca52c
Author: Stephen Houston 
Date:   Tue Sep 20 16:02:33 2016 -0500

Evas: Don't access members of a null struct. Fixes T4616
---
 src/lib/evas/canvas/evas_filter_mixin.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/lib/evas/canvas/evas_filter_mixin.c 
b/src/lib/evas/canvas/evas_filter_mixin.c
index 5d810e5..04d1bea 100644
--- a/src/lib/evas/canvas/evas_filter_mixin.c
+++ b/src/lib/evas/canvas/evas_filter_mixin.c
@@ -101,6 +101,8 @@ _filter_cb(Evas_Filter_Context *ctx, void *data, Eina_Bool 
success)
Evas_Filter_Data *pd = efl_data_scope_get(eo_obj, MY_CLASS);
Evas_Filter_Post_Render_Data *post_data;
 
+   if (!pd)
+ return;
if (!pd->data->async)
  {
 _filter_end_sync(ctx, obj, pd, success);

-- 




[EGIT] [apps/ephoto] master 01/01: Ephoto: Fix opening of images from command.

2016-09-20 Thread Stephen Houston
okra pushed a commit to branch master.

http://git.enlightenment.org/apps/ephoto.git/commit/?id=1dbee7b7b3cdbfc3a83e6dfbb4494a89b72602bb

commit 1dbee7b7b3cdbfc3a83e6dfbb4494a89b72602bb
Author: Stephen Houston 
Date:   Tue Sep 20 15:24:49 2016 -0500

Ephoto: Fix opening of images from command.
---
 src/bin/ephoto_single_browser.c | 33 +
 src/bin/ephoto_thumb_browser.c  | 16 ++--
 2 files changed, 31 insertions(+), 18 deletions(-)

diff --git a/src/bin/ephoto_single_browser.c b/src/bin/ephoto_single_browser.c
index 96ba403..bf1fe07 100644
--- a/src/bin/ephoto_single_browser.c
+++ b/src/bin/ephoto_single_browser.c
@@ -1537,7 +1537,7 @@ _ephoto_single_populate_end(void *data, int type 
EINA_UNUSED,
 
if (!sb->entry && sb->ephoto->state == EPHOTO_STATE_SINGLE)
  ephoto_single_browser_entry_set(sb->main,
- eina_list_nth(sb->ephoto->entries, 0));
+ _first_entry_find(sb));
 
return ECORE_CALLBACK_PASS_ON;
 }
@@ -1554,8 +1554,7 @@ _ephoto_single_entry_create(void *data, int type 
EINA_UNUSED,
if (sb->pending_path && !strcmp(e->path, sb->pending_path))
  {
eina_stringshare_del(sb->pending_path);
-   sb->pending_path = NULL;
-   ephoto_single_browser_entry_set(sb->ephoto->single_browser, e);
+   ephoto_single_browser_entry_set(sb->main, e);
  }
 
return ECORE_CALLBACK_PASS_ON;
@@ -2108,9 +2107,35 @@ void
 ephoto_single_browser_entries_set(Evas_Object *obj, Eina_List *entries)
 {
Ephoto_Single_Browser *sb = evas_object_data_get(obj, "single_browser");
+   Ephoto_Viewer *v = NULL;
 
+   if (sb->viewer)
+ v = evas_object_data_get(sb->viewer, "viewer");
if (entries)
- sb->entries = entries;
+ {
+sb->entries = entries;
+if (sb->ephoto->state == EPHOTO_STATE_SINGLE)
+  {
+ if (v)
+   {
+  const char *image;
+  char *dir;
+
+  elm_image_file_get(v->image, &image, NULL);
+  printf("%s\n", image);
+  dir = ecore_file_dir_get(image);
+  if (strcmp(sb->ephoto->config->directory, dir))
+ephoto_single_browser_entry_set(sb->main,
+_first_entry_find(sb));
+  free(dir);
+   }
+ else
+   ephoto_single_browser_entry_set(sb->main,
+_first_entry_find(sb));
+  }
+ }
+   else
+ ephoto_single_browser_entry_set(sb->main, NULL);
 }
 
 void
diff --git a/src/bin/ephoto_thumb_browser.c b/src/bin/ephoto_thumb_browser.c
index 3f0198d..cb2acf6 100644
--- a/src/bin/ephoto_thumb_browser.c
+++ b/src/bin/ephoto_thumb_browser.c
@@ -1560,21 +1560,9 @@ _ephoto_thumb_populate_end(void *data, int type 
EINA_UNUSED,
 evas_object_smart_callback_call(tb->main, "changed,directory", NULL);  
  
 ephoto_thumb_browser_update_info_label(tb->ephoto);
  }
-   else if (tb->ephoto->state == EPHOTO_STATE_SINGLE)
- {
-if (tb->ephoto->entries)
-  {
- ephoto_single_browser_entry_set(tb->ephoto->single_browser, NULL);
- ephoto_single_browser_entries_set(tb->ephoto->single_browser,
- tb->ephoto->entries);
-  }
-else
-  {
- ephoto_single_browser_entry_set(tb->ephoto->single_browser, NULL);
- ephoto_title_set(tb->ephoto, tb->ephoto->config->directory);
-  }
- }
tb->entries = tb->ephoto->entries;
+   ephoto_single_browser_entries_set(tb->ephoto->single_browser,
+ tb->ephoto->entries);
if (eina_list_count(tb->entries) < 1 && tb->ephoto->config->folders)
  {
 ephoto_show_folders(tb->ephoto, EINA_FALSE);

-- 




Re: [E-devel] Debugging edc at runtime is possible?

2016-09-20 Thread Michael Blumenkrantz
On Tue, 20 Sep 2016 09:52:53 -0700
Cedric BAIL  wrote:

> Hello,
> 
> On Tue, Sep 20, 2016 at 9:19 AM, Jiwon Kim  wrote:
> > I wonder about debugging edc script. (or maybe it's just idea :) )
> > Is it possible to debug at running time of application?
> > Likes gdb (or with gdb), attach to app,
> >  and set break point to 'program' syntex (edc's program blocks).  
> 
> This is an interesting idea. I don't know if it could be doable
> actually as program are run related to time. Any debugging would
> likely affect that.

it's possible to do this by breaking conditionally on the _edje_program_run 
function based on a program's attributes

> 
> > If we can check edc's (when/which) program running and signaling,
> > I think it's very convenient.  
> 
> Agreed, I don't see a way to do step by step debugging of an edc. Will
> have to think about it.

this is also possible by breaking on edje/embryo/edje_embryo functions and 
stepping through them

> 
> > If it is impossible, how about log function for edc? (only for debug)  
> 
> Once upon a time, there was a lot of log generated in the form of edje
> signal. They were removed as they impacted speed to much. Today, we
> have evlog, it may be worse experimenting with it and see if we can
> log events with it somehow. Alternative possibility would be to add an
> eo event on edje object for debug. Once someone register for that
> event, we would trigger that event for every state we want to debug.
> Between evlog and eo event tracing, I don't know which one could work
> best. You would have to experiment !
> 
> Have fun !

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


Re: [E-devel] Standard Icon Changes in Recent EFL?

2016-09-20 Thread Andrew Williams
Hi Jeff,

We're now allowing the user to choose whether they want to use an fdo icon
theme or elementary. This is configurable and we are working on E making it
easier too.

Also the spec we adhere to is
https://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html
But the gtk-directory is not a "standard" name but one that gnome themes
have added on top.

Does that make sense?
If the icon names you use are in the standard list it should work fine...

Andy
On Sun, 18 Sep 2016 at 23:20, Jeff Hoogland  wrote:

> Did the way we utilize standard icons change in a recent version of
> Elementary? Been using EFL 1.15 for awhile now, but 1.18.1 is finally
> functional with Moksha so looking to include this with Bodhi's upcoming
> release.
>
> My epad application isn't setting the proper standard icons with this EFL
> release though. In terminal I see this over and over and over again:
>
> Traceback (most recent call last):
>   File "efl/elementary/genlist.pxi", line 55, in
> efl.elementary.__init__._py_elm_genlist_item_content_get
> (efl/elementary/__init__.c:117699)
>   File "/usr/lib/python2.7/dist-packages/elmextensions/fileselector.py",
> line 57, in content_get
> standard="gtk-directory"
>   File "efl/elementary/icon.pxi", line 38, in
> efl.elementary.__init__.Icon.__init__ (efl/elementary/__init__.c:154226)
>   File "efl/evas/efl.evas_object.pxi", line 209, in
> efl.evas.Object._set_properties_from_keyword_args
> (efl/evas/efl.evas.c:51751)
>   File "efl/eo/efl.eo.pyx", line 276, in
> efl.eo.Eo._set_properties_from_keyword_args (efl/eo/efl.eo.c:3661)
>   File "efl/elementary/icon.pxi", line 109, in
> efl.elementary.__init__.Icon.standard.__set__
> (efl/elementary/__init__.c:154806)
> RuntimeWarning: Setting standard icon failed
>
> Same source code worked as expected with EFL 1.15 and displayed the desired
> icons. Do I need to do something differently or is this a bug?
>
> --
> ~Jeff Hoogland 
> My Projects on GitHub 
>
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[EGIT] [core/efl] master 01/01: libproxy: dlopen() and make it runtime optional.

2016-09-20 Thread Gustavo Sverzut Barbieri
barbieri pushed a commit to branch master.

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

commit f0f9c5d24a0a261367371fd420bc3a3e04b5285f
Author: Gustavo Sverzut Barbieri 
Date:   Tue Sep 20 15:00:17 2016 -0300

libproxy: dlopen() and make it runtime optional.
---
 configure.ac|  13 
 src/lib/ecore_con/ecore_con.c   | 132 ++--
 src/lib/ecore_con/ecore_con_private.h   |  10 ++-
 src/lib/ecore_con/efl_net_dialer_http.c |  16 +---
 4 files changed, 101 insertions(+), 70 deletions(-)

diff --git a/configure.ac b/configure.ac
index a403484..d0b9962 100644
--- a/configure.ac
+++ b/configure.ac
@@ -224,7 +224,6 @@ case "$host_os" in
;;
freebsd*)
   have_freebsd="yes"
-  want_libproxy="yes"
   ELM_UNIX_DEF="#define"
;;
darwin*)
@@ -235,7 +234,6 @@ case "$host_os" in
   have_linux="yes"
   have_systemd_pkg="auto"
   want_systemd="yes"
-  want_libproxy="yes"
   ELM_UNIX_DEF="#define"
;;
*)
@@ -3034,16 +3032,6 @@ EFL_LIB_START([Ecore_Con])
 
 ### Default values
 
-AC_ARG_ENABLE([libproxy],
-   [AS_HELP_STRING([--enable-libproxy],[Enable libproxy support. 
@<:@default=enabled@:>@])],
-   [
-if test "x${enableval}" = "xyes" ; then
-   want_libproxy="yes"
-else
-   want_libproxy="no"
-fi
-   ])
-
 want_ecore_con_local_sockets="yes"
 want_ecore_con_abstract_sockets="yes"
 
@@ -3080,7 +3068,6 @@ EFL_INTERNAL_DEPEND_PKG([ECORE_CON], [emile])
 EFL_ADD_LIBS([ECORE_CON], [-lm])
 
 EFL_OPTIONAL_DEPEND_PKG([ECORE_CON], [${want_systemd}], [SYSTEMD], 
[libsystemd])
-EFL_OPTIONAL_DEPEND_PKG([ECORE_CON], [${want_libproxy}], [LIBPROXY], 
[libproxy-1.0])
 
 EFL_ADD_FEATURE([ECORE_CON], [local-sockets], 
[${want_ecore_con_local_sockets}])
 EFL_ADD_FEATURE([ECORE_CON], [abstract-sockets], 
[${want_ecore_con_abstract_sockets}])
diff --git a/src/lib/ecore_con/ecore_con.c b/src/lib/ecore_con/ecore_con.c
index d79c77e..cc17fe8 100644
--- a/src/lib/ecore_con/ecore_con.c
+++ b/src/lib/ecore_con/ecore_con.c
@@ -191,9 +191,15 @@ int _ecore_con_log_dom = -1;
 Ecore_Con_Socks *_ecore_con_proxy_once = NULL;
 Ecore_Con_Socks *_ecore_con_proxy_global = NULL;
 
-#ifdef HAVE_LIBPROXY
-pxProxyFactory *_ecore_con_libproxy_factory = NULL;
-#endif
+typedef struct pxProxyFactory_  pxProxyFactory;
+typedef struct _Ecore_Con_Libproxy {
+   pxProxyFactory *factory;
+   char **(*px_proxy_factory_get_proxies)(pxProxyFactory *factory, const char 
*url);
+   void *(*px_proxy_factory_new)(void);
+   void (*px_proxy_factory_free)(pxProxyFactory *);
+   Eina_Module *mod;
+} Ecore_Con_Libproxy;
+static Ecore_Con_Libproxy _ecore_con_libproxy;
 
 EAPI int
 ecore_con_init(void)
@@ -279,13 +285,16 @@ ecore_con_shutdown(void)
if (--_ecore_con_init_count != 0)
  return _ecore_con_init_count;
 
-#ifdef HAVE_LIBPROXY
-   if (_ecore_con_libproxy_factory)
+   if (_ecore_con_libproxy.factory)
  {
-px_proxy_factory_free(_ecore_con_libproxy_factory);
-_ecore_con_libproxy_factory = NULL;
+_ecore_con_libproxy.px_proxy_factory_free(_ecore_con_libproxy.factory);
+_ecore_con_libproxy.factory = NULL;
+ }
+   if (_ecore_con_libproxy.mod)
+ {
+eina_module_free(_ecore_con_libproxy.mod);
+_ecore_con_libproxy.mod = NULL;
  }
-#endif
 
eina_log_timing(_ecore_con_log_dom,
EINA_LOG_STATE_START,
@@ -,32 +4453,15 @@ 
_efl_net_ip_connect_async_run_socks5h(Efl_Net_Ip_Connect_Async_Data *d, const ch
EINA_THREAD_CLEANUP_POP(EINA_TRUE); /* free(str) */
 }
 
-#ifdef HAVE_LIBPROXY
-static void
-_cleanup_proxies(void *data)
-{
-   char **proxies = data;
-   char **itr;
-
-   if (!proxies) return;
-
-   for (itr = proxies; *itr != NULL; itr++)
- free(*itr);
-   free(proxies);
-}
-#endif
-
 static void
 _efl_net_ip_connect_async_run(void *data, Ecore_Thread *thread EINA_UNUSED)
 {
Efl_Net_Ip_Connect_Async_Data *d = data;
const char *host, *port, *proxy;
char *addrcopy;
-#ifdef HAVE_LIBPROXY
char **proxies = NULL;
int proxies_idx = 0;
Eina_Bool is_libproxy = EINA_FALSE;
-#endif
 
addrcopy = strdup(d->address);
if (!addrcopy)
@@ -4489,8 +4481,7 @@ _efl_net_ip_connect_async_run(void *data, Ecore_Thread 
*thread EINA_UNUSED)
 
proxy = d->proxy;
 
-#ifdef HAVE_LIBPROXY
-   if ((!proxy) && (_ecore_con_libproxy_factory))
+   if ((!proxy) && (_ecore_con_libproxy.factory))
  {
 /* libproxy is thread-safe but not cancellable.  the provided
  * parameter must be a URL with schema, otherwise it won't
@@ -4499,11 +4490,11 @@ _efl_net_ip_connect_async_run(void *data, Ecore_Thread 
*thread EINA_UNUSED)
 char *url;
 
 asprintf(&url, "%s://%s:%s", d->protocol == IPPROTO_UDP ? "udp" : 
"tcp", host, port);
-proxies = px_proxy_factory_get_proxies(_ecore_con_libproxy_factory, 
url);
+proxies = ecore_con_libproxy_proxies_get(url);
 

Re: [E-devel] [EGIT] [core/efl] master 01/02: eina - redo a lot of the static inlines to have better instr cache usage

2016-09-20 Thread Cedric BAIL
On Tue, Sep 20, 2016 at 8:47 AM, Gustavo Sverzut Barbieri
 wrote:
> On Tue, Sep 20, 2016 at 12:12 PM, Gustavo Sverzut Barbieri
>  wrote:
>> On Tue, Sep 20, 2016 at 11:29 AM, Carsten Haitzler  
>> wrote:
>>> On Tue, 20 Sep 2016 08:27:25 -0300 Gustavo Sverzut Barbieri
>>>  said:
>>>
 >  static inline void *
 > @@ -104,12 +101,11 @@ eina_array_foreach(Eina_Array *array, Eina_Each_Cb
 > cb, void *fdata) Eina_Bool ret = EINA_TRUE;
 >
 > EINA_ARRAY_ITER_NEXT(array, i, data, iterator)
 > - if (cb(array, data, fdata) != EINA_TRUE)
 > -   {
 > - ret = EINA_FALSE;
 > - break;
 > -   }
 > -
 > + {
 > +if (cb(array, data, fdata) == EINA_TRUE) continue;
 > +ret = EINA_FALSE;
 > +break;
 > + }
 > return ret;
 >  }


 for these wouldn't EINA_LIKELY/UNLIKELY be more clear on what is the
 expected/preference to the user AND the compiler. What you did is
 likely to work for one compiler but not the other, if branch
 prediction preference is difference.
>>>
>>> no. likely/unlikely dont do anything useful since 486 architecture days. 
>>> back
>>> then the cmp would always predict either true or false (i dont remember) so 
>>> the
>>> compiler SHOULD adjust the compare so the more likely outcome is what the 
>>> cpu
>>> will then just blindly run while waiting for the result. its is not true 
>>> anymore
>>> and these really do nothing useful.
>>
>> it should have the same impact, but admittedly I did not test to guarantee.
>
> Okay, I had to test:
>
> #include 
> int main(int argc, char *argv[]) {
> if (argc < 1)
> puts("less");
> else
>   fprintf(stderr, "more: %d", argc);
> return 0;
> }
>
> $ gcc -O2 -S /tmp/a.c -o /tmp/original-order.s
> $ cat /tmp/original-order.s
> .file "a.c"
> .section .rodata.str1.1,"aMS",@progbits,1
> .LC0:
> .string "less"
> .LC1:
> .string "more: %d"
> .section .text.startup,"ax",@progbits
> .p2align 4,,15
> .globl main
> .type main, @function
> main:
> .LFB11:
> .cfi_startproc
> subq $8, %rsp
> .cfi_def_cfa_offset 16
> testl %edi, %edi
> jle .L6
> movl %edi, %edx
> movq stderr(%rip), %rdi
> movl $.LC1, %esi
> xorl %eax, %eax
> call fprintf
> .L3:
> xorl %eax, %eax
> addq $8, %rsp
> .cfi_remember_state
> .cfi_def_cfa_offset 8
> ret
> .L6:
> .cfi_restore_state
> movl $.LC0, %edi
> call puts
> jmp .L3
> .cfi_endproc
> .LFE11:
> .size main, .-main
> .ident "GCC: (GNU) 6.2.1 20160830"
> .section .note.GNU-stack,"",@progbits
>
>
> that is, fprintf() is prefered over puts()... It doesn't read like our
> input code, since -O1 will imply -freorder-blocks.
>
>
> GCC -O2 prefers "else" condition, which can be confirmed by using
> __builtin_expect((argc < 1), 0)  -> EINA_UNLIKELY()
>
> $ gcc -O2 -S /tmp/a.c -o /tmp/unlikely.s
> $ diff -u /tmp/original-order.s /tmp/unlikely.s
>
> no changes.
>
>
> now force different prediction by using __builtin_expect((argc < 1),
> 1)  -> EINA_LIKELY()
>
> $ gcc -O2 -S /tmp/a.c -o /tmp/likely.s
> $ diff -u /tmp/original-order.s /tmp/likely.s
>
> --- /tmp/original-order.s 2016-09-20 12:31:35.747803857 -0300
> +++ /tmp/likely.s 2016-09-20 12:34:02.599250150 -0300
> @@ -14,22 +14,22 @@
>   subq $8, %rsp
>   .cfi_def_cfa_offset 16
>   testl %edi, %edi
> - jle .L6
> - movl %edi, %edx
> - movq stderr(%rip), %rdi
> - movl $.LC1, %esi
> - xorl %eax, %eax
> - call fprintf
> + jg .L2
> + movl $.LC0, %edi
> + call puts
>  .L3:
>   xorl %eax, %eax
>   addq $8, %rsp
>   .cfi_remember_state
>   .cfi_def_cfa_offset 8
>   ret
> -.L6:
> +.L2:
>   .cfi_restore_state
> - movl $.LC0, %edi
> - call puts
> + movl %edi, %edx
> + movq stderr(%rip), %rdi
> + movl $.LC1, %esi
> + xorl %eax, %eax
> + call fprintf
>   jmp .L3
>   .cfi_endproc
>  .LFE11:
>
> that is, puts is now before fprintf. Inverting the branch ourselves,
> no __builtin_expect():
>
> $ gcc -O2 -S /tmp/a.c -o /tmp/
> $ diff -u /tmp/original-order.s /tmp/unlikely.s
>
> --- /tmp/original-order.s 2016-09-20 12:31:35.747803857 -0300
> +++ /tmp/inverted-order.s 2016-09-20 12:35:56.710377570 -0300
> @@ -1,9 +1,9 @@
>   .file "a.c"
>   .section .rodata.str1.1,"aMS",@progbits,1
>  .LC0:
> - .string "less"
> -.LC1:
>   .string "more: %d"
> +.LC1:
> + .string "less"
>   .section .text.startup,"ax",@progbits
>   .p2align 4,,15
>   .globl main
> @@ -14,10 +14,10 @@
>   subq $8, %rsp
>   .cfi_def_cfa_offset 16
>   testl %edi, %edi
> - jle .L6
> + jle .L2
>   movl %edi, %edx
>   movq stderr(%rip), %rdi
> - movl $.LC1, %esi
> + movl $.LC0, %esi
>   xorl %eax, %eax
>   call fprintf
>  .L3:
> @@ -26,9 +26,9 @@
>   .cfi_remember_state
>   .cfi_def_cfa_offset 8
>   ret
> -.L6:
> +.L2:
>   .cfi_restore_state
> - movl $.LC0, %edi
> + movl $.LC1, %edi
>   call puts
>   jmp .L3
>   .cfi_endproc
>
> That is, only the stings changed order... the code remained the SAME :-/
>
> Maybe it was pure luck on your side, something we can't trust. IF you
> want to be sure, do use t

[EGIT] [core/efl] master 01/01: ecore_file: Fix improper way of comparing in ecore_file_path_dir_exists @fix

2016-09-20 Thread Artem Popov
nikawhite pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=132ae9683c242b695d1bb3050c09f83386d0667d

commit 132ae9683c242b695d1bb3050c09f83386d0667d
Author: Artem Popov 
Date:   Tue Sep 20 19:52:23 2016 +0300

ecore_file: Fix improper way of comparing in ecore_file_path_dir_exists @fix

Summary: There is wrong comparing while using strcmp function. Should be 
inverted.

Reviewers: cedric, raster, NikaWhite

Reviewed By: NikaWhite

Subscribers: cedric, NikaWhite, jpeg

Differential Revision: https://phab.enlightenment.org/D4291
---
 src/lib/ecore_file/ecore_file_path.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/lib/ecore_file/ecore_file_path.c 
b/src/lib/ecore_file/ecore_file_path.c
index a368cf3..71fdb68 100644
--- a/src/lib/ecore_file/ecore_file_path.c
+++ b/src/lib/ecore_file/ecore_file_path.c
@@ -97,7 +97,7 @@ ecore_file_path_dir_exists(const char *in_dir)
if (!__ecore_file_path_bin) return EINA_FALSE;
EINA_LIST_FOREACH(__ecore_file_path_bin, l, dir)
  {
-if (strcmp(dir, in_dir))
+if (!strcmp(dir, in_dir))
   return EINA_TRUE;
  }
 

-- 




Re: [E-devel] Debugging edc at runtime is possible?

2016-09-20 Thread Cedric BAIL
Hello,

On Tue, Sep 20, 2016 at 9:19 AM, Jiwon Kim  wrote:
> I wonder about debugging edc script. (or maybe it's just idea :) )
> Is it possible to debug at running time of application?
> Likes gdb (or with gdb), attach to app,
>  and set break point to 'program' syntex (edc's program blocks).

This is an interesting idea. I don't know if it could be doable
actually as program are run related to time. Any debugging would
likely affect that.

> If we can check edc's (when/which) program running and signaling,
> I think it's very convenient.

Agreed, I don't see a way to do step by step debugging of an edc. Will
have to think about it.

> If it is impossible, how about log function for edc? (only for debug)

Once upon a time, there was a lot of log generated in the form of edje
signal. They were removed as they impacted speed to much. Today, we
have evlog, it may be worse experimenting with it and see if we can
log events with it somehow. Alternative possibility would be to add an
eo event on edje object for debug. Once someone register for that
event, we would trigger that event for every state we want to debug.
Between evlog and eo event tracing, I don't know which one could work
best. You would have to experiment !

Have fun !
-- 
Cedric BAIL

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


[EGIT] [core/enlightenment] master 02/03: clean up gadget drop handlers correctly

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

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

commit f700a57baf6952eb1d7aa33078312c7b5511c363
Author: Mike Blumenkrantz 
Date:   Tue Sep 20 11:43:42 2016 -0400

clean up gadget drop handlers correctly

use drop_handler_del when deleting gadget drop handlers, also delete spacer 
rects
---
 src/bin/e_gadget.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/src/bin/e_gadget.c b/src/bin/e_gadget.c
index 75dbc29..7b68487 100644
--- a/src/bin/e_gadget.c
+++ b/src/bin/e_gadget.c
@@ -248,6 +248,15 @@ _gadget_util_allow_deny_cleanup(E_Gadget_Config *zgc)
 }
 
 static void
+_gadget_drop_handler_del(void *data, Evas *e EINA_UNUSED, Evas_Object *obj, 
void *event_info EINA_UNUSED)
+{
+   E_Gadget_Config *zgc = data;
+
+   if (zgc->drop_handlers)//may be calling during object_free
+ eina_hash_del_by_key(zgc->drop_handlers, &obj);
+}
+
+static void
 _gadget_object_free(E_Object *eobj)
 {
E_Gadget_Config *zgc;
@@ -265,6 +274,7 @@ _gadget_object_free(E_Object *eobj)
 E_FREE_FUNC(zgc->display, evas_object_del);
  }
zgc->gadget = NULL;
+
E_FREE_FUNC(zgc->drop_handlers, eina_hash_free);
E_FREE_FUNC(zgc->gadget, evas_object_del);
E_FREE_FUNC(zgc->cfg_object, evas_object_del);
@@ -1429,15 +1439,6 @@ _gadget_drop_handler_moveresize(void *data, Evas *e 
EINA_UNUSED, Evas_Object *ob
e_drop_handler_geometry_set(data, x, y, w, h);
 }
 
-static void
-_gadget_drop_handler_del(void *data, Evas *e EINA_UNUSED, Evas_Object *obj, 
void *event_info EINA_UNUSED)
-{
-   E_Gadget_Config *zgc = data;
-
-   eina_hash_del_by_key(zgc->drop_handlers, &obj);
-   e_object_del(evas_object_data_get(obj, "gadget_drop_handler"));
-}
-
 E_API Evas_Object *
 e_gadget_drop_handler_add(Evas_Object *g, void *data,
 void (*enter_cb)(void *data, const 
char *type, void *event),
@@ -1456,13 +1457,14 @@ e_gadget_drop_handler_add(Evas_Object *g, void *data,
EINA_SAFETY_ON_NULL_RETURN_VAL(zgc, NULL);
 
if (!zgc->drop_handlers)
- zgc->drop_handlers = eina_hash_pointer_new((Eina_Free_Cb)evas_object_del);
+ zgc->drop_handlers = 
eina_hash_pointer_new((Eina_Free_Cb)e_drop_handler_del);
 
evas_object_geometry_get(zgc->display, &x, &y, &w, &h);
drop_handler = e_drop_handler_add(zgc->e_obj_inherit, NULL, data,
 enter_cb, move_cb, leave_cb, drop_cb,
 types, num_types, x, y, w, h);
drop_object = evas_object_rectangle_add(e_comp->evas);
+   e_comp_object_util_del_list_append(g, drop_object);
drop_handler->base = drop_object;
evas_object_color_set(drop_object, 0, 0, 0, 0);
e_object_data_set(E_OBJECT(drop_handler), drop_object);

-- 




[EGIT] [core/enlightenment] master 01/03: always delete gadget's display object and ensure gadget object is null

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

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

commit 17909e4fb5ef282ef33f2641882adaca303e1bf8
Author: Mike Blumenkrantz 
Date:   Tue Sep 20 10:26:28 2016 -0400

always delete gadget's display object and ensure gadget object is null

fixes some object errors during container deletion
---
 src/bin/e_gadget.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/bin/e_gadget.c b/src/bin/e_gadget.c
index 54ef51c..75dbc29 100644
--- a/src/bin/e_gadget.c
+++ b/src/bin/e_gadget.c
@@ -264,6 +264,7 @@ _gadget_object_free(E_Object *eobj)
 evas_object_event_callback_del_full(zgc->display, EVAS_CALLBACK_DEL, 
_gadget_del, zgc);
 E_FREE_FUNC(zgc->display, evas_object_del);
  }
+   zgc->gadget = NULL;
E_FREE_FUNC(zgc->drop_handlers, eina_hash_free);
E_FREE_FUNC(zgc->gadget, evas_object_del);
E_FREE_FUNC(zgc->cfg_object, evas_object_del);
@@ -1102,7 +1103,7 @@ _site_del(void *data, Evas *e EINA_UNUSED, Evas_Object 
*obj EINA_UNUSED, void *e
E_FREE_FUNC(zgs->move_handler, ecore_event_handler_del);
E_FREE_FUNC(zgs->mouse_up_handler, ecore_event_handler_del);
EINA_LIST_FOREACH(zgs->gadgets, l, zgc)
- evas_object_del(zgc->gadget);
+ evas_object_del(zgc->display);
if (zgs->name) return;
eina_stringshare_del(zgs->name);
free(zgs);

-- 




[EGIT] [core/enlightenment] master 03/03: do not update bryce layer when restacking to a higher layer than CLIENT_ABOVE

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

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

commit 509443af55371262375ee8ba9f15f7aa80e2fea5
Author: Mike Blumenkrantz 
Date:   Tue Sep 20 12:44:50 2016 -0400

do not update bryce layer when restacking to a higher layer than 
CLIENT_ABOVE
---
 src/bin/e_bryce.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/bin/e_bryce.c b/src/bin/e_bryce.c
index aa406a3..d352d9e 100644
--- a/src/bin/e_bryce.c
+++ b/src/bin/e_bryce.c
@@ -361,6 +361,7 @@ _bryce_restack(void *data, Evas *e EINA_UNUSED, Evas_Object 
*obj, void *event_in
E_Layer layer;
 
layer = evas_object_layer_get(obj);
+   if (layer > DEFAULT_LAYER) return;
b->layer = layer;
if ((!b->noshadow) && (layer != b->layer))
  e_comp_object_util_type_set(b->bryce, _bryce_shadow_type(b));

-- 




[EGIT] [core/efl] master 01/01: eina_cpu, evas: Remove _eina_cpu_fast_core_get, don't set render thread affinity

2016-09-20 Thread Derek Foreman
derekf pushed a commit to branch master.

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

commit e2875cefc49768f919919fbfa478f81570168688
Author: Derek Foreman 
Date:   Tue Sep 20 11:33:33 2016 -0500

eina_cpu, evas: Remove _eina_cpu_fast_core_get, don't set render thread 
affinity

We've decided it would be best to just let the scheduler do its job.
---
 src/Makefile_Eina.am |   1 -
 src/lib/eina/eina_cpu.c  | 117 ---
 src/lib/eina/eina_cpu_private.h  |  42 ---
 src/lib/evas/common/evas_thread_render.c |  13 +---
 4 files changed, 2 insertions(+), 171 deletions(-)

diff --git a/src/Makefile_Eina.am b/src/Makefile_Eina.am
index 96ff376..22ade8f 100644
--- a/src/Makefile_Eina.am
+++ b/src/Makefile_Eina.am
@@ -58,7 +58,6 @@ lib/eina/eina_trash.h \
 lib/eina/eina_iterator.h \
 lib/eina/eina_main.h \
 lib/eina/eina_cpu.h \
-lib/eina/eina_cpu_private.h \
 lib/eina/eina_inline_cpu.x \
 lib/eina/eina_sched.h \
 lib/eina/eina_tiler.h \
diff --git a/src/lib/eina/eina_cpu.c b/src/lib/eina/eina_cpu.c
index 9f4ab4b..3ec9204 100644
--- a/src/lib/eina/eina_cpu.c
+++ b/src/lib/eina/eina_cpu.c
@@ -49,25 +49,12 @@
 #include "eina_log.h"
 #include "eina_cpu.h"
 
-#include 
-
-#include "eina_cpu_private.h"
-
-#if defined(HAVE_SYS_AUXV_H) && defined(HAVE_ASM_HWCAP_H) && defined(__arm__) 
&& defined(__linux__)
-# include 
-# include 
-#endif
-
 /**
 *  Local *
 **/
 
 static void _eina_page_size(void);
 
-static int fastest_core_speed = 0;
-static int slowest_core_speed = INT_MAX;
-static Eina_Hash *cpu_hash = NULL;
-
 /* FIXME this ifdefs should be replaced */
 #if defined(__i386__) || defined(__x86_64__)
 /* We save ebx and restore it to be PIC compatible */
@@ -178,9 +165,6 @@ eina_cpu_init(void)
 Eina_Bool
 eina_cpu_shutdown(void)
 {
-   eina_hash_free(cpu_hash);
-   cpu_hash = NULL;
-   fastest_core_speed = 0;
return EINA_TRUE;
 }
 
@@ -316,104 +300,3 @@ void eina_cpu_count_internal(void)
else
  _cpu_count = _eina_cpu_count_internal();
 }
-
-static void
-eina_cpu_map_init(void)
-{
-   fastest_core_speed = -1;
-
-#if defined (__linux__) || defined(__GLIBC__)
-   FILE *f = NULL;
-   Eina_Iterator *it;
-   Eina_Strbuf *fname;
-   const Eina_File_Direct_Info *f_info;
-
-   it = eina_file_stat_ls("/sys/devices/system/cpu/cpufreq");
-   if (!it) return;
-
-   cpu_hash = eina_hash_int32_new(free);
-
-   fname = eina_strbuf_new();
-   EINA_ITERATOR_FOREACH(it, f_info)
- {
-if ((f_info->type == EINA_FILE_DIR) &&
-eina_str_has_prefix(f_info->path,
-"/sys/devices/system/cpu/cpufreq/policy"))
-  {
- int num, speed;
-
- eina_strbuf_append_printf(fname, "%s%s", f_info->path, 
"/cpuinfo_max_freq");
- f = fopen(eina_strbuf_string_get(fname), "r");
- eina_strbuf_reset(fname);
- if (!f) goto err;
- speed = -1;
- num = fscanf(f, "%d", &speed);
- fclose(f);
- f = NULL;
- if ((num != 1) || (speed == -1)) goto err;
-
- slowest_core_speed = MIN(speed, slowest_core_speed);
- fastest_core_speed = MAX(speed, fastest_core_speed);
-
- eina_strbuf_append_printf(fname, "%s%s", f_info->path, 
"/affected_cpus");
- f = fopen(eina_strbuf_string_get(fname), "r");
- eina_strbuf_reset(fname);
- if (!f) goto err;
- do
-   {
-  int core;
-  uint64_t *corelist;
-  num = fscanf(f, "%d", &core);
-  if ((num == EOF) || (core > 63)) break;
-
-  corelist = eina_hash_find(cpu_hash, &speed);
-  if (!corelist)
-{
-   corelist = malloc(sizeof(*corelist));
-   if (!corelist) goto err;
-   *corelist = 1LL << core;
-   eina_hash_add(cpu_hash, &speed, corelist);
-}
-  *corelist |= 1LL << core;
-   } while (num != EOF);
- fclose(f);
- f = NULL;
-  }
- }
-err:
-   if (f) fclose(f);
-   eina_strbuf_free(fname);
-   eina_iterator_free(it);
-#endif
-}
-
-EAPI int
-_eina_cpu_fast_core_get(void)
-{
-#if defined (__linux__) || defined(__GLIBC__)
-   uint64_t *corelist;
-   uint64_t cores;
-   int bit, place = 0;
-
-   if (fastest_core_speed == -1) return -1;
-
-   if (fastest_core_speed == 0) eina_cpu_map_init();
-
-   /* Check again now that it's actually set up */
-   if (fastest_core_speed == -1) return -1;
-
-   corelist = eina_hash_find(cpu_hash, &fastest_core_spe

Re: [E-devel] [EGIT] [core/efl] master 01/01: eina/ecore: allow threads to be canceled, use in ecore_con.

2016-09-20 Thread The Rasterman
On Tue, 20 Sep 2016 17:51:15 +0900 Jean-Philippe André  said:

> Hi Gustavo,
> 
> On 14 September 2016 at 13:55, Gustavo Sverzut Barbieri 
> wrote:
> 
> > HEADS UP -- BINDINGS:
> >
> > If you wish to expose the new "cancellable" property, or cope with
> > naughty users or 3rd party deps that may call
> > pthread_setcancelstate(PTHREAD_CANCEL_ENABLE), please register your
> > cleanup functions with:
> >
> >EINA_THREAD_CLEANUP_PUSH(cb, ctx); // will call cb() on
> > pthread_cancel()/ecore_thread_cancel()/eina_thread_cancel()
> >call_user();
> >EINA_THREAD_CLEANUP_POP(EINA_TRUE); // will call cb() on clean exit
> >
> > If different functions are desired:
> >
> >EINA_THREAD_CLEANUP_PUSH(cb, ctx); // will call cb() on
> > pthread_cancel()/ecore_thread_cancel()/eina_thread_cancel()
> >call_user();
> >EINA_THREAD_CLEANUP_POP(EINA_FALSE); // will NOT call cb() on clean
> > exit
> >another_cb(ctx);
> >
> > This is recommended if you expose ecore_thread to your users. If you
> > don't, then you do not need to do anything.
> 
> 
> pthread_cancel did (does?) not exist on Android, by design choice. bionic
> isn't posix in that regard.
> One way or another, I remember that using cancel is actually quite hard,
> because you need to be very careful about the cleanup.
> 
> So I wonder if adding cancel like pthread here is the best choice?
> Note that I understand the need and don't have any good alternative :)

i also really dislike this. handling cleanup is horrible. this is like
encouraging setjmp/longjmp for error handling. it's HORRIBLE. i was looking at
this and was thinking 'ugh.. cleanup. what if u are in the middle of a malloc()
or something else that is REALLy hard to do a cleanup on...

this is just incredibly fragile and i think its a very poor idea.

as jp said.. this now puts a huge kick in ever porting to android.

i say ditch this. it's too much trouble and it basically vetos android as a
platform for efl ever. this last one alone is enough to say no.

the voluntary thread check api we have is controllable and the app can decide
the check points and unwind cleanly. if they don't check often enough well..
thats just going to be the cost of latency.

yes - there is an issue of a blocking dns lookup ... it is just something we
have to deal with and that thread will be blocked until it times out... :
( thus .. we have a pool of them.

> > On Wed, Sep 14, 2016 at 1:47 AM, Gustavo Sverzut Barbieri
> >  wrote:
> > > barbieri pushed a commit to branch master.
> > >
> > > http://git.enlightenment.org/core/efl.git/commit/?id=
> > 960e1a1d168ba0044544ca22b05cbf505941f150
> > >
> > > commit 960e1a1d168ba0044544ca22b05cbf505941f150
> > > Author: Gustavo Sverzut Barbieri 
> > > Date:   Wed Sep 14 01:38:58 2016 -0300
> > >
> > > eina/ecore: allow threads to be canceled, use in ecore_con.
> > >
> > > As discussed in the mailing list, many people will use worker threads
> > > to execute blocking syscalls and mandating ecore_thread_check() for
> > > voluntary preemption reduces the ecore_thread usefulness a lot.
> > >
> > > A clear example is ecore_con usage of connect() and getaddrinfo() in
> > > threads. If the connect timeout expires, the thread will be
> > cancelled,
> > > but it was blocked on syscalls and they will hang around for long
> > > time. If the application exits, ecore will print an error saying it
> > > can SEGV.
> > >
> > > Then enable access to pthread_setcancelstate(PTHREAD_CANCEL_ENABLE)
> > > via eina_thread_cancellable_set(EINA_TRUE), to pthread_cancel() via
> > > eina_thread_cancel(), to pthread_cleanup_push()/
> > pthread_cleanup_pop()
> > > via EINA_THREAD_CLEANUP_PUSH()/EINA_THREAD_CLEANUP_POP() and so on.
> > >
> > > Ecore threads will enforce non-cancellable threads on its own code,
> > > but the user may decide to enable that and allow cancellation, that's
> > > not an issue since ecore_thread now plays well and use cleanup
> > > functions.
> > >
> > > Ecore con connect/resolve make use of that and enable cancellable
> > > state, efl_net_dialer_tcp benefits a lot from that.
> > >
> > > A good comparison of the benefit is to run:
> > >
> > >./src/examples/ecore/efl_io_copier_example tcp://google.com:1234
> > :stdout:
> > >
> > > before and after. It will timeout after 30s and with this patch the
> > > thread is gone, no ecore error is printed about possible SEGV.
> > > ---
> > >  src/lib/ecore/Ecore_Common.h  |  12 +++
> > >  src/lib/ecore/ecore_thread.c  | 108 +++--
> > >  src/lib/ecore_con/ecore_con.c |  41 +---
> > >  src/lib/eina/Eina.h   |   2 +-
> > >  src/lib/eina/eina_thread.c|  32 ++
> > >  src/lib/eina/eina_thread.h| 219 ++
> > 
> > >  6 files changed, 373 insertions(+), 41 deletions(-)
> > >
> > > diff --git a/src/lib/ecore/Ecore_Common.h b/src/lib/ecore/Ecore_Common.h
> > > index 54044

[E-devel] Debugging edc at runtime is possible?

2016-09-20 Thread Jiwon Kim
Hi all.

I wonder about debugging edc script. (or maybe it's just idea :) )
Is it possible to debug at running time of application?
Likes gdb (or with gdb), attach to app,
 and set break point to 'program' syntex (edc's program blocks).

If we can check edc's (when/which) program running and signaling,
I think it's very convenient.

If it is impossible, how about log function for edc? (only for debug)

Does anyone has know-how regarding this?
Or, has anyone ever tried to similar attempt?

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


[EGIT] [tools/eflete] master 01/01: style_manager: fix label text

2016-09-20 Thread Andrii Kroitor
rimmed pushed a commit to branch master.

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

commit 678c9224dcdab904ad00c0576cf20942876212b3
Author: Andrii Kroitor 
Date:   Tue Sep 20 18:15:04 2016 +0300

style_manager: fix label text
---
 src/bin/ui/style_manager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/bin/ui/style_manager.c b/src/bin/ui/style_manager.c
index ef11b1a..552bd64 100644
--- a/src/bin/ui/style_manager.c
+++ b/src/bin/ui/style_manager.c
@@ -827,7 +827,7 @@ style_manager_add()
mng.layout = elm_layout_add(ap.win);
elm_layout_theme_set(mng.layout, "layout", "manager", "internal");
elm_object_part_text_set(mng.layout, "elm.text", _("Preview"));
-   elm_layout_text_set(mng.layout, "elm.subtext", _("Font list"));
+   elm_layout_text_set(mng.layout, "elm.subtext", _("Textblock styles list"));
mng.panes = elm_panes_add(mng.win);
elm_panes_content_right_size_set(mng.panes, 0);
elm_panes_content_right_min_size_set(mng.panes, 400);

-- 




Re: [E-devel] [EGIT] [core/efl] master 01/02: eina - redo a lot of the static inlines to have better instr cache usage

2016-09-20 Thread Gustavo Sverzut Barbieri
On Tue, Sep 20, 2016 at 12:12 PM, Gustavo Sverzut Barbieri
 wrote:
> On Tue, Sep 20, 2016 at 11:29 AM, Carsten Haitzler  
> wrote:
>> On Tue, 20 Sep 2016 08:27:25 -0300 Gustavo Sverzut Barbieri
>>  said:
>>
>>> >  static inline void *
>>> > @@ -104,12 +101,11 @@ eina_array_foreach(Eina_Array *array, Eina_Each_Cb
>>> > cb, void *fdata) Eina_Bool ret = EINA_TRUE;
>>> >
>>> > EINA_ARRAY_ITER_NEXT(array, i, data, iterator)
>>> > - if (cb(array, data, fdata) != EINA_TRUE)
>>> > -   {
>>> > - ret = EINA_FALSE;
>>> > - break;
>>> > -   }
>>> > -
>>> > + {
>>> > +if (cb(array, data, fdata) == EINA_TRUE) continue;
>>> > +ret = EINA_FALSE;
>>> > +break;
>>> > + }
>>> > return ret;
>>> >  }
>>>
>>>
>>> for these wouldn't EINA_LIKELY/UNLIKELY be more clear on what is the
>>> expected/preference to the user AND the compiler. What you did is
>>> likely to work for one compiler but not the other, if branch
>>> prediction preference is difference.
>>
>> no. likely/unlikely dont do anything useful since 486 architecture days. back
>> then the cmp would always predict either true or false (i dont remember) so 
>> the
>> compiler SHOULD adjust the compare so the more likely outcome is what the cpu
>> will then just blindly run while waiting for the result. its is not true 
>> anymore
>> and these really do nothing useful.
>
> it should have the same impact, but admittedly I did not test to guarantee.

Okay, I had to test:

#include 
int main(int argc, char *argv[]) {
if (argc < 1)
puts("less");
else
  fprintf(stderr, "more: %d", argc);
return 0;
}

$ gcc -O2 -S /tmp/a.c -o /tmp/original-order.s
$ cat /tmp/original-order.s
.file "a.c"
.section .rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "less"
.LC1:
.string "more: %d"
.section .text.startup,"ax",@progbits
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB11:
.cfi_startproc
subq $8, %rsp
.cfi_def_cfa_offset 16
testl %edi, %edi
jle .L6
movl %edi, %edx
movq stderr(%rip), %rdi
movl $.LC1, %esi
xorl %eax, %eax
call fprintf
.L3:
xorl %eax, %eax
addq $8, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.L6:
.cfi_restore_state
movl $.LC0, %edi
call puts
jmp .L3
.cfi_endproc
.LFE11:
.size main, .-main
.ident "GCC: (GNU) 6.2.1 20160830"
.section .note.GNU-stack,"",@progbits


that is, fprintf() is prefered over puts()... It doesn't read like our
input code, since -O1 will imply -freorder-blocks.


GCC -O2 prefers "else" condition, which can be confirmed by using
__builtin_expect((argc < 1), 0)  -> EINA_UNLIKELY()

$ gcc -O2 -S /tmp/a.c -o /tmp/unlikely.s
$ diff -u /tmp/original-order.s /tmp/unlikely.s

no changes.


now force different prediction by using __builtin_expect((argc < 1),
1)  -> EINA_LIKELY()

$ gcc -O2 -S /tmp/a.c -o /tmp/likely.s
$ diff -u /tmp/original-order.s /tmp/likely.s

--- /tmp/original-order.s 2016-09-20 12:31:35.747803857 -0300
+++ /tmp/likely.s 2016-09-20 12:34:02.599250150 -0300
@@ -14,22 +14,22 @@
  subq $8, %rsp
  .cfi_def_cfa_offset 16
  testl %edi, %edi
- jle .L6
- movl %edi, %edx
- movq stderr(%rip), %rdi
- movl $.LC1, %esi
- xorl %eax, %eax
- call fprintf
+ jg .L2
+ movl $.LC0, %edi
+ call puts
 .L3:
  xorl %eax, %eax
  addq $8, %rsp
  .cfi_remember_state
  .cfi_def_cfa_offset 8
  ret
-.L6:
+.L2:
  .cfi_restore_state
- movl $.LC0, %edi
- call puts
+ movl %edi, %edx
+ movq stderr(%rip), %rdi
+ movl $.LC1, %esi
+ xorl %eax, %eax
+ call fprintf
  jmp .L3
  .cfi_endproc
 .LFE11:

that is, puts is now before fprintf. Inverting the branch ourselves,
no __builtin_expect():

$ gcc -O2 -S /tmp/a.c -o /tmp/
$ diff -u /tmp/original-order.s /tmp/unlikely.s

--- /tmp/original-order.s 2016-09-20 12:31:35.747803857 -0300
+++ /tmp/inverted-order.s 2016-09-20 12:35:56.710377570 -0300
@@ -1,9 +1,9 @@
  .file "a.c"
  .section .rodata.str1.1,"aMS",@progbits,1
 .LC0:
- .string "less"
-.LC1:
  .string "more: %d"
+.LC1:
+ .string "less"
  .section .text.startup,"ax",@progbits
  .p2align 4,,15
  .globl main
@@ -14,10 +14,10 @@
  subq $8, %rsp
  .cfi_def_cfa_offset 16
  testl %edi, %edi
- jle .L6
+ jle .L2
  movl %edi, %edx
  movq stderr(%rip), %rdi
- movl $.LC1, %esi
+ movl $.LC0, %esi
  xorl %eax, %eax
  call fprintf
 .L3:
@@ -26,9 +26,9 @@
  .cfi_remember_state
  .cfi_def_cfa_offset 8
  ret
-.L6:
+.L2:
  .cfi_restore_state
- movl $.LC0, %edi
+ movl $.LC1, %edi
  call puts
  jmp .L3
  .cfi_endproc

That is, only the stings changed order... the code remained the SAME :-/

Maybe it was pure luck on your side, something we can't trust. IF you
want to be sure, do use the __builtin_expect().


-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

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


Re: [E-devel] [EGIT] [core/efl] master 01/01: eina/ecore: allow threads to be canceled, use in ecore_con.

2016-09-20 Thread Gustavo Sverzut Barbieri
On Tue, Sep 20, 2016 at 11:18 AM, Carsten Haitzler  wrote:
> On Tue, 20 Sep 2016 08:16:21 -0300 Gustavo Sverzut Barbieri
>  said:
>
>> On Tue, Sep 20, 2016 at 5:51 AM, Jean-Philippe André 
>> wrote:
>> > Hi Gustavo,
>> >
>> > On 14 September 2016 at 13:55, Gustavo Sverzut Barbieri 
>> > 
>> > wrote:
>> >
>> >> HEADS UP -- BINDINGS:
>> >>
>> >> If you wish to expose the new "cancellable" property, or cope with
>> >> naughty users or 3rd party deps that may call
>> >> pthread_setcancelstate(PTHREAD_CANCEL_ENABLE), please register your
>> >> cleanup functions with:
>> >>
>> >>EINA_THREAD_CLEANUP_PUSH(cb, ctx); // will call cb() on
>> >> pthread_cancel()/ecore_thread_cancel()/eina_thread_cancel()
>> >>call_user();
>> >>EINA_THREAD_CLEANUP_POP(EINA_TRUE); // will call cb() on clean exit
>> >>
>> >> If different functions are desired:
>> >>
>> >>EINA_THREAD_CLEANUP_PUSH(cb, ctx); // will call cb() on
>> >> pthread_cancel()/ecore_thread_cancel()/eina_thread_cancel()
>> >>call_user();
>> >>EINA_THREAD_CLEANUP_POP(EINA_FALSE); // will NOT call cb() on clean
>> >> exit
>> >>another_cb(ctx);
>> >>
>> >> This is recommended if you expose ecore_thread to your users. If you
>> >> don't, then you do not need to do anything.
>> >
>> >
>> > pthread_cancel did (does?) not exist on Android, by design choice. bionic
>> > isn't posix in that regard.
>> > One way or another, I remember that using cancel is actually quite hard,
>> > because you need to be very careful about the cleanup.
>> >
>> > So I wonder if adding cancel like pthread here is the best choice?
>> > Note that I understand the need and don't have any good alternative :)
>>
>> Hi jpeg, thanks for letting me know.
>>
>> When we port to bionic we should then take one choice:
>>
>>  - let the thread hang there for a while, the new code I'm doing based
>> on this concept shouldn't break, it will just consume few more
>> resources for a while. (== #ifdef)
>
> i'd say do this all the time. cancellation otherwise is way too hard AND its
> non-portable. this is an api in eina that is non-portable and that means we
> have to try make it work on other platforms... if we keepit.

by default the thread cancellation is disabled. You have to manually
enable that and live with the pain, If you wish.

I've used new efl_net code to test that, simulate what our users that
loves thread would do... indeed it simplifies the code a lot to use a
thread and do procedural programming (see ecore_con.c, socks stuff).
The single detail to remember is to EINA_THREAD_CLEANUP_PUSH()/POP()
and take care to not return in the middle, since it wouldn't execute
the POP(EINA_TRUE) -- if you want to always cleanup.

The portability part can be done, like vlc did. And that is said to
work on Windows, seems Android is the only one not doing it.


>>  - use pthread_kill() with an unused signal and use a signal
>> handler... this can be a full wrapper like the one in videolan.org, or
>> just to generate EINTR like I proposed in my first discussion.
>
> this would be a far better workaround. :)

doesn't work on Windows :-(


-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

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


Re: [E-devel] [EGIT] [core/efl] master 01/02: eina - redo a lot of the static inlines to have better instr cache usage

2016-09-20 Thread Gustavo Sverzut Barbieri
On Tue, Sep 20, 2016 at 11:29 AM, Carsten Haitzler  wrote:
> On Tue, 20 Sep 2016 08:27:25 -0300 Gustavo Sverzut Barbieri
>  said:
>
>> >  static inline void *
>> > @@ -104,12 +101,11 @@ eina_array_foreach(Eina_Array *array, Eina_Each_Cb
>> > cb, void *fdata) Eina_Bool ret = EINA_TRUE;
>> >
>> > EINA_ARRAY_ITER_NEXT(array, i, data, iterator)
>> > - if (cb(array, data, fdata) != EINA_TRUE)
>> > -   {
>> > - ret = EINA_FALSE;
>> > - break;
>> > -   }
>> > -
>> > + {
>> > +if (cb(array, data, fdata) == EINA_TRUE) continue;
>> > +ret = EINA_FALSE;
>> > +break;
>> > + }
>> > return ret;
>> >  }
>>
>>
>> for these wouldn't EINA_LIKELY/UNLIKELY be more clear on what is the
>> expected/preference to the user AND the compiler. What you did is
>> likely to work for one compiler but not the other, if branch
>> prediction preference is difference.
>
> no. likely/unlikely dont do anything useful since 486 architecture days. back
> then the cmp would always predict either true or false (i dont remember) so 
> the
> compiler SHOULD adjust the compare so the more likely outcome is what the cpu
> will then just blindly run while waiting for the result. its is not true 
> anymore
> and these really do nothing useful.

it should have the same impact, but admittedly I did not test to guarantee.



>> Also, with clearlinux they use AutoFDO
>> (https://gcc.gnu.org/wiki/AutoFDO), likely in future most distros
>> should use that, thus this kind of micro-optimization is not that
>> helpful.
>
> incorrect. see my mail reply to cedric. i sped up eoid lookup by almost 3x by
> doing this. its a valid micro optimization. compilers are not that smart. they
> do put the if () content code right where it is in the c, ie right next to the
> compare and after it. i checked the asm output ... or well i was reading the
> asm output while profiling and noticed this... and the whole 2-3x speedup came
> from doing these micro-optimizations based on real code output by a very 
> recent
> compiler.

Did you check this AutoFDO? It's a profile based optimization, it will
collect data of the usage and re-compile using that as input.

I've heard of impressive gains. I recall yocto-project guys saying
that bitbake (their core tool) was much faster if python was compiled
with that... I recall Ubuntu or Fedora already did it.

The issue is more on cross-compilation, since you can't run the tests
to then recompile.



>> Given that we already run software we just compiled in the build tree
>> we could even integrate autofdo to the build system (like compile -
>> benchmark - compile)?
>
> not so easy. but as above. i dropped eoid lookup from ~6-7% to 2.5% of cpu 
> time
> just through goto's and moving "rarely accessed paths" out of the way of the
> code as the compiler LIERALLY would produce asm like the c code is written.
>
> a_stuff();
> if (x) {
>   b_stuff();
> }
> c_stuff();
>
> literally the asm here has
>
> a_stuff asm
> cmp x
> jne after
> b_stuff asm
> after:
> c_stuff asm
>
> with -O3 -march=native on gcc 6.1
>
> it is totally worth it. TOTALLY.

ok, I get that. But most of the cases above were returns... which are
very small and will not change the code that much. Not to say that
since these are static inline functions, when inlining the compiler
will remove checks if they were previously evaluated.



>> > diff --git a/src/lib/eina/eina_inline_hash.x
>> > b/src/lib/eina/eina_inline_hash.x index ab87960..114b584 100644
>> > --- a/src/lib/eina/eina_inline_hash.x
>> > +++ b/src/lib/eina/eina_inline_hash.x
>> > @@ -33,11 +33,13 @@ eina_hash_djb2(const char *key, int len)
>> > unsigned int hash_num = 5381 ^ eina_seed;
>> > const unsigned char *ptr;
>> >
>> > -   if (!key) return 0;
>> > -   for (ptr = (unsigned char *)key; len; ptr++, len--)
>> > - hash_num = ((hash_num << 5) + hash_num) ^ *ptr; /* hash * 33 ^ c */
>> > -
>> > -   return (int)hash_num;
>> > +   if (key)
>> > + {
>> > +for (ptr = (unsigned char *)key; len; ptr++, len--)
>> > +  hash_num = ((hash_num << 5) + hash_num) ^ *ptr; /* hash * 33 ^ c
>> > */
>> > +return (int)hash_num;
>> > + }
>> > +   return 0;
>> >  }
>>
>>
>> for these, which are error handling, EINA_UNLIKELY() is much, much
>> better to read and doesn't change the whole code because of 1 line.
>
> been there. done that. EINA_UNLIKELY had no effect. see above.

in this example it's adding one instruction. That's not impacting the
cacheline as you say. If the error handling code was much bigger, I'd
agree.


>> >  static inline Eina_Bool
>> >  eina_lock_new(Eina_Lock *mutex)
>> >  {
>> [...]
>> > +   return _eina_lock_new(mutex, EINA_FALSE);
>> >  }
>>
>> since you did not had a symbol before, why not just introduce one
>> without the "_"?
>
> as per my commit. i was tossing up but then i would have to change the
> prototypes so i went for the least intrusive version for now. i was on the
> plane 30kft up not sle

Re: [E-devel] [EGIT] [core/efl] master 01/01: eina/ecore: allow threads to be canceled, use in ecore_con.

2016-09-20 Thread The Rasterman
On Tue, 20 Sep 2016 08:16:21 -0300 Gustavo Sverzut Barbieri
 said:

> On Tue, Sep 20, 2016 at 5:51 AM, Jean-Philippe André 
> wrote:
> > Hi Gustavo,
> >
> > On 14 September 2016 at 13:55, Gustavo Sverzut Barbieri 
> > wrote:
> >
> >> HEADS UP -- BINDINGS:
> >>
> >> If you wish to expose the new "cancellable" property, or cope with
> >> naughty users or 3rd party deps that may call
> >> pthread_setcancelstate(PTHREAD_CANCEL_ENABLE), please register your
> >> cleanup functions with:
> >>
> >>EINA_THREAD_CLEANUP_PUSH(cb, ctx); // will call cb() on
> >> pthread_cancel()/ecore_thread_cancel()/eina_thread_cancel()
> >>call_user();
> >>EINA_THREAD_CLEANUP_POP(EINA_TRUE); // will call cb() on clean exit
> >>
> >> If different functions are desired:
> >>
> >>EINA_THREAD_CLEANUP_PUSH(cb, ctx); // will call cb() on
> >> pthread_cancel()/ecore_thread_cancel()/eina_thread_cancel()
> >>call_user();
> >>EINA_THREAD_CLEANUP_POP(EINA_FALSE); // will NOT call cb() on clean
> >> exit
> >>another_cb(ctx);
> >>
> >> This is recommended if you expose ecore_thread to your users. If you
> >> don't, then you do not need to do anything.
> >
> >
> > pthread_cancel did (does?) not exist on Android, by design choice. bionic
> > isn't posix in that regard.
> > One way or another, I remember that using cancel is actually quite hard,
> > because you need to be very careful about the cleanup.
> >
> > So I wonder if adding cancel like pthread here is the best choice?
> > Note that I understand the need and don't have any good alternative :)
> 
> Hi jpeg, thanks for letting me know.
> 
> When we port to bionic we should then take one choice:
> 
>  - let the thread hang there for a while, the new code I'm doing based
> on this concept shouldn't break, it will just consume few more
> resources for a while. (== #ifdef)

i'd say do this all the time. cancellation otherwise is way too hard AND its
non-portable. this is an api in eina that is non-portable and that means we
have to try make it work on other platforms... if we keepit.

>  - use pthread_kill() with an unused signal and use a signal
> handler... this can be a full wrapper like the one in videolan.org, or
> just to generate EINTR like I proposed in my first discussion.

this would be a far better workaround. :)

> -- 
> Gustavo Sverzut Barbieri
> --
> Mobile: +55 (16) 99354-9890
> 
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


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


Re: [E-devel] Efl.Net and libproxy

2016-09-20 Thread Gustavo Sverzut Barbieri
On Tue, Sep 20, 2016 at 11:43 AM, Simon Lees  wrote:
>
>
> On 09/20/2016 02:24 PM, Carsten Haitzler (The Rasterman) wrote:
>> On Tue, 20 Sep 2016 01:08:48 -0300 Gustavo Sverzut Barbieri
>>  said:
>>
>>> On Mon, Sep 19, 2016 at 8:44 PM, Carsten Haitzler 
>>> wrote:
 On Mon, 19 Sep 2016 11:31:58 -0300 Gustavo Sverzut Barbieri
  said:

> Hi all,
>
> Today I did commit support for libproxy in ecore_con's new API,
> Efl.Net.Dialer.Tcp, Efl.Net.Dialer.Http and Efl.Net.Dialer.Websocket
> (implicit from HTTP).

 ummm i just am looking now (i have a lot of catching up to do). can you 
 undo
 the changes to configure.ac and make this a dlopen/dlsym approach? well use
 eina_module. look a the old curl eina_module approach. look at what i did 
 in
 ecore_audio too. in fact i need to look over all the efl net code, but you
 want to use emile for ssl stuff and eina_module for curl too there too (i
 haven't looked yet). there are very good reasons to do all of this.
>>>
>>> I've checked what you did for curl, since I use that and need more symbols.
>>>
>>> my question and concern are just:
>>>  - not being able to compile without libproxy. If we always detect,
>>> should we remove --enable-libproxy from configure.ac?
>>
>> yes. it moves to runtime not compile-time. several reasons:
>>
>> 1. makes compiling simpler. people dont have to find dependencies and those
>> -dev/devel pkgs too. if they add libproxy later after building efl magically
>> the feature works without a rebuild.
>
> No no no, just Never that is about the most evil thing you can do if
> there is no configure check distro's won't know that it should be pulled
> in as a dependency and you will end up with different behavior on
> different machines because one has a completely unrelated package
> installed which also installed the dependency.
>
> Keep the ./configure check, add a --disable-libproxy flag for those that
> don't want to go find it and sure after that dlopen it or whatever. But
> the #1 priority should be making sure that distro packagers don't screw
> it up because after all in a ideal world thats how most people should
> get efl, sure make it easy enough for anyone to compile but don't make
> it easier for distros to shoot there users in the foot by not realising
> theres a extra dependency that probably should be pulled in. Unless of
> course libproxy is not useful on a normal Linux distro and will only
> ever be used in embedded contexts.

Simon, although I do understand your PoV -- packaging -- Raster is
right and is concerned about runtime impact on non-users.

If you link to a library, particularly one that has a huge dep graph
like libproxy, you end pulling too much and impacting everyone... even
if that's not used.

Raster is approaching those as runtime optional dependencies with
manual linking. Currently this is done with libcurl and some other
audio stuff. Once needed they will be dlopen()'ed, if they are found
the feature is enabled, otherwise it will remain working without that
feature.

To solve packaging issues my suggestion is that we should document
these guys and ask the packages to add some "Recommends: libcurl,
libproxy..." instead of "Depends: libcurl, libproxy".


-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

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


[EGIT] [tools/eflete] master 02/03: group_navigator: use gm_part_type_text_get to get part type text

2016-09-20 Thread Andrii Kroitor
rimmed pushed a commit to branch master.

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

commit 6360d2da7e64832cdd64f02367afd59ca406ecd5
Author: Andrii Kroitor 
Date:   Tue Sep 20 17:21:42 2016 +0300

group_navigator: use gm_part_type_text_get to get part type text
---
 src/bin/ui/workspace/group_navigator.c | 79 --
 1 file changed, 19 insertions(+), 60 deletions(-)

diff --git a/src/bin/ui/workspace/group_navigator.c 
b/src/bin/ui/workspace/group_navigator.c
index a8a7e19..4b744bf 100644
--- a/src/bin/ui/workspace/group_navigator.c
+++ b/src/bin/ui/workspace/group_navigator.c
@@ -86,18 +86,18 @@ typedef struct
} popup;
 } Part_List;
 
-static char *part_types[] = {
- N_("Rectangle"),
- N_("Text"),
- N_("Image"),
- N_("Swallow"),
- N_("Textblock"),
- N_("Group"),
- N_("Box"),
- N_("Table"),
- N_("Proxy"),
- N_("Spacer"),
- NULL
+static Edje_Part_Type part_types[] = {
+ EDJE_PART_TYPE_RECTANGLE,
+ EDJE_PART_TYPE_TEXT,
+ EDJE_PART_TYPE_IMAGE,
+ EDJE_PART_TYPE_SWALLOW,
+ EDJE_PART_TYPE_TEXTBLOCK,
+ EDJE_PART_TYPE_GROUP,
+ EDJE_PART_TYPE_BOX,
+ EDJE_PART_TYPE_TABLE,
+ EDJE_PART_TYPE_PROXY,
+ EDJE_PART_TYPE_SPACER,
+ EDJE_PART_TYPE_NONE
 };
 static const char *program_actions[] = {
  N_("None"),
@@ -906,7 +906,6 @@ _popup_add_part_close_cb(void *data,
Popup_Button pb = (Popup_Button)ei;
if (pb != BTN_OK) return;
 
-   Edje_Part_Type type = EDJE_PART_TYPE_NONE;
Part_List *pl = data;
const char *name, *copy_name;
Eina_Stringshare *msg;
@@ -928,46 +927,11 @@ _popup_add_part_close_cb(void *data,
  }
else
  {
-switch (pl->popup.part_type)
-  {
-   case 0:
-  type = EDJE_PART_TYPE_RECTANGLE;
-  break;
-   case 1:
-  type = EDJE_PART_TYPE_TEXT;
-  break;
-   case 2:
-  type = EDJE_PART_TYPE_IMAGE;
-  break;
-   case 3:
-  type = EDJE_PART_TYPE_SWALLOW;
-  break;
-   case 4:
-  type = EDJE_PART_TYPE_TEXTBLOCK;
-  break;
-   case 5:
-  type = EDJE_PART_TYPE_GROUP;
-  break;
-   case 6:
-  type = EDJE_PART_TYPE_BOX;
-  break;
-   case 7:
-  type = EDJE_PART_TYPE_TABLE;
-  break;
-   case 8:
-  type = EDJE_PART_TYPE_PROXY;
-  break;
-   case 9:
-  type = EDJE_PART_TYPE_SPACER;
-  break;
-  }
-assert(type != EDJE_PART_TYPE_NONE);
-
 name = elm_entry_entry_get(pl->popup.entry_name);
 msg = eina_stringshare_printf(_("added new part \"%s\""), name);
 change = change_add(msg);
-CRIT_ON_FAIL(editor_part_add(pl->group->edit_object, change, false, 
true, name, type));
-pl->popup.part_type = 0; /* get that selected stuff down, next type 
RECT again */
+CRIT_ON_FAIL(editor_part_add(pl->group->edit_object, change, false, 
true, name, pl->popup.part_type));
+pl->popup.part_type = EDJE_PART_TYPE_RECTANGLE; /* get that selected 
stuff down, next type RECT again */
  }
 
history_change_add(pl->group->history, change);
@@ -1009,7 +973,6 @@ _part_selected_cb(void *data,
   void *event_info)
 {
Part_List *pl = data;
-   Elm_Genlist_Item *glit;
Combobox_Item *item;
Edje_Part_Type type;
 
@@ -1025,11 +988,7 @@ _part_selected_cb(void *data,
  }
else
  {
-glit = elm_genlist_first_item_get(pl->popup.combobox);
-item = elm_object_item_data_get(glit);
-elm_object_text_set(pl->popup.combobox, item->data);
-pl->popup.part_type = 0;
-
+elm_object_text_set(pl->popup.combobox, 
gm_part_type_text_get(pl->popup.part_type));
 elm_object_disabled_set(pl->popup.combobox, false);
  }
 }
@@ -1121,16 +1080,16 @@ _add_part_content_get(void *data, Evas_Object *popup 
__UNUSED__, Evas_Object **t
COMBOBOX_ADD(item, pl->popup.combobox)
evas_object_smart_callback_add(pl->popup.combobox, 
signals.elm.combobox.item_pressed,
   _combobox_item_pressed_cb, NULL);
-   for (i = 0; part_types[i]; i++)
+   for (i = 0; part_types[i] != EDJE_PART_TYPE_NONE; i++)
  {
 combobox_item = mem_malloc(sizeof(Combobox_Item));
-combobox_item->data = eina_stringshare_add(part_types[i]);
-combobox_item->index = i;
+combobox_item->data = 
eina_stringshare_add(gm_part_type_text_get(part_types[i]));
+combobox_item->index = part_types[i];
 elm_genlist_item_append(pl->popup.combobox, pl->popup.itc,
 combobox_item, NULL,
 ELM_GENLIST_ITEM_NONE, NULL, NULL);
  }
-   elm_object_text_set(pl->popup.combobox, part_types[0]);
+   el

[EGIT] [tools/eflete] master 03/03: group_manager: don't use upper case for part type names

2016-09-20 Thread Andrii Kroitor
rimmed pushed a commit to branch master.

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

commit 96d5053506bb651e2bb8b071c0e1cbf2c416fd90
Author: Andrii Kroitor 
Date:   Tue Sep 20 17:22:40 2016 +0300

group_manager: don't use upper case for part type names
---
 src/bin/project_manager/group_manager.c | 34 -
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/src/bin/project_manager/group_manager.c 
b/src/bin/project_manager/group_manager.c
index 8c3b657..ada111f 100644
--- a/src/bin/project_manager/group_manager.c
+++ b/src/bin/project_manager/group_manager.c
@@ -1117,23 +1117,23 @@ gm_group_data_rename(Project *pro, Group *group, 
Resource* group_data, const cha
  * ref http://docs.enlightenment.org/auto/edje/group__Edje__Object__Part.html
  */
 static char *part_types[] = {
- "NONE",
- "RECTANGLE",
- "TEXT",
- "IMAGE",
- "SWALLOW",
- "TEXTBLOCK",
- "GRADIENT",
- "GROUP",
- "BOX",
- "TABLE",
- "EXTERNAL",
- "PROXY",
- "SPACER",
- "MESH NODE",
- "LIGHT",
- "CAMERA",
- "SNAPSHOT"
+ "None",
+ "Rectangle",
+ "Text",
+ "Image",
+ "Swallow",
+ "Textblock",
+ "Gradient",
+ "Group",
+ "Box",
+ "Table",
+ "External",
+ "Proxy",
+ "Spacer",
+ "Mesh node",
+ "Light",
+ "Camera",
+ "Snapshot"
 };
 static unsigned int part_types_count = 16;
 

-- 




[EGIT] [tools/eflete] master 01/03: group_navigator: show type of copied part

2016-09-20 Thread Andrii Kroitor
rimmed pushed a commit to branch master.

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

commit da80ac35ba3df4253f7359773cc9a9209ad8e4d1
Author: Andrii Kroitor 
Date:   Tue Sep 20 17:07:03 2016 +0300

group_navigator: show type of copied part
---
 src/bin/ui/workspace/group_navigator.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/src/bin/ui/workspace/group_navigator.c 
b/src/bin/ui/workspace/group_navigator.c
index 32f1ad3..a8a7e19 100644
--- a/src/bin/ui/workspace/group_navigator.c
+++ b/src/bin/ui/workspace/group_navigator.c
@@ -1009,16 +1009,29 @@ _part_selected_cb(void *data,
   void *event_info)
 {
Part_List *pl = data;
+   Elm_Genlist_Item *glit;
Combobox_Item *item;
+   Edje_Part_Type type;
 
assert(pl != NULL);
 
item = elm_object_item_data_get(event_info);
pl->popup.copy_part = item->index;
if (item->index != 0)
- elm_object_disabled_set(pl->popup.combobox, true);
+ {
+type = edje_edit_part_type_get(pl->group->edit_object, 
elm_object_text_get(pl->popup.combobox_copy));
+elm_object_text_set(pl->popup.combobox, gm_part_type_text_get(type));
+elm_object_disabled_set(pl->popup.combobox, true);
+ }
else
- elm_object_disabled_set(pl->popup.combobox, false);
+ {
+glit = elm_genlist_first_item_get(pl->popup.combobox);
+item = elm_object_item_data_get(glit);
+elm_object_text_set(pl->popup.combobox, item->data);
+pl->popup.part_type = 0;
+
+elm_object_disabled_set(pl->popup.combobox, false);
+ }
 }
 
 static void

-- 




Re: [E-devel] Efl.Net and libproxy

2016-09-20 Thread Gustavo Sverzut Barbieri
On Tue, Sep 20, 2016 at 1:54 AM, Carsten Haitzler  wrote:
> On Tue, 20 Sep 2016 01:08:48 -0300 Gustavo Sverzut Barbieri
>  said:
>
>> On Mon, Sep 19, 2016 at 8:44 PM, Carsten Haitzler 
>> wrote:
>> > On Mon, 19 Sep 2016 11:31:58 -0300 Gustavo Sverzut Barbieri
>> >  said:
>> >
>> >> Hi all,
>> >>
>> >> Today I did commit support for libproxy in ecore_con's new API,
>> >> Efl.Net.Dialer.Tcp, Efl.Net.Dialer.Http and Efl.Net.Dialer.Websocket
>> >> (implicit from HTTP).
>> >
>> > ummm i just am looking now (i have a lot of catching up to do). can you 
>> > undo
>> > the changes to configure.ac and make this a dlopen/dlsym approach? well use
>> > eina_module. look a the old curl eina_module approach. look at what i did 
>> > in
>> > ecore_audio too. in fact i need to look over all the efl net code, but you
>> > want to use emile for ssl stuff and eina_module for curl too there too (i
>> > haven't looked yet). there are very good reasons to do all of this.
>>
>> I've checked what you did for curl, since I use that and need more symbols.
>>
>> my question and concern are just:
>>  - not being able to compile without libproxy. If we always detect,
>> should we remove --enable-libproxy from configure.ac?
>
> yes. it moves to runtime not compile-time. several reasons:
>
> 1. makes compiling simpler. people dont have to find dependencies and those
> -dev/devel pkgs too. if they add libproxy later after building efl magically
> the feature works without a rebuild.
> 2. speed up startup time with less linking going on for apps especially for
> features they may never use
> 3. saves memory - symbol tables and dirtying private pages to do the symbol
> fixups is expensive. i nuked like 320k or so before 1.18 release of actual
> real memory usage that was dirty pages from rarely used libraries.features.
> it's expensive and so only load in if/when needed to save this cost. this cost
> is private pages PER PROCESS using efl so it multiples and is not a one-off
> cost.
> 4. the idea of isolating such costs into a proxy daemon/process probably is a
> good thing and that saves adding the above cost for any process then needing 
> to
> do proxy pac file parsing etc. and isolates the cost into a single daemon.

I was asking if we should offer a way to not even try runtime detection.


>>  - I ask the above because libproxy is a monster, it will pull in a JS
>> loader, glib, C++... all of that, per process. If using pacrunner
>> (from connman guys) you can just link with libdbus, less bad.
>
> in GENERAL go for a dlopen(eina_module) style approach, BUT if a daemon makes
> sense, then do that.

It's not something that excludes the other. Actually the opposite if
we do the proper way.

 - efl does libproxy dlopen, so doesn't link to that library (simple
API but heavy in dependency)

 - efl could recommend pacrunner's libproxy until we do our own, a big
improvement - zero work

 - efl could provide its own libproxy.so, like
/usr/lib/enlightenment/libproxy.so which would talk to our own server
(which can be built to use system's libproxy, which in turn can be the
official one or pacrunner's drop-in replacement). Our dlopen() can
prefer that version.

 - we can employ LD_PRELOAD tricks in Enlightenment to force loading
our libproxy.so instead of the system. Our daemon must be started
without it, of course :-)


>it makes more sense for us to do our own daemon for efl
> like efreet. dbus is not a good solution for this.

agreed, the API is simple so a pure unix socket can do, protocol is:

send: 
recv: 


as libproxy IS blocking and they explicitly recommend to be called
from a thread, our code will be simple send/recv calls, no other
libraries to pollute our users.



> supporting pacrunner later
> of course is doable, but i would not do this out of the box because pacrunner
> is not everywhere, dbus session buses do not exist when you do things like use
> the console (terminology using fbcon is a major problem when it comes to 
> ethumb
> and was for efreet because no session bus is active thus everything bound to a
> session bus is broken). i will eventually rewrite ethumb features likely in 
> elm
> and drop ethumb because of such issues. also ethumb design is broken for SMACK
> systems so we really do need a "fork off a slave process that is custom for
> your app only" method of working.

you know my opinion on this: this is a nasty approach. The dbus is
simple to achieve if you start that, as you do in E if there was no
session. Or use systemd, it should be doing that from pam_systemd.

SMACK is a different issue and the design of Ethumb came from a time
where we expected all processes to share thumbnails, like efm, your
elm file selector, etc. Private thumbnails as you mentioned started to
gain traction later... application isolation as well, it began with
iOS/Android, linux desktop still is not there.


> for proxies i see the value of a single efl.net.proxy daemon service to serve
> as a proxy handler - send relevan

Re: [E-devel] Efl.Net and libproxy

2016-09-20 Thread Simon Lees


On 09/20/2016 02:24 PM, Carsten Haitzler (The Rasterman) wrote:
> On Tue, 20 Sep 2016 01:08:48 -0300 Gustavo Sverzut Barbieri
>  said:
> 
>> On Mon, Sep 19, 2016 at 8:44 PM, Carsten Haitzler 
>> wrote:
>>> On Mon, 19 Sep 2016 11:31:58 -0300 Gustavo Sverzut Barbieri
>>>  said:
>>>
 Hi all,

 Today I did commit support for libproxy in ecore_con's new API,
 Efl.Net.Dialer.Tcp, Efl.Net.Dialer.Http and Efl.Net.Dialer.Websocket
 (implicit from HTTP).
>>>
>>> ummm i just am looking now (i have a lot of catching up to do). can you undo
>>> the changes to configure.ac and make this a dlopen/dlsym approach? well use
>>> eina_module. look a the old curl eina_module approach. look at what i did in
>>> ecore_audio too. in fact i need to look over all the efl net code, but you
>>> want to use emile for ssl stuff and eina_module for curl too there too (i
>>> haven't looked yet). there are very good reasons to do all of this.
>>
>> I've checked what you did for curl, since I use that and need more symbols.
>>
>> my question and concern are just:
>>  - not being able to compile without libproxy. If we always detect,
>> should we remove --enable-libproxy from configure.ac?
> 
> yes. it moves to runtime not compile-time. several reasons:
> 
> 1. makes compiling simpler. people dont have to find dependencies and those
> -dev/devel pkgs too. if they add libproxy later after building efl magically
> the feature works without a rebuild.

No no no, just Never that is about the most evil thing you can do if
there is no configure check distro's won't know that it should be pulled
in as a dependency and you will end up with different behavior on
different machines because one has a completely unrelated package
installed which also installed the dependency.

Keep the ./configure check, add a --disable-libproxy flag for those that
don't want to go find it and sure after that dlopen it or whatever. But
the #1 priority should be making sure that distro packagers don't screw
it up because after all in a ideal world thats how most people should
get efl, sure make it easy enough for anyone to compile but don't make
it easier for distros to shoot there users in the foot by not realising
theres a extra dependency that probably should be pulled in. Unless of
course libproxy is not useful on a normal Linux distro and will only
ever be used in embedded contexts.

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE LinuxAdeliade Australia, UTC+9:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [EGIT] [core/efl] master 01/02: eina - redo a lot of the static inlines to have better instr cache usage

2016-09-20 Thread The Rasterman
On Tue, 20 Sep 2016 08:27:25 -0300 Gustavo Sverzut Barbieri
 said:

> >  static inline void *
> > @@ -104,12 +101,11 @@ eina_array_foreach(Eina_Array *array, Eina_Each_Cb
> > cb, void *fdata) Eina_Bool ret = EINA_TRUE;
> >
> > EINA_ARRAY_ITER_NEXT(array, i, data, iterator)
> > - if (cb(array, data, fdata) != EINA_TRUE)
> > -   {
> > - ret = EINA_FALSE;
> > - break;
> > -   }
> > -
> > + {
> > +if (cb(array, data, fdata) == EINA_TRUE) continue;
> > +ret = EINA_FALSE;
> > +break;
> > + }
> > return ret;
> >  }
> 
> 
> for these wouldn't EINA_LIKELY/UNLIKELY be more clear on what is the
> expected/preference to the user AND the compiler. What you did is
> likely to work for one compiler but not the other, if branch
> prediction preference is difference.

no. likely/unlikely dont do anything useful since 486 architecture days. back
then the cmp would always predict either true or false (i dont remember) so the
compiler SHOULD adjust the compare so the more likely outcome is what the cpu
will then just blindly run while waiting for the result. its is not true anymore
and these really do nothing useful.

> Also, with clearlinux they use AutoFDO
> (https://gcc.gnu.org/wiki/AutoFDO), likely in future most distros
> should use that, thus this kind of micro-optimization is not that
> helpful.

incorrect. see my mail reply to cedric. i sped up eoid lookup by almost 3x by
doing this. its a valid micro optimization. compilers are not that smart. they
do put the if () content code right where it is in the c, ie right next to the
compare and after it. i checked the asm output ... or well i was reading the
asm output while profiling and noticed this... and the whole 2-3x speedup came
from doing these micro-optimizations based on real code output by a very recent
compiler.

> Given that we already run software we just compiled in the build tree
> we could even integrate autofdo to the build system (like compile -
> benchmark - compile)?

not so easy. but as above. i dropped eoid lookup from ~6-7% to 2.5% of cpu time
just through goto's and moving "rarely accessed paths" out of the way of the
code as the compiler LIERALLY would produce asm like the c code is written.

a_stuff();
if (x) {
  b_stuff();
}
c_stuff();

literally the asm here has

a_stuff asm
cmp x
jne after
b_stuff asm
after:
c_stuff asm

with -O3 -march=native on gcc 6.1

it is totally worth it. TOTALLY.

> > diff --git a/src/lib/eina/eina_inline_hash.x
> > b/src/lib/eina/eina_inline_hash.x index ab87960..114b584 100644
> > --- a/src/lib/eina/eina_inline_hash.x
> > +++ b/src/lib/eina/eina_inline_hash.x
> > @@ -33,11 +33,13 @@ eina_hash_djb2(const char *key, int len)
> > unsigned int hash_num = 5381 ^ eina_seed;
> > const unsigned char *ptr;
> >
> > -   if (!key) return 0;
> > -   for (ptr = (unsigned char *)key; len; ptr++, len--)
> > - hash_num = ((hash_num << 5) + hash_num) ^ *ptr; /* hash * 33 ^ c */
> > -
> > -   return (int)hash_num;
> > +   if (key)
> > + {
> > +for (ptr = (unsigned char *)key; len; ptr++, len--)
> > +  hash_num = ((hash_num << 5) + hash_num) ^ *ptr; /* hash * 33 ^ c
> > */
> > +return (int)hash_num;
> > + }
> > +   return 0;
> >  }
> 
> 
> for these, which are error handling, EINA_UNLIKELY() is much, much
> better to read and doesn't change the whole code because of 1 line.

been there. done that. EINA_UNLIKELY had no effect. see above.

> >  static inline Eina_Bool
> >  eina_lock_new(Eina_Lock *mutex)
> >  {
> [...]
> > +   return _eina_lock_new(mutex, EINA_FALSE);
> >  }
> 
> since you did not had a symbol before, why not just introduce one
> without the "_"?

as per my commit. i was tossing up but then i would have to change the
prototypes so i went for the least intrusive version for now. i was on the
plane 30kft up not sleeping on my laptop... :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


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


Re: [E-devel] [RFC] EFL Multi-seat

2016-09-20 Thread Jean-Philippe André
Hi,

On 17 September 2016 at 06:11, Guilherme Íscaro 
wrote:

> Hey guys, Here's a version 2.
>
> = Changes on Evas =
>
>-
>
>_Evas_Public_Data should contain a hash indexed by seat of focused
>Evas_Objects. From “pd->focused” to “pd->focused[seat]”.
>-
>
>evas_canvas_focus_get() should return the object focused by the default
>seat.
>-
>
>evas_canvas_pointer_canvas_xy_get() Should return the XY from the
>default seat.
>-
>
>evas_canvas_seat_pointer_canvas_xy_get() - Same thing as
>evas_canvas_pointer_canvas_xy_get(), however it returns the XY based
> on the
>seat.
>-
>
>evas_object_focus_set() - his function will be refactored to use
>evas_canvas_object_focus_by_seat_set().
>-
>
>evas_canvas_object_focus_by_seat_set() should be added
>-
>

I would rather not have any new legacy function. All new or existing EO
functions should have an @optional seat object (where relevant).
At the moment it seems Efl.Input.Device can represent a seat, and an input
device should have a seat as a parent. If this design is OK, then let's
keep it that way.

Note that all I did when "creating" Efl.Input.Device was convert
Evas_Device to EO and avoid merging a patch where we introduce a different
struct for Ecore_Device.
Now, if we have device info at ecore level, it will be forwarded to evas
automatically. In theory. Nothing in upstream code actually does this yet :(


>Evas will automatically create Evas_Devices
>-
>
>All functions that handle multi-seat should be implement as non-legacy,
>this is using EO.
>-
>
>For every new Evas_Device creation an event
>(EFL_CANVAS_EVENT_DEVICE_ADD) should be generated containing the new
>Evas_Device.
>-
>
>When a device is removed another event will be generated
>(EFL_CANVAS_EVENT_DEVICE_DEL).
>

I agree that those 2 extra events make sense. Currently CHANGED is
triggered for ADD. A legacy wrapper needs to forward a change on both add
and change.



>-
>
>Every time an object/canvas receives focus a new event will be
>generated. The event
>(EFL_CANVAS_EVENT_DEVICE_FOCUS_IN/OUT)/(EFL_CANVAS_
> EVENT_OBJECT_DEVICE_FOCUS_IN/OUT)
>will contain the device itself that generated the focus event and the
>focused object/canvas.
>-
>
>Add new EO event functions: evas_canvas_event_*(EO *evas, Evas_Device
>*device_that_originated_the_event, ...Event Args….);
>

There shouldn't be any new (legacy or eo) function for that.
Events are not "fed" anymore but simply forged and sent with
efl_event_callback_call. ecore_evas or evas do that.

Legacy C API will simply not support multi-seat (only default seat / NULL).


>-
>
>   All the existing evas_events_*() functions will be refactored to use
>   the new event functions passing NULL as device, this will flag
> that device
>   belongs to the default seat.
>

Yes.


>   -
>
>   Internally EFL will be refactored to replace the old evas_event_*
>   functions and use the new ones.
>

No. As above, we don't call a feed function to feed events to evas.
Instead, we send an event to evas (yes, the Evas * eo object).



> = Changes on Ecore_Evas =
>
>-
>
>Eina_Bool ecore_evas_x11_vnc_server_start(Ecore_Evas *ee, const char
>*addr, int port, Accept_Client_Cb cb, void *cb_data); -> This will
> enable
>vnc server for the ecore_evas x11 module.
>-
>
>The Accept_Client_Cb will have the following signature: typedef
>Eina_Bool (Accept_Client_Cb)(void *data, Ecore_Evas *ee, const char
>*client_addr). This callback should return EINA_TRUE to accept the VNC
>client or EINA_FALSE otherwise.
>-
>
>The struct _Ecore_Evas_Interface_X11 should contain a new function with
>the following signature Eina_Bool _setup_vnc_server() that will create
> the
>vnc server and start listening for clients.
>-
>
>ecore_evas_x11_vnc_server_stop(Ecore_Evas *ee);
>-
>
>Ecore_Evas_x11 will create Efl_Input_Devices for every new user and set
>the emulated seat.
>-
>
>In case of x11 - For every new vnc client an Efl_Input_Device will be
>created and added to the Evas canvas.


>
>
> = Changes on Evas x11 engine =
>
>-
>
>A callback will be created in order to notify the ecore_evas_x11 backend
>with the modified pixels. This will be used to properly draw the VNC
> remote
>screen.
>

So VNC would be used to allow a second client to remotely connect to a
running app on X? Interesting...
Though I believe proper Wayland support for multi-seat is more important
right now :)



>
>
>
> = Changes on Ecore_Wl2 =
>
>-
>
>Implement the _seat_cb_name() function in order to collect the seat
> name.
>-
>
>For every wl_pointer/wl_keyboard/wl_seat it will be create an
>Efl_Input_Device. The wl_pointer and wl_keyboard will have the wl_seat
> as
>parent. After creation of these Efl_Input_Devices an ecore_event will b

[EGIT] [core/efl] master 01/01: eina - eina file map populate fallback to use log int not int... for size

2016-09-20 Thread Carsten Haitzler
raster pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=58d3328d80aec2249b681e0d791e562a2b399c47

commit 58d3328d80aec2249b681e0d791e562a2b399c47
Author: Carsten Haitzler (Rasterman) 
Date:   Tue Sep 20 21:57:47 2016 +0900

eina - eina file map populate fallback to use log int not int... for size

this makes the size match other sizes in eina_file. doesn't affect
linux but i think bsd's get hit.
---
 src/lib/eina/eina_file.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/lib/eina/eina_file.c b/src/lib/eina/eina_file.c
index 994905f..cb29f28 100644
--- a/src/lib/eina/eina_file.c
+++ b/src/lib/eina/eina_file.c
@@ -310,10 +310,10 @@ _eina_file_map_close(Eina_File_Map *map)
 
 #ifndef MAP_POPULATE
 static unsigned int
-_eina_file_map_populate(char *map, unsigned int size, Eina_Bool hugetlb)
+_eina_file_map_populate(char *map, unsigned long int size, Eina_Bool hugetlb)
 {
unsigned int r = 0xDEADBEEF;
-   unsigned int i;
+   unsigned long int i;
unsigned int s;
 
if (size == 0) return 0;

-- 




[EGIT] [tools/eflete] master 01/02: popup: fix image manager call from image_helper

2016-09-20 Thread Andrii Kroitor
rimmed pushed a commit to branch master.

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

commit 773d71a64b7498ba8f9b39f2c7ae2ee4663b4c41
Author: Andrii Kroitor 
Date:   Tue Sep 20 13:59:36 2016 +0300

popup: fix image manager call from image_helper
---
 src/bin/ui/popup.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/bin/ui/popup.c b/src/bin/ui/popup.c
index 6d29eee..7a9bef1 100644
--- a/src/bin/ui/popup.c
+++ b/src/bin/ui/popup.c
@@ -815,12 +815,18 @@ _search_next_gengrid_item_cb(void *data,
 }
 
 static void
+_image_manager_add_job(void *data __UNUSED__)
+{
+   image_manager_add();
+}
+
+static void
 _btn_image_manager_cb(void *data __UNUSED__,
   Evas_Object *obj __UNUSED__,
   void *event_info __UNUSED__)
 {
_helper_dismiss(NULL, helper, NULL, NULL);
-   image_manager_add();
+   ecore_job_add(_image_manager_add_job, NULL);
 }
 
 void

-- 




[EGIT] [tools/eflete] master 02/02: editor: add internal save after changing image border properties

2016-09-20 Thread Andrii Kroitor
rimmed pushed a commit to branch master.

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

commit a82afc769546a255719e22cb4c0b9a3a59681ad6
Author: Andrii Kroitor 
Date:   Tue Sep 20 14:22:38 2016 +0300

editor: add internal save after changing image border properties
---
 src/bin/editor/editor_macro.h  |  3 ++-
 src/bin/editor/editor_states.c | 12 
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/src/bin/editor/editor_macro.h b/src/bin/editor/editor_macro.h
index 48a5ab9..6eb4f6b 100644
--- a/src/bin/editor/editor_macro.h
+++ b/src/bin/editor/editor_macro.h
@@ -341,7 +341,7 @@ editor_state_## FUNC ##_## NUMBER ##_set(Evas_Object 
*edit_object, Change *chang
return true; \
 }
 
-#define EDITOR_STATE_UCHAR(FUNC, ATTRIBUTE) \
+#define EDITOR_STATE_UCHAR(FUNC, ATTRIBUTE, SAVE) \
 Eina_Bool \
 editor_state_## FUNC ##_set(Evas_Object *edit_object, Change *change, 
Eina_Bool merge, Eina_Bool apply, \
 const char *part_name, const char *state_name, 
double state_val, unsigned char new_val) \
@@ -375,6 +375,7 @@ editor_state_## FUNC ##_set(Evas_Object *edit_object, 
Change *change, Eina_Bool
if (apply) \
  { \
CRIT_ON_FAIL(edje_edit_state_## FUNC ##_set(edit_object, part_name, 
state_name, state_val, new_val)); \
+   if (SAVE) CRIT_ON_FAIL(editor_save(edit_object)); \
_editor_project_changed(); \
if (!_editor_signals_blocked) evas_object_smart_callback_call(ap.win, 
SIGNAL_EDITOR_ATTRIBUTE_CHANGED, &attribute); \
  } \
diff --git a/src/bin/editor/editor_states.c b/src/bin/editor/editor_states.c
index b904259..95645d7 100644
--- a/src/bin/editor/editor_states.c
+++ b/src/bin/editor/editor_states.c
@@ -397,6 +397,7 @@ editor_state_image_border_left_set(Evas_Object 
*edit_object, Change *change, Ein
if (apply)
  {
 CRIT_ON_FAIL(edje_edit_state_image_border_set(edit_object, part_name, 
state_name, state_val, n4, o5, o6, o7));
+CRIT_ON_FAIL(editor_save(edit_object));
 _editor_project_changed();
 if (!_editor_signals_blocked) evas_object_smart_callback_call(ap.win, 
SIGNAL_EDITOR_ATTRIBUTE_CHANGED, &attribute);
  }
@@ -437,6 +438,7 @@ editor_state_image_border_right_set(Evas_Object 
*edit_object, Change *change, Ei
if (apply)
  {
 CRIT_ON_FAIL(edje_edit_state_image_border_set(edit_object, part_name, 
state_name, state_val, o4, n5, o6, o7));
+CRIT_ON_FAIL(editor_save(edit_object));
 _editor_project_changed();
 if (!_editor_signals_blocked) evas_object_smart_callback_call(ap.win, 
SIGNAL_EDITOR_ATTRIBUTE_CHANGED, &attribute);
  }
@@ -477,6 +479,7 @@ editor_state_image_border_top_set(Evas_Object *edit_object, 
Change *change, Eina
if (apply)
  {
 CRIT_ON_FAIL(edje_edit_state_image_border_set(edit_object, part_name, 
state_name, state_val, o4, o5, n6, o7));
+CRIT_ON_FAIL(editor_save(edit_object));
 _editor_project_changed();
 if (!_editor_signals_blocked) evas_object_smart_callback_call(ap.win, 
SIGNAL_EDITOR_ATTRIBUTE_CHANGED, &attribute);
  }
@@ -517,6 +520,7 @@ editor_state_image_border_bottom_set(Evas_Object 
*edit_object, Change *change, E
if (apply)
  {
 CRIT_ON_FAIL(edje_edit_state_image_border_set(edit_object, part_name, 
state_name, state_val, o4, o5, o6, n7));
+CRIT_ON_FAIL(editor_save(edit_object));
 _editor_project_changed();
 if (!_editor_signals_blocked) evas_object_smart_callback_call(ap.win, 
SIGNAL_EDITOR_ATTRIBUTE_CHANGED, &attribute);
  }
@@ -525,10 +529,10 @@ editor_state_image_border_bottom_set(Evas_Object 
*edit_object, Change *change, E
 
 /**/
 
-EDITOR_STATE_UCHAR(image_border_fill, ATTRIBUTE_STATE_IMAGE_BORDER_FILL)
-EDITOR_STATE_UCHAR(fill_type, ATTRIBUTE_STATE_FILL_TYPE)
-EDITOR_STATE_UCHAR(aspect_pref, ATTRIBUTE_STATE_ASPECT_PREF)
-EDITOR_STATE_UCHAR(table_homogeneous, ATTRIBUTE_STATE_TABLE_HOMOGENEOUS)
+EDITOR_STATE_UCHAR(image_border_fill, ATTRIBUTE_STATE_IMAGE_BORDER_FILL, true)
+EDITOR_STATE_UCHAR(fill_type, ATTRIBUTE_STATE_FILL_TYPE, false)
+EDITOR_STATE_UCHAR(aspect_pref, ATTRIBUTE_STATE_ASPECT_PREF, false)
+EDITOR_STATE_UCHAR(table_homogeneous, ATTRIBUTE_STATE_TABLE_HOMOGENEOUS, false)
 
 EDITOR_STATE_INT_SAVE(container_padding_x, ATTRIBUTE_STATE_CONTAINER_PADING_X)
 EDITOR_STATE_INT_SAVE(container_padding_y, ATTRIBUTE_STATE_CONTAINER_PADING_Y)

-- 




Re: [E-devel] [EGIT] [core/efl] master 01/02: eina - redo a lot of the static inlines to have better instr cache usage

2016-09-20 Thread Gustavo Sverzut Barbieri
>  static inline void *
> @@ -104,12 +101,11 @@ eina_array_foreach(Eina_Array *array, Eina_Each_Cb cb, 
> void *fdata)
> Eina_Bool ret = EINA_TRUE;
>
> EINA_ARRAY_ITER_NEXT(array, i, data, iterator)
> - if (cb(array, data, fdata) != EINA_TRUE)
> -   {
> - ret = EINA_FALSE;
> - break;
> -   }
> -
> + {
> +if (cb(array, data, fdata) == EINA_TRUE) continue;
> +ret = EINA_FALSE;
> +break;
> + }
> return ret;
>  }


for these wouldn't EINA_LIKELY/UNLIKELY be more clear on what is the
expected/preference to the user AND the compiler. What you did is
likely to work for one compiler but not the other, if branch
prediction preference is difference.

Also, with clearlinux they use AutoFDO
(https://gcc.gnu.org/wiki/AutoFDO), likely in future most distros
should use that, thus this kind of micro-optimization is not that
helpful.

Given that we already run software we just compiled in the build tree
we could even integrate autofdo to the build system (like compile -
benchmark - compile)?


>
> diff --git a/src/lib/eina/eina_inline_hash.x b/src/lib/eina/eina_inline_hash.x
> index ab87960..114b584 100644
> --- a/src/lib/eina/eina_inline_hash.x
> +++ b/src/lib/eina/eina_inline_hash.x
> @@ -33,11 +33,13 @@ eina_hash_djb2(const char *key, int len)
> unsigned int hash_num = 5381 ^ eina_seed;
> const unsigned char *ptr;
>
> -   if (!key) return 0;
> -   for (ptr = (unsigned char *)key; len; ptr++, len--)
> - hash_num = ((hash_num << 5) + hash_num) ^ *ptr; /* hash * 33 ^ c */
> -
> -   return (int)hash_num;
> +   if (key)
> + {
> +for (ptr = (unsigned char *)key; len; ptr++, len--)
> +  hash_num = ((hash_num << 5) + hash_num) ^ *ptr; /* hash * 33 ^ c */
> +return (int)hash_num;
> + }
> +   return 0;
>  }


for these, which are error handling, EINA_UNLIKELY() is much, much
better to read and doesn't change the whole code because of 1 line.


>  static inline Eina_Bool
>  eina_lock_new(Eina_Lock *mutex)
>  {
[...]
> +   return _eina_lock_new(mutex, EINA_FALSE);
>  }

since you did not had a symbol before, why not just introduce one
without the "_"?


-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

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


[EGIT] [apps/epour] master 02/02: Fix tooltips for torrents without metadata

2016-09-20 Thread Kai Huuhko
kuuko pushed a commit to branch master.

http://git.enlightenment.org/apps/epour.git/commit/?id=e20d6c3788ef2361914517cddccd2cc7dffd9de6

commit e20d6c3788ef2361914517cddccd2cc7dffd9de6
Author: Kai Huuhko 
Date:   Tue Sep 20 11:51:07 2016 +0300

Fix tooltips for torrents without metadata
---
 epour/gui/Widgets.py  | 44 ++--
 epour/gui/__init__.py | 15 ++-
 2 files changed, 28 insertions(+), 31 deletions(-)

diff --git a/epour/gui/Widgets.py b/epour/gui/Widgets.py
index 9e1dab9..5c96ebe 100644
--- a/epour/gui/Widgets.py
+++ b/epour/gui/Widgets.py
@@ -170,42 +170,38 @@ class BlockGraph(Grid):
 (0, 255, 0, 255)
 )
 
-def __init__(self, parent, pieces, num_complete_pieces=0, *args, **kwargs):
+def __init__(self, parent, pieces, num_completed_pieces=0, *args, 
**kwargs):
 
-self.num_complete_pieces = num_complete_pieces
+self.num_completed_pieces = num_completed_pieces
+self.pieces = pieces
 
-self._blocks = None
-self._block_size = None
 self.rects = []
 
 super(self.__class__, self).__init__(parent, *args, **kwargs)
 
-self.pieces = pieces
-self.num_total_pieces = len(pieces)
-
 self.pack_rects()
 
-def block_size_get(self):
-if self._block_size is not None:
-return self._block_size
+@property
+def num_total_pieces(self):
+return len(self.pieces)
 
+@property
+def block_size(self):
 width, height = self.size
 num_pieces = self.num_total_pieces
 grid_size = width * height
 block_size = \
 num_pieces//grid_size + bool(num_pieces % grid_size)
 
-self._block_size = block_size
 return block_size
 
-block_size = property(block_size_get)
-
-def blocks_get(self):
-if self._blocks is not None:
-return self._blocks
-
+@property
+def blocks(self):
 blocks = []
 
+if self.block_size == 0:
+raise ValueError("Block size 0")
+
 for block in chunker(self.pieces, self.block_size):
 if all(block):
 blocks.append(2)
@@ -214,12 +210,11 @@ class BlockGraph(Grid):
 else:
 blocks.append(0)
 
-self._blocks = blocks
 return blocks
 
-blocks = property(blocks_get)
-
 def pack_rects(self):
+if self.num_total_pieces == 0:
+return
 blocks = self.blocks
 width, height = self.size
 len_blocks = len(blocks)
@@ -244,10 +239,15 @@ class BlockGraph(Grid):
 rect.show()
 p += 1
 
-def update(self, pieces):
+def update(self, pieces, num_pieces):
+self.pieces = pieces
+if pieces and not self.rects:
+self.pack_rects()
+elif self.num_completed_pieces == num_pieces:
+return
+self.num_completed_pieces = num_pieces
 width, height = self.size
 old_blocks = self.blocks
-self.pieces = pieces
 self._blocks = None
 new_blocks = self.blocks
 row = 0
diff --git a/epour/gui/__init__.py b/epour/gui/__init__.py
index e14532c..a060bbf 100644
--- a/epour/gui/__init__.py
+++ b/epour/gui/__init__.py
@@ -260,10 +260,12 @@ class MainInterface(object):
 if info_hash not in self.torrentitems:
 return
 
-self.torrentitems[info_hash].fields_update(
+item = self.torrentitems[info_hash]
+
+item.fields_update(
 "*", ELM_GENLIST_ITEM_FIELD_TEXT
 )
-self.torrentitems[info_hash].fields_update(
+item.fields_update(
 "elm.swallow.progress", ELM_GENLIST_ITEM_FIELD_CONTENT
 )
 
@@ -714,9 +716,6 @@ class TorrentTooltip(Table):
 flags = lt.status_flags_t.query_pieces
 status = handle.status(flags)
 
-# if not s.has_metadata:
-# return
-
 Table.__init__(self, parent, size_hint_weight=EXPAND_BOTH)
 
 value_labels = []
@@ -777,9 +776,7 @@ class TorrentTooltip(Table):
 v = conv(v)
 l.text = str(v)
 
-num_pieces = s.num_pieces
-if g.num_complete_pieces != num_pieces:
-g.update(s.pieces)
-g.num_complete_pieces = num_pieces
+if s.has_metadata:
+g.update(s.pieces, s.num_pieces)
 
 return True

-- 




[EGIT] [apps/epour] master 01/02: Add icon sizes better suited for toolbar

2016-09-20 Thread Kai Huuhko
kuuko pushed a commit to branch master.

http://git.enlightenment.org/apps/epour.git/commit/?id=50e60e6311d1295e58df37d6c0708277a6d2a0fc

commit 50e60e6311d1295e58df37d6c0708277a6d2a0fc
Author: Kai Huuhko 
Date:   Tue Sep 20 11:49:14 2016 +0300

Add icon sizes better suited for toolbar
---
 data/icons/16x16/actions/session-pause.png| Bin 368 -> 0 bytes
 data/icons/16x16/actions/session-resume.png   | Bin 423 -> 0 bytes
 data/icons/16x16/actions/toolbar-new.png  | Bin 465 -> 0 bytes
 data/icons/16x16/actions/toolbar-quit.png | Bin 615 -> 0 bytes
 data/icons/16x16/actions/toolbar-settings.png | Bin 627 -> 0 bytes
 data/icons/32x32/actions/session-pause.png| Bin 0 -> 378 bytes
 data/icons/32x32/actions/session-resume.png   | Bin 0 -> 473 bytes
 data/icons/32x32/actions/toolbar-new.png  | Bin 0 -> 569 bytes
 data/icons/32x32/actions/toolbar-quit.png | Bin 0 -> 969 bytes
 data/icons/32x32/actions/toolbar-settings.png | Bin 0 -> 994 bytes
 data/icons/48x48/actions/session-pause.png| Bin 0 -> 392 bytes
 data/icons/48x48/actions/session-resume.png   | Bin 0 -> 544 bytes
 data/icons/48x48/actions/toolbar-new.png  | Bin 0 -> 723 bytes
 data/icons/48x48/actions/toolbar-quit.png | Bin 0 -> 1389 bytes
 data/icons/48x48/actions/toolbar-settings.png | Bin 0 -> 1410 bytes
 data/icons/64x64/actions/session-pause.png| Bin 0 -> 403 bytes
 data/icons/64x64/actions/session-resume.png   | Bin 0 -> 631 bytes
 data/icons/64x64/actions/toolbar-new.png  | Bin 0 -> 871 bytes
 data/icons/64x64/actions/toolbar-quit.png | Bin 0 -> 1695 bytes
 data/icons/64x64/actions/toolbar-settings.png | Bin 0 -> 1809 bytes
 20 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/data/icons/16x16/actions/session-pause.png 
b/data/icons/16x16/actions/session-pause.png
deleted file mode 100644
index 66f0fc2..000
Binary files a/data/icons/16x16/actions/session-pause.png and /dev/null differ
diff --git a/data/icons/16x16/actions/session-resume.png 
b/data/icons/16x16/actions/session-resume.png
deleted file mode 100644
index db9f666..000
Binary files a/data/icons/16x16/actions/session-resume.png and /dev/null differ
diff --git a/data/icons/16x16/actions/toolbar-new.png 
b/data/icons/16x16/actions/toolbar-new.png
deleted file mode 100644
index 5dac0a9..000
Binary files a/data/icons/16x16/actions/toolbar-new.png and /dev/null differ
diff --git a/data/icons/16x16/actions/toolbar-quit.png 
b/data/icons/16x16/actions/toolbar-quit.png
deleted file mode 100644
index 7988d8f..000
Binary files a/data/icons/16x16/actions/toolbar-quit.png and /dev/null differ
diff --git a/data/icons/16x16/actions/toolbar-settings.png 
b/data/icons/16x16/actions/toolbar-settings.png
deleted file mode 100644
index d4c073f..000
Binary files a/data/icons/16x16/actions/toolbar-settings.png and /dev/null 
differ
diff --git a/data/icons/32x32/actions/session-pause.png 
b/data/icons/32x32/actions/session-pause.png
new file mode 100644
index 000..368f5cd
Binary files /dev/null and b/data/icons/32x32/actions/session-pause.png differ
diff --git a/data/icons/32x32/actions/session-resume.png 
b/data/icons/32x32/actions/session-resume.png
new file mode 100644
index 000..839e3f3
Binary files /dev/null and b/data/icons/32x32/actions/session-resume.png differ
diff --git a/data/icons/32x32/actions/toolbar-new.png 
b/data/icons/32x32/actions/toolbar-new.png
new file mode 100644
index 000..3963758
Binary files /dev/null and b/data/icons/32x32/actions/toolbar-new.png differ
diff --git a/data/icons/32x32/actions/toolbar-quit.png 
b/data/icons/32x32/actions/toolbar-quit.png
new file mode 100644
index 000..377fcd3
Binary files /dev/null and b/data/icons/32x32/actions/toolbar-quit.png differ
diff --git a/data/icons/32x32/actions/toolbar-settings.png 
b/data/icons/32x32/actions/toolbar-settings.png
new file mode 100644
index 000..063c8fa
Binary files /dev/null and b/data/icons/32x32/actions/toolbar-settings.png 
differ
diff --git a/data/icons/48x48/actions/session-pause.png 
b/data/icons/48x48/actions/session-pause.png
new file mode 100644
index 000..67f4b91
Binary files /dev/null and b/data/icons/48x48/actions/session-pause.png differ
diff --git a/data/icons/48x48/actions/session-resume.png 
b/data/icons/48x48/actions/session-resume.png
new file mode 100644
index 000..df1a9e5
Binary files /dev/null and b/data/icons/48x48/actions/session-resume.png differ
diff --git a/data/icons/48x48/actions/toolbar-new.png 
b/data/icons/48x48/actions/toolbar-new.png
new file mode 100644
index 000..758be54
Binary files /dev/null and b/data/icons/48x48/actions/toolbar-new.png differ
diff --git a/data/icons/48x48/actions/toolbar-quit.png 
b/data/icons/48x48/actions/toolbar-quit.png
new file mode 100644
index 000..49b8a65
Binary files /dev/null and b/data/icons/48x48/actions/toolbar-quit.png differ
diff --git a/data/icons/48x48/actions/toolbar-settings.png 
b/data/icons/48x48/actions/toolbar-settings.png
new file

Re: [E-devel] [EGIT] [core/efl] master 01/01: eina/ecore: allow threads to be canceled, use in ecore_con.

2016-09-20 Thread Gustavo Sverzut Barbieri
On Tue, Sep 20, 2016 at 5:51 AM, Jean-Philippe André  wrote:
> Hi Gustavo,
>
> On 14 September 2016 at 13:55, Gustavo Sverzut Barbieri 
> wrote:
>
>> HEADS UP -- BINDINGS:
>>
>> If you wish to expose the new "cancellable" property, or cope with
>> naughty users or 3rd party deps that may call
>> pthread_setcancelstate(PTHREAD_CANCEL_ENABLE), please register your
>> cleanup functions with:
>>
>>EINA_THREAD_CLEANUP_PUSH(cb, ctx); // will call cb() on
>> pthread_cancel()/ecore_thread_cancel()/eina_thread_cancel()
>>call_user();
>>EINA_THREAD_CLEANUP_POP(EINA_TRUE); // will call cb() on clean exit
>>
>> If different functions are desired:
>>
>>EINA_THREAD_CLEANUP_PUSH(cb, ctx); // will call cb() on
>> pthread_cancel()/ecore_thread_cancel()/eina_thread_cancel()
>>call_user();
>>EINA_THREAD_CLEANUP_POP(EINA_FALSE); // will NOT call cb() on clean
>> exit
>>another_cb(ctx);
>>
>> This is recommended if you expose ecore_thread to your users. If you
>> don't, then you do not need to do anything.
>
>
> pthread_cancel did (does?) not exist on Android, by design choice. bionic
> isn't posix in that regard.
> One way or another, I remember that using cancel is actually quite hard,
> because you need to be very careful about the cleanup.
>
> So I wonder if adding cancel like pthread here is the best choice?
> Note that I understand the need and don't have any good alternative :)

Hi jpeg, thanks for letting me know.

When we port to bionic we should then take one choice:

 - let the thread hang there for a while, the new code I'm doing based
on this concept shouldn't break, it will just consume few more
resources for a while. (== #ifdef)

 - use pthread_kill() with an unused signal and use a signal
handler... this can be a full wrapper like the one in videolan.org, or
just to generate EINTR like I proposed in my first discussion.




-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

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


[EGIT] [core/efl] master 01/01: tests: ecore: switch from fprintf to ck_asser_msg macro for custom error message

2016-09-20 Thread Stefan Schmidt
stefan pushed a commit to branch master.

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

commit a6d3c0d0fdd422b377004d45f5f246c5da572fa9
Author: Stefan Schmidt 
Date:   Tue Sep 20 12:43:29 2016 +0200

tests: ecore: switch from fprintf to ck_asser_msg macro for custom error 
message

The ck_assert_msg macro can do this for us already in a failed case.
---
 src/tests/ecore/ecore_test_timer.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/tests/ecore/ecore_test_timer.c 
b/src/tests/ecore/ecore_test_timer.c
index fe802bc..63cb533 100644
--- a/src/tests/ecore/ecore_test_timer.c
+++ b/src/tests/ecore/ecore_test_timer.c
@@ -183,8 +183,7 @@ _ecore_promise_quit(void *data, const Efl_Event *ev)
double *start = success->value;
double delta = ecore_loop_time_get() - *start;
 
-   fprintf(stderr, "Ecore promise timeout took %f (should be <= 0.02)\n", 
delta - 0.2);
-   fail_if(delta - 0.2 > 0.02);
+   ck_assert_msg(delta - 0.2 <= 0.02, "Ecore promise timeout took %f (should 
be <= 0.02)\n", delta - 0.2);
 
*bob = EINA_TRUE;
ecore_main_loop_quit();

-- 




Re: [E-devel] [EGIT] [core/efl] master 01/01: tests: ecore: relax the timing precision for the promise timeout test

2016-09-20 Thread Stefan Schmidt
Hello.

On 19/09/16 15:31, Tom Hacohen wrote:
> On 19/09/16 14:01, Stefan Schmidt wrote:
>> Hello.
>>
>> On 19/09/16 14:18, Tom Hacohen wrote:
>>> On 19/09/16 13:08, Stefan Schmidt wrote:
 stefan pushed a commit to branch master.

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

 commit c25d4e8325b428122439860f9d49dd25a4b4b66d
 Author: Stefan Schmidt 
 Date:   Mon Sep 19 14:01:19 2016 +0200

 tests: ecore: relax the timing precision for the promise timeout test

 This test has been failing on Jenkins again and again. After adding 
 the debug
 a while ago it now shows that the value is between 0.01 and 0.02 in 
 all cases
 I have seen. Relaxing the timeout here a bit to make it pass in 
 situation where
 our CI is under load.
 ---
  src/tests/ecore/ecore_test_timer.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/src/tests/ecore/ecore_test_timer.c 
 b/src/tests/ecore/ecore_test_timer.c
 index c7547e4..f3b277b 100644
 --- a/src/tests/ecore/ecore_test_timer.c
 +++ b/src/tests/ecore/ecore_test_timer.c
 @@ -183,8 +183,8 @@ _ecore_promise_quit(void *data, const Efl_Event *ev)
 double *start = success->value;
 double delta = ecore_loop_time_get() - *start;

 -   fprintf(stderr, "Ecore promise timeout took %f (should be <= 0.01)\n", 
 delta - 0.2);
 -   fail_if(delta - 0.2 > 0.01);
 +   fprintf(stderr, "Ecore promise timeout took %f (should be <= 0.02)\n", 
 delta - 0.2);
 +   fail_if(delta - 0.2 > 0.02);

 *bob = EINA_TRUE;
 ecore_main_loop_quit();

>>>
>>>
>>> Why is there an fprintf there? We don't do it in any other tests. That
>>> text should be either removed or moved to a comment. No?
>>
>> I already added it before this commit. For the exact reason to get some
>> debug information while this runs on Jenkins (where the problem happens).
>>
>> I left it in to verify that all works as expect for a while and after
>> that it can go.
>
> You have ck_assert_int_le() (or something like that) for that. It will
> print the values when it fails.
>
> for example:
>
> ck_assert_int_le(delta - 0.2, 0.02);

This would not work as ck_assert_int_* deals with signed integers and 
our values are double here.

I switched to ck_assert_msg though which combines the failure handling 
as well as messaging printing in the failure case.

regards
Stefan Schmidt

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


[EGIT] [tools/eflete] master 01/01: UI: change property caption item.

2016-09-20 Thread Mykyta Biliavskyi
rimmed pushed a commit to branch master.

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

commit 0a268d6ec2cb33edd129a87fd0ec14d49a5e579f
Author: Mykyta Biliavskyi 
Date:   Tue Sep 20 12:09:07 2016 +0300

UI: change property caption item.

From now: expanded style use arrow up, and collapsed use arrow down.
---
 .../tizen/images/Group navigator/view_arrow_up_nor.png  | Bin 0 -> 17287 bytes
 data/themes/tizen/widgets/genlist_property.edc  |   6 +++---
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/data/themes/tizen/images/Group navigator/view_arrow_up_nor.png 
b/data/themes/tizen/images/Group navigator/view_arrow_up_nor.png
new file mode 100644
index 000..07a35aa
Binary files /dev/null and b/data/themes/tizen/images/Group 
navigator/view_arrow_up_nor.png differ
diff --git a/data/themes/tizen/widgets/genlist_property.edc 
b/data/themes/tizen/widgets/genlist_property.edc
index 415e03a..2c7b088 100644
--- a/data/themes/tizen/widgets/genlist_property.edc
+++ b/data/themes/tizen/widgets/genlist_property.edc
@@ -95,7 +95,7 @@ group { name: "elm/genlist/tree/caption/property";
   item: "selectraise" "on";
}
images {
-  image: "Group navigator/view_arrow_right_nor.png" COMP;
+  image: "Group navigator/view_arrow_up_nor.png" COMP;
   image: "Group navigator/view_arrow_down_nor.png" COMP;
}
 
@@ -140,7 +140,7 @@ group { name: "elm/genlist/tree/caption/property";
  description { state: "default" 0.0;
 align: 0.0 0.5;
 max: 9 9;
-image.normal: "Group navigator/view_arrow_right_nor.png";
+image.normal: "Group navigator/view_arrow_down_nor.png";
 rel1 {
relative: 1.33 0.0;
offset: 20 0;
@@ -149,7 +149,7 @@ group { name: "elm/genlist/tree/caption/property";
  }
  description { state: "selected" 0.0;
 inherit: "default" 0.00;
-image.normal: "Group navigator/view_arrow_down_nor.png";
+image.normal: "Group navigator/view_arrow_up_nor.png";
  }
   }
   part { name: "disclip";

-- 




[EGIT] [core/efl] master 01/01: eldbus: fix null value usage

2016-09-20 Thread Ji-Youn Park
jypark pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=13bd4242eca76560fbefd690934bc63a5fbd28c3

commit 13bd4242eca76560fbefd690934bc63a5fbd28c3
Author: Ji-Youn Park 
Date:   Tue Sep 20 18:10:32 2016 +0830

eldbus: fix null value usage
---
 src/lib/eldbus/eldbus_message.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/lib/eldbus/eldbus_message.c b/src/lib/eldbus/eldbus_message.c
index 2464d0e..91f69b2 100644
--- a/src/lib/eldbus/eldbus_message.c
+++ b/src/lib/eldbus/eldbus_message.c
@@ -467,6 +467,7 @@ _eldbus_message_arguments_vappend(Eldbus_Message *msg, 
const char *signature, va
EINA_FALSE);
 
iter = eldbus_message_iter_get(msg);
+   EINA_SAFETY_ON_NULL_RETURN_VAL(iter, EINA_FALSE);
EINA_SAFETY_ON_FALSE_RETURN_VAL(iter->writable, EINA_FALSE);
 
dbus_signature_iter_init(&signature_iter, signature);

-- 




[EGIT] [tools/eflete] master 01/01: workspace: disable history in demo mode

2016-09-20 Thread Andrii Kroitor
rimmed pushed a commit to branch master.

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

commit f77f32a06566d1c008775732ae2a96df288e297c
Author: Andrii Kroitor 
Date:   Tue Sep 20 11:39:36 2016 +0300

workspace: disable history in demo mode
---
 src/bin/ui/workspace/workspace.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/bin/ui/workspace/workspace.c b/src/bin/ui/workspace/workspace.c
index a644ce4..dd14942 100644
--- a/src/bin/ui/workspace/workspace.c
+++ b/src/bin/ui/workspace/workspace.c
@@ -1184,6 +1184,7 @@ _mode_cb(void *data,
  //elm_object_part_content_set(wd->panes, "right", wd->group_navi);
  evas_object_show(wd->group_navi);
  _zoom_controls_disabled_set(wd, false);
+ elm_object_disabled_set(wd->toolbar.history, false);
  evas_object_smart_callback_call(ap.win, SIGNAL_GROUP_CHANGED, 
wd->group);
 
  area = &wd->normal;
@@ -1203,6 +1204,7 @@ _mode_cb(void *data,
  demo_group_demo_update(wd->demo_navi);
 
  _zoom_controls_disabled_set(wd, true);
+ elm_object_disabled_set(wd->toolbar.history, true);
  evas_object_smart_callback_call(ap.win, SIGNAL_DIFFERENT_TAB_CLICKED, 
NULL);
 
  area = &wd->demo;

-- 




Re: [E-devel] [EGIT] [core/efl] master 01/01: eina/ecore: allow threads to be canceled, use in ecore_con.

2016-09-20 Thread Jean-Philippe André
Hi Gustavo,

On 14 September 2016 at 13:55, Gustavo Sverzut Barbieri 
wrote:

> HEADS UP -- BINDINGS:
>
> If you wish to expose the new "cancellable" property, or cope with
> naughty users or 3rd party deps that may call
> pthread_setcancelstate(PTHREAD_CANCEL_ENABLE), please register your
> cleanup functions with:
>
>EINA_THREAD_CLEANUP_PUSH(cb, ctx); // will call cb() on
> pthread_cancel()/ecore_thread_cancel()/eina_thread_cancel()
>call_user();
>EINA_THREAD_CLEANUP_POP(EINA_TRUE); // will call cb() on clean exit
>
> If different functions are desired:
>
>EINA_THREAD_CLEANUP_PUSH(cb, ctx); // will call cb() on
> pthread_cancel()/ecore_thread_cancel()/eina_thread_cancel()
>call_user();
>EINA_THREAD_CLEANUP_POP(EINA_FALSE); // will NOT call cb() on clean
> exit
>another_cb(ctx);
>
> This is recommended if you expose ecore_thread to your users. If you
> don't, then you do not need to do anything.


pthread_cancel did (does?) not exist on Android, by design choice. bionic
isn't posix in that regard.
One way or another, I remember that using cancel is actually quite hard,
because you need to be very careful about the cleanup.

So I wonder if adding cancel like pthread here is the best choice?
Note that I understand the need and don't have any good alternative :)



> On Wed, Sep 14, 2016 at 1:47 AM, Gustavo Sverzut Barbieri
>  wrote:
> > barbieri pushed a commit to branch master.
> >
> > http://git.enlightenment.org/core/efl.git/commit/?id=
> 960e1a1d168ba0044544ca22b05cbf505941f150
> >
> > commit 960e1a1d168ba0044544ca22b05cbf505941f150
> > Author: Gustavo Sverzut Barbieri 
> > Date:   Wed Sep 14 01:38:58 2016 -0300
> >
> > eina/ecore: allow threads to be canceled, use in ecore_con.
> >
> > As discussed in the mailing list, many people will use worker threads
> > to execute blocking syscalls and mandating ecore_thread_check() for
> > voluntary preemption reduces the ecore_thread usefulness a lot.
> >
> > A clear example is ecore_con usage of connect() and getaddrinfo() in
> > threads. If the connect timeout expires, the thread will be
> cancelled,
> > but it was blocked on syscalls and they will hang around for long
> > time. If the application exits, ecore will print an error saying it
> > can SEGV.
> >
> > Then enable access to pthread_setcancelstate(PTHREAD_CANCEL_ENABLE)
> > via eina_thread_cancellable_set(EINA_TRUE), to pthread_cancel() via
> > eina_thread_cancel(), to pthread_cleanup_push()/
> pthread_cleanup_pop()
> > via EINA_THREAD_CLEANUP_PUSH()/EINA_THREAD_CLEANUP_POP() and so on.
> >
> > Ecore threads will enforce non-cancellable threads on its own code,
> > but the user may decide to enable that and allow cancellation, that's
> > not an issue since ecore_thread now plays well and use cleanup
> > functions.
> >
> > Ecore con connect/resolve make use of that and enable cancellable
> > state, efl_net_dialer_tcp benefits a lot from that.
> >
> > A good comparison of the benefit is to run:
> >
> >./src/examples/ecore/efl_io_copier_example tcp://google.com:1234
> :stdout:
> >
> > before and after. It will timeout after 30s and with this patch the
> > thread is gone, no ecore error is printed about possible SEGV.
> > ---
> >  src/lib/ecore/Ecore_Common.h  |  12 +++
> >  src/lib/ecore/ecore_thread.c  | 108 +++--
> >  src/lib/ecore_con/ecore_con.c |  41 +---
> >  src/lib/eina/Eina.h   |   2 +-
> >  src/lib/eina/eina_thread.c|  32 ++
> >  src/lib/eina/eina_thread.h| 219 ++
> 
> >  6 files changed, 373 insertions(+), 41 deletions(-)
> >
> > diff --git a/src/lib/ecore/Ecore_Common.h b/src/lib/ecore/Ecore_Common.h
> > index 5404438..22da9ab 100644
> > --- a/src/lib/ecore/Ecore_Common.h
> > +++ b/src/lib/ecore/Ecore_Common.h
> > @@ -1794,6 +1794,17 @@ EAPI Ecore_Thread 
> > *ecore_thread_feedback_run(Ecore_Thread_Cb
> func_heavy, Ecore_T
> >   * ecore_thread_reschedule().
> >   * @li The function is prepared to leave early by checking if
> >   * ecore_thread_check() returns @c EINA_TRUE.
> > +
> > + * @li The function marks the thread as cancellable using
> > + * eina_thread_cancellable_set(), allowing the thread to be terminated
> > + * at explicit cancellation points defined with
> > + * eina_thread_cancel_checkpoint() or with syscalls mentioned at
> > + * man:pthreads(7). This allows blocking operations such as network or
> > + * disk access to be stopped without polling
> > + * ecore_thread_check(). Note that a cancelled thread may leak
> > + * resources if no cleanup function is registered with
> > + * EINA_THREAD_CLEANUP_PUSH(). Consider running such code using
> > + * eina_thread_cancellable_run().
> >   *
> >   * The user function can cancel itself by calling
> ecore_thread_cancel(), but
> >   * it should always use the ::Ecore_Thread handle passed to it and never
> > @@ -1804,6 +1815,7 @@ EAPI Ecore_

Re: [E-devel] [EGIT] [core/efl] master 01/01: tests: ecore: relax the timing precision for the promise timeout test

2016-09-20 Thread Tom Hacohen
On 20/09/16 00:30, Carsten Haitzler (The Rasterman) wrote:
> On Mon, 19 Sep 2016 13:18:47 +0100 Tom Hacohen  said:
>
>> On 19/09/16 13:08, Stefan Schmidt wrote:
>>> stefan pushed a commit to branch master.
>>>
>>> http://git.enlightenment.org/core/efl.git/commit/?id=c25d4e8325b428122439860f9d49dd25a4b4b66d
>>>
>>> commit c25d4e8325b428122439860f9d49dd25a4b4b66d
>>> Author: Stefan Schmidt 
>>> Date:   Mon Sep 19 14:01:19 2016 +0200
>>>
>>> tests: ecore: relax the timing precision for the promise timeout test
>>>
>>> This test has been failing on Jenkins again and again. After adding the
>>> debug a while ago it now shows that the value is between 0.01 and 0.02 in
>>> all cases I have seen. Relaxing the timeout here a bit to make it pass in
>>> situation where our CI is under load.
>>> ---
>>>  src/tests/ecore/ecore_test_timer.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/tests/ecore/ecore_test_timer.c
>>> b/src/tests/ecore/ecore_test_timer.c index c7547e4..f3b277b 100644
>>> --- a/src/tests/ecore/ecore_test_timer.c
>>> +++ b/src/tests/ecore/ecore_test_timer.c
>>> @@ -183,8 +183,8 @@ _ecore_promise_quit(void *data, const Efl_Event *ev)
>>> double *start = success->value;
>>> double delta = ecore_loop_time_get() - *start;
>>>
>>> -   fprintf(stderr, "Ecore promise timeout took %f (should be <= 0.01)\n",
>>> delta - 0.2);
>>> -   fail_if(delta - 0.2 > 0.01);
>>> +   fprintf(stderr, "Ecore promise timeout took %f (should be <= 0.02)\n",
>>> delta - 0.2);
>>> +   fail_if(delta - 0.2 > 0.02);
>>>
>>> *bob = EINA_TRUE;
>>> ecore_main_loop_quit();
>>>
>>
>>
>> Why is there an fprintf there? We don't do it in any other tests. That
>> text should be either removed or moved to a comment. No?
>
> we do this in lots of tests. well printfs. also eina log's too. i make use of
> them all the time to run a test by hand to see what is actually going on in 
> the
> test.
>
>

It's useful in some cases, where you want to print additional 
information, but as I said, in this case is not, because all of the 
information would be printed when the error case actually happens if the 
check is done correctly.

--
Tom.

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


[EGIT] [core/efl] master 01/01: Evas font: force freetype v35 ttf interpreter

2016-09-20 Thread Daniel Hirt
herdsman pushed a commit to branch master.

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

commit f68a925d817dc469c68fa993b43b255a573b0243
Author: Daniel Hirt 
Date:   Sun Sep 18 17:02:27 2016 +0300

Evas font: force freetype v35 ttf interpreter

Ref T4623

v40 bytecode interpreter is official as of freetype 2.7.
The results don't look so good at the moment. The text looks and glyph
positioning seem worse than they were with the previous v35 interpreter.

So, in the meantime we'll keep using v35, just so everything looks
normal again.

Although the v40 is relevant since around 2.6.3, I rather not do any
FREETYPE_MINOR checks in this patch, because distributions might ship
previous versions with the other (v38) interpreter enabled.
---
 src/lib/evas/common/evas_font_main.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/lib/evas/common/evas_font_main.c 
b/src/lib/evas/common/evas_font_main.c
index 7562d28..ba56848 100644
--- a/src/lib/evas/common/evas_font_main.c
+++ b/src/lib/evas/common/evas_font_main.c
@@ -16,6 +16,7 @@
 #include FT_OUTLINE_H
 #include FT_SYNTHESIS_H
 #include FT_BITMAP_H
+#include FT_TRUETYPE_DRIVER_H
 
 FT_Library  evas_ft_lib = 0;
 static int  initialised = 0;
@@ -29,11 +30,14 @@ evas_common_font_init(void)
 {
int error;
const char *s;
+   FT_UInt interpreter_version = TT_INTERPRETER_VERSION_35;
 
initialised++;
if (initialised != 1) return;
error = FT_Init_FreeType(&evas_ft_lib);
if (error) return;
+   FT_Property_Set(evas_ft_lib,
+ "truetype", "interpreter-version", &interpreter_version);
evas_common_font_load_init();
evas_common_font_draw_init();
s = getenv("EVAS_FONT_DPI");

-- 




Re: [E-devel] Evas Events

2016-09-20 Thread Jean-Philippe André
On 8 September 2016 at 21:40, Christopher Michael 
wrote:

> On 09/07/2016 06:55 PM, Carsten Haitzler wrote:
> > On Wed, 07 Sep 2016 13:52:40 -0400 Christopher Michael <
> cp.mich...@samsung.com>
> > said:
> >
> >> I would appear that commit 405680e836eb47d7dd8f59a4761386e7a80d9244
> >> changed the way that hold events are sent. They are no longer being sent
> >> to the child objects, but rather the main 'obj':
> >>
> >> -EV_CALL(eo_child, child, EVAS_CALLBACK_HOLD, ev, event_id, he,
> >> parent_he);
> >> +evas_object_event_callback_call(eo_obj, obj,
> >> EVAS_CALLBACK_HOLD, NULL,
> >> +event_id, EFL_EVENT_HOLD, evt);
> >>
> >> This seems to me like a simple copy/paste problem, however I did not
> >> want to push a fix for it (to make the event be sent to the child
> >> object) until I can confirm that it is indeed an err.
> >>
> >> Anyone know ?? (I know jpeg is on vacation right now).
> >
> > fix it! :) make the commit title noticeable for jp when he comes back.
> >
>
> Fixed :)


Good catch! Thanks for the fix :)

-- 
Jean-Philippe André
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[EGIT] [core/efl] master 01/01: ecore_con_local: fix memory leak.

2016-09-20 Thread Ji-Youn Park
jypark pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=0a39fae0a2c27ec48b39caca3b00dc54bdffaa32

commit 0a39fae0a2c27ec48b39caca3b00dc54bdffaa32
Author: Ji-Youn Park 
Date:   Tue Sep 20 16:14:04 2016 +0830

ecore_con_local: fix memory leak.

after socket function call, close file descriptor.
---
 src/lib/ecore_con/ecore_con_local.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/src/lib/ecore_con/ecore_con_local.c 
b/src/lib/ecore_con/ecore_con_local.c
index 1453ea1..546b6e0 100644
--- a/src/lib/ecore_con/ecore_con_local.c
+++ b/src/lib/ecore_con/ecore_con_local.c
@@ -143,14 +143,14 @@ ecore_con_local_connect(Ecore_Con_Server *obj,
  return 0;
 
if (fcntl(svr->fd, F_SETFL, O_NONBLOCK) < 0)
- return 0;
+ goto error;
 
if (fcntl(svr->fd, F_SETFD, FD_CLOEXEC) < 0)
- return 0;
+ goto error;
 
if (setsockopt(svr->fd, SOL_SOCKET, SO_REUSEADDR, (const void *)&curstate,
   sizeof(curstate)) < 0)
- return 0;
+ goto error;
 
socket_unix.sun_family = AF_UNIX;
 
@@ -165,7 +165,7 @@ ecore_con_local_connect(Ecore_Con_Server *obj,
  svr->name);
 #else
 WRN("Your system does not support abstract sockets!");
-return 0;
+goto error;
 #endif
  }
else
@@ -179,12 +179,12 @@ ecore_con_local_connect(Ecore_Con_Server *obj,
socket_unix_len) < 0)
  {
 DBG("local connection failed: %s", strerror(errno));
-return 0;
+goto error;
  }
 
svr->path = strdup(buf);
if (!svr->path)
- return 0;
+ goto error;
 
if (svr->type & ECORE_CON_SSL)
  {
@@ -195,11 +195,15 @@ ecore_con_local_connect(Ecore_Con_Server *obj,
  ecore_main_fd_handler_add(svr->fd, ECORE_FD_READ,
cb_done, obj, NULL, NULL);
if (!svr->fd_handler)
- return 0;
+ goto error;
 
if (!svr->delete_me) ecore_con_event_server_add(obj);
 
return 1;
+error:
+   if (svr->fd) close(svr->fd);
+   svr->fd = -1;
+   return 0;
 #endif
 }
 

-- 




Re: [E-devel] Elm_Gengrid rewrite

2016-09-20 Thread Jean-Philippe André
Hi Marcel,

On 7 September 2016 at 19:05,  wrote:

> Hello,
>
> I would like to ask how the elm_gengrid rewrite is proceeding.
>
> I am using gengrid in verne and i have quite some problems with it. So
> is there some document or RFC?
>
> I would also like to give feedback on the problems i am having with it,
> so that those problems are not rising in the new widget again.


I also don't really know. I believe Felipe and Sanghyeon should know best.
In a few weeks we should meet again in Korea and I hope finalize teh design
(if not the implementation).

Can we have some news on this? Felipe? Sanghyeon? Cedric?

-- 
Jean-Philippe André
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Elm_Image 1.18 regression

2016-09-20 Thread Jean-Philippe André
Hi Dave,

On 14 September 2016 at 03:09, Davide Andreoli 
wrote:

> Hi guys,
>
> I think I found a behaviour break/regression in elm_image (or maybe edje
> swallow)
> in the 1.18 release.
>
> http://www.enlightenment.org/ss/e-57d83f0a338445.82540083.jpg
>
> Look at the provided screenshot: the image in the top-left corner should be
> top-aligned
> inside it's swallow (the red rect)
>
> The image is an elm_image, while the transparent red rectangle is the
> swallow where
> the image is swallowed into. To keep the image top-aligned in the swallow I
> was
> using size_hint_align(0.5, 0.0) on the elm_image.
>
> I'm quite sure this was working in 1.17 but do not work anymore in 1.18.
>
> I don't know if the breakage is in elm_image (so I need to spank jpeg) or
> is in
> edje (don't know the person to spank here)
>
> some ideas? what is the intended behavior in this case?


This is probably a regression in elm_image.
I've opened T4635 to track this.

-- 
Jean-Philippe André
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[EGIT] [core/efl] master 01/01: embryo : Prevent buffer overflow in embryo_cc_sc2

2016-09-20 Thread JEONGHYUN YUN
jypark pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=078c4a9f11b2d13805b52b7664485516103b

commit 078c4a9f11b2d13805b52b7664485516103b
Author: JEONGHYUN YUN 
Date:   Tue Sep 20 15:31:16 2016 +0830

embryo : Prevent buffer overflow in embryo_cc_sc2

Reviewers: jypark

Reviewed By: jypark

Subscribers: cedric, jpeg

Differential Revision: https://phab.enlightenment.org/D4304
---
 src/bin/embryo/embryo_cc_sc2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/bin/embryo/embryo_cc_sc2.c b/src/bin/embryo/embryo_cc_sc2.c
index 6956a80..fddc102 100644
--- a/src/bin/embryo/embryo_cc_sc2.c
+++ b/src/bin/embryo/embryo_cc_sc2.c
@@ -1005,7 +1005,7 @@ command(void)
int i;
 
for (i = 0; 
- (i < (int)(sizeof(name))) && 
+ (i < (int)(sizeof(name)) - 1) && 
  (alphanum(*lptr));
 i++, lptr++)
   name[i] = *lptr;

--