date:20130723

Re: [E-devel] [EGIT] [core/efl] master 02/02: Evas: adding image dump debug feature for wayland_egl backend

2013-07-23 Thread Christopher Michael

Thank you for porting this !! :)

Cheers,
dh

On 23/07/13 02:29, Sung W. Park - Enlightenment Git wrote:
 sung pushed a commit to branch master.

 commit 7aa516c01a620da3438de864ac0c0e5b80c93d0b
 Author: Sung W. Park dunamis.p...@samsung.com
 Date:   Tue Jul 23 10:23:36 2013 +0900

  Evas: adding image dump debug feature for wayland_egl backend
  
  Porting commit f10c108283d9b76708418ba172b9ff0b28a09cd6 to wayland
  engine.
  
  Added a feature to dump out a png image before calling SwapBuffers.
  To turn on the feature, use the following env vars.
  
  EVAS_GL_SWAP_BUFFER_DEBUG_DIR=dir_name sets the name of the directory
  that the files will be output to and enables the debug mode.
  
  EVAS_GL_SWAP_BUFFER_DEBUG_ALWAYS=1 will enable the writing of the
  files every frame.  This in effect turns on the swap_buffer_debug
  variable, which can be set on or off in gdb for debugging.  This will
  allow dumping of certain frames without having to dump out a ton of
  files to track down one frame.
 ---
   src/modules/evas/engines/wayland_egl/evas_engine.c | 43 
 ++
   1 file changed, 43 insertions(+)

 diff --git a/src/modules/evas/engines/wayland_egl/evas_engine.c 
 b/src/modules/evas/engines/wayland_egl/evas_engine.c
 index 1db4dbd..65edcca 100644
 --- a/src/modules/evas/engines/wayland_egl/evas_engine.c
 +++ b/src/modules/evas/engines/wayland_egl/evas_engine.c
 @@ -41,6 +41,7 @@ struct _Render_Engine
  Eina_Bool lost_back : 1;
  Eina_Bool end : 1;
  Eina_Bool evgl_initted : 1;
 +   int   frame_cnt;
   
  struct
{
 @@ -103,6 +104,9 @@ static Eina_Bool extn_have_buffer_age = EINA_TRUE;
   static int safe_native = -1;
   static int partial_rect_union_mode = -1;
   
 +static int swap_buffer_debug_mode = -1;
 +static int swap_buffer_debug = 0;
 +
   /* function tables - filled in later (func and parent func) */
   static Evas_Func func, pfunc;
   static EVGL_Interface evgl_funcs =
 @@ -1188,6 +1192,7 @@ static void
   eng_output_flush(void *data, Evas_Render_Mode render_mode)
   {
  Render_Engine *re;
 +   static char *dname = NULL;
   
  if (!(re = (Render_Engine *)data)) return;
   
 @@ -1201,6 +1206,41 @@ eng_output_flush(void *data, Evas_Render_Mode 
 render_mode)
   
  evas_gl_common_context_done(re-win-gl_context);
   
 +   // Save contents of the framebuffer to a file
 +   if (swap_buffer_debug_mode == -1)
 + {
 +if ((dname = getenv(EVAS_GL_SWAP_BUFFER_DEBUG_DIR)))
 +  {
 + int stat;
 + // Create a directory with 0775 permission
 + stat = mkdir(dname, S_IRWXU|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH);
 + if ((!stat) || errno == EEXIST) swap_buffer_debug_mode = 1;
 +  }
 +else
 +   swap_buffer_debug_mode = 0;
 + }
 +
 +   if (swap_buffer_debug_mode == 1)
 + {
 +// Set this env var to dump files every frame
 +// Or set the global var in gdb to 1|0 to turn it on and off
 +if (getenv(EVAS_GL_SWAP_BUFFER_DEBUG_ALWAYS))
 +   swap_buffer_debug = 1;
 +
 +if (swap_buffer_debug)
 +  {
 + char fname[100];
 + int ret = 0;
 + sprintf(fname, %p, (void*)re-win);
 +
 + ret = evas_gl_common_buffer_dump(re-win-gl_context,
 +  (const char*)dname,
 +  (const char*)fname,
 +  re-frame_cnt);
 + if (!ret) swap_buffer_debug_mode = 0;
 +  }
 + }
 +
  if (!re-vsync)
{
   if (re-info-vsync) eglSwapInterval(re-win-egl_disp, 1);
 @@ -1278,6 +1318,9 @@ eng_output_flush(void *data, Evas_Render_Mode 
 render_mode)
   evas_common_tilebuf_free_render_rects(re-rects);
   re-rects = NULL;
}
 +
 +   re-frame_cnt++;
 +
   end:
  evas_gl_preload_render_unlock(eng_gl_preload_make_current, re);
   }



--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 02/02: Evas: adding image dump debug feature for wayland_egl backend

2013-07-23 Thread Sung W. Park

No problem. :)

I was worried that I would break something since I couldn't compile it but
it was simple a simple addition so I just went ahead with it.

For big ones, I'll let you know. :)

cheers,
Sung


On Tue, Jul 23, 2013 at 2:58 PM, Christopher Michael cp.mich...@samsung.com
 wrote:

 Thank you for porting this !! :)

 Cheers,
 dh

 On 23/07/13 02:29, Sung W. Park - Enlightenment Git wrote:
  sung pushed a commit to branch master.
 
  commit 7aa516c01a620da3438de864ac0c0e5b80c93d0b
  Author: Sung W. Park dunamis.p...@samsung.com
  Date:   Tue Jul 23 10:23:36 2013 +0900
 
   Evas: adding image dump debug feature for wayland_egl backend
 
   Porting commit f10c108283d9b76708418ba172b9ff0b28a09cd6 to wayland
   engine.
 
   Added a feature to dump out a png image before calling SwapBuffers.
   To turn on the feature, use the following env vars.
 
   EVAS_GL_SWAP_BUFFER_DEBUG_DIR=dir_name sets the name of the
 directory
   that the files will be output to and enables the debug mode.
 
   EVAS_GL_SWAP_BUFFER_DEBUG_ALWAYS=1 will enable the writing of the
   files every frame.  This in effect turns on the swap_buffer_debug
   variable, which can be set on or off in gdb for debugging.  This
 will
   allow dumping of certain frames without having to dump out a ton of
   files to track down one frame.
  ---
src/modules/evas/engines/wayland_egl/evas_engine.c | 43
 ++
1 file changed, 43 insertions(+)
 
  diff --git a/src/modules/evas/engines/wayland_egl/evas_engine.c
 b/src/modules/evas/engines/wayland_egl/evas_engine.c
  index 1db4dbd..65edcca 100644
  --- a/src/modules/evas/engines/wayland_egl/evas_engine.c
  +++ b/src/modules/evas/engines/wayland_egl/evas_engine.c
  @@ -41,6 +41,7 @@ struct _Render_Engine
   Eina_Bool lost_back : 1;
   Eina_Bool end : 1;
   Eina_Bool evgl_initted : 1;
  +   int   frame_cnt;
 
   struct
 {
  @@ -103,6 +104,9 @@ static Eina_Bool extn_have_buffer_age = EINA_TRUE;
static int safe_native = -1;
static int partial_rect_union_mode = -1;
 
  +static int swap_buffer_debug_mode = -1;
  +static int swap_buffer_debug = 0;
  +
/* function tables - filled in later (func and parent func) */
static Evas_Func func, pfunc;
static EVGL_Interface evgl_funcs =
  @@ -1188,6 +1192,7 @@ static void
eng_output_flush(void *data, Evas_Render_Mode render_mode)
{
   Render_Engine *re;
  +   static char *dname = NULL;
 
   if (!(re = (Render_Engine *)data)) return;
 
  @@ -1201,6 +1206,41 @@ eng_output_flush(void *data, Evas_Render_Mode
 render_mode)
 
   evas_gl_common_context_done(re-win-gl_context);
 
  +   // Save contents of the framebuffer to a file
  +   if (swap_buffer_debug_mode == -1)
  + {
  +if ((dname = getenv(EVAS_GL_SWAP_BUFFER_DEBUG_DIR)))
  +  {
  + int stat;
  + // Create a directory with 0775 permission
  + stat = mkdir(dname,
 S_IRWXU|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH);
  + if ((!stat) || errno == EEXIST) swap_buffer_debug_mode = 1;
  +  }
  +else
  +   swap_buffer_debug_mode = 0;
  + }
  +
  +   if (swap_buffer_debug_mode == 1)
  + {
  +// Set this env var to dump files every frame
  +// Or set the global var in gdb to 1|0 to turn it on and off
  +if (getenv(EVAS_GL_SWAP_BUFFER_DEBUG_ALWAYS))
  +   swap_buffer_debug = 1;
  +
  +if (swap_buffer_debug)
  +  {
  + char fname[100];
  + int ret = 0;
  + sprintf(fname, %p, (void*)re-win);
  +
  + ret = evas_gl_common_buffer_dump(re-win-gl_context,
  +  (const char*)dname,
  +  (const char*)fname,
  +  re-frame_cnt);
  + if (!ret) swap_buffer_debug_mode = 0;
  +  }
  + }
  +
   if (!re-vsync)
 {
if (re-info-vsync) eglSwapInterval(re-win-egl_disp, 1);
  @@ -1278,6 +1318,9 @@ eng_output_flush(void *data, Evas_Render_Mode
 render_mode)
evas_common_tilebuf_free_render_rects(re-rects);
re-rects = NULL;
 }
  +
  +   re-frame_cnt++;
  +
end:
   evas_gl_preload_render_unlock(eng_gl_preload_make_current, re);
}
 



 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 02/02: Evas: adding image dump debug feature for wayland_egl backend

2013-07-23 Thread Christopher Michael

On 23/07/13 07:17, Sung W. Park wrote:
 No problem. :)

 I was worried that I would break something since I couldn't compile it but
 it was simple a simple addition so I just went ahead with it.
No Worries :) Ideally I would request at Least a compile check ;) (let's 
not pick up any bad habits from the French borker) ;) but I understand 
not being able to compile it. Yes, for simple additions like this don't 
worry too much about it. I'll be able to compile and run it for testing 
so any breakage would get detected promptly anyway ;)
 For big ones, I'll let you know. :)
Not a problem :) I look forward to any help or efforts that you want to 
contribute :)

Cheers,
Chris

 cheers,
 Sung


 On Tue, Jul 23, 2013 at 2:58 PM, Christopher Michael cp.mich...@samsung.com
 wrote:
 Thank you for porting this !! :)

 Cheers,
 dh

 On 23/07/13 02:29, Sung W. Park - Enlightenment Git wrote:
 sung pushed a commit to branch master.

 commit 7aa516c01a620da3438de864ac0c0e5b80c93d0b
 Author: Sung W. Park dunamis.p...@samsung.com
 Date:   Tue Jul 23 10:23:36 2013 +0900

   Evas: adding image dump debug feature for wayland_egl backend

   Porting commit f10c108283d9b76708418ba172b9ff0b28a09cd6 to wayland
   engine.

   Added a feature to dump out a png image before calling SwapBuffers.
   To turn on the feature, use the following env vars.

   EVAS_GL_SWAP_BUFFER_DEBUG_DIR=dir_name sets the name of the
 directory
   that the files will be output to and enables the debug mode.

   EVAS_GL_SWAP_BUFFER_DEBUG_ALWAYS=1 will enable the writing of the
   files every frame.  This in effect turns on the swap_buffer_debug
   variable, which can be set on or off in gdb for debugging.  This
 will
   allow dumping of certain frames without having to dump out a ton of
   files to track down one frame.
 ---
src/modules/evas/engines/wayland_egl/evas_engine.c | 43
 ++
1 file changed, 43 insertions(+)

 diff --git a/src/modules/evas/engines/wayland_egl/evas_engine.c
 b/src/modules/evas/engines/wayland_egl/evas_engine.c
 index 1db4dbd..65edcca 100644
 --- a/src/modules/evas/engines/wayland_egl/evas_engine.c
 +++ b/src/modules/evas/engines/wayland_egl/evas_engine.c
 @@ -41,6 +41,7 @@ struct _Render_Engine
   Eina_Bool lost_back : 1;
   Eina_Bool end : 1;
   Eina_Bool evgl_initted : 1;
 +   int   frame_cnt;

   struct
 {
 @@ -103,6 +104,9 @@ static Eina_Bool extn_have_buffer_age = EINA_TRUE;
static int safe_native = -1;
static int partial_rect_union_mode = -1;

 +static int swap_buffer_debug_mode = -1;
 +static int swap_buffer_debug = 0;
 +
/* function tables - filled in later (func and parent func) */
static Evas_Func func, pfunc;
static EVGL_Interface evgl_funcs =
 @@ -1188,6 +1192,7 @@ static void
eng_output_flush(void *data, Evas_Render_Mode render_mode)
{
   Render_Engine *re;
 +   static char *dname = NULL;

   if (!(re = (Render_Engine *)data)) return;

 @@ -1201,6 +1206,41 @@ eng_output_flush(void *data, Evas_Render_Mode
 render_mode)
   evas_gl_common_context_done(re-win-gl_context);

 +   // Save contents of the framebuffer to a file
 +   if (swap_buffer_debug_mode == -1)
 + {
 +if ((dname = getenv(EVAS_GL_SWAP_BUFFER_DEBUG_DIR)))
 +  {
 + int stat;
 + // Create a directory with 0775 permission
 + stat = mkdir(dname,
 S_IRWXU|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH);
 + if ((!stat) || errno == EEXIST) swap_buffer_debug_mode = 1;
 +  }
 +else
 +   swap_buffer_debug_mode = 0;
 + }
 +
 +   if (swap_buffer_debug_mode == 1)
 + {
 +// Set this env var to dump files every frame
 +// Or set the global var in gdb to 1|0 to turn it on and off
 +if (getenv(EVAS_GL_SWAP_BUFFER_DEBUG_ALWAYS))
 +   swap_buffer_debug = 1;
 +
 +if (swap_buffer_debug)
 +  {
 + char fname[100];
 + int ret = 0;
 + sprintf(fname, %p, (void*)re-win);
 +
 + ret = evas_gl_common_buffer_dump(re-win-gl_context,
 +  (const char*)dname,
 +  (const char*)fname,
 +  re-frame_cnt);
 + if (!ret) swap_buffer_debug_mode = 0;
 +  }
 + }
 +
   if (!re-vsync)
 {
if (re-info-vsync) eglSwapInterval(re-win-egl_disp, 1);
 @@ -1278,6 +1318,9 @@ eng_output_flush(void *data, Evas_Render_Mode
 render_mode)
evas_common_tilebuf_free_render_rects(re-rects);
re-rects = NULL;
 }
 +
 +   re-frame_cnt++;
 +
end:
   evas_gl_preload_render_unlock(eng_gl_preload_make_current, re);
}





--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility

[E-devel] EFL Beta API

2013-07-23 Thread Cedric BAIL

Hello,

As the time comes, we are trying to move to a time based release. But
as the discussion on Eo does show, it takes time to reach a consensus
on some API and make it difficult to move forward on a release.

So I have introduced a macro EFL_BETA_API_SUPPORT that is used to
disable API that we won't support for the next release, but still want
to push forward. The people that want to use those API should be
advised that they will have no ABI/API stability on such API and will
need to enable it manually. I have added a m4 macro that will add it
to the config.h at configure time.

The first API that I have just marked as beta is Eo. All program that
use are now using efl_beta.m4 (elementary, expedite, clouseau). The
goal is offcourse to have the least amount of those API in beta, but
that is I think the only sane way to move forward.

Regards,
--
Cedric BAIL

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL Beta API

2013-07-23 Thread Michael Blumenkrantz

I don't understand why we can't just remove all those from the public
headers. If we're still rewriting them so much that they need to be marked
as beta, they should not be released at all imo.

On Tue, Jul 23, 2013 at 8:46 AM, Cedric BAIL cedric.b...@free.fr wrote:

 Hello,

 As the time comes, we are trying to move to a time based release. But
 as the discussion on Eo does show, it takes time to reach a consensus
 on some API and make it difficult to move forward on a release.

 So I have introduced a macro EFL_BETA_API_SUPPORT that is used to
 disable API that we won't support for the next release, but still want
 to push forward. The people that want to use those API should be
 advised that they will have no ABI/API stability on such API and will
 need to enable it manually. I have added a m4 macro that will add it
 to the config.h at configure time.

 The first API that I have just marked as beta is Eo. All program that
 use are now using efl_beta.m4 (elementary, expedite, clouseau). The
 goal is offcourse to have the least amount of those API in beta, but
 that is I think the only sane way to move forward.

 Regards,
 --
 Cedric BAIL


 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL Beta API

2013-07-23 Thread Cedric BAIL

On Tue, Jul 23, 2013 at 4:56 PM, Michael Blumenkrantz
michael.blumenkra...@gmail.com wrote:
 I don't understand why we can't just remove all those from the public
 headers. If we're still rewriting them so much that they need to be marked
 as beta, they should not be released at all imo.

Because we use it. That's the point. If you don't have the ability to
mark some API as beta, you can't use some API and if you don't use
them you don't know how good they are at the end. It also reduce the
review of such API. So in the end you need a way to mark those API
beta.

 On Tue, Jul 23, 2013 at 8:46 AM, Cedric BAIL cedric.b...@free.fr wrote:

 Hello,

 As the time comes, we are trying to move to a time based release. But
 as the discussion on Eo does show, it takes time to reach a consensus
 on some API and make it difficult to move forward on a release.

 So I have introduced a macro EFL_BETA_API_SUPPORT that is used to
 disable API that we won't support for the next release, but still want
 to push forward. The people that want to use those API should be
 advised that they will have no ABI/API stability on such API and will
 need to enable it manually. I have added a m4 macro that will add it
 to the config.h at configure time.

 The first API that I have just marked as beta is Eo. All program that
 use are now using efl_beta.m4 (elementary, expedite, clouseau). The
 goal is offcourse to have the least amount of those API in beta, but
 that is I think the only sane way to move forward.

 Regards,
 --
 Cedric BAIL


 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel




--
Cedric BAIL

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL Beta API

2013-07-23 Thread Michael Blumenkrantz

sure, but it sounds more like pre-alpha than beta at this point
considering the amount of rewrite occurring.

On Tue, Jul 23, 2013 at 9:01 AM, Cedric BAIL cedric.b...@free.fr wrote:

 On Tue, Jul 23, 2013 at 4:56 PM, Michael Blumenkrantz
 michael.blumenkra...@gmail.com wrote:
  I don't understand why we can't just remove all those from the public
  headers. If we're still rewriting them so much that they need to be
 marked
  as beta, they should not be released at all imo.

 Because we use it. That's the point. If you don't have the ability to
 mark some API as beta, you can't use some API and if you don't use
 them you don't know how good they are at the end. It also reduce the
 review of such API. So in the end you need a way to mark those API
 beta.

  On Tue, Jul 23, 2013 at 8:46 AM, Cedric BAIL cedric.b...@free.fr
 wrote:
 
  Hello,
 
  As the time comes, we are trying to move to a time based release. But
  as the discussion on Eo does show, it takes time to reach a consensus
  on some API and make it difficult to move forward on a release.
 
  So I have introduced a macro EFL_BETA_API_SUPPORT that is used to
  disable API that we won't support for the next release, but still want
  to push forward. The people that want to use those API should be
  advised that they will have no ABI/API stability on such API and will
  need to enable it manually. I have added a m4 macro that will add it
  to the config.h at configure time.
 
  The first API that I have just marked as beta is Eo. All program that
  use are now using efl_beta.m4 (elementary, expedite, clouseau). The
  goal is offcourse to have the least amount of those API in beta, but
  that is I think the only sane way to move forward.
 
  Regards,
  --
  Cedric BAIL
 
 
 
 --
  See everything from the browser to the database with AppDynamics
  Get end-to-end visibility with application monitoring from AppDynamics
  Isolate bottlenecks and diagnose root cause in seconds.
  Start your free trial of AppDynamics Pro today!
 
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
 
 --
  See everything from the browser to the database with AppDynamics
  Get end-to-end visibility with application monitoring from AppDynamics
  Isolate bottlenecks and diagnose root cause in seconds.
  Start your free trial of AppDynamics Pro today!
 
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 



 --
 Cedric BAIL


 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL Beta API

2013-07-23 Thread Cedric BAIL

On Tue, Jul 23, 2013 at 5:04 PM, Michael Blumenkrantz
michael.blumenkra...@gmail.com wrote:
 sure, but it sounds more like pre-alpha than beta at this point
 considering the amount of rewrite occurring.

There is still no agreement about if we are going to change any of the
existing API or not. It is still a discussion. And the change is going
to impact mostly EFL internal than an application using EFL.

 On Tue, Jul 23, 2013 at 9:01 AM, Cedric BAIL cedric.b...@free.fr wrote:
 On Tue, Jul 23, 2013 at 4:56 PM, Michael Blumenkrantz
 michael.blumenkra...@gmail.com wrote:
  I don't understand why we can't just remove all those from the public
  headers. If we're still rewriting them so much that they need to be
 marked
  as beta, they should not be released at all imo.

 Because we use it. That's the point. If you don't have the ability to
 mark some API as beta, you can't use some API and if you don't use
 them you don't know how good they are at the end. It also reduce the
 review of such API. So in the end you need a way to mark those API
 beta.

  On Tue, Jul 23, 2013 at 8:46 AM, Cedric BAIL cedric.b...@free.fr
 wrote:
 
  Hello,
 
  As the time comes, we are trying to move to a time based release. But
  as the discussion on Eo does show, it takes time to reach a consensus
  on some API and make it difficult to move forward on a release.
 
  So I have introduced a macro EFL_BETA_API_SUPPORT that is used to
  disable API that we won't support for the next release, but still want
  to push forward. The people that want to use those API should be
  advised that they will have no ABI/API stability on such API and will
  need to enable it manually. I have added a m4 macro that will add it
  to the config.h at configure time.
 
  The first API that I have just marked as beta is Eo. All program that
  use are now using efl_beta.m4 (elementary, expedite, clouseau). The
  goal is offcourse to have the least amount of those API in beta, but
  that is I think the only sane way to move forward.
 
  Regards,
  --
  Cedric BAIL
 
 
 
 --
  See everything from the browser to the database with AppDynamics
  Get end-to-end visibility with application monitoring from AppDynamics
  Isolate bottlenecks and diagnose root cause in seconds.
  Start your free trial of AppDynamics Pro today!
 
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
 
 --
  See everything from the browser to the database with AppDynamics
  Get end-to-end visibility with application monitoring from AppDynamics
  Isolate bottlenecks and diagnose root cause in seconds.
  Start your free trial of AppDynamics Pro today!
 
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 



 --
 Cedric BAIL


 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel




--
Cedric BAIL

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list

Re: [E-devel] enventor (an edc editor prototype)

2013-07-23 Thread Tom Hacohen

On 22/07/13 18:42, ChunEon Park wrote:
 http://www.youtube.com/watch?v=cOdgBBV4J3sfeature=youtu.be

Hm.. syntax highlighting - nice.
Looks like you have a nice syntax highlighting, line numbering and etc. 
going on there, what did you use?

Really nice, and I see the source as in your private repo, cool. :)

--
Tom.


--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: tasn trunk/elementary/src/lib

2013-07-23 Thread Tom Hacohen

Hey,

 From the setlocale man page:
If locale is NULL, the current locale is only queried, not modified.

I am only querying it there, not modifying it. It's up to the 
application to set the locale to whatever it wants, for example by 
calling setlocale with  like you've suggested.

This is *correct* don't change it. Look at ecrire for example, Ecrire 
does it right and works correctly.

--
Tom.

On 23/07/13 05:08, Daniel Juyung Seo wrote:
 Dear Tom,
 what does if the app using elm is translatable. mean?

 With setlocale LC_MESSAGES to NULL, running applications with environment
 variable with LANG doesn't translate the texts.
 const char *msg_locale = setlocale(LC_MESSAGES, NULL);

 I tried with  instead of NULL and it worked.
 const char *msg_locale = setlocale(LC_MESSAGES, ;

 Can you check this?
 Thanks.

 Daniel Juyung Seo (SeoZ)


 On Sun, Sep 18, 2011 at 4:53 PM, Enlightenment SVN 
 no-re...@enlightenment.org wrote:

 Log:
 Elm gettext: Only translate if the app using elm is translatable.

It assumes gettext is initialized before the call to elm_init.

 Author:   tasn
 Date: 2011-09-18 00:53:41 -0700 (Sun, 18 Sep 2011)
 New Revision: 63452
 Trac: http://trac.enlightenment.org/e/changeset/63452

 Modified:
trunk/elementary/src/lib/elm_config.c trunk/elementary/src/lib/elm_priv.h

 Modified: trunk/elementary/src/lib/elm_config.c
 ===
 --- trunk/elementary/src/lib/elm_config.c   2011-09-17 17:15:32 UTC
 (rev 63451)
 +++ trunk/elementary/src/lib/elm_config.c   2011-09-18 07:53:41 UTC
 (rev 63452)
 @@ -1658,12 +1658,33 @@
  _elm_rescale();
   }

 +static void
 +_translation_init()
 +{
 +#ifdef ENABLE_NLS
 +   const char *cur_dom = textdomain(NULL);
 +   const char *trans_comment = gettext();
 +   const char *msg_locale = setlocale(LC_MESSAGES, NULL);
 +
 +   /* Same concept as what glib does:
 +* We shouldn't translate if there are no translations for the
 +* application in the current locale + domain. (Unless locale is
 +* en_/C where translating only parts of the interface make some
 +* sense).
 +*/
 +   _elm_config-translate = !(strcmp (cur_dom, messages) 
 + !*trans_comment  strncmp (msg_locale, en_, 3) 
 + strcmp (msg_locale, C));
 +#endif
 +}
 +
   void
   _elm_config_init(void)
   {
  _desc_init();
  _profile_fetch_from_conf();
  _config_load();
 +   _translation_init();
  _env_get();
  _config_apply();
  _elm_config_font_overlay_apply();

 Modified: trunk/elementary/src/lib/elm_priv.h
 ===
 --- trunk/elementary/src/lib/elm_priv.h 2011-09-17 17:15:32 UTC (rev 63451)
 +++ trunk/elementary/src/lib/elm_priv.h 2011-09-18 07:53:41 UTC (rev 63452)
 @@ -28,7 +28,7 @@

   #ifdef ENABLE_NLS
   # include libintl.h
 -# define E_(string) dgettext(PACKAGE, string)
 +# define E_(string) _elm_dgettext(string)
   #else
   # define bindtextdomain(domain,dir)
   # define E_(string) (string)
 @@ -148,6 +148,7 @@

  /* Not part of the EET file */
  Eina_Bool  is_mirrored : 1;
 +   Eina_Bool  translate : 1;
   };

   struct _Elm_Module
 @@ -247,6 +248,20 @@
   extern Eina_List   *_elm_win_list;
   extern int  _elm_win_deferred_free;

 +/* Our gettext wrapper, used to disable translation of elm if the app
 + * is not translated. */
 +static inline const char *
 +_elm_dgettext(const char *string)
 +{
 +   if (EINA_UNLIKELY(_elm_config-translate == EINA_FALSE))
 + {
 +return string;
 + }
 +
 +   return dgettext(PACKAGE, string);
 +}
 +
 +
   /* Used by the paste handler */
   void _elm_entry_entry_paste(Evas_Object *obj, const char *entry);




 --
 BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
 http://p.sf.net/sfu/rim-devcon-copy2
 ___
 enlightenment-svn mailing list
 enlightenment-...@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-svn

 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in

Re: [E-devel] EFL Beta API

2013-07-23 Thread Tom Hacohen

On 23/07/13 08:46, Cedric BAIL wrote:
 Hello,

 As the time comes, we are trying to move to a time based release. But
 as the discussion on Eo does show, it takes time to reach a consensus
 on some API and make it difficult to move forward on a release.

 So I have introduced a macro EFL_BETA_API_SUPPORT that is used to
 disable API that we won't support for the next release, but still want
 to push forward. The people that want to use those API should be
 advised that they will have no ABI/API stability on such API and will
 need to enable it manually. I have added a m4 macro that will add it
 to the config.h at configure time.

 The first API that I have just marked as beta is Eo. All program that
 use are now using efl_beta.m4 (elementary, expedite, clouseau). The
 goal is offcourse to have the least amount of those API in beta, but
 that is I think the only sane way to move forward.


Great, thanks. :)

--
Tom.


--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] enventor (an edc editor prototype)

2013-07-23 Thread ChunEon Park

just an entry. :-) 
still have many stuff to do with entry before first release.

1. auto indentation.
2. undo/redo.
3. fix the entry object maximum size problem.
 

-Regards, Hermet- 

-Original Message-
From: Tom Hacohentom.haco...@samsung.com 
To: Enlightenment developer listenlightenment-devel@lists.sourceforge.net; 
Cc: ChunEon Parkher...@naver.com; 
enlightenment-us...@lists.sourceforge.net; 
Sent: 2013-07-23 (화) 18:32:18
Subject: Re: [E-devel] enventor (an edc editor prototype)

On 22/07/13 18:42, ChunEon Park wrote:
 http://www.youtube.com/watch?v=cOdgBBV4J3sfeature=youtu.be

Hm.. syntax highlighting - nice.
Looks like you have a nice syntax highlighting, line numbering and etc. 
going on there, what did you use?

Really nice, and I see the source as in your private repo, cool. :)

--
Tom.


--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] enventor (an edc editor prototype)

2013-07-23 Thread Tom Hacohen

On 23/07/13 11:43, ChunEon Park wrote:
 just an entry. :-)
 still have many stuff to do with entry before first release.

 1. auto indentation.
 2. undo/redo.
 3. fix the entry object maximum size problem.

Cool. :)

--
Tom.


--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] enventor (an edc editor prototype)

2013-07-23 Thread The Rasterman

On Tue, 23 Jul 2013 11:07:30 +0900 Sung W. Park sung...@gmail.com said:

 Looks really nice hermet! :)
 
 what's wrong with 'enventor'???  it totally makes sense you know, like all
 the other names.  i'm surprised that terminology wasn't name eterminology
 ;-)

espion, evas, edje, eet, ecore, elementary, efl, eina, enna, entrance, eterm,
exactness, enlightenment, entice, ephoto, elev8, ecrire, enjoy, emotion,
embryo, efreet, eio, eldbus, ephysics, expedite, ... just to name a few... too
many e things with too little idea of which does what.

i chose enlightenment as a word.. because it invoked an idea. a feeling. it
wasn't an excuse to just call everything e*. this is like the wm naming i
was trying to break from. everything was twm, fvm, ctwm, olvwm, mwm etc...
because people had no imagination to come up with something more emotive.

inventor is great name on its own. its simple and clear. no need to hack at
it by replacing the i with an e and create yet more stuff starting with e that
people find it hard to pick apart. break away! choose words that have a
meaning. that bring up images/feelings that convey a message. inventor is
already great! :)

 cheers,
 Sung
 
 
 On Tue, Jul 23, 2013 at 10:52 AM, Carsten Haitzler
 ras...@rasterman.comwrote:
 
  On Tue, 23 Jul 2013 02:42:10 +0900 (KST) ChunEon Park her...@naver.com
  said:
 
   http://www.youtube.com/watch?v=cOdgBBV4J3sfeature=youtu.be
 
  just call it inventor. enough of the e stuff. it sounds stupid to mangle
  words to stuff an e on the front. we have so much of it that people already
  can't keep track of what is what.
 
  --
  - Codito, ergo sum - I code, therefore I am --
  The Rasterman (Carsten Haitzler)ras...@rasterman.com
 
 
 
  --
  See everything from the browser to the database with AppDynamics
  Get end-to-end visibility with application monitoring from AppDynamics
  Isolate bottlenecks and diagnose root cause in seconds.
  Start your free trial of AppDynamics Pro today!
  http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 ___
 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


--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] systemd: change from simple e18 service to target

2013-07-23 Thread Leif Middelschulte

Hello everyone,

If this lands, https://phab.enlightenment.org/w/e18_with_systemd_user_session/ 
should be updated.  

--  
Leif


Am Samstag, 20. Juli 2013 um 16:50 schrieb Thomas Gstädtner:

  
 This has a few advantages over the current approach:
 - only depends on user-session-units, not the flawed systemd-user-units
 - allows isolating the target to switch between e.g. e17 and e18 at
 runtime
 - works much more reliably for me
  
 Important: please don't commit without review by Cedric!
 ---
 data/units/Makefile.am (http://Makefile.am) | 6 +-
 data/units/e18.service | 9 +++--
 data/units/e18.target | 6 ++
 3 files changed, 14 insertions(+), 7 deletions(-)
 create mode 100644 data/units/e18.target
  
 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
  
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net 
 (mailto:enlightenment-devel@lists.sourceforge.net)
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
  
  
  
  
 Anhänge:  
 - 0001-systemd-change-from-simple-e18-service-to-target.patch
  


--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo: potential improvements

2013-07-23 Thread Tom Hacohen

On 12/07/13 07:42, Carsten Haitzler (The Rasterman) wrote:
 On Mon, 08 Jul 2013 18:00:15 +0100 Tom Hacohen tom.haco...@samsung.com said:

 ok. looked at eo2test.c

 eo2_do(obj,
   a = inst_func(eo_o, 32);
   inst_func(eo_o, 10);
   b = inst_func(eo_o, 50);
   );

 first... passing in eo_o... should probably go away. ie


Gustavo suggested (but he's too lazy to write an email about it and I 
need reminders so I'm sending it) that we use a stack to keep the eo 
pointer. This means we won't expose the eo pointer anymore (which 
doesn't matter, but whatever), we will be able to have function 
signatures the way we want them, e.g: evas_object_move(x, y), instead of 
passing anything and it should be cool in general. I'm happy, and will 
incorporate that unless objected. As long as we pre-allocate the stack 
it shouldn't come at a big cost.

What do you guys think?

--
Tom.


--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo: potential improvements

2013-07-23 Thread Gustavo Sverzut Barbieri

On Tue, Jul 23, 2013 at 11:47 AM, Tom Hacohen tom.haco...@samsung.com wrote:
 On 12/07/13 07:42, Carsten Haitzler (The Rasterman) wrote:
 On Mon, 08 Jul 2013 18:00:15 +0100 Tom Hacohen tom.haco...@samsung.com 
 said:

 ok. looked at eo2test.c

 eo2_do(obj,
   a = inst_func(eo_o, 32);
   inst_func(eo_o, 10);
   b = inst_func(eo_o, 50);
   );

 first... passing in eo_o... should probably go away. ie


 Gustavo suggested (but he's too lazy to write an email about it and I
 need reminders so I'm sending it) that we use a stack to keep the eo
 pointer. This means we won't expose the eo pointer anymore (which
 doesn't matter, but whatever), we will be able to have function
 signatures the way we want them, e.g: evas_object_move(x, y), instead of
 passing anything and it should be cool in general. I'm happy, and will
 incorporate that unless objected. As long as we pre-allocate the stack
 it shouldn't come at a big cost.

 What do you guys think?

just a reminder this stack should be per thread, in a
thread-local-storage region.

for single calls it should be worse as we set-call-unset, but for
multiple calls that may pay off. The readability is much better this
way, at least it would be similar to previous code where we got the
private data.

the con I could see is we loose validation in the caller, you'd need
to validate in the function... Example:
eo_do(evas_obj, ecore_timer_interval_set(10.0));
this would still call directly ecore_timer_interval_set(), which
internally would get the eo_o, which should be validated and return if
not right. All in all that would be the case, as
ecore_timer_interval_set() would need to get the actual method
(virtual) to call.

I did not read the whole thread, so that may be addressed in another
way. From the above example this could happen as well, inst_func()
also has a potential of not being a method of obj.


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo: potential improvements

2013-07-23 Thread Tom Hacohen

On 23/07/13 02:51, Carsten Haitzler (The Rasterman) wrote:
 On Mon, 22 Jul 2013 17:30:17 +0100 Tom Hacohen tom.haco...@samsung.com said:

 On 21/07/13 14:18, Jérémy Zurcher wrote:
 Hello from my holiday in France (for the frenchies who know lofofora ;)

 On Friday 12 July 2013  15:42, Carsten Haitzler wrote :
 On Mon, 08 Jul 2013 18:00:15 +0100 Tom Hacohen tom.haco...@samsung.com
 said:

 ok. looked at eo2test.c

  eo2_do(obj,
a = inst_func(eo_o, 32);
inst_func(eo_o, 10);
b = inst_func(eo_o, 50);
);

 first... passing in eo_o... should probably go away. ie

  eo2_do(obj,
a = inst_func(32);
inst_func(10);
b = inst_func(50);
);

 the declaration is
 EAPI int inst_func_set(eo2_a, int a, int b);

 expanded to
 EAPI int inst_func_set( _Eo *obj, Eo *objid, int a, int b);

 what I first proposed was using a second macro
   eo2_do(obj,
 sum = eo_call(inst_func_set, 32, 12);
 a = eo_call(inst_func_get_a);
 );

 would it be better ?
 (Tom, I don't love it, that's just handy ;)

 I don't like it because it doesn't look like c code any more. This means
 that what Carsten is asking for can't be done.

 of course it looks like c. it just is not c that you are used to seeing. if we
 make it look like c  (that is the plain simple funca(x); funcb(x, y); funcc
 (x, y, z);), then we can't really do eo at all. you're SOL. we NEED to be able
 to.

 1. begin a block of operations by dereferencing the objid to a ptr AND ref()
 the obj.
 2. allow N operations to work on the currently bound context object ptr 
 after
 lookup/checks
 3. when all of #2 are done, unref the obj again.

 we need this to compensate for objid indirection. amortizing the cost is part
 of the premise of doing eo. objid's are an absolute must for many reasons
 already explained. you know them as well as i do.

You got me wrong. I was talking about the eo_call(inst_func_get_a) 
convention which I don't like. Anyhow, Gustavo suggested a nice idea 
that I've sent in another email on this thread, take a look, I think it 
can do everything we need.


 so as i see it.. your choice is - forget eo entirely, or live with the fact
 that it introduces a usage of c that looks odd to you. you'll get used to it.
 the varargs solution means the compiler disallows arbitrary code in the block
 and makes it much safer - you can't shoot yourself in the foot as easily 
 (don't
 think you, or me - think someone new to efl who sees how to do this and then
 starts thinking they can do if (method(x)) return; etc. etc. - they wont read
 docs telling them they can't do this. it will be an obvious next step to 
 them).
 if you do it the eo2 way you need to somehow try to alert the user to NOT do
 this. if you use nested do{}while(0);s then you can use ONLY break (or 
 continue
 actually), but not return. i can't think of a way of erroring out or warning a
 user that return is disallowed within this block.


Told you, I have a solution for that. We can just pass them as 
parameters to a function we are calling that does nothing and is just 
static inline. So the func declaration will be:
static inline void bla(void *a, ...)
{
}

and in the macro we'll do:

code
do {
__VA_ARGS__ // (like we do now)
} while (0);
if (0)
bla(__VA_ARGS__) // this will do the checking for us.
/code

we can't just do the bla thing because parameter evaluation order is not 
defined in the standard.


 secondly, having a = ; with ; too.. is going to start encouraging
 people to do really bad things like:

  eo2_do(obj,
if (inst_func(32) != 22) return;
inst_func(10);
b = inst_func(50);
);

 and all sorts of hell is going to break loose here. i don't believe that
 as a result of returns we can now sensibly handle method errors from an
 eo_do() batch. if we are using returns for errors we SHOULD have something
 like:

 well the rule is really simple to document and explain:
 use break not return in e eo2_do() construct

 It's better to have enforcement by the compiler.

 i agree. in that respect varargs are better. the macros do typechecking and 
 arg
 count checks so we are essentially ok unless you KNOW its varargs underneath
 and bypass the method macros. this requires much more understanding and 
 reading
 of docs/headers so i'd guess this is ok.



 Eo_Err err;

 err = eo_do(obj,
   a = inst_func(32);
   inst_func(10);
   b = inst_func(50);
   );
 if (err.error == inst_func1_id) return; // inst_func1 method id is what
 failed

 we have no more function id in the latest prototype,
 but this disallow EAPI static inline func();

 I'm waiting for comments from Tom and others about this.

 if (err.failedop == 2) return; // in a batch, operations are counted, 0,
 1, 2 // so op id 2 (last one) failed here
 if (err.type == EO_ERR_INVALID_VALUE) return; // can

Re: [E-devel] Eo: potential improvements

2013-07-23 Thread Jérémy Zurcher

On Tuesday 23 July 2013  15:47, Tom Hacohen wrote :
 On 12/07/13 07:42, Carsten Haitzler (The Rasterman) wrote:
  On Mon, 08 Jul 2013 18:00:15 +0100 Tom Hacohen tom.haco...@samsung.com 
  said:
 
  ok. looked at eo2test.c
 
  eo2_do(obj,
a = inst_func(eo_o, 32);
inst_func(eo_o, 10);
b = inst_func(eo_o, 50);
);
 
  first... passing in eo_o... should probably go away. ie
 
 
 Gustavo suggested (but he's too lazy to write an email about it and I 
 need reminders so I'm sending it) that we use a stack to keep the eo 
 pointer. This means we won't expose the eo pointer anymore (which 
 doesn't matter, but whatever), we will be able to have function 
 signatures the way we want them, e.g: evas_object_move(x, y), instead of 
 passing anything and it should be cool in general. I'm happy, and will 
 incorporate that unless objected. As long as we pre-allocate the stack 
 it shouldn't come at a big cost.
 
 What do you guys think?

I think that's perfect, this is where I wanted to go next with my sandbox branch
  - remove eo2_a from EAPI signature (the Eo2_Call_Ctx)
  - transform the static Eo2_Call_Data into a per thread stack
as you talked about eo2_do calls inside each others and I saw them
in eo_base_class

  I think we should incorporate 'class_data' ptr with obj ptr in the stack 
frame, computed as needed

  btw I think that naming the object private data 'class_data' is very wrong in 
a OO way,
  that's object variables not class variables.

 
 --
 Tom.
 
 
--- Hell'O from Yverdoom

Jérémy (jeyzu)

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo: potential improvements

2013-07-23 Thread Jérémy Zurcher

just to clarify a few points:

- I think the less macro we have in an eo class declaration the best,
  actually we have nothing but that extra first parameter called eo2_o, wich
  is either an obj_ptr (devs/tasn/eo2) or a call_ctx (devs/jeyzu/eo2)

  this should go away if we use a stack per thread in eo private code,
  so we end up with a clean
  EAPI float times(float f, float t);

- since day 1 break is supported in eo2_do:
  #define eo2_do(obj_id, ...)
  do
{
   obj_ptr_or_ctx = eo2_do_start(obj_id);
   if(!obj_ptr_or_ctx) break;
   do { __VA_ARGS__ ; } while (0);
   eo2_do_end(obj_ptr_or_ctx);
} while (0)

- EAPI static inline func() and overriding worked
  untill I used eapi symbol address instead of OPID
  it's a 2 hops game: EAPI func() { f = eo2_get_real_func_ptr(OPID, OBJ); 
return f(OBJ, OBJ_DATA, _args_) };

  is it ok for everyone to forget about EAPI static inline ?

On Monday 22 July 2013  14:45, Carsten Haitzler wrote :
 On Mon, 22 Jul 2013 10:24:03 +0900 Cedric BAIL cedric.b...@free.fr said:
 
  On Mon, Jul 22, 2013 at 8:55 AM, Carsten Haitzler ras...@rasterman.com
  wrote:
   On Sun, 21 Jul 2013 15:18:02 +0200 Jérémy Zurcher jer...@asynk.ch said:
   Hello from my holiday in France (for the frenchies who know lofofora ;)
  
  Enjoy !
  
   On Friday 12 July 2013  15:42, Carsten Haitzler wrote :
On Mon, 08 Jul 2013 18:00:15 +0100 Tom Hacohen 
tom.haco...@samsung.com
said:
   
ok. looked at eo2test.c
   
   eo2_do(obj,
 a = inst_func(eo_o, 32);
 inst_func(eo_o, 10);
 b = inst_func(eo_o, 50);
 );
   
first... passing in eo_o... should probably go away. ie
   
   eo2_do(obj,
 a = inst_func(32);
 inst_func(10);
 b = inst_func(50);
 );
  
   the declaration is
   EAPI int inst_func_set(eo2_a, int a, int b);
  
   expanded to
   EAPI int inst_func_set( _Eo *obj, Eo *objid, int a, int b);
  
   what I first proposed was using a second macro
   eo2_do(obj,
 sum = eo_call(inst_func_set, 32, 12);
 a = eo_call(inst_func_get_a);
 );
  
   would it be better ?
   (Tom, I don't love it, that's just handy ;)
  
   i dont see why? make inst_func() a macro that defines to inst_func_real
   (__cur_obj, ...) eo2_do() defines a local var for __cur_obj when obj is
   looked-up (so lookup happens only once per do block).
  
secondly, having a = ; with ; too.. is going to start encouraging
people to do really bad things like:
   
   eo2_do(obj,
 if (inst_func(32) != 22) return;
 inst_func(10);
 b = inst_func(50);
 );
   
and all sorts of hell is going to break loose here. i don't believe 
that
as a result of returns we can now sensibly handle method errors from an
eo_do() batch. if we are using returns for errors we SHOULD have
something like:
  
   well the rule is really simple to document and explain:
 use break not return in e eo2_do() construct
  
   next problem. if we ref() on do start and unref() on end of do... this 
   just
   broke it. any form of breaking out will break stuff badly (break, return,
   continue).
  
  Not break. It is easy to make it work without using macro. We just
  embedded it into a do { } while (0); loop and the break will work just
  fine. The problem will be that the semantic of continue will not be
  related to a loop where eo_do is running, but to eo_do code itself. I
  would just strongly advise in the documentation to not use those
  trick.
 
 we need 2 do {} while's then... :)
 
Eo_Err err;
   
err = eo_do(obj,
a = inst_func(32);
inst_func(10);
b = inst_func(50);
);
if (err.error == inst_func1_id) return; // inst_func1 method id is what
failed
  
   we have no more function id in the latest prototype,
   but this disallow EAPI static inline func();
  
   I'm waiting for comments from Tom and others about this.
  
   static inline is  incompatible with things like method overriding at
   runtime anyway :) but still... imho the now we have returns we can get
   errors is a bogus claim, because of the previous point... you can get..
   but you cant DO anything useful (return, break, continue)... UNLESS you
   provide a macro that cleanly aborts the do block (example - #define
   eo2_break() _eo_unref(__cur_obj); break). i was just showing how errors
   could be done very simply with the current eo api by returning an eo_err
   struct, rather than a single bool.
  
if (err.failedop == 2) return; // in a batch, operations are counted, 
0,
1, 2 // so op id 2 (last one) failed here
if (err.type == EO_ERR_INVALID_VALUE) return; // can put err inside a
type field.
   
note that this is using an error return as a struct, not a basic type
(int, pointer, char, etc.), and this is perfectly valid and correct

Re: [E-devel] [PATCH] systemd: change from simple e18 service to target

2013-07-23 Thread thomasg

On Tue, Jul 23, 2013 at 2:31 PM, Leif Middelschulte
leif.middelschu...@gmail.com wrote:
 Hello everyone,

 If this lands, 
 https://phab.enlightenment.org/w/e18_with_systemd_user_session/ should be 
 updated.

 --
 Leif


I will do that once it is in. I talked to Cedric already and am
waiting until he gets his systemd machine running again and tests it.
In the meantime, if you want to test it: There isn't actually much
changing, just ignore the systemd-user-units part of the article and
everything will be fine (in fact, the current howto isn't enough to
use it like described anyway, it is much more likely that you get the
new stuff working with it than the existing one :).
Other than that, simply use the documentation of sofar's
user-session-units and replace e17 by e18, it is fully compatible to
this and should work on any machine with systemd (not just arch).

Sidenote: There still is a bug with systemd's watchdog in E, so the
watchdog doesn't actually work, but that's not directly related to
this and happens with both approaches. I will have a look at this,
soon.


 Am Samstag, 20. Juli 2013 um 16:50 schrieb Thomas Gstädtner:


 This has a few advantages over the current approach:
 - only depends on user-session-units, not the flawed systemd-user-units
 - allows isolating the target to switch between e.g. e17 and e18 at
 runtime
 - works much more reliably for me

 Important: please don't commit without review by Cedric!
 ---
 data/units/Makefile.am (http://Makefile.am) | 6 +-
 data/units/e18.service | 9 +++--
 data/units/e18.target | 6 ++
 3 files changed, 14 insertions(+), 7 deletions(-)
 create mode 100644 data/units/e18.target

 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk

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




 Anhänge:
 - 0001-systemd-change-from-simple-e18-service-to-target.patch



 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] enventor (an edc editor prototype)

2013-07-23 Thread thomasg

On Tue, Jul 23, 2013 at 7:32 AM, Carsten Haitzler ras...@rasterman.com wrote:
 On Tue, 23 Jul 2013 11:07:30 +0900 Sung W. Park sung...@gmail.com said:

 Looks really nice hermet! :)

 what's wrong with 'enventor'???  it totally makes sense you know, like all
 the other names.  i'm surprised that terminology wasn't name eterminology
 ;-)

 espion, evas, edje, eet, ecore, elementary, efl, eina, enna, entrance, eterm,
 exactness, enlightenment, entice, ephoto, elev8, ecrire, enjoy, emotion,
 embryo, efreet, eio, eldbus, ephysics, expedite, ... just to name a few... too
 many e things with too little idea of which does what.

 i chose enlightenment as a word.. because it invoked an idea. a feeling. it
 wasn't an excuse to just call everything e*. this is like the wm naming i
 was trying to break from. everything was twm, fvm, ctwm, olvwm, mwm etc...
 because people had no imagination to come up with something more emotive.

 inventor is great name on its own. its simple and clear. no need to hack at
 it by replacing the i with an e and create yet more stuff starting with e that
 people find it hard to pick apart. break away! choose words that have a
 meaning. that bring up images/feelings that convey a message. inventor is
 already great! :)


However, a name should be somewhat unique I think. Call it inventor
and nobody will be able to google it.
The next problem here is, that calling it inventor is highly likely a
trademark problem, because there is a commercial, widely used software
called Inventor (it's a CAD software, but that's close enough to be
in conflict).

Anyway, I like Enventor - it's very clearly derived from inventor and
thus just as clear, but it is also unique.

 cheers,
 Sung


 On Tue, Jul 23, 2013 at 10:52 AM, Carsten Haitzler
 ras...@rasterman.comwrote:

  On Tue, 23 Jul 2013 02:42:10 +0900 (KST) ChunEon Park her...@naver.com
  said:
 
   http://www.youtube.com/watch?v=cOdgBBV4J3sfeature=youtu.be
 
  just call it inventor. enough of the e stuff. it sounds stupid to mangle
  words to stuff an e on the front. we have so much of it that people already
  can't keep track of what is what.
 
  --
  - Codito, ergo sum - I code, therefore I am --
  The Rasterman (Carsten Haitzler)ras...@rasterman.com
 
 
 
  --
  See everything from the browser to the database with AppDynamics
  Get end-to-end visibility with application monitoring from AppDynamics
  Isolate bottlenecks and diagnose root cause in seconds.
  Start your free trial of AppDynamics Pro today!
  http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 ___
 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


 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] enventor (an edc editor prototype)

2013-07-23 Thread ChunEon Park

Inventor is simple and intutive word but doesn't impact on people (at least 
on me.)
Enventor sounds something different and sounds as if it's a special one.

I like Enventor than Inventor.


-Regards, Hermet- 

-Original Message-
From: thomasgtho...@gstaedtner.net 
To: Enlightenment developer listenlightenment-devel@lists.sourceforge.net; 
Cc: 
Sent: 2013-07-24 (수) 01:48:40
Subject: Re: [E-devel] enventor (an edc editor prototype)

On Tue, Jul 23, 2013 at 7:32 AM, Carsten Haitzler raster@rasterman.com wrote:
 On Tue, 23 Jul 2013 11:07:30 +0900 Sung W. Park sungwoo@gmail.com said:

 Looks really nice hermet! :)

 what's wrong with 'enventor'???  it totally makes sense you know, like all
 the other names.  i'm surprised that terminology wasn't name eterminology
 ;-)

 espion, evas, edje, eet, ecore, elementary, efl, eina, enna, entrance, eterm,
 exactness, enlightenment, entice, ephoto, elev8, ecrire, enjoy, emotion,
 embryo, efreet, eio, eldbus, ephysics, expedite, ... just to name a few... too
 many e things with too little idea of which does what.

 i chose enlightenment as a word.. because it invoked an idea. a feeling. it
 wasn't an excuse to just call everything e*. this is like the wm naming i
 was trying to break from. everything was twm, fvm, ctwm, olvwm, mwm etc...
 because people had no imagination to come up with something more emotive.

 inventor is great name on its own. its simple and clear. no need to hack at
 it by replacing the i with an e and create yet more stuff starting with e that
 people find it hard to pick apart. break away! choose words that have a
 meaning. that bring up images/feelings that convey a message. inventor is
 already great! :)


However, a name should be somewhat unique I think. Call it inventor
and nobody will be able to google it.
The next problem here is, that calling it inventor is highly likely a
trademark problem, because there is a commercial, widely used software
called Inventor (it's a CAD software, but that's close enough to be
in conflict).

Anyway, I like Enventor - it's very clearly derived from inventor and
thus just as clear, but it is also unique.

 cheers,
 Sung


 On Tue, Jul 23, 2013 at 10:52 AM, Carsten Haitzler
 raster@rasterman.comwrote:

  On Tue, 23 Jul 2013 02:42:10 +0900 (KST) ChunEon Park hermet@naver.com
  said:
 
   http://www.youtube.com/watch?v=cOdgBBV4J3sfeature=youtu.be
 
  just call it inventor. enough of the e stuff. it sounds stupid to mangle
  words to stuff an e on the front. we have so much of it that people already
  can't keep track of what is what.
 
  --
  - Codito, ergo sum - I code, therefore I am --
  The Rasterman (Carsten Haitzler)ras...@rasterman.com
 
 
 
  --
  See everything from the browser to the database with AppDynamics
  Get end-to-end visibility with application monitoring from AppDynamics
  Isolate bottlenecks and diagnose root cause in seconds.
  Start your free trial of AppDynamics Pro today!
  http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 ___
 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


 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of

Re: [E-devel] Eo: potential improvements

2013-07-23 Thread The Rasterman

On Tue, 23 Jul 2013 18:22:02 +0200 Jérémy Zurcher jer...@asynk.ch said:

 just to clarify a few points:
 
 - I think the less macro we have in an eo class declaration the best,
   actually we have nothing but that extra first parameter called eo2_o, wich
   is either an obj_ptr (devs/tasn/eo2) or a call_ctx (devs/jeyzu/eo2)
 
   this should go away if we use a stack per thread in eo private code,
   so we end up with a clean
   EAPI float times(float f, float t);
 
 - since day 1 break is supported in eo2_do:
   #define eo2_do(obj_id, ...)
   do
 {
obj_ptr_or_ctx = eo2_do_start(obj_id);
if(!obj_ptr_or_ctx) break;
do { __VA_ARGS__ ; } while (0);
eo2_do_end(obj_ptr_or_ctx);
 } while (0)

i'm worried about people doing return there. seriously - objid came in becau se
of experience that people using efl are in general inexperienced programmers
who don't take the time to do things right. they do things quickly and take
shortcuts, and they ignore warnings. they'd rather patch out abort()s in efl
code forcing them to fix their bugs, than fix their bugs. i am fearful that
they will stuff in returns quite happily and think it mostly works most of the
time... and then find subtle issues and waste our time finding them.

how do we protect/stop returns (or goto's for that matter) within the while
block. i looked for some pragmas - can't find any to do this. this would be a
really useful compiler feature though (to maybe disable some constructs for a
sequence of code).

 - EAPI static inline func() and overriding worked
   untill I used eapi symbol address instead of OPID
   it's a 2 hops game: EAPI func() { f = eo2_get_real_func_ptr(OPID, OBJ);
 return f(OBJ, OBJ_DATA, _args_) };
 
   is it ok for everyone to forget about EAPI static inline ?

as long as the method the programmer sees is

method(p1, p2);
NOT
method(obj, p1, p2);

:) (ie its wrapped in a macro)

 On Monday 22 July 2013  14:45, Carsten Haitzler wrote :
  On Mon, 22 Jul 2013 10:24:03 +0900 Cedric BAIL cedric.b...@free.fr said:
  
   On Mon, Jul 22, 2013 at 8:55 AM, Carsten Haitzler ras...@rasterman.com
   wrote:
On Sun, 21 Jul 2013 15:18:02 +0200 Jérémy Zurcher jer...@asynk.ch
said:
Hello from my holiday in France (for the frenchies who know lofofora ;)
   
   Enjoy !
   
On Friday 12 July 2013  15:42, Carsten Haitzler wrote :
 On Mon, 08 Jul 2013 18:00:15 +0100 Tom Hacohen
 tom.haco...@samsung.com said:

 ok. looked at eo2test.c

eo2_do(obj,
  a = inst_func(eo_o, 32);
  inst_func(eo_o, 10);
  b = inst_func(eo_o, 50);
  );

 first... passing in eo_o... should probably go away. ie

eo2_do(obj,
  a = inst_func(32);
  inst_func(10);
  b = inst_func(50);
  );
   
the declaration is
EAPI int inst_func_set(eo2_a, int a, int b);
   
expanded to
EAPI int inst_func_set( _Eo *obj, Eo *objid, int a, int b);
   
what I first proposed was using a second macro
eo2_do(obj,
  sum = eo_call(inst_func_set, 32, 12);
  a = eo_call(inst_func_get_a);
  );
   
would it be better ?
(Tom, I don't love it, that's just handy ;)
   
i dont see why? make inst_func() a macro that defines to inst_func_real
(__cur_obj, ...) eo2_do() defines a local var for __cur_obj when obj is
looked-up (so lookup happens only once per do block).
   
 secondly, having a = ; with ; too.. is going to start encouraging
 people to do really bad things like:

eo2_do(obj,
  if (inst_func(32) != 22) return;
  inst_func(10);
  b = inst_func(50);
  );

 and all sorts of hell is going to break loose here. i don't believe
 that as a result of returns we can now sensibly handle method errors
 from an eo_do() batch. if we are using returns for errors we SHOULD
 have something like:
   
well the rule is really simple to document and explain:
  use break not return in e eo2_do() construct
   
next problem. if we ref() on do start and unref() on end of do... this
just broke it. any form of breaking out will break stuff badly (break,
return, continue).
   
   Not break. It is easy to make it work without using macro. We just
   embedded it into a do { } while (0); loop and the break will work just
   fine. The problem will be that the semantic of continue will not be
   related to a loop where eo_do is running, but to eo_do code itself. I
   would just strongly advise in the documentation to not use those
   trick.
  
  we need 2 do {} while's then... :)
  
 Eo_Err err;

 err = eo_do(obj,
 a = inst_func(32);
 inst_func(10);
 b = inst_func(50);
 );
 if (err.error == inst_func1_id) return; // inst_func1 method id is
 what failed
   
we have no

[E-devel] Fwd: Re: [EGIT] [core/elementary] master 01/01: elementary/widget - use eina_inlist in transate data to improve memory access / allocations.

2013-07-23 Thread ChunEon Park

I reviewed the code right before and found that was incorrect.
Fixed.  commit 9560669f925cfd875c80cc212b32c6d1499d0e78

Thanks you for catching it. :)
 

-Regards, Hermet- 

-Original Message-
From: daniel.za...@samsung.comdaniel.zaoui@samsung.com 
To: hermet@hermet.pe.kr; 
Cc: 
Sent: 2013-07-23 (화) 00:12:23
Subject: Fwd: Re: [E-devel] [EGIT] [core/elementary] master 01/01: 
elementary/widget - use eina_inlist in transate data to improve memory access / 
allocations.

  FYI


  
   Original Message   Subject:Re: 
[E-devel] [EGIT] [core/elementary] master 01/01:  elementary/widget 
- use eina_inlist in transate data to  improve memory access / 
allocations.
Date: Mon, 22 Jul 2013 17:30:20 +0300
From: daniel.za...@samsung.com  daniel.zaoui@samsung.com
Reply-To:Enlightenment developer list  
enlightenment-devel@lists.sourceforge.net
To: enlightenment-devel@lists.sourceforge.net
CC: ChunEon Park - Enlightenment Git  no-reply@enlightenment.org

  
  Hi Hermet,I have an issue with that commit. In Tizen, I am almost sure it 
sigsegvs because of the change from list to inlist. In 
_translate_string_data_get, ts = NULL is done before the it-next of the loop. 
I say I am almost sure because gdb gives me a ts not NULL and sigsegvs on the 
line before, on the comparison that is false.Can you check that, please?By the 
way, if setting to NULL is used to exit and break too, do you know why we need 
the comparison? It is really weird for me. I supposed I missed something 
here.Thank youJackDanielZ, alias DanielOn 07/17/2013 09:06 AM, ChunEon Park - 
Enlightenment Git wrote: hermet pushed a commit to branch master. commit 
6c7b2afd9bb8767a2d90c48a3b7e68a650585d71 Author: ChunEon Park 
hermet@hermet.pe.kr Date:   Wed Jul 17 15:05:40 2013 +0900  
elementary/widget - use eina_inlist in transate data to improve memory access / 
allocations. ---   src/lib/elm_widget.c  35 
+--   src/lib/elm_widget.h   4 ++--   2 files 
changed, 23 insertions(+), 16 deletions(-) diff --git a/src/lib/elm_widget.c 
b/src/lib/elm_widget.c index f3d2fe9..370fb67 100644 --- 
a/src/lib/elm_widget.c +++ b/src/lib/elm_widget.c @@ -40,6 +40,7 @@ struct 
_Elm_Event_Cb_Data  struct _Elm_Translate_String_Data   { +   
EINA_INLIST;  Eina_Stringshare *id;  Eina_Stringshare *domain;  
Eina_Stringshare *string; @@ -305,11 +306,15 @@ _elm_widget_smart_del(Eo *obj, 
void *_pd, va_list *list EINA_UNUSED)}  sd-tooltips = 
eina_list_free(sd-tooltips); /* should be empty anyway */  sd-cursors = 
eina_list_free(sd-cursors); /* should be empty anyway */ -   
EINA_LIST_FREE(sd-translate_strings, ts) +   while (sd-translate_strings)   
 { +ts = EINA_INLIST_CONTAINER_GET(sd-translate_strings, +   
Elm_Translate_String_Data);   
eina_stringshare_del(ts-id);   eina_stringshare_del(ts-domain); 
  eina_stringshare_del(ts-string); +sd-translate_strings = 
eina_inlist_remove(sd-translate_strings, +
   sd-translate_strings);   free(ts);}@@ 
-3815,16 +3820,15 @@ elm_widget_domain_translatable_part_text_set(Evas_Object 
*obj,   }  static Elm_Translate_String_Data * 
-_translate_string_data_get(Eina_List *translate_strings, const char *part) 
+_translate_string_data_get(Eina_Inlist *translate_strings, const char *part)  
 {  Elm_Translate_String_Data *ts;  Eina_Stringshare *str; -   
Eina_List *l;-   if (eina_list_count(translate_strings) == 0) return 
NULL; +   if (!translate_strings) return NULL; str = 
eina_stringshare_add(part); -   EINA_LIST_FOREACH(translate_strings, l, ts) + 
  EINA_INLIST_FOREACH(translate_strings, ts){   if (ts-id == 
str) break;   else ts = NULL; @@ -3835,9 +3839,9 @@ 
_translate_string_data_get(Eina_List *translate_strings, const char *part)   
}  static Elm_Translate_String_Data * 
-_part_text_translatable_set(Eina_List **translate_strings, const char *part, 
Eina_Bool translatable, Eina_Bool preset) 
+_part_text_translatable_set(Eina_Inlist **translate_strings, const char *part, 
Eina_Bool translatable, Eina_Bool preset)   { -   Eina_List *t; +   
Eina_Inlist *t;  Elm_Translate_String_Data *ts;  t = 
*translate_strings;  ts = _translate_string_data_get(t, part); @@ -3850,7 
+3854,7 @@ _part_text_translatable_set(Eina_List **translate_strings, const 
char *part, Einif (!ts) return NULL;   
ts-id = eina_stringshare_add(part); - t = eina_list_append(t, 
ts); + t = eina_inlist_append(t, (Eina_Inlist*) ts); 
}   if (preset) ts-preset = EINA_TRUE;} @@ -3860,7 +3864,7 
@@

Re: [E-devel] [EGIT] [core/efl] master 02/02: Evas: adding image dump debug feature for wayland_egl backend

Re: [E-devel] [EGIT] [core/efl] master 02/02: Evas: adding image dump debug feature for wayland_egl backend

Re: [E-devel] [EGIT] [core/efl] master 02/02: Evas: adding image dump debug feature for wayland_egl backend

[E-devel] EFL Beta API

Re: [E-devel] EFL Beta API

Re: [E-devel] EFL Beta API

Re: [E-devel] EFL Beta API

Re: [E-devel] EFL Beta API

Re: [E-devel] enventor (an edc editor prototype)

Re: [E-devel] E SVN: tasn trunk/elementary/src/lib

Re: [E-devel] EFL Beta API

Re: [E-devel] enventor (an edc editor prototype)

Re: [E-devel] enventor (an edc editor prototype)

Re: [E-devel] enventor (an edc editor prototype)

Re: [E-devel] [PATCH] systemd: change from simple e18 service to target

Re: [E-devel] Eo: potential improvements

Re: [E-devel] Eo: potential improvements

Re: [E-devel] Eo: potential improvements

Re: [E-devel] Eo: potential improvements

Re: [E-devel] Eo: potential improvements

Re: [E-devel] [PATCH] systemd: change from simple e18 service to target

Re: [E-devel] enventor (an edc editor prototype)

Re: [E-devel] enventor (an edc editor prototype)

Re: [E-devel] Eo: potential improvements

[E-devel] Fwd: Re: [EGIT] [core/elementary] master 01/01: elementary/widget - use eina_inlist in transate data to improve memory access / allocations.

25 matches

Site Navigation

Mail list logo

Footer information