Re: [E-devel] [Elc_Naviframe]: Crash on evas_object_del fix.

[Daniel Juyung Seo]

Dear Shilpa,
it doesn't crash here.

Do you have any reproducable code?
I tried with the following code.

--- a/elementary/src/bin/test_naviframe.c
+++ b/elementary/src/bin/test_naviframe.c
@@ -190,6 +190,10 @@ _page2(void *data, Evas_Object *obj __UNUSED__, void
*event_info __UNUSED__)
Evas_Object *bt, *content, *ic, *nf = data;
Elm_Object_Item *it;

+elm_naviframe_item_pop(data);
+evas_object_del(data);
+return;
+
bt = elm_button_add(nf);
evas_object_size_hint_align_set(bt, EVAS_HINT_FILL, EVAS_HINT_FILL);
evas_object_smart_callback_add(bt, "clicked", _page3, nf);

Daniel Juyung Seo (SeoZ)

On Thu, Dec 6, 2012 at 3:51 PM, SHILPA ONKAR SINGH  wrote:

> Hi All,
>
> Please find attached bug fix patch for Naviframe.
> This patch fixes crash in naviframe which happens when evas_object_del
> is called immediately after item_pop.
>
> Change description:
>elc_naviframe: Crash on calling evas_object_del of naviframe
> immediately after item_pop fixed.
>
> Signed-Off by: Shilpa Singh(shilpa.si...@samsung.com)
>
> Thanks & Regards
> Shilpa Singh
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk/efl: . m4 src src/lib/eio

[Vincent Torri]

On Thu, Dec 6, 2012 at 7:37 AM, Vincent Torri  wrote:
> revert !!
>
> i want to let it where it was

and it breaks configuration on some debian

Vincent

>
> Vincent
>
> On Thu, Dec 6, 2012 at 1:57 AM, Enlightenment SVN
>  wrote:
>> Log:
>> efl: simplify inotify by moving it to common.
>>
>>   also deprecate very ancient inotify usage by direct syscall.
>>
>>
>>
>> Author:   barbieri
>> Date: 2012-12-05 16:57:29 -0800 (Wed, 05 Dec 2012)
>> New Revision: 80292
>> Trac: http://trac.enlightenment.org/e/changeset/80292
>>
>> Modified:
>>   trunk/efl/configure.ac trunk/efl/m4/eio_check_options.m4 
>> trunk/efl/src/Makefile_Eio.am trunk/efl/src/lib/eio/eio_monitor_inotify.c
>>
>> Modified: trunk/efl/configure.ac
>> ===
>> --- trunk/efl/configure.ac  2012-12-06 00:35:14 UTC (rev 80291)
>> +++ trunk/efl/configure.ac  2012-12-06 00:57:29 UTC (rev 80292)
>> @@ -104,6 +104,8 @@
>>
>>   Default values
>>
>> +want_inotify="no"
>> +
>>  requirements_pc_crypto=""
>>  requirements_pc_deps_crypto=""
>>  requirements_libs_crypto=""
>> @@ -277,6 +279,11 @@
>>MODULE_ARCH="$host_os-$host_cpu-v_maj.v_min.v_mic"
>>MODULE_EXT=".dll"
>> ;;
>> +   linux*)
>> +  want_inotify="yes"
>> +  MODULE_ARCH="$host_os-$host_cpu-v_maj.v_min.v_mic"
>> +  MODULE_EXT=".so"
>> +   ;;
>> *)
>>MODULE_ARCH="$host_os-$host_cpu-v_maj.v_min.v_mic"
>>MODULE_EXT=".so"
>> @@ -474,6 +481,17 @@
>>  unistd.h \
>>  ])
>>
>> +have_inotify="no"
>> +if test "x${want_inotify}" = "xyes" ; then
>> +   AC_CHECK_HEADER([sys/inotify.h],
>> +  [
>> +   AC_DEFINE([HAVE_INOTIFY], [1], [File monitoring with Inotify])
>> +   have_inotify="yes"
>> +  ],
>> +  [have_inotify="no"])
>> +fi
>> +AM_CONDITIONAL([HAVE_INOTIFY], [test "x${have_inotify}" = "xyes"])
>> +
>>  EFL_CHECK_PATH_MAX
>>
>>
>> @@ -1825,19 +1843,13 @@
>>
>>  # cserve2 only works on Linux so far.
>>
>> -if test "x${efl_func_shm_open}" = "xno" ; then
>> +if test "x${efl_func_shm_open}" = "xno" -o "x${have_inotify}" = "xno"; then
>> want_evas_cserve2="no"
>>  fi
>>
>> -if test "x${want_evas_cserve2}" = "xyes" ; then
>> -   AC_CHECK_HEADERS([sys/epoll.h sys/inotify.h sys/signalfd.h],
>> -  [],
>> -  [want_evas_cserve2="no"])
>> -fi
>> -
>> -if test "x${want_evas_cserve2}" = "xyes" ; then
>> -  AC_DEFINE([EVAS_CSERVE2], [1], [Shared cache server.])
>> -fi
>> +AC_DEFINE_IF([EVAS_CSERVE2],
>> +   [test "x${want_evas_cserve2}" = "xyes"],
>> +   [1], [Shared cache server.])
>>  AM_CONDITIONAL([EVAS_CSERVE2], [test "x${want_evas_cserve2}" = "xyes"])
>>
>>  ### Configuration
>> @@ -2368,18 +2380,6 @@
>> ],
>> [want_poll="yes"])
>>
>> -AC_ARG_ENABLE([inotify],
>> -   [AC_HELP_STRING([--disable-inotify],
>> -  [disable inotify in the ecore_file module. @<:@default=enabled@:>@])],
>> -   [
>> -if test "x${enableval}" = "xyes" ; then
>> -   want_inotify="yes"
>> -else
>> -   want_inotify="no"
>> -fi
>> -   ],
>> -   [want_inotify="yes"])
>> -
>>  AC_ARG_ENABLE([atfile-source],
>> [AC_HELP_STRING([--disable-atfile-source],
>> [disable use of atfile source functions as openat and mkdirat 
>> @<:@default=detect@:>@])],
>> @@ -2440,19 +2440,6 @@
>>
>>  ### Checks for header files
>>
>> -have_inotify="no"
>> -if test "x${want_inotify}" = "xyes" ; then
>> -   AC_CHECK_HEADER([sys/inotify.h],
>> -  [
>> -   AC_DEFINE([HAVE_INOTIFY], [1], [File monitoring with Inotify])
>> -   have_inotify="yes"
>> -  ],
>> -  [have_inotify="no"])
>> -fi
>> -
>> -AC_MSG_CHECKING([whether inotify is to be used for filemonitoring])
>> -AC_MSG_RESULT(${have_inotify})
>> -
>>  ### Checks for types
>>
>>  ### Checks for structures
>> @@ -3954,12 +3941,9 @@
>>  AC_MSG_RESULT([${have_xattr}])
>>
>>  # Check for inotify specificity
>> -have_inotify="no"
>>  have_notify_win32="no"
>> -EIO_CHECK_INOTIFY([have_inotify="yes"], [have_inotify="no"])
>>  EIO_CHECK_NOTIFY_WIN32([have_notify_win32="yes"], [have_notify_win32="no"])
>>
>> -AM_CONDITIONAL([EIO_HAVE_INOTIFY], [test "x${have_inotify}" = "xyes"])
>>  AM_CONDITIONAL([EIO_HAVE_WINCHANGE], [test "x${have_notify_win32}" = 
>> "xyes"])
>>
>>   End of Eio
>>
>> Modified: trunk/efl/m4/eio_check_options.m4
>> ===
>> --- trunk/efl/m4/eio_check_options.m4   2012-12-06 00:35:14 UTC (rev 80291)
>> +++ trunk/efl/m4/eio_check_options.m4   2012-12-06 00:57:29 UTC (rev 80292)
>> @@ -1,47 +1,3 @@
>> -dnl use: EIO_CHECK_INOTIFY([ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
>> -AC_DEFUN([EIO_CHECK_INOTIFY],
>> -[
>> -_eio_have_inotify="no"
>> -
>> -dnl We need to check if the right inotify version is accessible
>> -
>> -dnl It is hard to find a good test on how to check the correct
>> -dnl inotify version. They changed the headers a lot.
>> -dnl in kernel 2.6.13 __NR_inotify_init was added to the defined syscalls
>> -dnl 

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

[Christopher Michael]

On 06/12/12 09:20, Enlightenment SVN wrote:
> Log:
> elementary: let's not break the work when we don't use Wayland.
>

I disagree. If you don't use Wayland then you're world is already broken :P

Thanks for the fix ;)

dh



>
> Author:   cedric
> Date: 2012-12-06 01:20:37 -0800 (Thu, 06 Dec 2012)
> New Revision: 80325
> Trac: http://trac.enlightenment.org/e/changeset/80325
>
> Modified:
>trunk/elementary/src/lib/elm_win.c trunk/elementary/src/lib/elm_win.h
>
> Modified: trunk/elementary/src/lib/elm_win.c
> ===
> --- trunk/elementary/src/lib/elm_win.c2012-12-06 09:16:15 UTC (rev 
> 80324)
> +++ trunk/elementary/src/lib/elm_win.c2012-12-06 09:20:37 UTC (rev 
> 80325)
> @@ -5008,10 +5008,10 @@
>  *ret = 0;
>   }
>
> -#if HAVE_ELEMENTARY_WAYLAND
>   EAPI Ecore_Wl_Window *
>   elm_win_wl_window_get(const Evas_Object *obj)
>   {
> +#if HAVE_ELEMENTARY_WAYLAND
>  if (!obj) return NULL;
>
>  if (!evas_object_smart_type_check_ptr(obj, MY_CLASS_NAME))
> @@ -5024,8 +5024,12 @@
>  Ecore_Wl_Window *ret = NULL;
>  eo_do((Eo *) obj, elm_obj_win_wl_window_get(&ret));
>  return ret;
> +#else
> +   return NULL;
> +#end
>   }
>
> +#if HAVE_ELEMENTARY_WAYLAND
>   static void
>   _wl_window_get(Eo *obj EINA_UNUSED, void *_pd EINA_UNUSED, va_list *list)
>   {
> @@ -5043,7 +5047,7 @@
>}
>  *ret = NULL;
>   }
> -#endif
> +#endif
>
>   EAPI Eina_Bool
>   elm_win_trap_set(const Elm_Win_Trap *t)
> @@ -5200,7 +5204,9 @@
>   
> EO_OP_FUNC(ELM_OBJ_WIN_ID(ELM_OBJ_WIN_SUB_ID_FOCUS_HIGHLIGHT_STYLE_GET), 
> _focus_highlight_style_get),
>   EO_OP_FUNC(ELM_OBJ_WIN_ID(ELM_OBJ_WIN_SUB_ID_SOCKET_LISTEN), 
> _socket_listen),
>   EO_OP_FUNC(ELM_OBJ_WIN_ID(ELM_OBJ_WIN_SUB_ID_XWINDOW_GET), 
> _xwindow_get),
> +#if HAVE_ELEMENTARY_WAYLAND
>   EO_OP_FUNC(ELM_OBJ_WIN_ID(ELM_OBJ_WIN_SUB_ID_WL_WINDOW_GET), 
> _wl_window_get),
> +#endif
>   EO_OP_FUNC_SENTINEL
>  };
>
> @@ -5297,7 +5303,9 @@
>EO_OP_DESCRIPTION(ELM_OBJ_WIN_SUB_ID_FOCUS_HIGHLIGHT_STYLE_GET, "Get 
> the style set for the focus highlight object."),
>EO_OP_DESCRIPTION(ELM_OBJ_WIN_SUB_ID_SOCKET_LISTEN, "Create a socket 
> to provide the service for Plug widget."),
>EO_OP_DESCRIPTION(ELM_OBJ_WIN_SUB_ID_XWINDOW_GET, "Get the 
> Ecore_X_Window of an Evas_Object."),
> +#if HAVE_ELEMENTARY_WAYLAND
>EO_OP_DESCRIPTION(ELM_OBJ_WIN_SUB_ID_WL_WINDOW_GET, "Get the 
> Ecore_Wl_Window of and Evas_Object."),
> +#endif
>EO_OP_DESCRIPTION_SENTINEL
>   };
>
>
> Modified: trunk/elementary/src/lib/elm_win.h
> ===
> --- trunk/elementary/src/lib/elm_win.h2012-12-06 09:16:15 UTC (rev 
> 80324)
> +++ trunk/elementary/src/lib/elm_win.h2012-12-06 09:20:37 UTC (rev 
> 80325)
> @@ -2651,7 +2651,6 @@
>*/
>   EAPI Ecore_X_Window elm_win_xwindow_get(const Evas_Object *obj);
>
> -#ifdef HAVE_ELEMENTARY_WAYLAND
>   /* Wayland specific call - returns NULL on non-Wayland engines */
>   /**
>* Get the Ecore_Wl_Window of and Evas_Object
> @@ -2663,7 +2662,6 @@
>* @ingroup Win
>*/
>   EAPI Ecore_Wl_Window *elm_win_wl_window_get(const Evas_Object *obj);
> -#endif
>
>   /**
>* @typedef Elm_Win_Trap



--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: seoz trunk/devs/seoz

[David Seikel]

On Thu,  6 Dec 2012 00:33:11 -0800 "Enlightenment SVN"
 wrote:

> Log:
> devs/seoz build.sh: Edje supports ephysics features now.  Build
> ephysics before edje.

I just realized, that's gonna be a problem with the merged EFL tree,
once edje gets in.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] std=c99 for ecore_con dns.c got missing

[Stefan Schmidt]

Hello.

Either during the merge of ecore into efl or during Gustavos changes the 
std=c99 passing to ecore_con got missing.

I just found it while compiling with clang. No time right now to dig 
into this so only the report here. Added it to my local cflags for now.

regards
Stefan Schmidt

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] std=c99 for ecore_con dns.c got missing

[Vincent Torri]

On Thu, Dec 6, 2012 at 11:28 AM, Stefan Schmidt  wrote:
> Hello.
>
> Either during the merge of ecore into efl or during Gustavos changes the
> std=c99 passing to ecore_con got missing.

adding std=c99 is a BAD idea. Better use AC_PROG_CC_C99 if a c99
compiler is needed. But honestly, i don't know why it is needed, as
current compiler check is working for years. So before changing, tell
me what the error is

Vincent

>
> I just found it while compiling with clang. No time right now to dig
> into this so only the report here. Added it to my local cflags for now.
>
> regards
> Stefan Schmidt
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Elm_colorselector]: saturation bar change from low to high

[Daniel Juyung Seo]

Sorry this can be pushed to svn on elementary 2.0.
Is there any reason that you have to push this?

Daniel Juyung Seo (SeoZ)

On Thu, Dec 6, 2012 at 4:36 PM, SHILPA ONKAR SINGH  wrote:

> When this change can be pushed to svn?
>
> --- Original Message ---
> Sender : Daniel Juyung Seo
> Date : Dec 06, 2012 00:48 (GMT+09:00)
> Title : Re: [E-devel] [Elm_colorselector]: saturation bar change from low
> to high
>
> On Wed, Dec 5, 2012 at 10:49 PM, SHILPA ONKAR SINGH <
> shilpa.si...@samsung.com> wrote:
>
> >
> >   basically this patch does not cause API break. what it does is make
> >changes in theme.
> >
> >   The saturation image used in colorselector is inverted in this
> patch.
> >   so that value change happens from low to high and ofcourse code is
> > also
> >   changed accordingly.
> >   so currently default theme is changed.  Similar changes needs to be
> > done
> >in
> >   other themes as well.
> >
>
> We call this 'theme api break'. After the official release we can't break
> theme api either.
> You can fix all the themes in trunk but they are not all the elm themes in
> this world.
> There must be some broken themes outside.
>
> For more information, I think theme api means:
> - text part names
> - swallow part names
> - signal names
> - behavior
> - etc
>
> Daniel Juyung Seo (SeoZ)
>
>
>
> >
> > Only   the   image   used   for   saturation   bar  needs  to  be
> >inverted/changed/modified.
> >   There is no API break but only change of image.
> >
> >   Please let me know if this is being considered as theme break?
> >
> >
> >--- Original Message ---
> >
> >Sender:SHILPA   ONKAR   SINGH   Lead
> >Engineer/SISO-Mobile Protocols & Platforms/Samsung Electronics
> >
> >Date : Dec 05, 2012 22:35 (GMT+09:00)
> >
> >Title : Re: [E-devel] [Elm_colorselector]: saturation bar change from
> > low to
> >high
> >
> >
> >   basically this patch does cause API break. what it does is make
> > changes
> >in
> >   theme.  the saturation image used in colorselector is inverted in
> > this
> >   patch.
> >   so that value change happens from low to high and ofcourse code is
> > also
> >   changed
> >   accordingly.
> >   so currently default theme is changed similar changes needs to be
> > done in
> >   other themes
> >   as well. only the image used for saturation bar needs to be
> inverted.
> >   Please let me know if this is being considered as theme break?
> >   --- Original Message ---
> >   Sender : Michael Blumenkrantz
> >   Date : Dec 05, 2012 22:09 (GMT+09:00)
> >   Title : Re: [E-devel] [Elm_colorselector]: saturation bar change
> > from low
> >to
> >   high
> >   no released api can be broken until 2.0, regardless of whether it
> is
> >theme
> >   or code
> >   On Wed, Dec 5, 2012 at 1:06 PM, Daniel Juyung Seo wrote:
> >   > Daniel Juyung Seo (SeoZ)
> >   > On Dec 5, 2012 7:04 PM, "SHILPA ONKAR SINGH"
> >   > wrote:
> >   > >
> >   > > you mean the existing themes like darkness will break as the
> > images
> >used
> >   > for colorselector-saturation
> >   > > is inverted.
> >   >
> >   > yes exactly.
> >   >
> >  >>Can   I   go   ahead   and   change   all   themes   -
> >images(color_picker_opacity.png)
> >   > and where are these themes present
> >   > > in e?
> >   >
> >   > colorselector was released in elm 1.7.
> >   > i dont think we can break theme api after the release.
> >   >
> >   > any opinions?
> >   >
> >   > >
> >   > > --- Original Message ---
> >   > > Sender : Daniel Juyung Seo
> >   > > Date : Dec 04, 2012 01:46 (GMT+09:00)
> >   > > Title : Re: [E-devel] [Elm_colorselector]: saturation bar
> change
> > from
> >   low
> >   > to high
> >   > >
> >   > > Sorry but this will break theme API.
> >   > > Existing elementary themes like darkness, ... will be broken.
> >   > > They will act in a wrong way.
> >   > >
> >   > > Daniel Juyung Seo (SeoZ)
> >   > >
> >   > > On Sat, Dec 1, 2012 at 4:16 PM, SHILPA ONKAR SINGH > wrote:
> >   > >
> >   > > > Hi All,
> >   > > >
> >   > > > Please find attached patch of elm_colorselector.
> >   > > > To maintain consistency with Lightness bar, saturation bar
> >   > > > is modified to be adjusted from low to high and to make it
> > similar
> >   > > > to other apps like GIMP.
> >   > > >
> >   > > > Change Description:
> >   > > > Elm_colorselector: Saturation bar modified to be adjusted
> >   > > > from low to high.
> >   > > >
> >   > > > Signed-off by: Shilpa Singh(shilpa.si...@samsung.com)
> >   > > >
> >   > > > Thanks & Regards
> >   > > > Shilpa Singh
> >   > > >
> >   > > >
> >   >
> >   >
> >
> >
> >
>  --

Re: [E-devel] E SVN: seoz trunk/devs/seoz

[Daniel Juyung Seo]

Yes that must be painful.
And ephysics_test depends on elm.

Daniel Juyung Seo (SeoZ)

On Thu, Dec 6, 2012 at 6:34 PM, David Seikel  wrote:

> On Thu,  6 Dec 2012 00:33:11 -0800 "Enlightenment SVN"
>  wrote:
>
> > Log:
> > devs/seoz build.sh: Edje supports ephysics features now.  Build
> > ephysics before edje.
>
> I just realized, that's gonna be a problem with the merged EFL tree,
> once edje gets in.
>
> --
> A big old stinking pile of genius that no one wants
> coz there are too many silver coated monkeys in the world.
>
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] std=c99 for ecore_con dns.c got missing

[Stefan Schmidt]

Hello.

On 06/12/12 10:34, Vincent Torri wrote:
> On Thu, Dec 6, 2012 at 11:28 AM, Stefan Schmidt  wrote:
>> Hello.
>>
>> Either during the merge of ecore into efl or during Gustavos changes the
>> std=c99 passing to ecore_con got missing.
>
> adding std=c99 is a BAD idea. Better use AC_PROG_CC_C99 if a c99
> compiler is needed. But honestly, i don't know why it is needed, as
> current compiler check is working for years. So before changing, tell
> me what the error is

I remember we had problems with that when Mike put in dns.c. Anyway here 
are the problems I see when building with Ubuntu clang version 
3.0-6ubuntu3 (tags/RELEASE_30/final) (based on LLVM 3.0):

lib/ecore_con/dns.c:878:4: error: 'for' loop initial declarations are 
only allowed in C99 mode
lib/ecore_con/dns.c:878:4: note: use option -std=c99 or -std=gnu99 to 
compile your code
lib/ecore_con/dns.c:885:4: error: 'for' loop initial declarations are 
only allowed in C99 mode
lib/ecore_con/dns.c:888:5: error: 'for' loop initial declarations are 
only allowed in C99 mode
lib/ecore_con/dns.c: In function 'dns_p_push':
lib/ecore_con/dns.c:988:28: warning: declaration of '__v' shadows a 
previous local [-Wshadow]
lib/ecore_con/dns.c:988:28: warning: shadowed declaration is here [-Wshadow]
lib/ecore_con/dns.c:988:28: warning: declaration of '__x' shadows a 
previous local [-Wshadow]
lib/ecore_con/dns.c:988:28: warning: shadowed declaration is here [-Wshadow]
lib/ecore_con/dns.c:1006:28: warning: declaration of '__v' shadows a 
previous local [-Wshadow]
lib/ecore_con/dns.c:1006:28: warning: shadowed declaration is here 
[-Wshadow]
lib/ecore_con/dns.c:1006:28: warning: declaration of '__x' shadows a 
previous local [-Wshadow]
lib/ecore_con/dns.c:1006:28: warning: shadowed declaration is here 
[-Wshadow]
lib/ecore_con/dns.c:1022:28: warning: declaration of '__v' shadows a 
previous local [-Wshadow]
lib/ecore_con/dns.c:1022:28: warning: shadowed declaration is here 
[-Wshadow]
lib/ecore_con/dns.c:1022:28: warning: declaration of '__x' shadows a 
previous local [-Wshadow]
lib/ecore_con/dns.c:1022:28: warning: shadowed declaration is here 
[-Wshadow]
lib/ecore_con/dns.c:1033:28: warning: declaration of '__v' shadows a 
previous local [-Wshadow]
lib/ecore_con/dns.c:1033:28: warning: shadowed declaration is here 
[-Wshadow]
lib/ecore_con/dns.c:1033:28: warning: declaration of '__x' shadows a 
previous local [-Wshadow]
lib/ecore_con/dns.c:1033:28: warning: shadowed declaration is here 
[-Wshadow]
lib/ecore_con/dns.c: In function 'dns_rr_exists':
lib/ecore_con/dns.c:1787:2: error: 'for' loop initial declarations are 
only allowed in C99 mode
lib/ecore_con/dns.c: In function 'dns_res_merge':
lib/ecore_con/dns.c:5414:2: error: 'for' loop initial declarations are 
only allowed in C99 mode
lib/ecore_con/dns.c:5421:4: error: 'for' loop initial declarations are 
only allowed in C99 mode
lib/ecore_con/dns.c:5424:5: error: 'for' loop initial declarations are 
only allowed in C99 mode
lib/ecore_con/dns.c: In function 'dns_res_glue':
lib/ecore_con/dns.c:5480:3: error: 'for' loop initial declarations are 
only allowed in C99 mode
lib/ecore_con/dns.c:5496:3: error: 'for' loop initial declarations are 
only allowed in C99 mode
lib/ecore_con/dns.c: In function 'dns_res_exec':
lib/ecore_con/dns.c:5604:3: error: 'for' loop initial declarations are 
only allowed in C99 mode
lib/ecore_con/dns.c:5608:3: error: 'for' loop initial declarations are 
only allowed in C99 mode
lib/ecore_con/dns.c:5806:3: error: 'for' loop initial declarations are 
only allowed in C99 mode
lib/ecore_con/dns.c:5880:3: error: 'for' loop initial declarations are 
only allowed in C99 mode
lib/ecore_con/dns.c:5884:3: error: 'for' loop initial declarations are 
only allowed in C99 mode
lib/ecore_con/dns.c:5893:3: error: 'for' loop initial declarations are 
only allowed in C99 mode
lib/ecore_con/dns.c:6027:3: error: 'for' loop initial declarations are 
only allowed in C99 mode

The warnings are always there so can be ignored for this particular case.

regards
Stefan Schmidt

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Patch][Elementary] export access api

[Kim Shinwoo]

this patch is in svn with r80339

On Wed, Dec 5, 2012 at 1:53 PM, Kim Shinwoo  wrote:

> dear all hi!
>
> 1. export elm_access_external_info_set();
> i would like to export an API which name is
> elm_access_external_info_set(Evas_Object *, const char*);
> this will be using by application side to set additional accessibility
> information.
>
> widget could have different information which could be different in
> another context.
> for example: there would be an entry which is for user ID, and there would
> be another entry which is for password.
> in this case, developer would like to add additional information for each
> entry as below.
>
>   entry for user id reads "entry (default information), this entry is for
> user id (additional information)"
>   entry for password reads "entry, this entry is for password"
>
> for this reason, i have attached patch. please review the patch and give
> feedbacks.
>
>
> 2. other APIs
> i'm not sure to export other APIs in elm_access. i need your opinion.
> IMHO, candidates to export as below.
>
>   1. _elm_access_edje_object_part_object_register();
>   2. _elm_access_text_set();
>   3. _elm_access_callback_set();
>   4. ELM_ACCESS_TYPE, INFO, STATE, Elm_Access_Content_Cb, and so on.
>
> this is for application developer who would like to make edje part be
> accessible which is not supported by default.
> i'm not sure to export candidates is useful or not. please give your
> opinion. thank you.
>
>
> cordially,
> shinwoo kim.
>
>
>
>
>
>
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Minor update of the EFL tomorrow (1.7.3)

[Luis Felipe Strano Moraes]

Hey guys,

I'm preparing a new minor release of the EFL for tomorrow, if you still
have things to backport please do so as soon as possible, we *WILL* have
another release to coincide with E17 so this is not the end of the world in
case you did not have the time.

Best regards,
Luis Felipe



-- 
Luís Felipe Strano Moraes
http://www.strano.org
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo debug helper

[daniel.za...@samsung.com]

When I compile without -O and -g, gdb behaves like with stripped 
library, i.e doesn't try to enter the function. Maybe I do something wrong.
Tom, can you try it on your computer?

Thank you
Daniel

On 12/06/2012 12:45 AM, Tom Hacohen wrote:
> Compile Eo in release mode: remove -O0/-g from your CFLAGS, re-configure Eo
> (efl tree I assume) with --with-profile=release (or something like that,
> just check the configure options, it's easy) and make && make install. You
> can potentially just strip the binary, doesn't matter really...
>
>
> On Wed, Dec 5, 2012 at 3:52 PM, daniel.za...@samsung.com <
> daniel.za...@samsung.com> wrote:
>
>> Tom, the 'sudo strip -g libeo.so' on my computer prevents me to see info
>> about this library in gdb, as explained before. How can I compile Eo in
>> release mode?
>>
>> Gustavo, this could be very useful. We need to check if it really can be
>> done and if it is easy for the user. Is the eo_do_step supposed to
>> execute the functions too? How does it wait for commands (your last
>> line), I mean, is it inside the eo_do_step function?
>> Eo uses va_list to store the parameters and we need to be careful with
>> that.
>>
>> On 12/05/2012 05:11 PM, Tom Hacohen wrote:
>>> Gustavo,
>>>
>>> Your suggestion is good (I already told you that in the past, I think),
>> but
>>> I believe it's unrelated to what we are trying to achieve here. What I
>> want
>>> is an easy way to step into an eo_do function, just like we would have
>> done
>>> with any other function.
>>>
>>> What I really want to see is just "run until you exit the libeo.so binary
>>> and get back to a user function"...
>>>
>>>
>>> On Wed, Dec 5, 2012 at 3:05 PM, Gustavo Sverzut Barbieri <
>>> barbi...@profusion.mobi> wrote:
>>>
 Let me jump in, proposing here what I already proposed earlier at IRC
 and in person during LinuxCon-EU:

 we should use the same debug helper way as gcc does for itself.

 GCC is built on top of an union of every possible AST node. So
 functions, variables, loops... are all into the same type/union,
 making it dozen pages of gdb output to get every possible field and
 combination if you "p *node"

 To solve this they ship some  functions in their own code, that you
 can use to debug its own code. Similar to "p gcc_node_print(node)" (I
 don't recall the exact name), and another to navigate the tree.

 Then I propose we create a "eo_do_step(obj, va_list ap)" that we can:
 "(gdb) p eo_do_step(obj, ap)" from our debug session. It would
 replicate the dispatch logic from eo_do(), but before executing each
 call it would print out the call and parameters. We can use Eo
 introspection to try to help user by showing the function name,
 description and parameter types.

 Suppose doing: eo_do(evas_obj, evas_obj_position_set(10, 20),
 evas_obj_size_set(300, 400));
 you break point in eo_do and call:

 (gdb) p eo_do_step(obj, ap)
 Operating on: obj=0xaabbcc00 (Evas_Object_Rectangle)
 Function: evas_obj_position_set(int x, int y) "Set the position of an
 evas object."
 calling: evas_obj_position_set(x=10, y=20)
 (eo_do_step)  <--- waits for commands such as continue, step...




 On Wed, Dec 5, 2012 at 12:46 PM, daniel.za...@samsung.com
  wrote:
> Hi all,
>
> I don't need to reply, but to thank you and give you respect, I feel
> that I must reply ;-) When I strip Eo library, I cannot in gcc step
>> into
> at all, I mean, I can't reach the final destination. It is like the
> 'skip' feature of gdb. So for the moment, I am stuck with that filename
> and need to find a solution.
>
> Second point, as I wrote before, there is a bug in gdb when executing
> python scripts (link below). It will be fixed in gdb 7.6 that is
> officially supposed to be delivered in mid-february 2013 but as a gdb
> maintainer said "In the past few releases, we have typically been late
> by a few weeks.", I think we will have to wait a little more.
>
> Hopefully, when I will have time, I will insert this script into SVN
>> and
> the installation will put it automatically into the /opt/e17 directory
> (or different). The question here is if we have a common directory for
> all this nice weird stuff or if it will be a new directory.
>
> JackDanielZ
>
> On 12/05/2012 04:24 PM, Tom Hacohen wrote:
>> Cool. And we already talked a bit more on IRC about the usage of the
 binary
>> name vs. the source file name, so I'm happy, no need for your reply
 here.
>> On 5 Dec 2012 05:16, "daniel.za...@samsung.com" <
 daniel.za...@samsung.com>
>> wrote:
>>
>>> Hey Tom,
>>>
>>> I saw your mail, I just wanted to explain SeoZ how to do now until I
 put
>>> it there automatically. I will change the name to eo_step.
>>> I know this site, I don't know yet which way to use to

Re: [E-devel] E SVN: seoz trunk/devs/seoz

[Gustavo Sverzut Barbieri]

On Thursday, December 6, 2012, Daniel Juyung Seo wrote:

> Yes that must be painful.
> And ephysics_test depends on elm.


Now we build libs (all) before we build binaries, so no problems for edje.
For elm, sure. We may split the tests into another package, source, or
migrate to elm itself



>
> Daniel Juyung Seo (SeoZ)
>
> On Thu, Dec 6, 2012 at 6:34 PM, David Seikel >
> wrote:
>
> > On Thu,  6 Dec 2012 00:33:11 -0800 "Enlightenment SVN"
> > > wrote:
> >
> > > Log:
> > > devs/seoz build.sh: Edje supports ephysics features now.  Build
> > > ephysics before edje.
> >
> > I just realized, that's gonna be a problem with the merged EFL tree,
> > once edje gets in.
> >
> > --
> > A big old stinking pile of genius that no one wants
> > coz there are too many silver coated monkeys in the world.
> >
> >
> >
> --
> > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> > Remotely access PCs and mobile devices and provide instant support
> > Improve your efficiency, and focus on delivering more value-add services
> > Discover what IT Professionals Know. Rescue delivers
> > http://p.sf.net/sfu/logmein_12329d2d
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net 
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> >
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk/efl: . m4 src src/lib/eio

[Gustavo Sverzut Barbieri]

On Thursday, December 6, 2012, Sebastian Dransfeld wrote:

> Den 6. des. 2012 kl. 01:57 skrev "Enlightenment SVN" <
> no-re...@enlightenment.org >:
>
> > Log:
> > efl: simplify inotify by moving it to common.
> >
> >  also deprecate very ancient inotify usage by direct syscall.
> >
> >
>
> Can you also do ecore_file?


It should be working, no? Let me know of issues



>
> S.
>
>
> >
> > Author:   barbieri
> > Date: 2012-12-05 16:57:29 -0800 (Wed, 05 Dec 2012)
> > New Revision: 80292
> > Trac: http://trac.enlightenment.org/e/changeset/80292
> >
> > Modified:
> >  trunk/efl/configure.ac trunk/efl/m4/eio_check_options.m4
> trunk/efl/src/Makefile_Eio.am trunk/efl/src/lib/eio/eio_monitor_inotify.c
> >
> > Modified: trunk/efl/configure.ac
> > ===
> > --- trunk/efl/configure.ac2012-12-06 00:35:14 UTC (rev 80291)
> > +++ trunk/efl/configure.ac2012-12-06 00:57:29 UTC (rev 80292)
> > @@ -104,6 +104,8 @@
> >
> >  Default values
> >
> > +want_inotify="no"
> > +
> > requirements_pc_crypto=""
> > requirements_pc_deps_crypto=""
> > requirements_libs_crypto=""
> > @@ -277,6 +279,11 @@
> >   MODULE_ARCH="$host_os-$host_cpu-v_maj.v_min.v_mic"
> >   MODULE_EXT=".dll"
> >;;
> > +   linux*)
> > +  want_inotify="yes"
> > +  MODULE_ARCH="$host_os-$host_cpu-v_maj.v_min.v_mic"
> > +  MODULE_EXT=".so"
> > +   ;;
> >*)
> >   MODULE_ARCH="$host_os-$host_cpu-v_maj.v_min.v_mic"
> >   MODULE_EXT=".so"
> > @@ -474,6 +481,17 @@
> > unistd.h \
> > ])
> >
> > +have_inotify="no"
> > +if test "x${want_inotify}" = "xyes" ; then
> > +   AC_CHECK_HEADER([sys/inotify.h],
> > +  [
> > +   AC_DEFINE([HAVE_INOTIFY], [1], [File monitoring with Inotify])
> > +   have_inotify="yes"
> > +  ],
> > +  [have_inotify="no"])
> > +fi
> > +AM_CONDITIONAL([HAVE_INOTIFY], [test "x${have_inotify}" = "xyes"])
> > +
> > EFL_CHECK_PATH_MAX
> >
> >
> > @@ -1825,19 +1843,13 @@
> >
> > # cserve2 only works on Linux so far.
> >
> > -if test "x${efl_func_shm_open}" = "xno" ; then
> > +if test "x${efl_func_shm_open}" = "xno" -o "x${have_inotify}" = "xno";
> then
> >want_evas_cserve2="no"
> > fi
> >
> > -if test "x${want_evas_cserve2}" = "xyes" ; then
> > -   AC_CHECK_HEADERS([sys/epoll.h sys/inotify.h sys/signalfd.h],
> > -  [],
> > -  [want_evas_cserve2="no"])
> > -fi
> > -
> > -if test "x${want_evas_cserve2}" = "xyes" ; then
> > -  AC_DEFINE([EVAS_CSERVE2], [1], [Shared cache server.])
> > -fi
> > +AC_DEFINE_IF([EVAS_CSERVE2],
> > +   [test "x${want_evas_cserve2}" = "xyes"],
> > +   [1], [Shared cache server.])
> > AM_CONDITIONAL([EVAS_CSERVE2], [test "x${want_evas_cserve2}" = "xyes"])
> >
> > ### Configuration
> > @@ -2368,18 +2380,6 @@
> >],
> >[want_poll="yes"])
> >
> > -AC_ARG_ENABLE([inotify],
> > -   [AC_HELP_STRING([--disable-inotify],
> > -  [disable inotify in the ecore_file module. @<:@default=enabled@
> :>@])],
> > -   [
> > -if test "x${enableval}" = "xyes" ; then
> > -   want_inotify="yes"
> > -else
> > -   want_inotify="no"
> > -fi
> > -   ],
> > -   [want_inotify="yes"])
> > -
> > AC_ARG_ENABLE([atfile-source],
> >[AC_HELP_STRING([--disable-atfile-source],
> >[disable use of atfile source functions as openat and mkdirat
> @<:@default=detect@:>@])],
> > @@ -2440,19 +2440,6 @@
> >
> > ### Checks for header files
> >
> > -have_inotify="no"
> > -if test "x${want_inotify}"enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo debug helper

[daniel.za...@samsung.com]

Hi Gustavo,

I think the problem with adding flags is the performance. eo_do is the 
most called function in Eo (with eo_data_get) and we need it fast. More, 
you know what the functions parameters are, you called it. So in my 
opinion, the most important thing is what the destination is.

Did you try the script? Do you think that something is missing in what 
it gives? It is a prototype, so sure we have to improve it.

Daniel

On 12/05/2012 07:22 PM, Gustavo Sverzut Barbieri wrote:
> On Wed, Dec 5, 2012 at 1:52 PM, daniel.za...@samsung.com
>  wrote:
>> Tom, the 'sudo strip -g libeo.so' on my computer prevents me to see info
>> about this library in gdb, as explained before. How can I compile Eo in
>> release mode?
>>
>> Gustavo, this could be very useful. We need to check if it really can be
>> done and if it is easy for the user. Is the eo_do_step supposed to
>> execute the functions too? How does it wait for commands (your last
>> line), I mean, is it inside the eo_do_step function?
>> Eo uses va_list to store the parameters and we need to be careful with that.
> it should execute them, in that case we can set some flag and have the
> actual eo_do() to not do anything as it was done already.
>
> As for wait commands, it's fscanf() and similar. When you "p call()"
> you actually stop gdb to execute call(). While it does not return, you
> have the control.
>
>
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>


--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk/efl: . m4 src src/lib/eio

[Gustavo Sverzut Barbieri]

On Thursday, December 6, 2012, Vincent Torri wrote:

> On Thu, Dec 6, 2012 at 7:37 AM, Vincent Torri 
> >
> wrote:
> > revert !!
> >
> > i want to let it where it was
>
> and it breaks configuration on some debian



Im not reverting, it where it should be. But if the breakages do happen,
I'll fix it.

Btw, the way it was it was rechecking, redefining and even checking for
ancient and unsupported method of inotify. It was also wrong, it's at least
less bad now being centralized, we can fix in a single place and everywhere
will be correct





>
> Vincent
>
> >
> > Vincent
> >
> > On Thu, Dec 6, 2012 at 1:57 AM, Enlightenment SVN
> >  wrote:
> >> Log:
> >> efl: simplify inotify by moving it to common.
> >>
> >>   also deprecate very ancient inotify usage by direct syscall.
> >>
> >>
> >>
> >> Author:   barbieri
> >> Date: 2012-12-05 16:57:29 -0800 (Wed, 05 Dec 2012)
> >> New Revision: 80292
> >> Trac: http://trac.enlightenment.org/e/changeset/80292
> >>
> >> Modified:
> >>   trunk/efl/configure.ac trunk/efl/m4/eio_check_options.m4
> trunk/efl/src/Makefile_Eio.am trunk/efl/src/lib/eio/eio_monitor_inotify.c
> >>
> >> Modified: trunk/efl/configure.ac
> >> ===
> >> --- trunk/efl/configure.ac  2012-12-06 00:35:14 UTC (rev 80291)
> >> +++ trunk/efl/configure.ac  2012-12-06 00:57:29 UTC (rev 80292)
> >> @@ -104,6 +104,8 @@
> >>
> >>   Default values
> >>
> >> +want_inotify="no"
> >> +
> >>  requirements_pc_crypto=""
> >>  requirements_pc_deps_crypto=""
> >>  requirements_libs_crypto=""
> >> @@ -277,6 +279,11 @@
> >>MODULE_ARCH="$host_os-$host_cpu-v_maj.v_min.v_mic"
> >>MODULE_EXT=".dll"
> >> ;;
> >> +   linux*)
> >> +  want_inotify="yes"
> >> +  MODULE_ARCH="$host_os-$host_cpu-v_maj.v_min.v_mic"
> >> +  MODULE_EXT=".so"
> >> +   ;;
> >> *)
> >>MODULE_ARCH="$host_os-$host_cpu-v_maj.v_min.v_mic"
> >>MODULE_EXT=".so"
> >> @@ -474,6 +481,17 @@
> >>  unistd.h \
> >>  ])
> >>
> >> +have_inotify="no"
> >> +if test "x${want_inotify}" = "xyes" ; then
> >> +   AC_CHECK_HEADER([sys/inotify.h],
> >> +  [
> >> +   AC_DEFINE([HAVE_INOTIFY], [1], [File monitoring with Inotify])
> >> +   have_inotify="yes"
> >> +  ],
> >> +  [have_inotify="no"])
> >> +fi
> >> +AM_CONDITIONAL([HAVE_INOTIFY], [test "x${have_inotify}" = "xyes"])
> >> +
> >>  EFL_CHECK_PATH_MAX
> >>
> >>
> >> @@ -1825,19 +1843,13 @@
> >>
> >>  # cserve2 only works on Linux so far.
> >>
> >> -if test "x${efl_func_shm_open}" = "xno" ; then
> >> +if test "x${efl_func_shm_open}" = "xno" -o "x${have_inotify}" = "xno";
> then
> >> want_evas_cserve2="no"
> >>  fi
> >>
> >> -if test "x${want_evas_cserve2}" = "xyes" ; then
> >> -   AC_CHECK_HEADERS([sys/epoll.h sys/inotify.h sys/signalfd.h],
> >> -  [],
> >> -  [want_evas_cserve2="no"])
> >> -fi
> >> -
> >> -if test "x${want_evas_cserve2}" = "xyes" ; then
> >> -  AC_DEFINE([EVAS_CSERVE2], [1], [Shared cache server.])
> >> -fi
> >> +AC_DEFINE_IF([EVAS_CSERVE2],
> >> +   [test "x${want_evas_cserve2}" = "xyes"],
> >> +   [1], [Shared cache server.])
> >>  AM_CONDITIONAL([EVAS_CSERVE2], [test "x${want_evas_cserve2}" = "xyes"])
> >>
> >>  ### Configuration
> >> @@ -2368,18 +2380,6 @@
> >> ],
> >> [want_poll="yes"])
> >>
> >> -AC_ARG_ENABLE([inotify],
> >> -   [AC_HELP_STRING([--disable-inotify],
> >> -  [disable inotify in th



-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

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

[Gustavo Sverzut Barbieri]

Not? Isn't it 1 or -1, not 1 and 0?

On Thursday, December 6, 2012, Enlightenment SVN wrote:

> Log:
> elm elm_interface_scrollable.c: Fixed wheel scroll direction with shift.
>
> Author:   seoz
> Date: 2012-12-06 00:25:53 -0800 (Thu, 06 Dec 2012)
> New Revision: 80312
> Trac: http://trac.enlightenment.org/e/changeset/80312
>
> Modified:
>   trunk/elementary/src/lib/elm_interface_scrollable.c
>
> Modified: trunk/elementary/src/lib/elm_interface_scrollable.c
> ===
> --- trunk/elementary/src/lib/elm_interface_scrollable.c 2012-12-06
> 08:25:47 UTC (rev 80311)
> +++ trunk/elementary/src/lib/elm_interface_scrollable.c 2012-12-06
> 08:25:53 UTC (rev 80312)
> @@ -1723,7 +1723,7 @@
> (evas_key_modifier_is_set(ev->modifiers, "Super")))
>   return;
> else if (evas_key_modifier_is_set(ev->modifiers, "Shift"))
> - direction = 1;
> + direction = !direction;
> eo_do(sid->obj, elm_scrollable_interface_content_pos_get(&x, &y));
> if ((sid->down.bounce_x_animator) || (sid->down.bounce_y_animator) ||
> (sid->scrollto.x.animator) || (sid->scrollto.y.animator))
>
>
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: caro IN trunk/efl: . m4 src src/lib/eio

[Gustavo Sverzut Barbieri]

On Thursday, December 6, 2012, Enlightenment SVN wrote:

> Log:
> inotify: revert : i want to keep autotools **modularized**. Instead, use
> in Eio what has been detected in Ecore_File.


Damn Vincent, why do you do these things when you don't understand?

Really, I'm quite disappointed you still don't get how this should work
after this merge, yet you are the one doing the merge. Inotify is a
platform thing and may be used in various modules as already done. There is
no reason, point, sense or intelligence in doing the way it was!

Apply this commit again and please don't revert things anymore unless you
clearly understand its purpose.



>
>
> Author:   caro
> Date: 2012-12-05 23:23:50 -0800 (Wed, 05 Dec 2012)
> New Revision: 80298
> Trac: http://trac.enlightenment.org/e/changeset/80298
>
> Modified:
>   trunk/efl/configure.ac trunk/efl/m4/eio_check_options.m4
> trunk/efl/src/Makefile_Eio.am trunk/efl/src/lib/eio/eio_monitor_inotify.c
>
> Modified: trunk/efl/configure.ac
> ===
> --- trunk/efl/configure.ac  2012-12-06 03:06:22 UTC (rev 80297)
> +++ trunk/efl/configure.ac  2012-12-06 07:23:50 UTC (rev 80298)
> @@ -104,8 +104,6 @@
>
>   Default values
>
> -want_inotify="no"
> -
>  requirements_pc_crypto=""
>  requirements_pc_deps_crypto=""
>  requirements_libs_crypto=""
> @@ -279,11 +277,6 @@
>MODULE_ARCH="$host_os-$host_cpu-v_maj.v_min.v_mic"
>MODULE_EXT=".dll"
> ;;
> -   linux*)
> -  want_inotify="yes"
> -  MODULE_ARCH="$host_os-$host_cpu-v_maj.v_min.v_mic"
> -  MODULE_EXT=".so"
> -   ;;
> *)
>MODULE_ARCH="$host_os-$host_cpu-v_maj.v_min.v_mic"
>MODULE_EXT=".so"
> @@ -481,17 +474,6 @@
>  unistd.h \
>  ])
>
> -have_inotify="no"
> -if test "x${want_inotify}" = "xyes" ; then
> -   AC_CHECK_HEADER([sys/inotify.h],
> -  [
> -   AC_DEFINE([HAVE_INOTIFY], [1], [File monitoring with Inotify])
> -   have_inotify="yes"
> -  ],
> -  [have_inotify="no"])
> -fi
> -AM_CONDITIONAL([HAVE_INOTIFY], [test "x${have_inotify}" = "xyes"])
> -
>  EFL_CHECK_PATH_MAX
>
>
> @@ -1843,13 +1825,19 @@
>
>  # cserve2 only works on Linux so far.
>
> -if test "x${efl_func_shm_open}" = "xno" -o "x${have_inotify}" = "xno";
> then
> +if test "x${efl_func_shm_open}" = "xno" ; then
> want_evas_cserve2="no"
>  fi
>
> -AC_DEFINE_IF([EVAS_CSERVE2],
> -   [test "x${want_evas_cserve2}" = "xyes"],
> -   [1], [Shared cache server.])
> +if test "x${want_evas_cserve2}" = "xyes" ; then
> +   AC_CHECK_HEADERS([sys/epoll.h sys/inotify.h sys/signalfd.h],
> +  [],
> +  [want_evas_cserve2="no"])
> +fi
> +
> +if test "x${want_evas_cserve2}" = "xyes" ; then
> +  AC_DEFINE([EVAS_CSERVE2], [1], [Shared cache server.])
> +fi
>  AM_CONDITIONAL([EVAS_CSERVE2], [test "x${want_evas_cserve2}" = "xyes"])
>
>  ### Configuration
> @@ -2398,6 +2386,18 @@
> ],
> [want_poll="yes"])
>
> +AC_ARG_ENABLE([inotify],
> +   [AC_HELP_STRING([--disable-inotify],
> +  [disable inotify in the ecore_file module. @<:@default=enabled@
> :>@])],
> +   [
> +if test "x${enableval}" = "xyes" ; then
> +   want_inotify="yes"
> +else
> +   want_inotify="no"
> +fi
> +   ],
> +   [want_inotify="yes"])
> +
>  AC_ARG_ENABLE([atfile-source],
> [AC_HELP_STRING([--disable-atfile-source],
> [disable use of atfile source functions as openat and mkdirat
> @<:@default=detect@:>@])],
> @@ -2458,6 +2458,19 @@
>
>  ### Checks for header files
>
> +have_inotify="no"
> +if test "x${want_inotify}" = "xyes" ; then
> +   AC_CHECK_HEADER([sys/inotify.h],
> +  [
> +   AC_DEFINE([HAVE_INOTIFY], [1], [File monitoring with Inotify])
> +   have_inotify="yes"
> +  ],
> +  [have_inotify="no"])
> +fi
> +
> +AC_MSG_CHECKING([whether inotify is to be used for filemonitoring])
> +AC_MSG_RESULT(${have_inotify})
> +
>  ### Checks for types
>
>  ### Checks for structures
> @@ -3959,9 +3972,12 @@
>  AC_MSG_RESULT([${have_xattr}])
>
>  # Check for inotify specificity
> +have_inotify="no"
>  have_notify_win32="no"
> +EIO_CHECK_INOTIFY([have_inotify="yes"], [have_inotify="no"])
>  EIO_CHECK_NOTIFY_WIN32([have_notify_win32="yes"],
> [have_notify_win32="no"])
>
> +AM_CONDITIONAL([EIO_HAVE_INOTIFY], [test "x${have_inotify}" = "xyes"])
>  AM_CONDITIONAL([EIO_HAVE_WINCHANGE], [test "x${have_notify_win32}" =
> "xyes"])
>
>   End of Eio
>
> Modified: trunk/efl/m4/eio_check_options.m4
> ===
> --- trunk/efl/m4/eio_check_options.m4   2012-12-06 03:06:22 UTC (rev 80297)
> +++ trunk/efl/m4/eio_check_options.m4   2012-12-06 07:23:50 UTC (rev 80298)
> @@ -1,3 +1,47 @@
> +dnl use: EIO_CHECK_INOTIFY([ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
> +AC_DEFUN([EIO_CHECK_INOTIFY],
> +[
> +_eio_have_inotify="no"
> +
> +dnl We need to check if the right inotify version is accessible
> +
> +dnl It is hard to find a good test on how to check the correct

Re: [E-devel] Eo debug helper

[Gustavo Sverzut Barbieri]

On Thursday, December 6, 2012, daniel.za...@samsung.com wrote:

> Hi Gustavo,
>
> I think the problem with adding flags is the performance.


A single Boolean check is nothing compared to everything else. And it's
once per eo_do() not per subcall



>  eo_do is the
> most called function in Eo (with eo_data_get) and we need it fast. More,
> you know what the functions parameters are, you called it.


That's the problem, if what you knew was right and worked, you were nor
debugging it:-) you want to really see them all, that's why gdb always show
every parameter when debugging functions.


> So in my
> opinion, the most important thing is what the destination is.
>
> Did you try the script? Do you think that something is missing in what
> it gives? It is a prototype, so sure we have to improve it.
>
>
Not yet





> Daniel
>
> On 12/05/2012 07:22 PM, Gustavo Sverzut Barbieri wrote:
> > On Wed, Dec 5, 2012 at 1:52 PM, daniel.za...@samsung.com 
> > > wrote:
> >> Tom, the 'sudo strip -g libeo.so' on my computer prevents me to see info
> >> about this library in gdb, as explained before. How can I compile Eo in
> >> release mode?
> >>
> >> Gustavo, this could be very useful. We need to check if it really can be
> >> done and if it is easy for the user. Is the eo_do_step supposed to
> >> execute the functions too? How does it wait for commands (your last
> >> line), I mean, is it inside the eo_do_step function?
> >> Eo uses va_list to store the parameters and we need to be careful with
> that.
> > it should execute them, in that case we can set some flag and have the
> > actual eo_do() to not do anything as it was done already.
> >
> > As for wait commands, it's fscanf() and similar. When you "p call()"
> > you actually stop gdb to execute call(). While it does not return, you
> > have the control.
> >
> >
> >
> > --
> > Gustavo Sverzut Barbieri
> > http://profusion.mobi embedded systems
> > --
> > MSN: barbi...@gmail.com 
> > Skype: gsbarbieri
> > Mobile: +55 (19) 9225-2202
> >
> >
> --
> > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> > Remotely access PCs and mobile devices and provide instant support
> > Improve your efficiency, and focus on delivering more value-add services
> > Discover what IT Professionals Know. Rescue delivers
> > http://p.sf.net/sfu/logmein_12329d2d
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net 
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
>
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: caro IN trunk/efl: . m4 src src/lib/eio

[Vincent Torri]

On Thu, Dec 6, 2012 at 12:48 PM, Gustavo Sverzut Barbieri
 wrote:
> On Thursday, December 6, 2012, Enlightenment SVN wrote:
>
>> Log:
>> inotify: revert : i want to keep autotools **modularized**. Instead, use
>> in Eio what has been detected in Ecore_File.
>
>
> Damn Vincent, why do you do these things when you don't understand?
>
> Really, I'm quite disappointed you still don't get how this should work
> after this merge, yet you are the one doing the merge. Inotify is a
> platform thing and may be used in various modules as already done. There is
> no reason, point, sense or intelligence in doing the way it was!
>
> Apply this commit again and please don't revert things anymore unless you
> clearly understand its purpose.

funny...

>
>
>
>>
>>
>> Author:   caro
>> Date: 2012-12-05 23:23:50 -0800 (Wed, 05 Dec 2012)
>> New Revision: 80298
>> Trac: http://trac.enlightenment.org/e/changeset/80298
>>
>> Modified:
>>   trunk/efl/configure.ac trunk/efl/m4/eio_check_options.m4
>> trunk/efl/src/Makefile_Eio.am trunk/efl/src/lib/eio/eio_monitor_inotify.c
>>
>> Modified: trunk/efl/configure.ac
>> ===
>> --- trunk/efl/configure.ac  2012-12-06 03:06:22 UTC (rev 80297)
>> +++ trunk/efl/configure.ac  2012-12-06 07:23:50 UTC (rev 80298)
>> @@ -104,8 +104,6 @@
>>
>>   Default values
>>
>> -want_inotify="no"
>> -
>>  requirements_pc_crypto=""
>>  requirements_pc_deps_crypto=""
>>  requirements_libs_crypto=""
>> @@ -279,11 +277,6 @@
>>MODULE_ARCH="$host_os-$host_cpu-v_maj.v_min.v_mic"
>>MODULE_EXT=".dll"
>> ;;
>> -   linux*)
>> -  want_inotify="yes"
>> -  MODULE_ARCH="$host_os-$host_cpu-v_maj.v_min.v_mic"
>> -  MODULE_EXT=".so"
>> -   ;;
>> *)
>>MODULE_ARCH="$host_os-$host_cpu-v_maj.v_min.v_mic"
>>MODULE_EXT=".so"
>> @@ -481,17 +474,6 @@
>>  unistd.h \
>>  ])
>>
>> -have_inotify="no"
>> -if test "x${want_inotify}" = "xyes" ; then
>> -   AC_CHECK_HEADER([sys/inotify.h],
>> -  [
>> -   AC_DEFINE([HAVE_INOTIFY], [1], [File monitoring with Inotify])
>> -   have_inotify="yes"
>> -  ],
>> -  [have_inotify="no"])
>> -fi
>> -AM_CONDITIONAL([HAVE_INOTIFY], [test "x${have_inotify}" = "xyes"])
>> -
>>  EFL_CHECK_PATH_MAX
>>
>>
>> @@ -1843,13 +1825,19 @@
>>
>>  # cserve2 only works on Linux so far.
>>
>> -if test "x${efl_func_shm_open}" = "xno" -o "x${have_inotify}" = "xno";
>> then
>> +if test "x${efl_func_shm_open}" = "xno" ; then
>> want_evas_cserve2="no"
>>  fi
>>
>> -AC_DEFINE_IF([EVAS_CSERVE2],
>> -   [test "x${want_evas_cserve2}" = "xyes"],
>> -   [1], [Shared cache server.])
>> +if test "x${want_evas_cserve2}" = "xyes" ; then
>> +   AC_CHECK_HEADERS([sys/epoll.h sys/inotify.h sys/signalfd.h],
>> +  [],
>> +  [want_evas_cserve2="no"])
>> +fi
>> +
>> +if test "x${want_evas_cserve2}" = "xyes" ; then
>> +  AC_DEFINE([EVAS_CSERVE2], [1], [Shared cache server.])
>> +fi
>>  AM_CONDITIONAL([EVAS_CSERVE2], [test "x${want_evas_cserve2}" = "xyes"])
>>
>>  ### Configuration
>> @@ -2398,6 +2386,18 @@
>> ],
>> [want_poll="yes"])
>>
>> +AC_ARG_ENABLE([inotify],
>> +   [AC_HELP_STRING([--disable-inotify],
>> +  [disable inotify in the ecore_file module. @<:@default=enabled@
>> :>@])],
>> +   [
>> +if test "x${enableval}" = "xyes" ; then
>> +   want_inotify="yes"
>> +else
>> +   want_inotify="no"
>> +fi
>> +   ],
>> +   [want_inotify="yes"])
>> +
>>  AC_ARG_ENABLE([atfile-source],
>> [AC_HELP_STRING([--disable-atfile-source],
>> [disable use of atfile source functions as openat and mkdirat
>> @<:@default=detect@:>@])],
>> @@ -2458,6 +2458,19 @@
>>
>>  ### Checks for header files
>>
>> +have_inotify="no"
>> +if test "x${want_inotify}" = "xyes" ; then
>> +   AC_CHECK_HEADER([sys/inotify.h],
>> +  [
>> +   AC_DEFINE([HAVE_INOTIFY], [1], [File monitoring with Inotify])
>> +   have_inotify="yes"
>> +  ],
>> +  [have_inotify="no"])
>> +fi
>> +
>> +AC_MSG_CHECKING([whether inotify is to be used for filemonitoring])
>> +AC_MSG_RESULT(${have_inotify})
>> +
>>  ### Checks for types
>>
>>  ### Checks for structures
>> @@ -3959,9 +3972,12 @@
>>  AC_MSG_RESULT([${have_xattr}])
>>
>>  # Check for inotify specificity
>> +have_inotify="no"
>>  have_notify_win32="no"
>> +EIO_CHECK_INOTIFY([have_inotify="yes"], [have_inotify="no"])
>>  EIO_CHECK_NOTIFY_WIN32([have_notify_win32="yes"],
>> [have_notify_win32="no"])
>>
>> +AM_CONDITIONAL([EIO_HAVE_INOTIFY], [test "x${have_inotify}" = "xyes"])
>>  AM_CONDITIONAL([EIO_HAVE_WINCHANGE], [test "x${have_notify_win32}" =
>> "xyes"])
>>
>>   End of Eio
>>
>> Modified: trunk/efl/m4/eio_check_options.m4
>> ===
>> --- trunk/efl/m4/eio_check_options.m4   2012-12-06 03:06:22 UTC (rev 80297)
>> +++ trunk/efl/m4/eio_check_options.m4   2012-12-06 07:23:50 UTC (rev 80298)
>> @@ -1,3 +1,47 @@
>> +dnl use: EIO_CHECK_INOTIFY(

Re: [E-devel] std=c99 for ecore_con dns.c got missing

[Vincent Torri]

so it's a problem with clang. Fix your CC, then

On Thu, Dec 6, 2012 at 11:59 AM, Stefan Schmidt  wrote:
> Hello.
>
> On 06/12/12 10:34, Vincent Torri wrote:
>> On Thu, Dec 6, 2012 at 11:28 AM, Stefan Schmidt  
>> wrote:
>>> Hello.
>>>
>>> Either during the merge of ecore into efl or during Gustavos changes the
>>> std=c99 passing to ecore_con got missing.
>>
>> adding std=c99 is a BAD idea. Better use AC_PROG_CC_C99 if a c99
>> compiler is needed. But honestly, i don't know why it is needed, as
>> current compiler check is working for years. So before changing, tell
>> me what the error is
>
> I remember we had problems with that when Mike put in dns.c. Anyway here
> are the problems I see when building with Ubuntu clang version
> 3.0-6ubuntu3 (tags/RELEASE_30/final) (based on LLVM 3.0):
>
> lib/ecore_con/dns.c:878:4: error: 'for' loop initial declarations are
> only allowed in C99 mode
> lib/ecore_con/dns.c:878:4: note: use option -std=c99 or -std=gnu99 to
> compile your code
> lib/ecore_con/dns.c:885:4: error: 'for' loop initial declarations are
> only allowed in C99 mode
> lib/ecore_con/dns.c:888:5: error: 'for' loop initial declarations are
> only allowed in C99 mode
> lib/ecore_con/dns.c: In function 'dns_p_push':
> lib/ecore_con/dns.c:988:28: warning: declaration of '__v' shadows a
> previous local [-Wshadow]
> lib/ecore_con/dns.c:988:28: warning: shadowed declaration is here [-Wshadow]
> lib/ecore_con/dns.c:988:28: warning: declaration of '__x' shadows a
> previous local [-Wshadow]
> lib/ecore_con/dns.c:988:28: warning: shadowed declaration is here [-Wshadow]
> lib/ecore_con/dns.c:1006:28: warning: declaration of '__v' shadows a
> previous local [-Wshadow]
> lib/ecore_con/dns.c:1006:28: warning: shadowed declaration is here
> [-Wshadow]
> lib/ecore_con/dns.c:1006:28: warning: declaration of '__x' shadows a
> previous local [-Wshadow]
> lib/ecore_con/dns.c:1006:28: warning: shadowed declaration is here
> [-Wshadow]
> lib/ecore_con/dns.c:1022:28: warning: declaration of '__v' shadows a
> previous local [-Wshadow]
> lib/ecore_con/dns.c:1022:28: warning: shadowed declaration is here
> [-Wshadow]
> lib/ecore_con/dns.c:1022:28: warning: declaration of '__x' shadows a
> previous local [-Wshadow]
> lib/ecore_con/dns.c:1022:28: warning: shadowed declaration is here
> [-Wshadow]
> lib/ecore_con/dns.c:1033:28: warning: declaration of '__v' shadows a
> previous local [-Wshadow]
> lib/ecore_con/dns.c:1033:28: warning: shadowed declaration is here
> [-Wshadow]
> lib/ecore_con/dns.c:1033:28: warning: declaration of '__x' shadows a
> previous local [-Wshadow]
> lib/ecore_con/dns.c:1033:28: warning: shadowed declaration is here
> [-Wshadow]
> lib/ecore_con/dns.c: In function 'dns_rr_exists':
> lib/ecore_con/dns.c:1787:2: error: 'for' loop initial declarations are
> only allowed in C99 mode
> lib/ecore_con/dns.c: In function 'dns_res_merge':
> lib/ecore_con/dns.c:5414:2: error: 'for' loop initial declarations are
> only allowed in C99 mode
> lib/ecore_con/dns.c:5421:4: error: 'for' loop initial declarations are
> only allowed in C99 mode
> lib/ecore_con/dns.c:5424:5: error: 'for' loop initial declarations are
> only allowed in C99 mode
> lib/ecore_con/dns.c: In function 'dns_res_glue':
> lib/ecore_con/dns.c:5480:3: error: 'for' loop initial declarations are
> only allowed in C99 mode
> lib/ecore_con/dns.c:5496:3: error: 'for' loop initial declarations are
> only allowed in C99 mode
> lib/ecore_con/dns.c: In function 'dns_res_exec':
> lib/ecore_con/dns.c:5604:3: error: 'for' loop initial declarations are
> only allowed in C99 mode
> lib/ecore_con/dns.c:5608:3: error: 'for' loop initial declarations are
> only allowed in C99 mode
> lib/ecore_con/dns.c:5806:3: error: 'for' loop initial declarations are
> only allowed in C99 mode
> lib/ecore_con/dns.c:5880:3: error: 'for' loop initial declarations are
> only allowed in C99 mode
> lib/ecore_con/dns.c:5884:3: error: 'for' loop initial declarations are
> only allowed in C99 mode
> lib/ecore_con/dns.c:5893:3: error: 'for' loop initial declarations are
> only allowed in C99 mode
> lib/ecore_con/dns.c:6027:3: error: 'for' loop initial declarations are
> only allowed in C99 mode
>
> The warnings are always there so can be ignored for this particular case.
>
> regards
> Stefan Schmidt
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
LogMeIn Rescue: Anywhere, Anytime Remot

Re: [E-devel] E SVN: caro IN trunk/efl: . m4 src src/lib/eio

[Vincent Torri]

On Thu, Dec 6, 2012 at 12:55 PM, Vincent Torri  wrote:
> On Thu, Dec 6, 2012 at 12:48 PM, Gustavo Sverzut Barbieri
>  wrote:
>> On Thursday, December 6, 2012, Enlightenment SVN wrote:
>>
>>> Log:
>>> inotify: revert : i want to keep autotools **modularized**. Instead, use
>>> in Eio what has been detected in Ecore_File.
>>
>>
>> Damn Vincent, why do you do these things when you don't understand?
>>
>> Really, I'm quite disappointed you still don't get how this should work
>> after this merge, yet you are the one doing the merge. Inotify is a
>> platform thing and may be used in various modules as already done. There is
>> no reason, point, sense or intelligence in doing the way it was!
>>
>> Apply this commit again and please don't revert things anymore unless you
>> clearly understand its purpose.
>
> funny...

i answer a bit more : your problem is that you have an idea, i have
another one and you can't stand that someone else is having another
opinion than your.

I know perfectly what you are trying to do, and i am strongly against that.

With your way of putting everything at the top, you are adding a mess
that i wanted to avoid.

In addition, that inotify stuff :

1) is used only in ecore_file and eio (and ecore_file should be
deprecated). As I said, it is checked in ecore_file, so **USE** the
result, as I have done with glib. I'm more aware of what is in those
autotools than you. I know that as i've written them, if you remember
(/end of sarcasm)
2) is used only in linux, that is, you are adding a useless test for
all other platforms, so your way is less optimal. Even if you use
host_os for that, that way is wrong, wrt GNU coding style as it's the
availability of that feature that must be checked, and not wrt an OS /
compiler. The only exception is Windows as it's too far from
UNIX/BSD/POSIX standards.

i won't commit that again. I won't let mess be added.

Vincent

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

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

[Daniel Juyung Seo]

It is 0 and 1.

Daniel Juyung Seo (SeoZ)
On Dec 6, 2012 8:46 PM, "Gustavo Sverzut Barbieri" 
wrote:

> Not? Isn't it 1 or -1, not 1 and 0?
>
> On Thursday, December 6, 2012, Enlightenment SVN wrote:
>
> > Log:
> > elm elm_interface_scrollable.c: Fixed wheel scroll direction with shift.
> >
> > Author:   seoz
> > Date: 2012-12-06 00:25:53 -0800 (Thu, 06 Dec 2012)
> > New Revision: 80312
> > Trac: http://trac.enlightenment.org/e/changeset/80312
> >
> > Modified:
> >   trunk/elementary/src/lib/elm_interface_scrollable.c
> >
> > Modified: trunk/elementary/src/lib/elm_interface_scrollable.c
> > ===
> > --- trunk/elementary/src/lib/elm_interface_scrollable.c 2012-12-06
> > 08:25:47 UTC (rev 80311)
> > +++ trunk/elementary/src/lib/elm_interface_scrollable.c 2012-12-06
> > 08:25:53 UTC (rev 80312)
> > @@ -1723,7 +1723,7 @@
> > (evas_key_modifier_is_set(ev->modifiers, "Super")))
> >   return;
> > else if (evas_key_modifier_is_set(ev->modifiers, "Shift"))
> > - direction = 1;
> > + direction = !direction;
> > eo_do(sid->obj, elm_scrollable_interface_content_pos_get(&x, &y));
> > if ((sid->down.bounce_x_animator) || (sid->down.bounce_y_animator) ||
> > (sid->scrollto.x.animator) || (sid->scrollto.y.animator))
> >
> >
> >
> >
> --
> > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> > Remotely access PCs and mobile devices and provide instant support
> > Improve your efficiency, and focus on delivering more value-add services
> > Discover what IT Professionals Know. Rescue delivers
> > http://p.sf.net/sfu/logmein_12329d2d
> > ___
> > enlightenment-svn mailing list
> > enlightenment-...@lists.sourceforge.net 
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
> >
>
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: caro IN trunk/efl: . m4 src src/lib/eio

[Gustavo Sverzut Barbieri]

On Thu, Dec 6, 2012 at 10:12 AM, Vincent Torri  wrote:
> On Thu, Dec 6, 2012 at 12:55 PM, Vincent Torri  
> wrote:
>> On Thu, Dec 6, 2012 at 12:48 PM, Gustavo Sverzut Barbieri
>>  wrote:
>>> On Thursday, December 6, 2012, Enlightenment SVN wrote:
>>>
 Log:
 inotify: revert : i want to keep autotools **modularized**. Instead, use
 in Eio what has been detected in Ecore_File.
>>>
>>>
>>> Damn Vincent, why do you do these things when you don't understand?
>>>
>>> Really, I'm quite disappointed you still don't get how this should work
>>> after this merge, yet you are the one doing the merge. Inotify is a
>>> platform thing and may be used in various modules as already done. There is
>>> no reason, point, sense or intelligence in doing the way it was!
>>>
>>> Apply this commit again and please don't revert things anymore unless you
>>> clearly understand its purpose.
>>
>> funny...
>
> i answer a bit more : your problem is that you have an idea, i have
> another one and you can't stand that someone else is having another
> opinion than your.
>
> I know perfectly what you are trying to do, and i am strongly against that.
>
> With your way of putting everything at the top, you are adding a mess
> that i wanted to avoid.
>
> In addition, that inotify stuff :
>
> 1) is used only in ecore_file and eio (and ecore_file should be
> deprecated). As I said, it is checked in ecore_file, so **USE** the
> result, as I have done with glib. I'm more aware of what is in those
> autotools than you. I know that as i've written them, if you remember
> (/end of sarcasm)

This is wrong. Not because of cosmetics, but dependency. if you're
doing code, you need a behavior, you create a common function that you
call from both sites. Not call one function expecting one behavior.

Here you have ecore_file and eio. Both direct users of inotify, it
makes no sense to have eio depend on a test from ecore_file. Even if
that's deprecated and may be removed one day, it's not the case
anytime soon.

And THAT is the exact point of the single tree merge. You move all
common to a common section. X11, Wayland... will all be checked in a
common section. Same for ipv6, crypto/tls...


> 2) is used only in linux, that is, you are adding a useless test for
> all other platforms, so your way is less optimal. Even if you use
> host_os for that, that way is wrong, wrt GNU coding style as it's the
> availability of that feature that must be checked, and not wrt an OS /
> compiler. The only exception is Windows as it's too far from
> UNIX/BSD/POSIX standards.

In this case I'm open for discussion, we could always check for
inotify.h as we don't fail if it's not there. But indeed I'm just
checking for that with linux to avoid the check when you don't expect
it to exist. It's just a matter of remove want_inotify and always
doing the check.

I'll come back with the previous commit, change this want_inotify if you wish.

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

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: etrunko trunk/efl

[Vincent Torri]

On Thu, Dec 6, 2012 at 1:26 PM, Enlightenment SVN
 wrote:
> Log:
> Avoid calling test so many times. Use -a/-o instead.

as i have already said, it can break on some shells and the autotools
prefer what i have done than what you are doing. Excerpt :

test
The test program is the way to perform many file and string tests.
It is often invoked by the alternate name ‘[’, but using that name in
Autoconf code is asking for trouble since it is an M4 quote character.

The -a, -o, ‘(’, and ‘)’ operands are not present in all
implementations, and have been marked obsolete by Posix 2008. This is
because there are inherent ambiguities in using them. For example,
‘test "$1" -a "$2"’ looks like a binary operator to check whether two
strings are both non-empty, but if ‘$1’ is the literal ‘!’, then some
implementations of test treat it as a negation of the unary operator
-a.

from 
http://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Builtins

So revert...

Vincent

>
>   Signed-off-by: Eduardo Lima (Etrunko) 
>
>
>
> Author:   etrunko
> Date: 2012-12-06 04:26:52 -0800 (Thu, 06 Dec 2012)
> New Revision: 80354
> Trac: http://trac.enlightenment.org/e/changeset/80354
>
> Modified:
>   trunk/efl/configure.ac
>
> Modified: trunk/efl/configure.ac
> ===
> --- trunk/efl/configure.ac  2012-12-06 12:21:19 UTC (rev 80353)
> +++ trunk/efl/configure.ac  2012-12-06 12:26:52 UTC (rev 80354)
> @@ -851,7 +851,7 @@
>  fi
>
>  AC_DEFINE_IF([EINA_DEBUG_MALLOC],
> -   [test "x${ac_cv_func_malloc_usable_size}" = "xyes" && test 
> "x${want_debug_malloc}" = "xyes"],
> +   [test "x${ac_cv_func_malloc_usable_size}" = "xyes" -a 
> "x${want_debug_malloc}" = "xyes"],
> [1], [Turn on debugging overhead in mempool])
>
>  if ! test "x${requirements_pc_deps_eina}" = "x" ; then
> @@ -916,7 +916,7 @@
>  EFL_CHECK_FUNCS([EINA], [dirfd dlopen dladdr iconv shm_open setxattr])
>
>  enable_log="no"
> -if test "x${efl_func_fnmatch}" = "xyes" && test "x${want_log}" = "xyes" ; 
> then
> +if test "x${efl_func_fnmatch}" = "xyes" -a "x${want_log}" = "xyes" ; then
> enable_log="yes"
>  fi
>
> @@ -980,7 +980,7 @@
>  EFL_CHECK_LIBS([EET], [libjpeg zlib])
>
>  # TODO: better way to force those instead of is secondary check
> -if test "x${efl_lib_zlib}" != "xyes" || test "x${efl_lib_libjpeg}" != "xyes" 
> ; then
> +if test "x${efl_lib_zlib}" != "xyes" -o "x${efl_lib_libjpeg}" != "xyes" ; 
> then
> AC_MSG_ERROR([Required EET libraries were not found.])
>  fi
>
> @@ -1490,7 +1490,7 @@
>  # harfbuzz support
>  have_harfbuzz="no"
>  have_harfbuzz_ft="no"
> -if test "x${want_harfbuzz}" = "xyes" || test "x${want_harfbuzz}" = "xauto" ; 
> then
> +if test "x${want_harfbuzz}" = "xyes" -o "x${want_harfbuzz}" = "xauto" ; then
> PKG_CHECK_EXISTS([harfbuzz >= 0.9.0],
>[
> have_harfbuzz="yes"
> @@ -1498,7 +1498,7 @@
> requirements_pc_deps_evas="harfbuzz >= 0.9.0 
> ${requirements_pc_deps_evas}"
>],
>[
> -   if test "x$want_harfbuzz" = "xyes" && test "x$use_strict" = "xyes" ; 
> then
> +   if test "x$want_harfbuzz" = "xyes" -a "x$use_strict" = "xyes" ; then
>AC_MSG_ERROR([Harfbuzz not found (strict dependencies checking)])
> fi
>])
> @@ -1510,7 +1510,7 @@
>
>  # Pixman
>  have_pixman="no"
> -if test "x${want_pixman}" = "xyes" || test "x${want_pixman}" = "xauto" ; then
> +if test "x${want_pixman}" = "xyes" -o "x${want_pixman}" = "xauto" ; then
> PKG_CHECK_EXISTS([pixman-1],
>[
> have_pixman="yes"
> @@ -1587,16 +1587,16 @@
>  # If software_x11 is available, define everything needed for X11
>
>  have_evas_engine_software_x11="no"
> -if test "x${have_evas_engine_software_xlib}" = "xyes" || test 
> "x${have_evas_engine_software_xlib}" = "xstatic" || test 
> "x${have_evas_engine_software_xcb}" = "xyes" || test 
> "x${have_evas_engine_software_xcb}" = "xstatic" ; then
> +if test "x${have_evas_engine_software_xlib}" = "xyes" -o 
> "x${have_evas_engine_software_xlib}" = "xstatic" -o 
> "x${have_evas_engine_software_xcb}" = "xyes" -o 
> "x${have_evas_engine_software_xcb}" = "xstatic" ; then
> have_evas_engine_software_x11="yes"
> AC_DEFINE_UNQUOTED([BUILD_ENGINE_SOFTWARE_X11], [1], [Build software X11 
> engine])
>  fi
>  AM_CONDITIONAL([BUILD_ENGINE_SOFTWARE_X11], [test 
> "x${have_evas_engine_software_x11}" = "xyes"])
>
> -if test "x${have_evas_engine_software_xlib}" = "xstatic" || test 
> "x${have_evas_engine_software_xcb}" = "xstatic"; then
> +if test "x${have_evas_engine_software_xlib}" = "xstatic" -o 
> "x${have_evas_engine_software_xcb}" = "xstatic"; then
> AC_DEFINE_UNQUOTED([EVAS_STATIC_BUILD_SOFTWARE_X11], [1], [Build software 
> X11 engine as part of libevas])
>  fi
> -AM_CONDITIONAL([EVAS_STATIC_BUILD_SOFTWARE_X11], [test 
> "x${have_evas_engine_software_xcb}" = "xstatic" || test 
> "x${have_evas_engine_software_xlib}" = "xstatic"])
> +AM_CONDIT

Re: [E-devel] E SVN: caro IN trunk/efl: . m4 src src/lib/eio

[Vincent Torri]

On Thu, Dec 6, 2012 at 1:30 PM, Gustavo Sverzut Barbieri
 wrote:
> On Thu, Dec 6, 2012 at 10:12 AM, Vincent Torri  
> wrote:
>> On Thu, Dec 6, 2012 at 12:55 PM, Vincent Torri  
>> wrote:
>>> On Thu, Dec 6, 2012 at 12:48 PM, Gustavo Sverzut Barbieri
>>>  wrote:
 On Thursday, December 6, 2012, Enlightenment SVN wrote:

> Log:
> inotify: revert : i want to keep autotools **modularized**. Instead, use
> in Eio what has been detected in Ecore_File.


 Damn Vincent, why do you do these things when you don't understand?

 Really, I'm quite disappointed you still don't get how this should work
 after this merge, yet you are the one doing the merge. Inotify is a
 platform thing and may be used in various modules as already done. There is
 no reason, point, sense or intelligence in doing the way it was!

 Apply this commit again and please don't revert things anymore unless you
 clearly understand its purpose.
>>>
>>> funny...
>>
>> i answer a bit more : your problem is that you have an idea, i have
>> another one and you can't stand that someone else is having another
>> opinion than your.
>>
>> I know perfectly what you are trying to do, and i am strongly against that.
>>
>> With your way of putting everything at the top, you are adding a mess
>> that i wanted to avoid.
>>
>> In addition, that inotify stuff :
>>
>> 1) is used only in ecore_file and eio (and ecore_file should be
>> deprecated). As I said, it is checked in ecore_file, so **USE** the
>> result, as I have done with glib. I'm more aware of what is in those
>> autotools than you. I know that as i've written them, if you remember
>> (/end of sarcasm)
>
> This is wrong. Not because of cosmetics, but dependency. if you're
> doing code, you need a behavior, you create a common function that you
> call from both sites. Not call one function expecting one behavior.
>
> Here you have ecore_file and eio. Both direct users of inotify, it
> makes no sense to have eio depend on a test from ecore_file. Even if
> that's deprecated and may be removed one day, it's not the case
> anytime soon.
>
> And THAT is the exact point of the single tree merge. You move all
> common to a common section. X11, Wayland... will all be checked in a
> common section. Same for ipv6, crypto/tls...
>
>
>> 2) is used only in linux, that is, you are adding a useless test for
>> all other platforms, so your way is less optimal. Even if you use
>> host_os for that, that way is wrong, wrt GNU coding style as it's the
>> availability of that feature that must be checked, and not wrt an OS /
>> compiler. The only exception is Windows as it's too far from
>> UNIX/BSD/POSIX standards.
>
> In this case I'm open for discussion, we could always check for
> inotify.h as we don't fail if it's not there. But indeed I'm just
> checking for that with linux to avoid the check when you don't expect
> it to exist. It's just a matter of remove want_inotify and always
> doing the check.
>
> I'll come back with the previous commit, change this want_inotify if you wish.

You said in your commit that you fixed code. So split at least your
commit into 2 parts : code first (with a bit of autotools if needed)
and the remaining part

Vincent

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: etrunko trunk/efl

[Eduardo Lima (Etrunko)]

On Thu, Dec 6, 2012 at 10:33 AM, Vincent Torri  wrote:
> On Thu, Dec 6, 2012 at 1:26 PM, Enlightenment SVN
>  wrote:
>> Log:
>> Avoid calling test so many times. Use -a/-o instead.
>
> as i have already said, it can break on some shells and the autotools
> prefer what i have done than what you are doing. Excerpt :
>
> test
> The test program is the way to perform many file and string tests.
> It is often invoked by the alternate name ‘[’, but using that name in
> Autoconf code is asking for trouble since it is an M4 quote character.
>
> The -a, -o, ‘(’, and ‘)’ operands are not present in all
> implementations, and have been marked obsolete by Posix 2008. This is
> because there are inherent ambiguities in using them. For example,
> ‘test "$1" -a "$2"’ looks like a binary operator to check whether two
> strings are both non-empty, but if ‘$1’ is the literal ‘!’, then some
> implementations of test treat it as a negation of the unary operator
> -a.
>
> from 
> http://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Builtins
>

Thanks for the clarification.

> So revert...

Done in 80357.

>
> Vincent
>
>>
>>   Signed-off-by: Eduardo Lima (Etrunko) 
>>
>>
>>
>> Author:   etrunko
>> Date: 2012-12-06 04:26:52 -0800 (Thu, 06 Dec 2012)
>> New Revision: 80354
>> Trac: http://trac.enlightenment.org/e/changeset/80354
>>
>> Modified:
>>   trunk/efl/configure.ac
>>
>> Modified: trunk/efl/configure.ac
>> ===
>> --- trunk/efl/configure.ac  2012-12-06 12:21:19 UTC (rev 80353)
>> +++ trunk/efl/configure.ac  2012-12-06 12:26:52 UTC (rev 80354)
>> @@ -851,7 +851,7 @@
>>  fi
>>
>>  AC_DEFINE_IF([EINA_DEBUG_MALLOC],
>> -   [test "x${ac_cv_func_malloc_usable_size}" = "xyes" && test 
>> "x${want_debug_malloc}" = "xyes"],
>> +   [test "x${ac_cv_func_malloc_usable_size}" = "xyes" -a 
>> "x${want_debug_malloc}" = "xyes"],
>> [1], [Turn on debugging overhead in mempool])
>>
>>  if ! test "x${requirements_pc_deps_eina}" = "x" ; then
>> @@ -916,7 +916,7 @@
>>  EFL_CHECK_FUNCS([EINA], [dirfd dlopen dladdr iconv shm_open setxattr])
>>
>>  enable_log="no"
>> -if test "x${efl_func_fnmatch}" = "xyes" && test "x${want_log}" = "xyes" ; 
>> then
>> +if test "x${efl_func_fnmatch}" = "xyes" -a "x${want_log}" = "xyes" ; then
>> enable_log="yes"
>>  fi
>>
>> @@ -980,7 +980,7 @@
>>  EFL_CHECK_LIBS([EET], [libjpeg zlib])
>>
>>  # TODO: better way to force those instead of is secondary check
>> -if test "x${efl_lib_zlib}" != "xyes" || test "x${efl_lib_libjpeg}" != 
>> "xyes" ; then
>> +if test "x${efl_lib_zlib}" != "xyes" -o "x${efl_lib_libjpeg}" != "xyes" ; 
>> then
>> AC_MSG_ERROR([Required EET libraries were not found.])
>>  fi
>>
>> @@ -1490,7 +1490,7 @@
>>  # harfbuzz support
>>  have_harfbuzz="no"
>>  have_harfbuzz_ft="no"
>> -if test "x${want_harfbuzz}" = "xyes" || test "x${want_harfbuzz}" = "xauto" 
>> ; then
>> +if test "x${want_harfbuzz}" = "xyes" -o "x${want_harfbuzz}" = "xauto" ; then
>> PKG_CHECK_EXISTS([harfbuzz >= 0.9.0],
>>[
>> have_harfbuzz="yes"
>> @@ -1498,7 +1498,7 @@
>> requirements_pc_deps_evas="harfbuzz >= 0.9.0 
>> ${requirements_pc_deps_evas}"
>>],
>>[
>> -   if test "x$want_harfbuzz" = "xyes" && test "x$use_strict" = "xyes" ; 
>> then
>> +   if test "x$want_harfbuzz" = "xyes" -a "x$use_strict" = "xyes" ; then
>>AC_MSG_ERROR([Harfbuzz not found (strict dependencies checking)])
>> fi
>>])
>> @@ -1510,7 +1510,7 @@
>>
>>  # Pixman
>>  have_pixman="no"
>> -if test "x${want_pixman}" = "xyes" || test "x${want_pixman}" = "xauto" ; 
>> then
>> +if test "x${want_pixman}" = "xyes" -o "x${want_pixman}" = "xauto" ; then
>> PKG_CHECK_EXISTS([pixman-1],
>>[
>> have_pixman="yes"
>> @@ -1587,16 +1587,16 @@
>>  # If software_x11 is available, define everything needed for X11
>>
>>  have_evas_engine_software_x11="no"
>> -if test "x${have_evas_engine_software_xlib}" = "xyes" || test 
>> "x${have_evas_engine_software_xlib}" = "xstatic" || test 
>> "x${have_evas_engine_software_xcb}" = "xyes" || test 
>> "x${have_evas_engine_software_xcb}" = "xstatic" ; then
>> +if test "x${have_evas_engine_software_xlib}" = "xyes" -o 
>> "x${have_evas_engine_software_xlib}" = "xstatic" -o 
>> "x${have_evas_engine_software_xcb}" = "xyes" -o 
>> "x${have_evas_engine_software_xcb}" = "xstatic" ; then
>> have_evas_engine_software_x11="yes"
>> AC_DEFINE_UNQUOTED([BUILD_ENGINE_SOFTWARE_X11], [1], [Build software X11 
>> engine])
>>  fi
>>  AM_CONDITIONAL([BUILD_ENGINE_SOFTWARE_X11], [test 
>> "x${have_evas_engine_software_x11}" = "xyes"])
>>
>> -if test "x${have_evas_engine_software_xlib}" = "xstatic" || test 
>> "x${have_evas_engine_software_xcb}" = "xstatic"; then
>> +if test "x${have_evas_engine_software_xlib}" = "xstatic" -o 
>> "x${have_evas_engine_software_xcb}" = "xstatic"; then
>> AC_DEFINE_UNQUOTED([EVAS_STATIC_BUILD_SO

Re: [E-devel] E SVN: etrunko trunk/efl

[Gustavo Sverzut Barbieri]

On Thu, Dec 6, 2012 at 10:33 AM, Vincent Torri  wrote:
> On Thu, Dec 6, 2012 at 1:26 PM, Enlightenment SVN
>  wrote:
>> Log:
>> Avoid calling test so many times. Use -a/-o instead.
>
> as i have already said, it can break on some shells and the autotools
> prefer what i have done than what you are doing. Excerpt :
>
> test
> The test program is the way to perform many file and string tests.
> It is often invoked by the alternate name ‘[’, but using that name in
> Autoconf code is asking for trouble since it is an M4 quote character.
>
> The -a, -o, ‘(’, and ‘)’ operands are not present in all
> implementations, and have been marked obsolete by Posix 2008. This is
> because there are inherent ambiguities in using them. For example,
> ‘test "$1" -a "$2"’ looks like a binary operator to check whether two
> strings are both non-empty, but if ‘$1’ is the literal ‘!’, then some
> implementations of test treat it as a negation of the unary operator
> -a.
>
> from 
> http://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Builtins
>
> So revert...

I disagree here, given that we never use the first operand as ! in any
of our checks, just yes/no, there is no harm. The benefit is reducing
the number of calls to test binary and also the resulting code size as
it's smaller.

as for not being present, could you point a real case other than an
imaginary case? I never saw that and we already had some of that in
our efl before, so it should work.

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

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] deprecating some of ecore_file for 1.8

[Vincent Torri]

Hey

as eio is quite used, now, why not deprecating ecore_file parts that
are in common with eio ?

Vincent

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: etrunko trunk/efl

[Eduardo Lima (Etrunko)]

On Thu, Dec 6, 2012 at 11:02 AM, Gustavo Sverzut Barbieri
 wrote:
> On Thu, Dec 6, 2012 at 10:33 AM, Vincent Torri  
> wrote:
>> On Thu, Dec 6, 2012 at 1:26 PM, Enlightenment SVN
>>  wrote:
>>> Log:
>>> Avoid calling test so many times. Use -a/-o instead.
>>
>> as i have already said, it can break on some shells and the autotools
>> prefer what i have done than what you are doing. Excerpt :
>>
>> test
>> The test program is the way to perform many file and string tests.
>> It is often invoked by the alternate name ‘[’, but using that name in
>> Autoconf code is asking for trouble since it is an M4 quote character.
>>
>> The -a, -o, ‘(’, and ‘)’ operands are not present in all
>> implementations, and have been marked obsolete by Posix 2008. This is
>> because there are inherent ambiguities in using them. For example,
>> ‘test "$1" -a "$2"’ looks like a binary operator to check whether two
>> strings are both non-empty, but if ‘$1’ is the literal ‘!’, then some
>> implementations of test treat it as a negation of the unary operator
>> -a.
>>
>> from 
>> http://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Builtins
>>
>> So revert...
>
> I disagree here, given that we never use the first operand as ! in any
> of our checks, just yes/no, there is no harm. The benefit is reducing
> the number of calls to test binary and also the resulting code size as
> it's smaller.
>
> as for not being present, could you point a real case other than an
> imaginary case? I never saw that and we already had some of that in
> our efl before, so it should work.
>

I reverted mostly due to the fact of "have been marked obsolete by Posix 2008".

-- 
Eduardo de Barros Lima ◤✠◢
ebl...@gmail.com

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: etrunko trunk/efl

[Vincent Torri]

On Thu, Dec 6, 2012 at 2:12 PM, Eduardo Lima (Etrunko)  wrote:
> On Thu, Dec 6, 2012 at 11:02 AM, Gustavo Sverzut Barbieri
>  wrote:
>> On Thu, Dec 6, 2012 at 10:33 AM, Vincent Torri  
>> wrote:
>>> On Thu, Dec 6, 2012 at 1:26 PM, Enlightenment SVN
>>>  wrote:
 Log:
 Avoid calling test so many times. Use -a/-o instead.
>>>
>>> as i have already said, it can break on some shells and the autotools
>>> prefer what i have done than what you are doing. Excerpt :
>>>
>>> test
>>> The test program is the way to perform many file and string tests.
>>> It is often invoked by the alternate name ‘[’, but using that name in
>>> Autoconf code is asking for trouble since it is an M4 quote character.
>>>
>>> The -a, -o, ‘(’, and ‘)’ operands are not present in all
>>> implementations, and have been marked obsolete by Posix 2008. This is
>>> because there are inherent ambiguities in using them. For example,
>>> ‘test "$1" -a "$2"’ looks like a binary operator to check whether two
>>> strings are both non-empty, but if ‘$1’ is the literal ‘!’, then some
>>> implementations of test treat it as a negation of the unary operator
>>> -a.
>>>
>>> from 
>>> http://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Builtins
>>>
>>> So revert...
>>
>> I disagree here, given that we never use the first operand as ! in any
>> of our checks, just yes/no, there is no harm. The benefit is reducing
>> the number of calls to test binary and also the resulting code size as
>> it's smaller.
>>
>> as for not being present, could you point a real case other than an
>> imaginary case? I never saw that and we already had some of that in
>> our efl before, so it should work.

never seeing something does not mean that it does exists. You of
course are an expert on any other OS than linux, it seems.

Vincent

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] deprecating some of ecore_file for 1.8

[Christopher Michael]

On 06/12/12 13:05, Vincent Torri wrote:
> Hey
>
> as eio is quite used, now, why not deprecating ecore_file parts that
> are in common with eio ?
>
> Vincent
>

+1

dh



--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] deprecating some of ecore_file for 1.8

[Gustavo Sverzut Barbieri]

ecore_file itself should go.

path manipulation (exists, dirname...) should go in eina, other bits
should go in eio.

On Thu, Dec 6, 2012 at 11:05 AM, Vincent Torri  wrote:
> Hey
>
> as eio is quite used, now, why not deprecating ecore_file parts that
> are in common with eio ?
>
> Vincent
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



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

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk/efl: . m4 src src/lib/ecore_file src/lib/eio

[Guillaume Friloux]

Hello, excuse me to interfere, but what you deleted was added 11 months 
ago so inotify works on old distros like debian4.
Here we officially dropped all the debian4 during summer, so im not 
embarrassed, by maybe others could be.
Is it really necessary to remove these ? Shouldnt warnings be added 
somewhere to warn people that theres a required min kernel version to be 
able to use it ?



On 06/12/2012 14:02, Enlightenment SVN wrote:

Log:
efl: common inotify checks, simplified.
   
   Another try to make inotify checks more common.
   
   This time uses AC_CHECK_HEADERS() as for others, that already define

   HAVE_SYS_INOTIFY_H, then uses that.
   
   I still kept AM_CONDITIONAL([HAVE_INOTIFY]) because I plan to convert

   ecore_file to the same, smarter, method that is used in eio (compiling
   the file depending on the backend.
   
   


Author:   barbieri
Date: 2012-12-06 05:02:59 -0800 (Thu, 06 Dec 2012)
New Revision: 80358
Trac: http://trac.enlightenment.org/e/changeset/80358

Modified: trunk/efl/src/lib/eio/eio_monitor_inotify.c
===
--- trunk/efl/src/lib/eio/eio_monitor_inotify.c 2012-12-06 13:01:21 UTC (rev 
80357)
+++ trunk/efl/src/lib/eio/eio_monitor_inotify.c 2012-12-06 13:02:59 UTC (rev 
80358)
@@ -20,11 +20,8 @@
  #include "eio_private.h"
  #include "Eio.h"
  
-#ifdef HAVE_SYS_INOTIFY

+#ifdef HAVE_SYS_INOTIFY_H
  # include 
-#else
-# include 
-# include 
  #endif
  
  /**

@@ -70,26 +67,6 @@
EIO_INOTIFY_LINE(IN_UNMOUNT, SELF_DELETED, SELF_DELETED)
  };
  
-#ifndef HAVE_SYS_INOTIFY

-static inline int
-inotify_init(void)
-{
-   return syscall(__NR_inotify_init);
-}
-
-static inline int
-inotify_add_watch(int fd, const char *name, __u32 mask)
-{
-   return syscall(__NR_inotify_add_watch, fd, name, mask);
-}
-
-static inline int
-inotify_rm_watch(int fd, __u32 wd)
-{
-   return syscall(__NR_inotify_rm_watch, fd, wd);
-}
-#endif
-
  static void
  _eio_inotify_del(void *data)
  {

Modified: trunk/efl/src/lib/eio/eio_monitor_poll.c
===
--- trunk/efl/src/lib/eio/eio_monitor_poll.c2012-12-06 13:01:21 UTC (rev 
80357)
+++ trunk/efl/src/lib/eio/eio_monitor_poll.c2012-12-06 13:02:59 UTC (rev 
80358)
@@ -270,7 +270,7 @@
   * @cond LOCAL
   */
  
-#if !defined HAVE_INOTIFY && !defined HAVE_NOTIFY_WIN32

+#if !defined HAVE_SYS_INOTIFY_H && !defined HAVE_NOTIFY_WIN32
  void eio_monitor_backend_init(void)
  {
  }




<>--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] std=c99 for ecore_con dns.c got missing

[Stefan Schmidt]

Hello.

On 06/12/12 11:57, Vincent Torri wrote:
> so it's a problem with clang. Fix your CC, then

Thanks, its not my CC. I have a way to build it for my cases.

regards
Stefan Schmidt


--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] deprecating some of ecore_file for 1.8

[Christopher Michael]

On 06/12/12 13:25, Gustavo Sverzut Barbieri wrote:
> ecore_file itself should go.
>
> path manipulation (exists, dirname...) should go in eina, other bits
> should go in eio.
>

Why split file/path functions (exists, dirname, etc) to eina ? If Eio is 
to be the library for file functions, then why break only "some" of them 
out into eina ?

> On Thu, Dec 6, 2012 at 11:05 AM, Vincent Torri  
> wrote:
>> Hey
>>
>> as eio is quite used, now, why not deprecating ecore_file parts that
>> are in common with eio ?
>>
>> Vincent
>>

+1 on the idea tho ;)

dh



--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] deprecating some of ecore_file for 1.8

[Gustavo Sverzut Barbieri]

On Thu, Dec 6, 2012 at 11:38 AM, Christopher Michael
 wrote:
> On 06/12/12 13:25, Gustavo Sverzut Barbieri wrote:
>>
>> ecore_file itself should go.
>>
>> path manipulation (exists, dirname...) should go in eina, other bits
>> should go in eio.
>>
>
> Why split file/path functions (exists, dirname, etc) to eina ? If Eio is to
> be the library for file functions, then why break only "some" of them out
> into eina ?

two reasons:
 1 - they are very, very simple. mostly wrappers around system versions
 2 - many modules uses that, like eina itself, ecore and evas. to do
path finding, etc.


>> On Thu, Dec 6, 2012 at 11:05 AM, Vincent Torri 
>> wrote:
>>>
>>> Hey
>>>
>>> as eio is quite used, now, why not deprecating ecore_file parts that
>>> are in common with eio ?
>>>
>>> Vincent
>>>
>
> +1 on the idea tho ;)
>
> dh
>
>



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

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk/efl: . m4 src src/lib/ecore_file src/lib/eio

[Gustavo Sverzut Barbieri]

On Thu, Dec 6, 2012 at 11:26 AM, Guillaume Friloux
 wrote:
> Hello, excuse me to interfere, but what you deleted was added 11 months ago
> so inotify works on old distros like debian4.
> Here we officially dropped all the debian4 during summer, so im not
> embarrassed, by maybe others could be.
> Is it really necessary to remove these ? Shouldnt warnings be added
> somewhere to warn people that theres a required min kernel version to be
> able to use it ?

it's not kernel, it's libc. we don't support such an old libc.
Actually since debian4 doesn't update anything, keep with efl branch
1.7 that will still support that.

we're not even sure when 1.8 will be released, so far it's
unreleased/future code.

PS: if you really want to have it, you can create a debian package
backport-sys-inotify with:
/usr/include/sys/inotify.h:
#include 

static inline int
inotify_init(void)
{
   return syscall(__NR_inotify_init);
}

static inline int
inotify_add_watch(int fd, const char *name, __u32 mask)
{
   return syscall(__NR_inotify_add_watch, fd, name, mask);
}

static inline int
inotify_rm_watch(int fd, __u32 wd)
{
   return syscall(__NR_inotify_rm_watch, fd, wd);
}

Another option is to backport the inotify support to debian4 libc's.
Both are better and useful outside of just EFL.

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

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Elc_Naviframe]: Crash on evas_object_del fix.

[SHILPA ONKAR SINGH]

Hi,

This crash happens if pop_transition_cb gets scheduled first but transition is 
not completed  and before that itself evas_object_del
is called, with below code it might be hard to reproduce, as per below code 
pop_transition_cb will not 
even get a chance to get scheduled.

so to reproduce this crash you can call item_pop in some button click callback 
and then call evas_object_del in a timer callback and give time gap of 0.3 
seconds. when you do this 
pop_transition_cb gets called first, then evas_object_del before animation is 
complete and hence the crash can be reproduced.

I have got this crash with various apps which I am testing here on target (as 
they have their own cleanup code before calling del the above scenario was 
created almost everywhere)
and logically if you check the item pointer from sd->popping list needs
to be removed only after pop operation is complete. instead its being done in 
pop_transition_cb which begins the animation.

Thanks & Regards
Shilpa Singh




--- Original Message ---
Sender : Daniel Juyung Seo
Date : Dec 06, 2012 17:25 (GMT+09:00)
Title : Re: [E-devel] [Elc_Naviframe]: Crash on evas_object_del fix.

Dear Shilpa,
it doesn't crash here.

Do you have any reproducable code?
I tried with the following code.

--- a/elementary/src/bin/test_naviframe.c
+++ b/elementary/src/bin/test_naviframe.c
@@ -190,6 +190,10 @@ _page2(void *data, Evas_Object *obj __UNUSED__, void
*event_info __UNUSED__)
Evas_Object *bt, *content, *ic, *nf = data;
Elm_Object_Item *it;

+elm_naviframe_item_pop(data);
+evas_object_del(data);
+return;
+
bt = elm_button_add(nf);
evas_object_size_hint_align_set(bt, EVAS_HINT_FILL, EVAS_HINT_FILL);
evas_object_smart_callback_add(bt, "clicked", _page3, nf);

Daniel Juyung Seo (SeoZ)

On Thu, Dec 6, 2012 at 3:51 PM, SHILPA ONKAR SINGH > wrote:

> Hi All,
>
> Please find attached bug fix patch for Naviframe.
> This patch fixes crash in naviframe which happens when evas_object_del
> is called immediately after item_pop.
>
> Change description:
>elc_naviframe: Crash on calling evas_object_del of naviframe
> immediately after item_pop fixed.
>
> Signed-Off by: Shilpa Singh(shilpa.si...@samsung.com)
>
> Thanks & Regards
> Shilpa Singh
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] deprecating some of ecore_file for 1.8

[Christopher Michael]

On 06/12/12 13:40, Gustavo Sverzut Barbieri wrote:
> On Thu, Dec 6, 2012 at 11:38 AM, Christopher Michael
>  wrote:
>> On 06/12/12 13:25, Gustavo Sverzut Barbieri wrote:
>>>
>>> ecore_file itself should go.
>>>
>>> path manipulation (exists, dirname...) should go in eina, other bits
>>> should go in eio.
>>>
>>
>> Why split file/path functions (exists, dirname, etc) to eina ? If Eio is to
>> be the library for file functions, then why break only "some" of them out
>> into eina ?
>
> two reasons:
>   1 - they are very, very simple. mostly wrappers around system versions

Well, I think the complexity of the functions is irrelevant as a reason 
really.

Do we typically use, "Well this graphical function is incredibly complex 
so it should be broken out from evas and stuck into a different library" 
as a basis for development ? Or the converse .. "Well this graphical 
function is incredibly simple so it doesn't belong in evas". I don't 
think we do development that ;)

 IMO, I don't see function complexity as a valid reason here.

>   2 - many modules uses that, like eina itself, ecore and evas. to do
> path finding, etc.
>

Ok ...then why can't those libraries use eio ??

dh

>
>>> On Thu, Dec 6, 2012 at 11:05 AM, Vincent Torri 
>>> wrote:

 Hey

 as eio is quite used, now, why not deprecating ecore_file parts that
 are in common with eio ?

 Vincent

>>
>> +1 on the idea tho ;)
>>
>> dh
>>
>>
>



--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] deprecating some of ecore_file for 1.8

[Vincent Torri]

On Thu, Dec 6, 2012 at 2:48 PM, Christopher Michael
 wrote:
> On 06/12/12 13:40, Gustavo Sverzut Barbieri wrote:
>> On Thu, Dec 6, 2012 at 11:38 AM, Christopher Michael
>>  wrote:
>>> On 06/12/12 13:25, Gustavo Sverzut Barbieri wrote:

 ecore_file itself should go.

 path manipulation (exists, dirname...) should go in eina, other bits
 should go in eio.

>>>
>>> Why split file/path functions (exists, dirname, etc) to eina ? If Eio is to
>>> be the library for file functions, then why break only "some" of them out
>>> into eina ?
>>
>> two reasons:
>>   1 - they are very, very simple. mostly wrappers around system versions
>
> Well, I think the complexity of the functions is irrelevant as a reason
> really.
>
> Do we typically use, "Well this graphical function is incredibly complex
> so it should be broken out from evas and stuck into a different library"
> as a basis for development ? Or the converse .. "Well this graphical
> function is incredibly simple so it doesn't belong in evas". I don't
> think we do development that ;)
>
>  IMO, I don't see function complexity as a valid reason here.
>
>>   2 - many modules uses that, like eina itself, ecore and evas. to do
>> path finding, etc.
>>
>
> Ok ...then why can't those libraries use eio ??

if i'm not mistaken, eio uses ecore, so could be a problem for a use in evas

Vincent

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk/efl: . m4 src src/lib/ecore_file src/lib/eio

[Guillaume Friloux]

Ok, sorry for my mistake, its old and forgot some things.
But still, there must be warns added somewhere to clearly state that 
next version will drop support. In my vision, once a functionnality is 
added, you must maintain it, or clearly tell its dropped, and even give 
solutions, no ?


On 06/12/2012 14:45, Gustavo Sverzut Barbieri wrote:

On Thu, Dec 6, 2012 at 11:26 AM, Guillaume Friloux
 wrote:

Hello, excuse me to interfere, but what you deleted was added 11 months ago
so inotify works on old distros like debian4.
Here we officially dropped all the debian4 during summer, so im not
embarrassed, by maybe others could be.
Is it really necessary to remove these ? Shouldnt warnings be added
somewhere to warn people that theres a required min kernel version to be
able to use it ?

it's not kernel, it's libc. we don't support such an old libc.
Actually since debian4 doesn't update anything, keep with efl branch
1.7 that will still support that.

we're not even sure when 1.8 will be released, so far it's
unreleased/future code.

PS: if you really want to have it, you can create a debian package
backport-sys-inotify with:
/usr/include/sys/inotify.h:
#include 

static inline int
inotify_init(void)
{
return syscall(__NR_inotify_init);
}

static inline int
inotify_add_watch(int fd, const char *name, __u32 mask)
{
return syscall(__NR_inotify_add_watch, fd, name, mask);
}

static inline int
inotify_rm_watch(int fd, __u32 wd)
{
return syscall(__NR_inotify_rm_watch, fd, wd);
}

Another option is to backport the inotify support to debian4 libc's.
Both are better and useful outside of just EFL.



<>--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] deprecating some of ecore_file for 1.8

[Christopher Michael]

On 06/12/12 13:50, Vincent Torri wrote:
> On Thu, Dec 6, 2012 at 2:48 PM, Christopher Michael
>  wrote:
>> On 06/12/12 13:40, Gustavo Sverzut Barbieri wrote:
>>> On Thu, Dec 6, 2012 at 11:38 AM, Christopher Michael
>>>  wrote:
 On 06/12/12 13:25, Gustavo Sverzut Barbieri wrote:
>
> ecore_file itself should go.
>
> path manipulation (exists, dirname...) should go in eina, other bits
> should go in eio.
>

 Why split file/path functions (exists, dirname, etc) to eina ? If Eio is to
 be the library for file functions, then why break only "some" of them out
 into eina ?
>>>
>>> two reasons:
>>>1 - they are very, very simple. mostly wrappers around system versions
>>
>> Well, I think the complexity of the functions is irrelevant as a reason
>> really.
>>
>> Do we typically use, "Well this graphical function is incredibly complex
>> so it should be broken out from evas and stuck into a different library"
>> as a basis for development ? Or the converse .. "Well this graphical
>> function is incredibly simple so it doesn't belong in evas". I don't
>> think we do development that ;)
>>
>>  IMO, I don't see function complexity as a valid reason here.
>>
>>>2 - many modules uses that, like eina itself, ecore and evas. to do
>>> path finding, etc.
>>>
>>
>> Ok ...then why can't those libraries use eio ??
>
> if i'm not mistaken, eio uses ecore, so could be a problem for a use in evas
>
> Vincent

Ahh. If that is the case, then it makes sense.

Thanks for clarifying ;)

As an aside...what is eio using ecore For ??

dh



--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri trunk/efl

[Vincent Torri]

On Thu, Dec 6, 2012 at 2:58 PM, Enlightenment SVN
 wrote:
> Log:
> efl: remove want_poll.
>
>
> Author:   barbieri
> Date: 2012-12-06 05:58:32 -0800 (Thu, 06 Dec 2012)
> New Revision: 80362
> Trac: http://trac.enlightenment.org/e/changeset/80362
>
> Modified:
>   trunk/efl/configure.ac
>
> Modified: trunk/efl/configure.ac
> ===
> --- trunk/efl/configure.ac  2012-12-06 13:39:58 UTC (rev 80361)
> +++ trunk/efl/configure.ac  2012-12-06 13:58:32 UTC (rev 80362)
> @@ -2367,19 +2367,6 @@
>
>  ### Additional options to configure
>
> -AC_ARG_ENABLE([poll],
> -   [AC_HELP_STRING([--disable-poll],
> -  [disable poll in the ecore_file module. @<:@default=enabled@:>@])],
> -   [
> -if test "x${enableval}" = "xyes" ; then
> -   want_poll="yes"
> -else
> -   want_poll="no"
> -fi
> -   ],
> -   [want_poll="yes"])
> -
> -
>  AC_ARG_ENABLE([atfile-source],
> [AC_HELP_STRING([--disable-atfile-source],
> [disable use of atfile source functions as openat and mkdirat 
> @<:@default=detect@:>@])],
> @@ -2393,12 +2380,6 @@
>
>  ### Default values
>
> -have_poll="no"
> -if test "x${want_poll}" = "xyes" ; then
> -   AC_DEFINE([HAVE_POLL], [1], [File monitoring with polling])

and you don't touch code that uses HAVE_POLL ?

Vincent


> -   have_poll="yes"
> -fi
> -
>  if ! test "x${have_atfile_source}" = "xno" ; then
> AC_CHECK_FUNCS([mkdirat],
>[
>
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] deprecating some of ecore_file for 1.8

[sd]

> On 06/12/12 13:50, Vincent Torri wrote:
>> On Thu, Dec 6, 2012 at 2:48 PM, Christopher Michael
>>  wrote:
>>> On 06/12/12 13:40, Gustavo Sverzut Barbieri wrote:
 On Thu, Dec 6, 2012 at 11:38 AM, Christopher Michael
  wrote:
> On 06/12/12 13:25, Gustavo Sverzut Barbieri wrote:
>>
>> ecore_file itself should go.
>>
>> path manipulation (exists, dirname...) should go in eina, other bits
>> should go in eio.
>>
>
> Why split file/path functions (exists, dirname, etc) to eina ? If Eio
> is to
> be the library for file functions, then why break only "some" of them
> out
> into eina ?

 two reasons:
1 - they are very, very simple. mostly wrappers around system
 versions
>>>
>>> Well, I think the complexity of the functions is irrelevant as a reason
>>> really.
>>>
>>> Do we typically use, "Well this graphical function is incredibly
>>> complex
>>> so it should be broken out from evas and stuck into a different
>>> library"
>>> as a basis for development ? Or the converse .. "Well this graphical
>>> function is incredibly simple so it doesn't belong in evas". I don't
>>> think we do development that ;)
>>>
>>>  IMO, I don't see function complexity as a valid reason here.
>>>
2 - many modules uses that, like eina itself, ecore and evas. to do
 path finding, etc.

>>>
>>> Ok ...then why can't those libraries use eio ??
>>
>> if i'm not mistaken, eio uses ecore, so could be a problem for a use in
>> evas
>>
>> Vincent
>
> Ahh. If that is the case, then it makes sense.
>
> Thanks for clarifying ;)
>
> As an aside...what is eio using ecore For ??

At least threading, so it is heavily dependent.

S.


--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] std=c99 for ecore_con dns.c got missing

[thomasg]

On Thu, Dec 6, 2012 at 12:57 PM, Vincent Torri wrote:

> so it's a problem with clang. Fix your CC, then
>
>
Is it really?
dns_rr_foreach is defined as "for (struct dns_rr_i DNS_PP_XPASTE(i,
__LINE__) = *dns_rr_i_new((P), __VA_ARGS__); ..." in dns.h
As this is a declaration in the loop, it seems that clang's complaining is
correct, this is a C99 feature.

So I think, a C99 compiler should be required, even if GCC does not
complain.



>
>
On Thu, Dec 6, 2012 at 11:59 AM, Stefan Schmidt 
> wrote:
> > Hello.
> >
> > On 06/12/12 10:34, Vincent Torri wrote:
> >> On Thu, Dec 6, 2012 at 11:28 AM, Stefan Schmidt 
> wrote:
> >>> Hello.
> >>>
> >>> Either during the merge of ecore into efl or during Gustavos changes
> the
> >>> std=c99 passing to ecore_con got missing.
> >>
> >> adding std=c99 is a BAD idea. Better use AC_PROG_CC_C99 if a c99
> >> compiler is needed. But honestly, i don't know why it is needed, as
> >> current compiler check is working for years. So before changing, tell
> >> me what the error is
> >
> > I remember we had problems with that when Mike put in dns.c. Anyway here
> > are the problems I see when building with Ubuntu clang version
> > 3.0-6ubuntu3 (tags/RELEASE_30/final) (based on LLVM 3.0):
> >
> > lib/ecore_con/dns.c:878:4: error: 'for' loop initial declarations are
> > only allowed in C99 mode
> > lib/ecore_con/dns.c:878:4: note: use option -std=c99 or -std=gnu99 to
> > compile your code
> > lib/ecore_con/dns.c:885:4: error: 'for' loop initial declarations are
> > only allowed in C99 mode
> > lib/ecore_con/dns.c:888:5: error: 'for' loop initial declarations are
> > only allowed in C99 mode
> > lib/ecore_con/dns.c: In function 'dns_p_push':
> > lib/ecore_con/dns.c:988:28: warning: declaration of '__v' shadows a
> > previous local [-Wshadow]
> > lib/ecore_con/dns.c:988:28: warning: shadowed declaration is here
> [-Wshadow]
> > lib/ecore_con/dns.c:988:28: warning: declaration of '__x' shadows a
> > previous local [-Wshadow]
> > lib/ecore_con/dns.c:988:28: warning: shadowed declaration is here
> [-Wshadow]
> > lib/ecore_con/dns.c:1006:28: warning: declaration of '__v' shadows a
> > previous local [-Wshadow]
> > lib/ecore_con/dns.c:1006:28: warning: shadowed declaration is here
> > [-Wshadow]
> > lib/ecore_con/dns.c:1006:28: warning: declaration of '__x' shadows a
> > previous local [-Wshadow]
> > lib/ecore_con/dns.c:1006:28: warning: shadowed declaration is here
> > [-Wshadow]
> > lib/ecore_con/dns.c:1022:28: warning: declaration of '__v' shadows a
> > previous local [-Wshadow]
> > lib/ecore_con/dns.c:1022:28: warning: shadowed declaration is here
> > [-Wshadow]
> > lib/ecore_con/dns.c:1022:28: warning: declaration of '__x' shadows a
> > previous local [-Wshadow]
> > lib/ecore_con/dns.c:1022:28: warning: shadowed declaration is here
> > [-Wshadow]
> > lib/ecore_con/dns.c:1033:28: warning: declaration of '__v' shadows a
> > previous local [-Wshadow]
> > lib/ecore_con/dns.c:1033:28: warning: shadowed declaration is here
> > [-Wshadow]
> > lib/ecore_con/dns.c:1033:28: warning: declaration of '__x' shadows a
> > previous local [-Wshadow]
> > lib/ecore_con/dns.c:1033:28: warning: shadowed declaration is here
> > [-Wshadow]
> > lib/ecore_con/dns.c: In function 'dns_rr_exists':
> > lib/ecore_con/dns.c:1787:2: error: 'for' loop initial declarations are
> > only allowed in C99 mode
> > lib/ecore_con/dns.c: In function 'dns_res_merge':
> > lib/ecore_con/dns.c:5414:2: error: 'for' loop initial declarations are
> > only allowed in C99 mode
> > lib/ecore_con/dns.c:5421:4: error: 'for' loop initial declarations are
> > only allowed in C99 mode
> > lib/ecore_con/dns.c:5424:5: error: 'for' loop initial declarations are
> > only allowed in C99 mode
> > lib/ecore_con/dns.c: In function 'dns_res_glue':
> > lib/ecore_con/dns.c:5480:3: error: 'for' loop initial declarations are
> > only allowed in C99 mode
> > lib/ecore_con/dns.c:5496:3: error: 'for' loop initial declarations are
> > only allowed in C99 mode
> > lib/ecore_con/dns.c: In function 'dns_res_exec':
> > lib/ecore_con/dns.c:5604:3: error: 'for' loop initial declarations are
> > only allowed in C99 mode
> > lib/ecore_con/dns.c:5608:3: error: 'for' loop initial declarations are
> > only allowed in C99 mode
> > lib/ecore_con/dns.c:5806:3: error: 'for' loop initial declarations are
> > only allowed in C99 mode
> > lib/ecore_con/dns.c:5880:3: error: 'for' loop initial declarations are
> > only allowed in C99 mode
> > lib/ecore_con/dns.c:5884:3: error: 'for' loop initial declarations are
> > only allowed in C99 mode
> > lib/ecore_con/dns.c:5893:3: error: 'for' loop initial declarations are
> > only allowed in C99 mode
> > lib/ecore_con/dns.c:6027:3: error: 'for' loop initial declarations are
> > only allowed in C99 mode
> >
> > The warnings are always there so can be ignored for this particular case.
> >
> > regards
> > Stefan Schmidt
> >
> >
> --
> > LogMeIn Rescue: Anywhere, Any

Re: [E-devel] deprecating some of ecore_file for 1.8

[Gustavo Sverzut Barbieri]

On Thu, Dec 6, 2012 at 11:56 AM, Christopher Michael
 wrote:
> On 06/12/12 13:50, Vincent Torri wrote:
>> On Thu, Dec 6, 2012 at 2:48 PM, Christopher Michael
>>  wrote:
>>> On 06/12/12 13:40, Gustavo Sverzut Barbieri wrote:
 On Thu, Dec 6, 2012 at 11:38 AM, Christopher Michael
  wrote:
> On 06/12/12 13:25, Gustavo Sverzut Barbieri wrote:
>>
>> ecore_file itself should go.
>>
>> path manipulation (exists, dirname...) should go in eina, other bits
>> should go in eio.
>>
>
> Why split file/path functions (exists, dirname, etc) to eina ? If Eio is 
> to
> be the library for file functions, then why break only "some" of them out
> into eina ?

 two reasons:
1 - they are very, very simple. mostly wrappers around system versions
>>>
>>> Well, I think the complexity of the functions is irrelevant as a reason
>>> really.
>>>
>>> Do we typically use, "Well this graphical function is incredibly complex
>>> so it should be broken out from evas and stuck into a different library"
>>> as a basis for development ? Or the converse .. "Well this graphical
>>> function is incredibly simple so it doesn't belong in evas". I don't
>>> think we do development that ;)
>>>
>>>  IMO, I don't see function complexity as a valid reason here.
>>>
2 - many modules uses that, like eina itself, ecore and evas. to do
 path finding, etc.

>>>
>>> Ok ...then why can't those libraries use eio ??
>>
>> if i'm not mistaken, eio uses ecore, so could be a problem for a use in evas
>>
>> Vincent
>
> Ahh. If that is the case, then it makes sense.
>
> Thanks for clarifying ;)
>
> As an aside...what is eio using ecore For ??

everything? It's a very high level library, uses extensively the main
loop to come back its threaded workers... so main loop, threads,
pipe...


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

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk/efl: . m4 src src/lib/ecore_file src/lib/eio

[Gustavo Sverzut Barbieri]

On Thu, Dec 6, 2012 at 11:52 AM, Guillaume Friloux
 wrote:
> Ok, sorry for my mistake, its old and forgot some things.
> But still, there must be warns added somewhere to clearly state that next
> version will drop support. In my vision, once a functionnality is added, you
> must maintain it, or clearly tell its dropped, and even give solutions, no ?

could be added to changelog...

but really, it will remain compiling, will use polling instead of kernel.

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

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] deprecating some of ecore_file for 1.8

[Christopher Michael]

On 06/12/12 14:05, s...@tango.flipp.net wrote:
>> On 06/12/12 13:50, Vincent Torri wrote:
>>> On Thu, Dec 6, 2012 at 2:48 PM, Christopher Michael
>>>  wrote:
 On 06/12/12 13:40, Gustavo Sverzut Barbieri wrote:
> On Thu, Dec 6, 2012 at 11:38 AM, Christopher Michael
>  wrote:
>> On 06/12/12 13:25, Gustavo Sverzut Barbieri wrote:
>>>
>>> ecore_file itself should go.
>>>
>>> path manipulation (exists, dirname...) should go in eina, other bits
>>> should go in eio.
>>>
>>
>> Why split file/path functions (exists, dirname, etc) to eina ? If Eio
>> is to
>> be the library for file functions, then why break only "some" of them
>> out
>> into eina ?
>
> two reasons:
> 1 - they are very, very simple. mostly wrappers around system
> versions

 Well, I think the complexity of the functions is irrelevant as a reason
 really.

 Do we typically use, "Well this graphical function is incredibly
 complex
 so it should be broken out from evas and stuck into a different
 library"
 as a basis for development ? Or the converse .. "Well this graphical
 function is incredibly simple so it doesn't belong in evas". I don't
 think we do development that ;)

  IMO, I don't see function complexity as a valid reason here.

> 2 - many modules uses that, like eina itself, ecore and evas. to do
> path finding, etc.
>

 Ok ...then why can't those libraries use eio ??
>>>
>>> if i'm not mistaken, eio uses ecore, so could be a problem for a use in
>>> evas
>>>
>>> Vincent
>>
>> Ahh. If that is the case, then it makes sense.
>>
>> Thanks for clarifying ;)
>>
>> As an aside...what is eio using ecore For ??
>
> At least threading, so it is heavily dependent.
>
> S.
>

Fair enough, thanks :)

That being the case, then it makes sense why eina, evas, etc, cannot be 
dependent on eio.

I retract any previous objections to moving path manipulation (exists, 
dirname...) into eina.

Carry on ;)

dh



--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] std=c99 for ecore_con dns.c got missing

[Vincent Torri]

On Thu, Dec 6, 2012 at 3:08 PM, thomasg  wrote:
> On Thu, Dec 6, 2012 at 12:57 PM, Vincent Torri wrote:
>
>> so it's a problem with clang. Fix your CC, then
>>
>>
> Is it really?
> dns_rr_foreach is defined as "for (struct dns_rr_i DNS_PP_XPASTE(i,
> __LINE__) = *dns_rr_i_new((P), __VA_ARGS__); ..." in dns.h
> As this is a declaration in the loop, it seems that clang's complaining is
> correct, this is a C99 feature.
>
> So I think, a C99 compiler should be required, even if GCC does not
> complain.

or move the declaration outside the loop...

Vincent

>
>
>>
>>
> On Thu, Dec 6, 2012 at 11:59 AM, Stefan Schmidt 
>> wrote:
>> > Hello.
>> >
>> > On 06/12/12 10:34, Vincent Torri wrote:
>> >> On Thu, Dec 6, 2012 at 11:28 AM, Stefan Schmidt 
>> wrote:
>> >>> Hello.
>> >>>
>> >>> Either during the merge of ecore into efl or during Gustavos changes
>> the
>> >>> std=c99 passing to ecore_con got missing.
>> >>
>> >> adding std=c99 is a BAD idea. Better use AC_PROG_CC_C99 if a c99
>> >> compiler is needed. But honestly, i don't know why it is needed, as
>> >> current compiler check is working for years. So before changing, tell
>> >> me what the error is
>> >
>> > I remember we had problems with that when Mike put in dns.c. Anyway here
>> > are the problems I see when building with Ubuntu clang version
>> > 3.0-6ubuntu3 (tags/RELEASE_30/final) (based on LLVM 3.0):
>> >
>> > lib/ecore_con/dns.c:878:4: error: 'for' loop initial declarations are
>> > only allowed in C99 mode
>> > lib/ecore_con/dns.c:878:4: note: use option -std=c99 or -std=gnu99 to
>> > compile your code
>> > lib/ecore_con/dns.c:885:4: error: 'for' loop initial declarations are
>> > only allowed in C99 mode
>> > lib/ecore_con/dns.c:888:5: error: 'for' loop initial declarations are
>> > only allowed in C99 mode
>> > lib/ecore_con/dns.c: In function 'dns_p_push':
>> > lib/ecore_con/dns.c:988:28: warning: declaration of '__v' shadows a
>> > previous local [-Wshadow]
>> > lib/ecore_con/dns.c:988:28: warning: shadowed declaration is here
>> [-Wshadow]
>> > lib/ecore_con/dns.c:988:28: warning: declaration of '__x' shadows a
>> > previous local [-Wshadow]
>> > lib/ecore_con/dns.c:988:28: warning: shadowed declaration is here
>> [-Wshadow]
>> > lib/ecore_con/dns.c:1006:28: warning: declaration of '__v' shadows a
>> > previous local [-Wshadow]
>> > lib/ecore_con/dns.c:1006:28: warning: shadowed declaration is here
>> > [-Wshadow]
>> > lib/ecore_con/dns.c:1006:28: warning: declaration of '__x' shadows a
>> > previous local [-Wshadow]
>> > lib/ecore_con/dns.c:1006:28: warning: shadowed declaration is here
>> > [-Wshadow]
>> > lib/ecore_con/dns.c:1022:28: warning: declaration of '__v' shadows a
>> > previous local [-Wshadow]
>> > lib/ecore_con/dns.c:1022:28: warning: shadowed declaration is here
>> > [-Wshadow]
>> > lib/ecore_con/dns.c:1022:28: warning: declaration of '__x' shadows a
>> > previous local [-Wshadow]
>> > lib/ecore_con/dns.c:1022:28: warning: shadowed declaration is here
>> > [-Wshadow]
>> > lib/ecore_con/dns.c:1033:28: warning: declaration of '__v' shadows a
>> > previous local [-Wshadow]
>> > lib/ecore_con/dns.c:1033:28: warning: shadowed declaration is here
>> > [-Wshadow]
>> > lib/ecore_con/dns.c:1033:28: warning: declaration of '__x' shadows a
>> > previous local [-Wshadow]
>> > lib/ecore_con/dns.c:1033:28: warning: shadowed declaration is here
>> > [-Wshadow]
>> > lib/ecore_con/dns.c: In function 'dns_rr_exists':
>> > lib/ecore_con/dns.c:1787:2: error: 'for' loop initial declarations are
>> > only allowed in C99 mode
>> > lib/ecore_con/dns.c: In function 'dns_res_merge':
>> > lib/ecore_con/dns.c:5414:2: error: 'for' loop initial declarations are
>> > only allowed in C99 mode
>> > lib/ecore_con/dns.c:5421:4: error: 'for' loop initial declarations are
>> > only allowed in C99 mode
>> > lib/ecore_con/dns.c:5424:5: error: 'for' loop initial declarations are
>> > only allowed in C99 mode
>> > lib/ecore_con/dns.c: In function 'dns_res_glue':
>> > lib/ecore_con/dns.c:5480:3: error: 'for' loop initial declarations are
>> > only allowed in C99 mode
>> > lib/ecore_con/dns.c:5496:3: error: 'for' loop initial declarations are
>> > only allowed in C99 mode
>> > lib/ecore_con/dns.c: In function 'dns_res_exec':
>> > lib/ecore_con/dns.c:5604:3: error: 'for' loop initial declarations are
>> > only allowed in C99 mode
>> > lib/ecore_con/dns.c:5608:3: error: 'for' loop initial declarations are
>> > only allowed in C99 mode
>> > lib/ecore_con/dns.c:5806:3: error: 'for' loop initial declarations are
>> > only allowed in C99 mode
>> > lib/ecore_con/dns.c:5880:3: error: 'for' loop initial declarations are
>> > only allowed in C99 mode
>> > lib/ecore_con/dns.c:5884:3: error: 'for' loop initial declarations are
>> > only allowed in C99 mode
>> > lib/ecore_con/dns.c:5893:3: error: 'for' loop initial declarations are
>> > only allowed in C99 mode
>> > lib/ecore_con/dns.c:6027:3: error: 'for' loop initial declarations are
>> > only allowed in C99 mode
>> >
>> > The warn

Re: [E-devel] E SVN: barbieri trunk/efl

[Gustavo Sverzut Barbieri]

On Thu, Dec 6, 2012 at 12:00 PM, Vincent Torri  wrote:
> On Thu, Dec 6, 2012 at 2:58 PM, Enlightenment SVN
>  wrote:
>> Log:
>> efl: remove want_poll.
>>
>>
>> Author:   barbieri
>> Date: 2012-12-06 05:58:32 -0800 (Thu, 06 Dec 2012)
>> New Revision: 80362
>> Trac: http://trac.enlightenment.org/e/changeset/80362
>>
>> Modified:
>>   trunk/efl/configure.ac
>>
>> Modified: trunk/efl/configure.ac
>> ===
>> --- trunk/efl/configure.ac  2012-12-06 13:39:58 UTC (rev 80361)
>> +++ trunk/efl/configure.ac  2012-12-06 13:58:32 UTC (rev 80362)
>> @@ -2367,19 +2367,6 @@
>>
>>  ### Additional options to configure
>>
>> -AC_ARG_ENABLE([poll],
>> -   [AC_HELP_STRING([--disable-poll],
>> -  [disable poll in the ecore_file module. @<:@default=enabled@:>@])],
>> -   [
>> -if test "x${enableval}" = "xyes" ; then
>> -   want_poll="yes"
>> -else
>> -   want_poll="no"
>> -fi
>> -   ],
>> -   [want_poll="yes"])
>> -
>> -
>>  AC_ARG_ENABLE([atfile-source],
>> [AC_HELP_STRING([--disable-atfile-source],
>> [disable use of atfile source functions as openat and mkdirat 
>> @<:@default=detect@:>@])],
>> @@ -2393,12 +2380,6 @@
>>
>>  ### Default values
>>
>> -have_poll="no"
>> -if test "x${want_poll}" = "xyes" ; then
>> -   AC_DEFINE([HAVE_POLL], [1], [File monitoring with polling])
>
> and you don't touch code that uses HAVE_POLL ?

none :-)



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

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk/efl: . m4 src src/lib/ecore_file src/lib/eio

[Guillaume Friloux]

On 06/12/2012 15:11, Gustavo Sverzut Barbieri wrote:

On Thu, Dec 6, 2012 at 11:52 AM, Guillaume Friloux
 wrote:

Ok, sorry for my mistake, its old and forgot some things.
But still, there must be warns added somewhere to clearly state that next
version will drop support. In my vision, once a functionnality is added, you
must maintain it, or clearly tell its dropped, and even give solutions, no ?

could be added to changelog...

but really, it will remain compiling, will use polling instead of kernel.


Thank you.
<>--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk/efl: . m4 src src/lib/ecore_file src/lib/eio

[Gustavo Sverzut Barbieri]

On Thu, Dec 6, 2012 at 12:18 PM, Guillaume Friloux
 wrote:
> On 06/12/2012 15:11, Gustavo Sverzut Barbieri wrote:
>>
>> On Thu, Dec 6, 2012 at 11:52 AM, Guillaume Friloux
>>  wrote:
>>>
>>> Ok, sorry for my mistake, its old and forgot some things.
>>> But still, there must be warns added somewhere to clearly state that next
>>> version will drop support. In my vision, once a functionnality is added,
>>> you
>>> must maintain it, or clearly tell its dropped, and even give solutions,
>>> no ?
>>
>> could be added to changelog...
>>
>> but really, it will remain compiling, will use polling instead of kernel.
>>
> Thank you.

added to changelog... glibc>=2.4 if you want that.


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

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk/efl: . m4 src src/lib/ecore_file src/lib/eio

[Guillaume Friloux]

On 06/12/2012 15:23, Gustavo Sverzut Barbieri wrote:

On Thu, Dec 6, 2012 at 12:18 PM, Guillaume Friloux
 wrote:

On 06/12/2012 15:11, Gustavo Sverzut Barbieri wrote:

On Thu, Dec 6, 2012 at 11:52 AM, Guillaume Friloux
 wrote:

Ok, sorry for my mistake, its old and forgot some things.
But still, there must be warns added somewhere to clearly state that next
version will drop support. In my vision, once a functionnality is added,
you
must maintain it, or clearly tell its dropped, and even give solutions,
no ?

could be added to changelog...

but really, it will remain compiling, will use polling instead of kernel.


Thank you.

added to changelog... glibc>=2.4 if you want that.




Yes, i saw your commit, thats why i thank you.
<>--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk/efl: . src/lib/ecore

[Cedric BAIL]

On Thu, Dec 6, 2012 at 9:18 PM, Enlightenment SVN
 wrote:
> Log:
> efl: ecore thread safety (remove option, keep code, add instructions).
>
>* remove the option, as it shouldn't really exist.
>
>* keep code, as requested by Cedric, someone may fix it someday. And
>  the default is the DISABLED, as the enable was broken.
>
>* Add instructions on how to solve the problem, if a brave folk is up
>  to it.
>
>
>
> Author:   barbieri
> Date: 2012-12-06 04:18:24 -0800 (Thu, 06 Dec 2012)
> New Revision: 80352
> Trac: http://trac.enlightenment.org/e/changeset/80352
>
> Modified:
>   trunk/efl/configure.ac trunk/efl/src/lib/ecore/ecore_private.h
>
> Modified: trunk/efl/configure.ac
> ===
> --- trunk/efl/configure.ac  2012-12-06 12:01:49 UTC (rev 80351)
> +++ trunk/efl/configure.ac  2012-12-06 12:18:24 UTC (rev 80352)
> @@ -1953,20 +1953,6 @@
> ],
> [want_g_main_loop="no"])
>
> -# thread safety
> -
> -AC_ARG_ENABLE([thread-safety],
> -   [AC_HELP_STRING([--enable-thread-safety],
> -   [enable thread safety. @<:@default=disabled@:>@])],
> -   [
> -if test "x${enableval}" = "xyes" ; then
> -   want_thread_safety="yes"
> -else
> -   want_thread_safety="no"
> -fi
> -   ],
> -   [want_thread_safety="no"])
> -
>  # epoll
>
>  AC_ARG_ENABLE([epoll],
> @@ -1994,10 +1980,6 @@
> want_glib="yes"
>  fi
>
> -if test "x${want_thread_safety}" = "xyes" ; then
> -   AC_DEFINE([HAVE_THREAD_SAFETY], [1], [Define to enable thread safety])
> -fi
> -
>  want_ecore_timer_dump="no"
>  if test "x${build_profile}" = "xdebug" && test "x${ac_cv_func_backtrace}" = 
> "xyes"; then
> want_ecore_timer_dump="yes"
> @@ -4164,7 +4146,6 @@
>  echo
>
>  echo "Ecore:"
> -echo "  Thread safety..: $want_thread_safety"
>  echo "  GLib support...: $with_glib"
>  echo "  Use g_main_loop: $want_g_main_loop"
>  echo "  Gathering memory statistic.: $ac_cv_func_mallinfo"
>
> Modified: trunk/efl/src/lib/ecore/ecore_private.h
> ===
> --- trunk/efl/src/lib/ecore/ecore_private.h 2012-12-06 12:01:49 UTC (rev 
> 80351)
> +++ trunk/efl/src/lib/ecore/ecore_private.h 2012-12-06 12:18:24 UTC (rev 
> 80352)
> @@ -247,6 +247,25 @@
>  _ecore_lock(void)
>  {
>  #ifdef HAVE_THREAD_SAFETY
> +   /* THIS IS BROKEN AND NEEDS FIXING
> +*
> +* the concept of lock to execute main-loop related functions is okay
> +* and the code below is correct per se, but with its usage in Ecore
> +* is leading to hard locks that must be investigated.
> +*
> +* One failure possibility is missing _ecore_unlock() that leaves
> +* the lock taken and on next take it will block.
> +*
> +* Another failure possibility is one function that takes the lock
> +* and calls some API function that also takes the lock, leading to
> +* block.
> +*
> +* When these are fixed, remove the HAVE_THREAD_SAFETY and leave it
> +* always on. To eliminate the lock overhead for non-threaded
> +* applications, have a global boolean that is set to TRUE by user
> +* if he uses this features, much like eina_log_threads_enable().
> +*  -- Gustavo, December 6th 2012.
> +*/

This comment is a lie. The current implementation can't work. Think
about creating a timer in a thread with zero activity in the main
loop. How will the main loop be awaken to take this new handler into
account at the right time ? Same with all handler. Second and the one
that prove that this is just impossible to make it work. Look at the
pseudo code below.

handler = ecore_handler_add();
ecore_handler_set(handler, something);

That code will never be safe because between the unlock inside the add
at the exit point of ecore_handler_add and the lock at the entry point
inside ecore_handler_set, there is a gap. This mean that the main
loop, another thread, whatever can mess with your handler and you have
no way to access it or manipulate it at all. Basically the only
function that may work are the ecore_*_add function and everything
else will always be racy.

The only thread safe solution is to completely lock the main loop with
begin/end or the add to actually not "commit" the handler until the
last instruction in the thread that may use the handler. This means we
need to add a ecore_main_loop_commit and have a special path in all
our code to handle the case where the handler is not yet handle by the
main loop. This is way to much work for very little gain. But anyway,
this solution can never work and be a thread safe solution for using
ecore in a thread.

> eina_lock_take(&_ecore_main_loop_lock);
>  #else
> /* at least check we're not being called from a thread */
>
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely acc

Re: [E-devel] E SVN: barbieri IN trunk/efl: . src/lib/ecore

[Gustavo Sverzut Barbieri]

On Thu, Dec 6, 2012 at 12:34 PM, Cedric BAIL  wrote:
> On Thu, Dec 6, 2012 at 9:18 PM, Enlightenment SVN
>  wrote:
>> Log:
>> efl: ecore thread safety (remove option, keep code, add instructions).
>>
>>* remove the option, as it shouldn't really exist.
>>
>>* keep code, as requested by Cedric, someone may fix it someday. And
>>  the default is the DISABLED, as the enable was broken.
>>
>>* Add instructions on how to solve the problem, if a brave folk is up
>>  to it.
>>
>>
>>
>> Author:   barbieri
>> Date: 2012-12-06 04:18:24 -0800 (Thu, 06 Dec 2012)
>> New Revision: 80352
>> Trac: http://trac.enlightenment.org/e/changeset/80352
>>
>> Modified:
>>   trunk/efl/configure.ac trunk/efl/src/lib/ecore/ecore_private.h
>>
>> Modified: trunk/efl/configure.ac
>> ===
>> --- trunk/efl/configure.ac  2012-12-06 12:01:49 UTC (rev 80351)
>> +++ trunk/efl/configure.ac  2012-12-06 12:18:24 UTC (rev 80352)
>> @@ -1953,20 +1953,6 @@
>> ],
>> [want_g_main_loop="no"])
>>
>> -# thread safety
>> -
>> -AC_ARG_ENABLE([thread-safety],
>> -   [AC_HELP_STRING([--enable-thread-safety],
>> -   [enable thread safety. @<:@default=disabled@:>@])],
>> -   [
>> -if test "x${enableval}" = "xyes" ; then
>> -   want_thread_safety="yes"
>> -else
>> -   want_thread_safety="no"
>> -fi
>> -   ],
>> -   [want_thread_safety="no"])
>> -
>>  # epoll
>>
>>  AC_ARG_ENABLE([epoll],
>> @@ -1994,10 +1980,6 @@
>> want_glib="yes"
>>  fi
>>
>> -if test "x${want_thread_safety}" = "xyes" ; then
>> -   AC_DEFINE([HAVE_THREAD_SAFETY], [1], [Define to enable thread safety])
>> -fi
>> -
>>  want_ecore_timer_dump="no"
>>  if test "x${build_profile}" = "xdebug" && test "x${ac_cv_func_backtrace}" = 
>> "xyes"; then
>> want_ecore_timer_dump="yes"
>> @@ -4164,7 +4146,6 @@
>>  echo
>>
>>  echo "Ecore:"
>> -echo "  Thread safety..: $want_thread_safety"
>>  echo "  GLib support...: $with_glib"
>>  echo "  Use g_main_loop: $want_g_main_loop"
>>  echo "  Gathering memory statistic.: $ac_cv_func_mallinfo"
>>
>> Modified: trunk/efl/src/lib/ecore/ecore_private.h
>> ===
>> --- trunk/efl/src/lib/ecore/ecore_private.h 2012-12-06 12:01:49 UTC (rev 
>> 80351)
>> +++ trunk/efl/src/lib/ecore/ecore_private.h 2012-12-06 12:18:24 UTC (rev 
>> 80352)
>> @@ -247,6 +247,25 @@
>>  _ecore_lock(void)
>>  {
>>  #ifdef HAVE_THREAD_SAFETY
>> +   /* THIS IS BROKEN AND NEEDS FIXING
>> +*
>> +* the concept of lock to execute main-loop related functions is okay
>> +* and the code below is correct per se, but with its usage in Ecore
>> +* is leading to hard locks that must be investigated.
>> +*
>> +* One failure possibility is missing _ecore_unlock() that leaves
>> +* the lock taken and on next take it will block.
>> +*
>> +* Another failure possibility is one function that takes the lock
>> +* and calls some API function that also takes the lock, leading to
>> +* block.
>> +*
>> +* When these are fixed, remove the HAVE_THREAD_SAFETY and leave it
>> +* always on. To eliminate the lock overhead for non-threaded
>> +* applications, have a global boolean that is set to TRUE by user
>> +* if he uses this features, much like eina_log_threads_enable().
>> +*  -- Gustavo, December 6th 2012.
>> +*/
>
> This comment is a lie. The current implementation can't work. Think
> about creating a timer in a thread with zero activity in the main
> loop. How will the main loop be awaken to take this new handler into
> account at the right time ?

you'd have to use a pipe trick if you're in secondary threads.


> Same with all handler. Second and the one
> that prove that this is just impossible to make it work. Look at the
> pseudo code below.
>
> handler = ecore_handler_add();
> ecore_handler_set(handler, something);
>
> That code will never be safe because between the unlock inside the add
> at the exit point of ecore_handler_add and the lock at the entry point
> inside ecore_handler_set, there is a gap. This mean that the main
> loop, another thread, whatever can mess with your handler and you have
> no way to access it or manipulate it at all. Basically the only
> function that may work are the ecore_*_add function and everything
> else will always be racy.

indeed, but the set() something would need to lock the handler itself,
not the main loop. If that impacts the main loop, also lock that... if
from secondary thread, needs to wakeup.


> The only thread safe solution is to completely lock the main loop with
> begin/end or the add to actually not "commit" the handler until the
> last instruction in the thread that may use the handler. This means we
> need to add a ecore_main_loop_commit and have a special path in all
> our code to handle the case where the handler is not yet handle by the

Re: [E-devel] Eo debug helper

[Tom Hacohen]

Just use "stepi", that one goes inside. "step" goes to the next line of
code and if there is none inside it just steps to the next line. I'm
actually trying to look for a command that does what I said we need in the
first place (and that you've implemented to some extent), which just goes
on until the next line with debug information. Anyhow, now you can
implement exactly that, just walk into eo_do_internal until the next line
with debug info, easy.

Btw, there's another thing we need, and that's probably a way to stop on an
eo_do with a specific op code, like we break on evas_object_resize at the
moment. It's not a big deal because this can be achieved with breaking on
the internal functions, but still, I think it'll make our lives easier.
This one is probably easier to make.


On Thu, Dec 6, 2012 at 11:30 AM, daniel.za...@samsung.com <
daniel.za...@samsung.com> wrote:

> When I compile without -O and -g, gdb behaves like with stripped
> library, i.e doesn't try to enter the function. Maybe I do something wrong.
> Tom, can you try it on your computer?
>
> Thank you
> Daniel
>
> On 12/06/2012 12:45 AM, Tom Hacohen wrote:
> > Compile Eo in release mode: remove -O0/-g from your CFLAGS, re-configure
> Eo
> > (efl tree I assume) with --with-profile=release (or something like that,
> > just check the configure options, it's easy) and make && make install.
> You
> > can potentially just strip the binary, doesn't matter really...
> >
> >
> > On Wed, Dec 5, 2012 at 3:52 PM, daniel.za...@samsung.com <
> > daniel.za...@samsung.com> wrote:
> >
> >> Tom, the 'sudo strip -g libeo.so' on my computer prevents me to see info
> >> about this library in gdb, as explained before. How can I compile Eo in
> >> release mode?
> >>
> >> Gustavo, this could be very useful. We need to check if it really can be
> >> done and if it is easy for the user. Is the eo_do_step supposed to
> >> execute the functions too? How does it wait for commands (your last
> >> line), I mean, is it inside the eo_do_step function?
> >> Eo uses va_list to store the parameters and we need to be careful with
> >> that.
> >>
> >> On 12/05/2012 05:11 PM, Tom Hacohen wrote:
> >>> Gustavo,
> >>>
> >>> Your suggestion is good (I already told you that in the past, I think),
> >> but
> >>> I believe it's unrelated to what we are trying to achieve here. What I
> >> want
> >>> is an easy way to step into an eo_do function, just like we would have
> >> done
> >>> with any other function.
> >>>
> >>> What I really want to see is just "run until you exit the libeo.so
> binary
> >>> and get back to a user function"...
> >>>
> >>>
> >>> On Wed, Dec 5, 2012 at 3:05 PM, Gustavo Sverzut Barbieri <
> >>> barbi...@profusion.mobi> wrote:
> >>>
>  Let me jump in, proposing here what I already proposed earlier at IRC
>  and in person during LinuxCon-EU:
> 
>  we should use the same debug helper way as gcc does for itself.
> 
>  GCC is built on top of an union of every possible AST node. So
>  functions, variables, loops... are all into the same type/union,
>  making it dozen pages of gdb output to get every possible field and
>  combination if you "p *node"
> 
>  To solve this they ship some  functions in their own code, that you
>  can use to debug its own code. Similar to "p gcc_node_print(node)" (I
>  don't recall the exact name), and another to navigate the tree.
> 
>  Then I propose we create a "eo_do_step(obj, va_list ap)" that we can:
>  "(gdb) p eo_do_step(obj, ap)" from our debug session. It would
>  replicate the dispatch logic from eo_do(), but before executing each
>  call it would print out the call and parameters. We can use Eo
>  introspection to try to help user by showing the function name,
>  description and parameter types.
> 
>  Suppose doing: eo_do(evas_obj, evas_obj_position_set(10, 20),
>  evas_obj_size_set(300, 400));
>  you break point in eo_do and call:
> 
>  (gdb) p eo_do_step(obj, ap)
>  Operating on: obj=0xaabbcc00 (Evas_Object_Rectangle)
>  Function: evas_obj_position_set(int x, int y) "Set the position of an
>  evas object."
>  calling: evas_obj_position_set(x=10, y=20)
>  (eo_do_step)  <--- waits for commands such as continue, step...
> 
> 
> 
> 
>  On Wed, Dec 5, 2012 at 12:46 PM, daniel.za...@samsung.com
>   wrote:
> > Hi all,
> >
> > I don't need to reply, but to thank you and give you respect, I feel
> > that I must reply ;-) When I strip Eo library, I cannot in gcc step
> >> into
> > at all, I mean, I can't reach the final destination. It is like the
> > 'skip' feature of gdb. So for the moment, I am stuck with that
> filename
> > and need to find a solution.
> >
> > Second point, as I wrote before, there is a bug in gdb when executing
> > python scripts (link below). It will be fixed in gdb 7.6 that is
> > officially supposed to be delivered in mid-feb

Re: [E-devel] E SVN: barbieri IN trunk/efl: . src src/lib/ecore_file

[Leandro Dorileo]

On Thu, Dec 06, 2012 at 05:38:36AM -0800, Enlightenment SVN wrote:
> Log:
> efl/ecore_file: refactor to be more like eio in providing backends.
>   
>   instead of the previous mess, just define the functions with common
>   names and call the backend that was compiled in, similar to what eio
>   does.
>   
>   also do not be silent on errors, use eina_safety_checks to issue warnings.
>   
>   
> 
> Author:   barbieri
> Date: 2012-12-06 05:38:34 -0800 (Thu, 06 Dec 2012)
> New Revision: 80360
> Trac: http://trac.enlightenment.org/e/changeset/80360
> 
> Modified:
>   trunk/efl/configure.ac trunk/efl/src/Makefile_Ecore_File.am 
> trunk/efl/src/Makefile_Eio.am 
> trunk/efl/src/lib/ecore_file/ecore_file_monitor.c 
> trunk/efl/src/lib/ecore_file/ecore_file_monitor_inotify.c 
> trunk/efl/src/lib/ecore_file/ecore_file_monitor_poll.c 
> trunk/efl/src/lib/ecore_file/ecore_file_monitor_win32.c 
> trunk/efl/src/lib/ecore_file/ecore_file_private.h 
> 
> Modified: trunk/efl/configure.ac
> ===
> --- trunk/efl/configure.ac2012-12-06 13:24:27 UTC (rev 80359)
> +++ trunk/efl/configure.ac2012-12-06 13:38:34 UTC (rev 80360)
> @@ -478,6 +478,13 @@
>  have_inotify="${ac_cv_header_sys_inotify_h}"
>  AM_CONDITIONAL([HAVE_INOTIFY], [test "x${have_inotify}" = "xyes"])
>  
> +have_notify_win32="${have_win32}"
> +AC_DEFINE_IF([HAVE_NOTIFY_WIN32],
> +   [test "x${have_notify_win32}" = "xyes"],
> +   [File monitoring with Windows notification])

Missing val argument here... it should be:

AC_DEFINE_IF([HAVE_NOTIFY_WIN32],
   [test "x${have_notify_win32}" = "xyes"], [1],
   [File monitoring with Windows notification])


> +AM_CONDITIONAL([HAVE_NOTIFY_WIN32], [test "x${have_notify_win32}" = "xyes"])
> +
> +
>  EFL_CHECK_PATH_MAX
>  
>  
> @@ -2392,17 +2399,6 @@
> have_poll="yes"
>  fi
>  
> -have_notify_win32="no"
> -
> -case "$host_os" in
> -  mingw32ce*)
> -;;
> -  mingw32*)
> - have_notify_win32="yes"
> - AC_DEFINE([HAVE_NOTIFY_WIN32], [1], [File monitoring with Windows 
> notification])
> -;;
> -esac
> -
>  if ! test "x${have_atfile_source}" = "xno" ; then
> AC_CHECK_FUNCS([mkdirat],
>[
> @@ -3933,11 +3929,6 @@
>  
>  AC_MSG_RESULT([${have_xattr}])
>  
> -# Check for inotify specificity
> -have_notify_win32="no"
> -EIO_CHECK_NOTIFY_WIN32([have_notify_win32="yes"], [have_notify_win32="no"])
> -AM_CONDITIONAL([EIO_HAVE_WINCHANGE], [test "x${have_notify_win32}" = "xyes"])
> -
>   End of Eio
>  
>  
> 
> Modified: trunk/efl/src/Makefile_Ecore_File.am
> ===
> --- trunk/efl/src/Makefile_Ecore_File.am  2012-12-06 13:24:27 UTC (rev 
> 80359)
> +++ trunk/efl/src/Makefile_Ecore_File.am  2012-12-06 13:38:34 UTC (rev 
> 80360)
> @@ -11,12 +11,22 @@
>  lib/ecore_file/ecore_file.c \
>  lib/ecore_file/ecore_file_download.c \
>  lib/ecore_file/ecore_file_monitor.c \
> -lib/ecore_file/ecore_file_monitor_inotify.c \
> -lib/ecore_file/ecore_file_monitor_poll.c \
> -lib/ecore_file/ecore_file_monitor_win32.c \
>  lib/ecore_file/ecore_file_path.c \
>  lib/ecore_file/ecore_file_private.h
>  
> +if HAVE_INOTIFY
> +lib_ecore_file_libecore_file_la_SOURCES += \
> +lib/ecore_file/ecore_file_monitor_inotify.c
> +else
> +if HAVE_NOTIFY_WIN32
> +lib_ecore_file_libecore_file_la_SOURCES += \
> +lib/ecore_file/ecore_file_monitor_win32.c
> +else
> +lib_ecore_file_libecore_file_la_SOURCES += \
> +lib/ecore_file/ecore_file_monitor_poll.c
> +endif
> +endif
> +
>  lib_ecore_file_libecore_file_la_CPPFLAGS = \
>  -I$(top_srcdir)/src/lib/eina \
>  -I$(top_srcdir)/src/lib/eo \
> 
> Modified: trunk/efl/src/Makefile_Eio.am
> ===
> --- trunk/efl/src/Makefile_Eio.am 2012-12-06 13:24:27 UTC (rev 80359)
> +++ trunk/efl/src/Makefile_Eio.am 2012-12-06 13:38:34 UTC (rev 80360)
> @@ -21,7 +21,7 @@
>  if HAVE_INOTIFY
>  lib_eio_libeio_la_SOURCES += lib/eio/eio_monitor_inotify.c
>  else
> -if EIO_HAVE_WINCHANGE
> +if HAVE_NOTIFY_WIN32
>  lib_eio_libeio_la_SOURCES += lib/eio/eio_monitor_win32.c
>  endif
>  endif
> 
> Modified: trunk/efl/src/lib/ecore_file/ecore_file_monitor.c
> ===
> --- trunk/efl/src/lib/ecore_file/ecore_file_monitor.c 2012-12-06 13:24:27 UTC 
> (rev 80359)
> +++ trunk/efl/src/lib/ecore_file/ecore_file_monitor.c 2012-12-06 13:38:34 UTC 
> (rev 80360)
> @@ -4,66 +4,18 @@
>  
>  #include "ecore_file_private.h"
>  
> -typedef enum {
> - ECORE_FILE_MONITOR_TYPE_NONE,
> -#ifdef HAVE_SYS_INOTIFY_H
> - ECORE_FILE_MONITOR_TYPE_INOTIFY,
> -#endif
> -#ifdef HAVE_NOTIFY_WIN32
> - ECORE_FILE_MONITOR_TYPE_NOTIFY_WIN32,
> -#endif
> -#ifdef HAVE_POLL
> - ECORE_FILE_MONITOR_TYPE_POLL
> -#endif
> -} Ecore_File_Monitor_Type;
> -
> -static Ecore_File_Monitor_Type monitor_type = ECORE_FILE_MONITOR_TYPE_NONE;
> -
>  int
>  ecore_file_monitor_init

Re: [E-devel] E SVN: barbieri IN trunk/efl: . src src/lib/ecore_file

[Gustavo Sverzut Barbieri]

On Thursday, December 6, 2012, Leandro Dorileo wrote:

> On Thu, Dec 06, 2012 at 05:38:36AM -0800, Enlightenment SVN wrote:
> > Log:
> > efl/ecore_file: refactor to be more like eio in providing backends.
> >
> >   instead of the previous mess, just define the functions with common
> >   names and call the backend that was compiled in, similar to what eio
> >   does.
> >
> >   also do not be silent on errors, use eina_safety_checks to issue
> warnings.
> >
> >
> >
> > Author:   barbieri
> > Date: 2012-12-06 05:38:34 -0800 (Thu, 06 Dec 2012)
> > New Revision: 80360
> > Trac: http://trac.enlightenment.org/e/changeset/80360
> >
> > Modified:
> >   trunk/efl/configure.ac trunk/efl/src/Makefile_Ecore_File.am
> trunk/efl/src/Makefile_Eio.am
> trunk/efl/src/lib/ecore_file/ecore_file_monitor.c
> trunk/efl/src/lib/ecore_file/ecore_file_monitor_inotify.c
> trunk/efl/src/lib/ecore_file/ecore_file_monitor_poll.c
> trunk/efl/src/lib/ecore_file/ecore_file_monitor_win32.c
> trunk/efl/src/lib/ecore_file/ecore_file_private.h
> >
> > Modified: trunk/efl/configure.ac
> > ===
> > --- trunk/efl/configure.ac2012-12-06 13:24:27 UTC (rev 80359)
> > +++ trunk/efl/configure.ac2012-12-06 13:38:34 UTC (rev 80360)
> > @@ -478,6 +478,13 @@
> >  have_inotify="${ac_cv_header_sys_inotify_h}"
> >  AM_CONDITIONAL([HAVE_INOTIFY], [test "x${have_inotify}" = "xyes"])
> >
> > +have_notify_win32="${have_win32}"
> > +AC_DEFINE_IF([HAVE_NOTIFY_WIN32],
> > +   [test "x${have_notify_win32}" = "xyes"],
> > +   [File monitoring with Windows notification])
>
> Missing val argument here... it should be:
>
> AC_DEFINE_IF([HAVE_NOTIFY_WIN32],
>[test "x${have_notify_win32}" = "xyes"], [1],
>[File monitoring with Windows notification])


Oops. Please commit a fix. I'm on the road





>
>
> > +AM_CONDITIONAL([HAVE_NOTIFY_WIN32], [test "x${have_notify_win32}" =
> "xyes"])
> > +
> > +
> >  EFL_CHECK_PATH_MAX
> >
> >
> > @@ -2392,17 +2399,6 @@
> > have_poll="yes"
> >  fi
> >
> > -have_notify_win32="no"
> > -
> > -case "$host_os" in
> > -  mingw32ce*)
> > -;;
> > -  mingw32*)
> > - have_notify_win32="yes"
> > - AC_DEFINE([HAVE_NOTIFY_WIN32], [1], [File monitoring with Windows
> notification])
> > -;;
> > -esac
> > -
> >  if ! test "x${have_atfile_source}" = "xno" ; then
> > AC_CHECK_FUNCS([mkdirat],
> >[
> > @@ -3933,11 +3929,6 @@
> >
> >  AC_MSG_RESULT([${have_xattr}])
> >
> > -# Check for inotify specificity
> > -have_notify_win32="no"
> > -EIO_CHECK_NOTIFY_WIN32([have_notify_win32="yes"],
> [have_notify_win32="no"])
> > -AM_CONDITIONAL([EIO_HAVE_WINCHANGE], [test "x${have_notify_win32}" =
> "xyes"])
> > -
> >   End of Eio
> >
> >
> >
> > Modified: trunk/efl/src/Makefile_Ecore_File.am
> > ===
> > --- trunk/efl/src/Makefile_Ecore_File.am  2012-12-06 13:24:27 UTC
> (rev 80359)
> > +++ trunk/efl/src/Makefile_Ecore_File.am  2012-12-06 13:38:34 UTC
> (rev 80360)
> > @@ -11,12 +11,22 @@
> >  lib/ecore_file/ecore_file.c \
> >  lib/ecore_file/ecore_file_download.c \
> >  lib/ecore_file/ecore_file_monitor.c \
> > -lib/ecore_file/ecore_file_monitor_inotify.c \
> > -lib/ecore_file/ecore_file_monitor_poll.c \
> > -lib/ecore_file/ecore_file_monitor_win32.c \
> >  lib/ecore_file/ecore_file_path.c \
> >  lib/ecore_file/ecore_file_private.h
> >
> > +if HAVE_INOTIFY
> > +lib_ecore_file_libecore_file_la_SOURCES += \
> > +lib/ecore_file/ecore_file_monitor_inotify.c
> > +else
> > +if HAVE_NOTIFY_WIN32
> > +lib_ecore_file_libecore_file_la_SOURCES += \
> > +lib/ecore_file/ecore_file_monitor_win32.c
> > +else
> > +lib_ecore_file_libecore_file_la_SOURCES += \
> > +lib/ecore_file/ecore_file_monitor_poll.c
> > +endif
> > +endif
> > +
> >  lib_ecore_file_libecore_file_la_CPPFLAGS = \
> >  -I$(top_srcdir)/src/lib/eina \
> >  -I$(top_srcdir)/src/lib/eo \
> >
> > Modified: trunk/efl/src/Makefile_Eio.am
> > ===
> > --- trunk/efl/src/Makefile_Eio.am 2012-12-06 13:24:27 UTC (rev 80359)
> > +++ trunk/efl/src/Makefile_Eio.am 2012-12-06 13:38:34 UTC (rev 80360)
> > @@ -21,7 +21,7 @@
> >  if HAVE_INOTIFY
> >  lib_eio_libeio_la_SOURCES += lib/eio/eio_monitor_inotify.c
> >  else
> > -if EIO_HAVE_WINCHANGE
> > +if HAVE_NOTIFY_WIN32
> >  lib_eio_libeio_la_SOURCES += lib/eio/eio_monitor_win32.c
> >  endif
> >  endif
> >
> > Modified: trunk/efl/src/lib/ecore_file/ecore_file_monitor.c
> > ===
> > --- trunk/efl/src/lib/ecore_file/ecore_file_monitor.c 2012-12-06
> 13:24:27 UTC (rev 80359)
> > +++ trunk/efl/src/lib/ecore_file/ecore_file_monitor.c 2012-12-06
> 13:38:34 UTC (rev 80360)
> > @@ -4,66 +4,18 @@
> >
> >  #include "ecore_file_private.h"
> >
> > -typedef enum {
> > - ECORE_FILE_MONITOR_TYPE_NONE,
> > -#ifdef HAVE_SYS_INOTIFY_H
> > - ECORE_FILE_MONITOR_

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

[Daniel Juyung Seo]

Hello cinoo,
I have four comments.

1. 'const' for getters.
Evas_Object *obj -> const Evas_Object
I fixed this in r80369.
http://trac.enlightenment.org/e/changeset/80369

2. also const for return values?
It returns 'char *' but is there any chance to change this from users?
If not, this needs to be 'const char *'.

3. documentations.
Can you add descriptions about those access APIs to elm_access.h?

4. samples
It will be great if there's any sample/tests in src/examples or src/bin.

Daniel Juyung Seo (SeoZ)

On Thu, Dec 6, 2012 at 9:21 PM, Enlightenment SVN <
no-re...@enlightenment.org> wrote:

> Log:
> [access] add elm_access_external_info_get(Evas_Object*); becuase there is
> set();
>
>
> Author:   kimcinoo
> Date: 2012-12-06 04:21:19 -0800 (Thu, 06 Dec 2012)
> New Revision: 80353
> Trac: http://trac.enlightenment.org/e/changeset/80353
>
> Modified:
>   trunk/elementary/src/lib/elm_access.c
> trunk/elementary/src/lib/elm_access.h
>
> Modified: trunk/elementary/src/lib/elm_access.c
> ===
> --- trunk/elementary/src/lib/elm_access.c   2012-12-06 12:18:24 UTC
> (rev 80352)
> +++ trunk/elementary/src/lib/elm_access.c   2012-12-06 12:21:19 UTC
> (rev 80353)
> @@ -790,5 +790,14 @@
>   (_elm_access_object_get(obj), ELM_ACCESS_EXTERNAL_INFO, text);
>  }
>
> +EAPI char *
> +elm_access_external_info_get(Evas_Object *obj)
> +{
> +   Elm_Access_Info *ac;
> +
> +   ac = _elm_access_object_get(obj);
> +   return _elm_access_text_get(ac, ELM_ACCESS_EXTERNAL_INFO, obj, NULL);
> +}
> +
>  EO_DEFINE_CLASS(elm_obj_access_class_get, &class_desc,
> ELM_OBJ_WIDGET_CLASS, NULL);
>
>
> Modified: trunk/elementary/src/lib/elm_access.h
> ===
> --- trunk/elementary/src/lib/elm_access.h   2012-12-06 12:18:24 UTC
> (rev 80352)
> +++ trunk/elementary/src/lib/elm_access.h   2012-12-06 12:21:19 UTC
> (rev 80353)
> @@ -1,5 +1,5 @@
>  /**
> - * @defgroup Naviframe Naviframe
> + * @defgroup Access Access
>   * @ingroup Elementary
>   *
>   * TODO: description
> @@ -12,3 +12,6 @@
>
>  EAPI void
>  elm_access_external_info_set(Evas_Object *obj, const char *text);
> +
> +EAPI char *
> +elm_access_external_info_get(Evas_Object *obj);
>
>
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk/efl: . src src/lib/ecore_file

[Vincent Torri]

On Thu, Dec 6, 2012 at 5:06 PM, Gustavo Sverzut Barbieri
 wrote:
> On Thursday, December 6, 2012, Leandro Dorileo wrote:
>
>> On Thu, Dec 06, 2012 at 05:38:36AM -0800, Enlightenment SVN wrote:
>> > Log:
>> > efl/ecore_file: refactor to be more like eio in providing backends.
>> >
>> >   instead of the previous mess, just define the functions with common
>> >   names and call the backend that was compiled in, similar to what eio
>> >   does.
>> >
>> >   also do not be silent on errors, use eina_safety_checks to issue
>> warnings.
>> >
>> >
>> >
>> > Author:   barbieri
>> > Date: 2012-12-06 05:38:34 -0800 (Thu, 06 Dec 2012)
>> > New Revision: 80360
>> > Trac: http://trac.enlightenment.org/e/changeset/80360
>> >
>> > Modified:
>> >   trunk/efl/configure.ac trunk/efl/src/Makefile_Ecore_File.am
>> trunk/efl/src/Makefile_Eio.am
>> trunk/efl/src/lib/ecore_file/ecore_file_monitor.c
>> trunk/efl/src/lib/ecore_file/ecore_file_monitor_inotify.c
>> trunk/efl/src/lib/ecore_file/ecore_file_monitor_poll.c
>> trunk/efl/src/lib/ecore_file/ecore_file_monitor_win32.c
>> trunk/efl/src/lib/ecore_file/ecore_file_private.h
>> >
>> > Modified: trunk/efl/configure.ac
>> > ===
>> > --- trunk/efl/configure.ac2012-12-06 13:24:27 UTC (rev 80359)
>> > +++ trunk/efl/configure.ac2012-12-06 13:38:34 UTC (rev 80360)
>> > @@ -478,6 +478,13 @@
>> >  have_inotify="${ac_cv_header_sys_inotify_h}"
>> >  AM_CONDITIONAL([HAVE_INOTIFY], [test "x${have_inotify}" = "xyes"])
>> >
>> > +have_notify_win32="${have_win32}"
>> > +AC_DEFINE_IF([HAVE_NOTIFY_WIN32],
>> > +   [test "x${have_notify_win32}" = "xyes"],
>> > +   [File monitoring with Windows notification])
>>
>> Missing val argument here... it should be:
>>
>> AC_DEFINE_IF([HAVE_NOTIFY_WIN32],
>>[test "x${have_notify_win32}" = "xyes"], [1],
>>[File monitoring with Windows notification])
>
>
> Oops. Please commit a fix. I'm on the road
>

do you test before committing 

Vincent

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: raster trunk/efl

[Gustavo Sverzut Barbieri]

On Thursday, December 6, 2012, Enlightenment SVN wrote:

> Log:
> without this i end up with a configure that does:
>
>   configure: updating cache config.cache
>   configure: creating ./config.status
>   config.status: error: cannot find input file: Makefile.in'
>   make: *** No targets specified and no makefile found.  Stop.


Sorry, Dorileo GOT the proper fix, was a missing [1] parameter after the
[test ...] in the AC_DEFINE_IF()





>   autoheader is unhappy:
>
>   autoreconf: running: /usr/bin/autoconf --force
>   autoreconf: running: /usr/bin/autoheader --force
>   autoheader: warning: missing template: HAVE_NOTIFY_WIN32
>   autoheader: Use AC_DEFINE([HAVE_NOTIFY_WIN32], [], [Description])
>   autoreconf: /usr/bin/autoheader failed with exit status: 1
>
>
>
> Author:   raster
> Date: 2012-12-06 08:08:07 -0800 (Thu, 06 Dec 2012)
> New Revision: 80368
> Trac: http://trac.enlightenment.org/e/changeset/80368
>
> Modified:
>   trunk/efl/configure.ac
>
> Modified: trunk/efl/configure.ac
> ===
> --- trunk/efl/configure.ac  2012-12-06 14:46:32 UTC (rev 80367)
> +++ trunk/efl/configure.ac  2012-12-06 16:08:07 UTC (rev 80368)
> @@ -479,9 +479,11 @@
>  AM_CONDITIONAL([HAVE_INOTIFY], [test "x${have_inotify}" = "xyes"])
>
>  have_notify_win32="${have_win32}"
> -AC_DEFINE_IF([HAVE_NOTIFY_WIN32],
> -   [test "x${have_notify_win32}" = "xyes"],
> -   [File monitoring with Windows notification])
> +if test "x${have_notify_win32}" = "xyes" ; then
> +  AC_DEFINE([HAVE_NOTIFY_WIN32], [1], [File monitoring with Windows
> notification])
> +else
> +  AC_DEFINE([HAVE_NOTIFY_WIN32], [], [File monitoring with Windows
> notification])
> +fi
>  AM_CONDITIONAL([HAVE_NOTIFY_WIN32], [test "x${have_notify_win32}" =
> "xyes"])
>
>
>
>
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk/efl: . src src/lib/ecore_file

[Gustavo Sverzut Barbieri]

On Thursday, December 6, 2012, Vincent Torri wrote:

> On Thu, Dec 6, 2012 at 5:06 PM, Gustavo Sverzut Barbieri
> > wrote:
> > On Thursday, December 6, 2012, Leandro Dorileo wrote:
> >
> >> On Thu, Dec 06, 2012 at 05:38:36AM -0800, Enlightenment SVN wrote:
> >> > Log:
> >> > efl/ecore_file: refactor to be more like eio in providing backends.
> >> >
> >> >   instead of the previous mess, just define the functions with common
> >> >   names and call the backend that was compiled in, similar to what eio
> >> >   does.
> >> >
> >> >   also do not be silent on errors, use eina_safety_checks to issue
> >> warnings.
> >> >
> >> >
> >> >
> >> > Author:   barbieri
> >> > Date: 2012-12-06 05:38:34 -0800 (Thu, 06 Dec 2012)
> >> > New Revision: 80360
> >> > Trac: http://trac.enlightenment.org/e/changeset/80360
> >> >
> >> > Modified:
> >> >   trunk/efl/configure.ac trunk/efl/src/Makefile_Ecore_File.am
> >> trunk/efl/src/Makefile_Eio.am
> >> trunk/efl/src/lib/ecore_file/ecore_file_monitor.c
> >> trunk/efl/src/lib/ecore_file/ecore_file_monitor_inotify.c
> >> trunk/efl/src/lib/ecore_file/ecore_file_monitor_poll.c
> >> trunk/efl/src/lib/ecore_file/ecore_file_monitor_win32.c
> >> trunk/efl/src/lib/ecore_file/ecore_file_private.h
> >> >
> >> > Modified: trunk/efl/configure.ac
> >> > ===
> >> > --- trunk/efl/configure.ac2012-12-06 13:24:27 UTC (rev 80359)
> >> > +++ trunk/efl/configure.ac2012-12-06 13:38:34 UTC (rev 80360)
> >> > @@ -478,6 +478,13 @@
> >> >  have_inotify="${ac_cv_header_sys_inotify_h}"
> >> >  AM_CONDITIONAL([HAVE_INOTIFY], [test "x${have_inotify}" = "xyes"])
> >> >
> >> > +have_notify_win32="${have_win32}"
> >> > +AC_DEFINE_IF([HAVE_NOTIFY_WIN32],
> >> > +   [test "x${have_notify_win32}" = "xyes"],
> >> > +   [File monitoring with Windows notification])
> >>
> >> Missing val argument here... it should be:
> >>
> >> AC_DEFINE_IF([HAVE_NOTIFY_WIN32],
> >>[test "x${have_notify_win32}" = "xyes"], [1],
> >>[File monitoring with Windows notification])
> >
> >
> > Oops. Please commit a fix. I'm on the road
> >
>
> do you test before committing 


I do, no idea why it passed through this time. Maybe I ran autogen.sh twice
and it somehow ignored it as file time stamp changed. :-/


>
> Vincent
>
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] building efl with debug profile

[Leandro Dorileo]

Hi,

While trying to build the efl merged tree with --profile=debug I got the
following errors:

lib/ecore/ecore_timer.c:540:4: warning: 'return' with no value, in function 
returning non-void [enabled by default]
lib/ecore/ecore_timer.c:540:31: error: expected ';' before '(' token
lib/ecore/ecore_timer.c:544:4: error: dereferencing pointer to incomplete type
lib/ecore/ecore_timer.c:544:4: error: dereferencing pointer to incomplete type
lib/ecore/ecore_timer.c:544:4: error: dereferencing pointer to incomplete type
lib/ecore/ecore_timer.c:544:4: error: dereferencing pointer to incomplete type
lib/ecore/ecore_timer.c:552:16: error: dereferencing pointer to incomplete type
lib/ecore/ecore_timer.c:552:31: error: dereferencing pointer to incomplete type
lib/ecore/ecore_timer.c:555:48: error: dereferencing pointer to incomplete type
lib/ecore/ecore_timer.c:555:62: error: dereferencing pointer to incomplete type
lib/ecore/ecore_timer.c:556:15: error: dereferencing pointer to incomplete type
lib/ecore/ecore_timer.c:562:68: error: dereferencing pointer to incomplete type
lib/ecore/ecore_timer.c:563:15: error: dereferencing pointer to incomplete type
lib/ecore/ecore_timer.c:565:15: error: dereferencing pointer to incomplete type
lib/ecore/ecore_timer.c:567:27: error: dereferencing pointer to incomplete type
lib/ecore/ecore_timer.c: In function '_ecore_timer_cmp':
lib/ecore/ecore_timer.c:966:20: error: dereferencing pointer to incomplete type
lib/ecore/ecore_timer.c:966:29: error: dereferencing pointer to incomplete type


Regards...

-- 
Leandro Dorileo
ProFUSION embedded systems
http://profusion.mobi

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Tablet Friendly Keyboard .kbd file

[Jeff Hoogland]

After talking with raster last night on IRC I realized I've never forwarded
the default .kbd file I've customized with tablets in mind up stream -
others might find it useful. It provides a fairly basic, three row keyboard:

http://www.enlightenment.org/ss/e-50c0d2146e3083.02166004.jpg
http://www.enlightenment.org/ss/e-50c0d2211eff02.47955663.jpg

Cheers,
-- 
~Jeff Hoogland 
Thoughts on Technology , Tech Blog
Bodhi Linux , Enlightenment for your Desktop


Default.kbd
Description: Binary data
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Fwd: Naviframe item title bar visibility behavior.

[Fábio Mello]

Hi all,

The title bar of a naviframe item is turned visible when the title is set,
even if it is setted as not visible. Is this the expected behavior?

I made a simple program that can be used to check it.

Tks.

Mello.
/*
 * gcc -o navi navi.c `pkg-config --cflags --libs elementary ecore-x`
 */
#ifdef HAVE_ELEMENTARY_X
# include 
#endif

#include 

static void
on_done(void *data, Evas_Object *obj, void *event_info)
{
   elm_exit();
}

static void
on_changed(void *data, Evas_Object *obj, void *event_info)
{
   Elm_Object_Item *item = (Elm_Object_Item *)data;
   elm_naviframe_item_title_visible_set(item, elm_check_state_get(obj));
}

static void
on_click(void *data, Evas_Object *obj, void *event_info)
{
   char s[256];
   static unsigned int i = 0;
   Elm_Object_Item *item = (Elm_Object_Item *)data;
   snprintf(s, sizeof(s), "Title: %d", i++);
   elm_object_item_part_text_set(item, NULL, s);
}

EAPI_MAIN int
elm_main(int argc, char *argv[])
{
   Elm_Object_Item *item;
   Evas_Object *win, *bg, *box, *hbox, *navi, *icon, *chk, *btn;

   win = elm_win_add(NULL, "win-example", ELM_WIN_BASIC);
   evas_object_smart_callback_add(win, "delete,request", on_done, NULL);
   evas_object_resize(win, 400, 400);
   evas_object_show(win);

   bg = elm_bg_add(win);
   evas_object_size_hint_weight_set(bg, EVAS_HINT_EXPAND, EVAS_HINT_EXPAND);
   elm_win_resize_object_add(win, bg);
   evas_object_show(bg);

   box = elm_box_add(win);
   evas_object_size_hint_weight_set(box, EVAS_HINT_EXPAND, EVAS_HINT_EXPAND);
   elm_win_resize_object_add(win, box);
   evas_object_show(box);

   navi = elm_naviframe_add(box);
   evas_object_size_hint_weight_set(navi, EVAS_HINT_EXPAND, EVAS_HINT_EXPAND);
   evas_object_size_hint_align_set(navi, EVAS_HINT_FILL, EVAS_HINT_FILL);
   elm_box_pack_end(box, navi);
   evas_object_show(navi);

   icon = elm_icon_add(navi);
   elm_icon_order_lookup_set(icon, ELM_ICON_LOOKUP_THEME_FDO);
   elm_icon_standard_set(icon, "home");
   evas_object_show(icon);

   item = elm_naviframe_item_push(navi, "Test", NULL, NULL, icon, NULL);

   chk = elm_check_add(box);
   elm_object_text_set(chk, "Title visible");
   elm_check_state_set(chk, EINA_TRUE);
   elm_box_pack_end(box, chk);
   evas_object_show(chk);

   evas_object_smart_callback_add(chk, "changed", on_changed, item);

   btn = elm_button_add(win);
   elm_object_text_set(btn, "Change text");
   elm_box_pack_end(box, btn);
   evas_object_show(btn);

   evas_object_smart_callback_add(btn, "clicked", on_click, item);

   elm_run();
   elm_shutdown();

   return 0;
}
ELM_MAIN()
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: maxerba IN trunk/e/src: bin modules/pager

[Michael Blumenkrantz]

On Thu,  6 Dec 2012 09:44:37 -0800
"Enlightenment SVN"  wrote:

> Log:
> this is to avoid duplicate messages different only for case of initial 
> letters, so translation files has less messages
> 
> Author:   maxerba
> Date: 2012-12-06 09:44:36 -0800 (Thu, 06 Dec 2012)
> New Revision: 80374
> Trac: http://trac.enlightenment.org/e/changeset/80374
> 
> Modified:
>   trunk/e/src/bin/e_int_border_menu.c 
> trunk/e/src/modules/pager/e_mod_config.c 
> 
> Modified: trunk/e/src/bin/e_int_border_menu.c
> ===
> --- trunk/e/src/bin/e_int_border_menu.c   2012-12-06 16:59:07 UTC (rev 
> 80373)
> +++ trunk/e/src/bin/e_int_border_menu.c   2012-12-06 17:44:36 UTC (rev 
> 80374)
> @@ -392,7 +392,7 @@
>"e/widgets/border/default/maximize");
>  
>  submi = e_menu_item_new(subm);
> -e_menu_item_label_set(submi, _("Maximize vertically"));
> +e_menu_item_label_set(submi, _("Maximize Vertically"));
>  e_menu_item_radio_set(submi, 1);
>  e_menu_item_radio_group_set(submi, 3);
>  e_menu_item_toggle_set(submi, (bd->maximized & E_MAXIMIZE_DIRECTION) 
> == E_MAXIMIZE_VERTICAL);
> @@ -403,7 +403,7 @@
>"e/widgets/border/default/maximize");
>  
>  submi = e_menu_item_new(subm);
> -e_menu_item_label_set(submi, _("Maximize horizontally"));
> +e_menu_item_label_set(submi, _("Maximize Horizontally"));
>  e_menu_item_radio_set(submi, 1);
>  e_menu_item_radio_group_set(submi, 3);
>  e_menu_item_toggle_set(submi, (bd->maximized & E_MAXIMIZE_DIRECTION) 
> == E_MAXIMIZE_HORIZONTAL);
> @@ -414,7 +414,7 @@
>"e/widgets/border/default/maximize");
>  
>  submi = e_menu_item_new(subm);
> -e_menu_item_label_set(submi, _("Maximize left"));
> +e_menu_item_label_set(submi, _("Maximize Left"));
>  e_menu_item_radio_set(submi, 1);
>  e_menu_item_radio_group_set(submi, 3);
>  e_menu_item_toggle_set(submi, (bd->maximized & E_MAXIMIZE_DIRECTION) 
> == E_MAXIMIZE_LEFT);
> @@ -425,7 +425,7 @@
>"e/widgets/border/default/maximize");
>  
>  submi = e_menu_item_new(subm);
> -e_menu_item_label_set(submi, _("Maximize right"));
> +e_menu_item_label_set(submi, _("Maximize Right"));
>  e_menu_item_radio_set(submi, 1);
>  e_menu_item_radio_group_set(submi, 3);
>  e_menu_item_toggle_set(submi, (bd->maximized & E_MAXIMIZE_DIRECTION) 
> == E_MAXIMIZE_RIGHT);
> 
> Modified: trunk/e/src/modules/pager/e_mod_config.c
> ===
> --- trunk/e/src/modules/pager/e_mod_config.c  2012-12-06 16:59:07 UTC (rev 
> 80373)
> +++ trunk/e/src/modules/pager/e_mod_config.c  2012-12-06 17:44:36 UTC (rev 
> 80374)
> @@ -141,7 +141,7 @@
> ow = e_widget_check_add(evas, _("Show popup on desktop change"),
> &(cfdata->popup.show));
> e_widget_framelist_object_append(of, ow);
> -   ow = e_widget_check_add(evas, _("Show popup for urgent windows"),
> +   ow = e_widget_check_add(evas, _("Show popup on urgent windows"),
> &(cfdata->popup.urgent_show));
> e_widget_framelist_object_append(of, ow);
> e_widget_list_object_append(ol, of, 1, 0, 0.5);
> 
> 

hmmm the last change here actually changes the meaning of the option though...

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: maxerba IN trunk/e/src: bin modules/pager

[Massimo Maiurana]

Michael Blumenkrantz, il 06/12/2012 18:49, ha scritto:

>> Modified: trunk/e/src/modules/pager/e_mod_config.c
>> ===
>> --- trunk/e/src/modules/pager/e_mod_config.c 2012-12-06 16:59:07 UTC (rev 
>> 80373)
>> +++ trunk/e/src/modules/pager/e_mod_config.c 2012-12-06 17:44:36 UTC (rev 
>> 80374)
>> @@ -141,7 +141,7 @@
>> ow = e_widget_check_add(evas, _("Show popup on desktop change"),
>> &(cfdata->popup.show));
>> e_widget_framelist_object_append(of, ow);
>> -   ow = e_widget_check_add(evas, _("Show popup for urgent windows"),
>> +   ow = e_widget_check_add(evas, _("Show popup on urgent windows"),
>> &(cfdata->popup.urgent_show));
>> e_widget_framelist_object_append(of, ow);
>> e_widget_list_object_append(ol, of, 1, 0, 0.5);
>>
>>
> 
> hmmm the last change here actually changes the meaning of the option though...

in src/modules/pager/e_mod_config.c:265 there is a string which says "Show
popup on urgent windows". should I change that instead?

-- 

  Massimo Maiurana   GPG keyID #7044D601

  La fede e' credere in cio' che sai non essere vero
[Mark Twain]



signature.asc
Description: OpenPGP digital signature
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: maxerba IN trunk/e/src: bin modules/pager

[Michael Blumenkrantz]

On Thu, 06 Dec 2012 19:01:22 +0100
Massimo Maiurana  wrote:

> Michael Blumenkrantz, il 06/12/2012 18:49, ha scritto:
> 
> >> Modified: trunk/e/src/modules/pager/e_mod_config.c
> >> ===
> >> --- trunk/e/src/modules/pager/e_mod_config.c   2012-12-06 16:59:07 UTC 
> >> (rev 80373)
> >> +++ trunk/e/src/modules/pager/e_mod_config.c   2012-12-06 17:44:36 UTC 
> >> (rev 80374)
> >> @@ -141,7 +141,7 @@
> >> ow = e_widget_check_add(evas, _("Show popup on desktop change"),
> >> &(cfdata->popup.show));
> >> e_widget_framelist_object_append(of, ow);
> >> -   ow = e_widget_check_add(evas, _("Show popup for urgent windows"),
> >> +   ow = e_widget_check_add(evas, _("Show popup on urgent windows"),
> >> &(cfdata->popup.urgent_show));
> >> e_widget_framelist_object_append(of, ow);
> >> e_widget_list_object_append(ol, of, 1, 0, 0.5);
> >>
> >>
> > 
> > hmmm the last change here actually changes the meaning of the option 
> > though...
> 
> in src/modules/pager/e_mod_config.c:265 there is a string which says "Show
> popup on urgent windows". should I change that instead?
> 

I think so...trying to remember what this option does. if it causes the popup 
to show in the middle of the screen then yes, it should be "show popup for 
urgent windows". if it shows a popup on the pager window itself (which I don't 
think it does?) then it should be "...on urgent windows"

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Fwd: Naviframe item title bar visibility behavior.

[Fábio Mello]

Hi all,

The title bar of a naviframe item is turned visible when the title is set,
even if it is setted as not visible. Is this the expected behavior?

I made a simple program that can be used to check it.

Tks.

Mello.
/*
 * gcc -o navi navi.c `pkg-config --cflags --libs elementary ecore-x`
 */
#ifdef HAVE_ELEMENTARY_X
# include 
#endif

#include 

static void
on_done(void *data, Evas_Object *obj, void *event_info)
{
   elm_exit();
}

static void
on_changed(void *data, Evas_Object *obj, void *event_info)
{
   Elm_Object_Item *item = (Elm_Object_Item *)data;
   elm_naviframe_item_title_visible_set(item, elm_check_state_get(obj));
}

static void
on_click(void *data, Evas_Object *obj, void *event_info)
{
   char s[256];
   static unsigned int i = 0;
   Elm_Object_Item *item = (Elm_Object_Item *)data;
   snprintf(s, sizeof(s), "Title: %d", i++);
   elm_object_item_part_text_set(item, NULL, s);
}

EAPI_MAIN int
elm_main(int argc, char *argv[])
{
   Elm_Object_Item *item;
   Evas_Object *win, *bg, *box, *hbox, *navi, *icon, *chk, *btn;

   win = elm_win_add(NULL, "win-example", ELM_WIN_BASIC);
   evas_object_smart_callback_add(win, "delete,request", on_done, NULL);
   evas_object_resize(win, 400, 400);
   evas_object_show(win);

   bg = elm_bg_add(win);
   evas_object_size_hint_weight_set(bg, EVAS_HINT_EXPAND, EVAS_HINT_EXPAND);
   elm_win_resize_object_add(win, bg);
   evas_object_show(bg);

   box = elm_box_add(win);
   evas_object_size_hint_weight_set(box, EVAS_HINT_EXPAND, EVAS_HINT_EXPAND);
   elm_win_resize_object_add(win, box);
   evas_object_show(box);

   navi = elm_naviframe_add(box);
   evas_object_size_hint_weight_set(navi, EVAS_HINT_EXPAND, EVAS_HINT_EXPAND);
   evas_object_size_hint_align_set(navi, EVAS_HINT_FILL, EVAS_HINT_FILL);
   elm_box_pack_end(box, navi);
   evas_object_show(navi);

   icon = elm_icon_add(navi);
   elm_icon_order_lookup_set(icon, ELM_ICON_LOOKUP_THEME_FDO);
   elm_icon_standard_set(icon, "home");
   evas_object_show(icon);

   item = elm_naviframe_item_push(navi, "Test", NULL, NULL, icon, NULL);

   chk = elm_check_add(box);
   elm_object_text_set(chk, "Title visible");
   elm_check_state_set(chk, EINA_TRUE);
   elm_box_pack_end(box, chk);
   evas_object_show(chk);

   evas_object_smart_callback_add(chk, "changed", on_changed, item);

   btn = elm_button_add(win);
   elm_object_text_set(btn, "Change text");
   elm_box_pack_end(box, btn);
   evas_object_show(btn);

   evas_object_smart_callback_add(btn, "clicked", on_click, item);

   elm_run();
   elm_shutdown();

   return 0;
}
ELM_MAIN()
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri trunk/efl

[Vincent Torri]

On Thu, Dec 6, 2012 at 11:09 PM, Enlightenment SVN
 wrote:
> Log:
> efl: add EFL_PKG_CHECK_STRICT() and use it.
>
>   PKG_CHECK_EXISTS() does not abort upon failure, our rule. So add this
>   and avoid replicating code like crazy.

the way i did it is such that it can not fail...

Vincent

>
>
>
> Author:   barbieri
> Date: 2012-12-06 14:09:47 -0800 (Thu, 06 Dec 2012)
> New Revision: 80396
> Trac: http://trac.enlightenment.org/e/changeset/80396
>
> Modified:
>   trunk/efl/configure.ac
>
> Modified: trunk/efl/configure.ac
> ===
> --- trunk/efl/configure.ac  2012-12-06 21:41:28 UTC (rev 80395)
> +++ trunk/efl/configure.ac  2012-12-06 22:09:47 UTC (rev 80396)
> @@ -431,7 +431,8 @@
>  # check for crypto/tls library to use
>  case "$build_crypto" in
> gnutls)
> -  PKG_CHECK_MODULES([GNUTLS], [gnutls >= 2.11])
> +  EFL_PKG_CHECK_STRICT([gnutls >= 2.11])
> +
>AC_DEFINE([HAVE_GNUTLS], [1], [Have Gnutls support])
>requirements_pc_crypto="gnutls >= 2.11 ${requirements_pc_crypto}"
>requirements_pc_deps_crypto="gnutls >= 2.11 
> ${requirements_pc_deps_crypto}"
> @@ -443,12 +444,11 @@
>;;
>
> openssl)
> -  PKG_CHECK_EXISTS([openssl],
> - [
> -  AC_DEFINE([HAVE_OPENSSL], [1], [Have Openssl support])
> -  requirements_pc_crypto="openssl ${requirements_pc_crypto}"
> -  requirements_pc_deps_crypto="openssl 
> ${requirements_pc_deps_crypto}"
> - ])
> +  EFL_PKG_CHECK_STRICT([openssl])
> +
> +  AC_DEFINE([HAVE_OPENSSL], [1], [Have Openssl support])
> +  requirements_pc_crypto="openssl ${requirements_pc_crypto}"
> +  requirements_pc_deps_crypto="openssl ${requirements_pc_deps_crypto}"
>;;
>  esac
>
> @@ -1453,9 +1453,8 @@
>  requirements_pc_evas="eo >= ${PACKAGE_VERSION} eet >= ${PACKAGE_VERSION} 
> eina >= ${PACKAGE_VERSION} ${requirements_pc_evas}"
>
>  # Freetype
> -PKG_CHECK_EXISTS([freetype2 >= 9.3.0],
> -   [requirements_pc_evas="freetype2 >= 9.3.0 ${requirements_pc_evas}"])
> -
> +EFL_PKG_CHECK_STRICT([freetype2 >= 9.3.0])
> +requirements_pc_evas="freetype2 >= 9.3.0 ${requirements_pc_evas}"
>  requirements_pc_deps_evas="freetype2 >= 9.3.0 ${requirements_pc_deps_evas}"
>
>  ## optional dependencies
> @@ -1463,53 +1462,46 @@
>  # FontConfig
>  have_fontconfig="no"
>  if test "x${want_fontconfig}" = "xyes"; then
> -   PKG_CHECK_EXISTS([fontconfig >= 2.5.0],
> -  [
> -   have_fontconfig="yes"
> -   AC_DEFINE(HAVE_FONTCONFIG, 1, [have fontconfig searching 
> capabilities])
> -   requirements_pc_evas="fontconfig >= 2.5.0 ${requirements_pc_evas}"
> -   requirements_pc_deps_evas="fontconfig >= 2.5.0 
> ${requirements_pc_deps_evas}"
> -  ])
> +   EFL_PKG_CHECK_STRICT([fontconfig >= 2.5.0])
> +   have_fontconfig="yes"
> +   AC_DEFINE(HAVE_FONTCONFIG, 1, [have fontconfig searching capabilities])
> +   requirements_pc_evas="fontconfig >= 2.5.0 ${requirements_pc_evas}"
> +   requirements_pc_deps_evas="fontconfig >= 2.5.0 
> ${requirements_pc_deps_evas}"
>  fi
>
>  # fribidi support
>  have_fribidi="no"
>  if test "x${want_fribidi}" = "xyes"; then
> -   PKG_CHECK_EXISTS([fribidi >= 0.19.2],
> -  [
> -   have_fribidi="yes"
> -   AC_DEFINE([HAVE_FRIBIDI], [1], [have fribidi support])
> -   requirements_pc_evas="fribidi >= 0.19.2 ${requirements_pc_evas}"
> -   requirements_pc_deps_evas="fribidi >= 0.19.2 
> ${requirements_pc_deps_evas}"
> -   CPPFLAGS_SAVE="$CPPFLAGS"
> -   CPPFLAGS="$CPPFLAGS $FRIBIDI_CFLAGS"
> -   AC_CHECK_SIZEOF([FriBidiChar], [], [#include ])
> -   CPPFLAGS="$CPPFLAGS_SAVE"
> -  ])
> +   EFL_PKG_CHECK_STRICT([fribidi >= 0.19.2])
> +   have_fribidi="yes"
> +   AC_DEFINE([HAVE_FRIBIDI], [1], [have fribidi support])
> +   requirements_pc_evas="fribidi >= 0.19.2 ${requirements_pc_evas}"
> +   requirements_pc_deps_evas="fribidi >= 0.19.2 ${requirements_pc_deps_evas}"
> +
> +   CPPFLAGS_SAVE="$CPPFLAGS"
> +   CPPFLAGS="$CPPFLAGS $FRIBIDI_CFLAGS"
> +   AC_CHECK_SIZEOF([FriBidiChar], [], [#include ])
> +   CPPFLAGS="$CPPFLAGS_SAVE"
>  fi
>
>  # harfbuzz support
>  have_harfbuzz="no"
>  have_harfbuzz_ft="no"
>  if test "x${want_harfbuzz}" = "xyes"; then
> -   PKG_CHECK_EXISTS([harfbuzz >= 0.9.0],
> -  [
> -   have_harfbuzz="yes"
> -   requirements_pc_evas="harfbuzz >= 0.9.0 ${requirements_pc_evas}"
> -   requirements_pc_deps_evas="harfbuzz >= 0.9.0 
> ${requirements_pc_deps_evas}"
> -  ], [AC_MSG_ERROR([pkg-config missing harfbuzz >= 0.9.0])])
> +   EFL_PKG_CHECK_STRICT([harfbuzz >= 0.9.0])
> +   have_harfbuzz="yes"
> +   requirements_pc_evas="harfbuzz >= 0.9.0 ${requirements_pc_evas}"
> +   requirements_pc_deps_evas="harfbuzz >= 0.9.0 ${requirements_pc_deps_evas}"
>  fi
>
>  # Pixman
>  have_pixman="no"
>  if test "x${want_pixman}" = "xyes"; then
> -   PKG_CHECK_EXISTS([pixman-1],
> -  [
> -   have_pixman="yes"
> -   AC_DEFI

Re: [E-devel] E SVN: raster trunk/efl

[The Rasterman]

On Thu, 6 Dec 2012 14:24:34 -0200 Gustavo Sverzut Barbieri
 said:

> On Thursday, December 6, 2012, Enlightenment SVN wrote:
> 
> > Log:
> > without this i end up with a configure that does:
> >
> >   configure: updating cache config.cache
> >   configure: creating ./config.status
> >   config.status: error: cannot find input file: Makefile.in'
> >   make: *** No targets specified and no makefile found.  Stop.
> 
> 
> Sorry, Dorileo GOT the proper fix, was a missing [1] parameter after the
> [test ...] in the AC_DEFINE_IF()

just saw... i was tyring to fix something else and my efl tree build broke...
so fix as fast as i could was what i did. :)

> >   autoheader is unhappy:
> >
> >   autoreconf: running: /usr/bin/autoconf --force
> >   autoreconf: running: /usr/bin/autoheader --force
> >   autoheader: warning: missing template: HAVE_NOTIFY_WIN32
> >   autoheader: Use AC_DEFINE([HAVE_NOTIFY_WIN32], [], [Description])
> >   autoreconf: /usr/bin/autoheader failed with exit status: 1
> >
> >
> >
> > Author:   raster
> > Date: 2012-12-06 08:08:07 -0800 (Thu, 06 Dec 2012)
> > New Revision: 80368
> > Trac: http://trac.enlightenment.org/e/changeset/80368
> >
> > Modified:
> >   trunk/efl/configure.ac
> >
> > Modified: trunk/efl/configure.ac
> > ===
> > --- trunk/efl/configure.ac  2012-12-06 14:46:32 UTC (rev 80367)
> > +++ trunk/efl/configure.ac  2012-12-06 16:08:07 UTC (rev 80368)
> > @@ -479,9 +479,11 @@
> >  AM_CONDITIONAL([HAVE_INOTIFY], [test "x${have_inotify}" = "xyes"])
> >
> >  have_notify_win32="${have_win32}"
> > -AC_DEFINE_IF([HAVE_NOTIFY_WIN32],
> > -   [test "x${have_notify_win32}" = "xyes"],
> > -   [File monitoring with Windows notification])
> > +if test "x${have_notify_win32}" = "xyes" ; then
> > +  AC_DEFINE([HAVE_NOTIFY_WIN32], [1], [File monitoring with Windows
> > notification])
> > +else
> > +  AC_DEFINE([HAVE_NOTIFY_WIN32], [], [File monitoring with Windows
> > notification])
> > +fi
> >  AM_CONDITIONAL([HAVE_NOTIFY_WIN32], [test "x${have_notify_win32}" =
> > "xyes"])
> >
> >
> >
> >
> >
> > --
> > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> > Remotely access PCs and mobile devices and provide instant support
> > Improve your efficiency, and focus on delivering more value-add services
> > Discover what IT Professionals Know. Rescue delivers
> > http://p.sf.net/sfu/logmein_12329d2d
> > ___
> > enlightenment-svn mailing list
> > enlightenment-...@lists.sourceforge.net 
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
> >
> 
> 
> -- 
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> 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


--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

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

[Kim Shinwoo]

sure, thanks for your response.

On Fri, Dec 7, 2012 at 1:15 AM, Daniel Juyung Seo wrote:

> Hello cinoo,
> I have four comments.
>
> 1. 'const' for getters.
> Evas_Object *obj -> const Evas_Object
> I fixed this in r80369.
> http://trac.enlightenment.org/e/changeset/80369
>
> 2. also const for return values?
> It returns 'char *' but is there any chance to change this from users?
> If not, this needs to be 'const char *'.
>
> 3. documentations.
> Can you add descriptions about those access APIs to elm_access.h?
>
> 4. samples
> It will be great if there's any sample/tests in src/examples or src/bin.
>
> Daniel Juyung Seo (SeoZ)
>
> On Thu, Dec 6, 2012 at 9:21 PM, Enlightenment SVN <
> no-re...@enlightenment.org> wrote:
>
> > Log:
> > [access] add elm_access_external_info_get(Evas_Object*); becuase there is
> > set();
> >
> >
> > Author:   kimcinoo
> > Date: 2012-12-06 04:21:19 -0800 (Thu, 06 Dec 2012)
> > New Revision: 80353
> > Trac: http://trac.enlightenment.org/e/changeset/80353
> >
> > Modified:
> >   trunk/elementary/src/lib/elm_access.c
> > trunk/elementary/src/lib/elm_access.h
> >
> > Modified: trunk/elementary/src/lib/elm_access.c
> > ===
> > --- trunk/elementary/src/lib/elm_access.c   2012-12-06 12:18:24 UTC
> > (rev 80352)
> > +++ trunk/elementary/src/lib/elm_access.c   2012-12-06 12:21:19 UTC
> > (rev 80353)
> > @@ -790,5 +790,14 @@
> >   (_elm_access_object_get(obj), ELM_ACCESS_EXTERNAL_INFO, text);
> >  }
> >
> > +EAPI char *
> > +elm_access_external_info_get(Evas_Object *obj)
> > +{
> > +   Elm_Access_Info *ac;
> > +
> > +   ac = _elm_access_object_get(obj);
> > +   return _elm_access_text_get(ac, ELM_ACCESS_EXTERNAL_INFO, obj, NULL);
> > +}
> > +
> >  EO_DEFINE_CLASS(elm_obj_access_class_get, &class_desc,
> > ELM_OBJ_WIDGET_CLASS, NULL);
> >
> >
> > Modified: trunk/elementary/src/lib/elm_access.h
> > ===
> > --- trunk/elementary/src/lib/elm_access.h   2012-12-06 12:18:24 UTC
> > (rev 80352)
> > +++ trunk/elementary/src/lib/elm_access.h   2012-12-06 12:21:19 UTC
> > (rev 80353)
> > @@ -1,5 +1,5 @@
> >  /**
> > - * @defgroup Naviframe Naviframe
> > + * @defgroup Access Access
> >   * @ingroup Elementary
> >   *
> >   * TODO: description
> > @@ -12,3 +12,6 @@
> >
> >  EAPI void
> >  elm_access_external_info_set(Evas_Object *obj, const char *text);
> > +
> > +EAPI char *
> > +elm_access_external_info_get(Evas_Object *obj);
> >
> >
> >
> >
> --
> > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> > Remotely access PCs and mobile devices and provide instant support
> > Improve your efficiency, and focus on delivering more value-add services
> > Discover what IT Professionals Know. Rescue delivers
> > http://p.sf.net/sfu/logmein_12329d2d
> > ___
> > enlightenment-svn mailing list
> > enlightenment-...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
> >
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] std=c99 for ecore_con dns.c got missing

[Joerg Sonnenberger]

On Thu, Dec 06, 2012 at 12:57:39PM +0100, Vincent Torri wrote:
> so it's a problem with clang. Fix your CC, then

Clang defaults to C99, so this should only happen if it was explicitly
instructed otherwise...

Joerg

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: etrunko trunk/efl

[Joerg Sonnenberger]

On Thu, Dec 06, 2012 at 11:02:26AM -0200, Gustavo Sverzut Barbieri wrote:
> I disagree here, given that we never use the first operand as ! in any
> of our checks, just yes/no, there is no harm. The benefit is reducing
> the number of calls to test binary and also the resulting code size as
> it's smaller.

For any sane implement of sh, test is builtin. So at most it avoids a
bunch of forks. Side note, the "x$foo" usage *is* obsolete and only for
certain brain dead versions that have more issues already *cough*
Solaris /bin/sh *cough*.

Joerg

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] building efl with debug profile

[Cedric BAIL]

Yop,

On Fri, Dec 7, 2012 at 1:55 AM, Leandro Dorileo  wrote:
> While trying to build the efl merged tree with --profile=debug I got the
> following errors:
>
> lib/ecore/ecore_timer.c:540:4: warning: 'return' with no value, in function 
> returning non-void [enabled by default]
> lib/ecore/ecore_timer.c:540:31: error: expected ';' before '(' token
> lib/ecore/ecore_timer.c:544:4: error: dereferencing pointer to incomplete type
> lib/ecore/ecore_timer.c:544:4: error: dereferencing pointer to incomplete type
> lib/ecore/ecore_timer.c:544:4: error: dereferencing pointer to incomplete type
> lib/ecore/ecore_timer.c:544:4: error: dereferencing pointer to incomplete type
> lib/ecore/ecore_timer.c:552:16: error: dereferencing pointer to incomplete 
> type
> lib/ecore/ecore_timer.c:552:31: error: dereferencing pointer to incomplete 
> type
> lib/ecore/ecore_timer.c:555:48: error: dereferencing pointer to incomplete 
> type
> lib/ecore/ecore_timer.c:555:62: error: dereferencing pointer to incomplete 
> type
> lib/ecore/ecore_timer.c:556:15: error: dereferencing pointer to incomplete 
> type
> lib/ecore/ecore_timer.c:562:68: error: dereferencing pointer to incomplete 
> type
> lib/ecore/ecore_timer.c:563:15: error: dereferencing pointer to incomplete 
> type
> lib/ecore/ecore_timer.c:565:15: error: dereferencing pointer to incomplete 
> type
> lib/ecore/ecore_timer.c:567:27: error: dereferencing pointer to incomplete 
> type
> lib/ecore/ecore_timer.c: In function '_ecore_timer_cmp':
> lib/ecore/ecore_timer.c:966:20: error: dereferencing pointer to incomplete 
> type
> lib/ecore/ecore_timer.c:966:29: error: dereferencing pointer to incomplete 
> type

Should be now fixed in svn.
--
Cedric BAIL

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Tablet Friendly Keyboard .kbd file

[The Rasterman]

On Thu, 6 Dec 2012 11:16:57 -0600 Jeff Hoogland  said:

> After talking with raster last night on IRC I realized I've never forwarded
> the default .kbd file I've customized with tablets in mind up stream -
> others might find it useful. It provides a fairly basic, three row keyboard:
> 
> http://www.enlightenment.org/ss/e-50c0d2146e3083.02166004.jpg
> http://www.enlightenment.org/ss/e-50c0d2211eff02.47955663.jpg

ummm gotta say... i dont think that is all that much better. those keys are
insanely massive... you have pretty much the same keys as the default (almost) -
just even bigger minus the padding. i did this before for just myself - i made
the keys smaller for a 10" exopc tablet - like half the size and it worked well
- basically the layouts that ship were really made for a device with a portrait
2.8" screen where on a good day u could use 2" of it for actual touches - so on
a bigger screen the kbd is hopelessly bloated and big. methinks the solution is
actually making the kbd "smarter" in dealing with both scaling and sizing - it
needs to deal with "finger size" and maybe based on that plus some "padding"
config for the kbd - choose a better layout for that screen - one that adds
more keys for example. this would cover the portrait and landscape case AND
cover a whole range of screen sizes (form like 2" up to 20") as long as enough
layouts were given to cover the extremes and various points in between.
finger_size will let e know how big a key must be to be hit... so we're talking
elm. :)

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


--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] std=c99 for ecore_con dns.c got missing

[Cedric BAIL]

On Thu, Dec 6, 2012 at 11:12 PM, Vincent Torri  wrote:
> On Thu, Dec 6, 2012 at 3:08 PM, thomasg  wrote:
>> On Thu, Dec 6, 2012 at 12:57 PM, Vincent Torri 
>> wrote:
>>
>>> so it's a problem with clang. Fix your CC, then
>>>
>>>
>> Is it really?
>> dns_rr_foreach is defined as "for (struct dns_rr_i DNS_PP_XPASTE(i,
>> __LINE__) = *dns_rr_i_new((P), __VA_ARGS__); ..." in dns.h
>> As this is a declaration in the loop, it seems that clang's complaining is
>> correct, this is a C99 feature.
>>
>> So I think, a C99 compiler should be required, even if GCC does not
>> complain.
>
> or move the declaration outside the loop...

I think this is some code we pull from outside. So we need to fix
upstream first before we do this kind of move...
--
Cedric BAIL

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Tablet Friendly Keyboard .kbd file

[Jeff Hoogland]

As a reference it looks a big awkward in those screenshots because I took
those on my 1920x1080 screen on my 17" laptop. It fits better on a
sub-10inch tablet screen.

I wasn't saying it was perfect by any means for a tablet - just that it was
better than the current default (which I know where designed for something
other than a tablet)


On Thu, Dec 6, 2012 at 6:53 PM, Carsten Haitzler wrote:

> On Thu, 6 Dec 2012 11:16:57 -0600 Jeff Hoogland 
> said:
>
> > After talking with raster last night on IRC I realized I've never
> forwarded
> > the default .kbd file I've customized with tablets in mind up stream -
> > others might find it useful. It provides a fairly basic, three row
> keyboard:
> >
> > http://www.enlightenment.org/ss/e-50c0d2146e3083.02166004.jpg
> > http://www.enlightenment.org/ss/e-50c0d2211eff02.47955663.jpg
>
> ummm gotta say... i dont think that is all that much better. those keys are
> insanely massive... you have pretty much the same keys as the default
> (almost) -
> just even bigger minus the padding. i did this before for just myself - i
> made
> the keys smaller for a 10" exopc tablet - like half the size and it worked
> well
> - basically the layouts that ship were really made for a device with a
> portrait
> 2.8" screen where on a good day u could use 2" of it for actual touches -
> so on
> a bigger screen the kbd is hopelessly bloated and big. methinks the
> solution is
> actually making the kbd "smarter" in dealing with both scaling and sizing
> - it
> needs to deal with "finger size" and maybe based on that plus some
> "padding"
> config for the kbd - choose a better layout for that screen - one that adds
> more keys for example. this would cover the portrait and landscape case AND
> cover a whole range of screen sizes (form like 2" up to 20") as long as
> enough
> layouts were given to cover the extremes and various points in between.
> finger_size will let e know how big a key must be to be hit... so we're
> talking
> elm. :)
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>


-- 
~Jeff Hoogland 
Thoughts on Technology , Tech Blog
Bodhi Linux , Enlightenment for your Desktop
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] ecore-wayland: Fix monitoring ECORE_FD_WRITE defaultly on wayland display fd lead to 100% cpu usage

[Alex Wu]

Hi,

In ecore_wl_init(), adding wayland display fd with ECORE_FD_WRITE flag
make CPU usage 100%. This is true for all efl app running on wayland.

The proper way to monitor the ECORE_FD_WRITE is when the
wl_display_flush() return value < 0 and errno == EAGAIN. And if
wl_display_flush() return, we remove ECORE_FD_WRITE flag from the
display fd.

Patch attached.

From 24f4698235d1a0b75ac963f53e00085a00fea0ef Mon Sep 17 00:00:00 2001
From: Alex Wu 
Date: Fri, 7 Dec 2012 11:17:16 +0800
Subject: [PATCH] ecore-wayland: Fix monitoring ECORE_FD_WRITE defaultly on
 waylanddisplay fd lead to 100% cpu usage

In ecore_wl_init(), adding wayland display fd with ECORE_FD_WRITE
flag make CPU usage 100%. The proper way to monitor the ECORE_FD_WRITE
is when the wl_display_flush() return value < 0 and errno == EAGAIN.
And if wl_display_flush() return, we remove ECORE_FD_WRITE flag from
the display fd.
---
 trunk/efl/src/lib/ecore_wayland/ecore_wl.c |   36 ++--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/trunk/efl/src/lib/ecore_wayland/ecore_wl.c 
b/trunk/efl/src/lib/ecore_wayland/ecore_wl.c
index 7f06a1d..861f6e4 100644
--- a/trunk/efl/src/lib/ecore_wayland/ecore_wl.c
+++ b/trunk/efl/src/lib/ecore_wayland/ecore_wl.c
@@ -7,6 +7,7 @@
 
 /* local function prototypes */
 static Eina_Bool _ecore_wl_shutdown(Eina_Bool close);
+static Eina_Bool _ecore_wl_cb_idle_enterer(void *data);
 static Eina_Bool _ecore_wl_cb_handle_data(void *data, Ecore_Fd_Handler *hdl);
 static void _ecore_wl_cb_handle_global(void *data, struct wl_registry 
*registry, unsigned int id, const char *interface, unsigned int version 
EINA_UNUSED);
 static Eina_Bool _ecore_wl_xkb_init(Ecore_Wl_Display *ewd);
@@ -138,10 +139,11 @@ ecore_wl_init(const char *name)
 
_ecore_wl_disp->fd_hdl =
  ecore_main_fd_handler_add(_ecore_wl_disp->fd,
-   ECORE_FD_READ | ECORE_FD_WRITE,
+   ECORE_FD_READ,
_ecore_wl_cb_handle_data, _ecore_wl_disp,
NULL, NULL);
 
+   ecore_idle_enterer_add(_ecore_wl_cb_idle_enterer, _ecore_wl_disp);
wl_list_init(&_ecore_wl_disp->inputs);
wl_list_init(&_ecore_wl_disp->outputs);
 
@@ -396,10 +398,32 @@ _ecore_wl_shutdown(Eina_Bool close)
return _ecore_wl_init_count;
 }
 
+static Eina_Bool 
+_ecore_wl_cb_idle_enterer(void *data)
+{
+   Ecore_Wl_Display *ewd;
+   int ret;
+
+   if (!(ewd = data)) return ECORE_CALLBACK_RENEW;
+
+   ret = wl_display_flush(ewd->wl.display);
+   if (ret < 0 && errno == EAGAIN)
+ {
+ecore_main_fd_handler_active_set(ewd->fd_hdl, ECORE_FD_READ | 
ECORE_FD_WRITE);
+ } 
+   else if (ret < 0) 
+ {
+  /* FIXME: need do error processing? */
+ }
+
+   return ECORE_CALLBACK_RENEW;
+}
+
 static Eina_Bool
 _ecore_wl_cb_handle_data(void *data, Ecore_Fd_Handler *hdl)
 {
Ecore_Wl_Display *ewd;
+   int ret;
 
/* LOGFN(__FILE__, __LINE__, __FUNCTION__); */
 
@@ -412,7 +436,15 @@ _ecore_wl_cb_handle_data(void *data, Ecore_Fd_Handler *hdl)
if (ecore_main_fd_handler_active_get(hdl, ECORE_FD_READ))
  wl_display_dispatch(ewd->wl.display);
else if (ecore_main_fd_handler_active_get(hdl, ECORE_FD_WRITE))
- wl_display_flush(ewd->wl.display);
+ {
+ret = wl_display_flush(ewd->wl.display);
+if (ret == 0)
+  ecore_main_fd_handler_active_set(hdl, ECORE_FD_READ);
+else if (ret == -1 && errno != EAGAIN)
+  {
+/* FIXME: need do error processing? */
+  }
+ }
 
return ECORE_CALLBACK_RENEW;
 }
-- 
1.7.9.5

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Tablet Friendly Keyboard .kbd file

[The Rasterman]

On Thu, 6 Dec 2012 19:51:37 -0800 Jeff Hoogland  said:

> As a reference it looks a big awkward in those screenshots because I took
> those on my 1920x1080 screen on my 17" laptop. It fits better on a
> sub-10inch tablet screen.

hmm tho it'd scale similarly on such a device as height is calculated from
widht and landscape mode makes it... really wide! :) 

> I wasn't saying it was perfect by any means for a tablet - just that it was
> better than the current default (which I know where designed for something
> other than a tablet)
> 
> 
> On Thu, Dec 6, 2012 at 6:53 PM, Carsten Haitzler wrote:
> 
> > On Thu, 6 Dec 2012 11:16:57 -0600 Jeff Hoogland 
> > said:
> >
> > > After talking with raster last night on IRC I realized I've never
> > forwarded
> > > the default .kbd file I've customized with tablets in mind up stream -
> > > others might find it useful. It provides a fairly basic, three row
> > keyboard:
> > >
> > > http://www.enlightenment.org/ss/e-50c0d2146e3083.02166004.jpg
> > > http://www.enlightenment.org/ss/e-50c0d2211eff02.47955663.jpg
> >
> > ummm gotta say... i dont think that is all that much better. those keys are
> > insanely massive... you have pretty much the same keys as the default
> > (almost) -
> > just even bigger minus the padding. i did this before for just myself - i
> > made
> > the keys smaller for a 10" exopc tablet - like half the size and it worked
> > well
> > - basically the layouts that ship were really made for a device with a
> > portrait
> > 2.8" screen where on a good day u could use 2" of it for actual touches -
> > so on
> > a bigger screen the kbd is hopelessly bloated and big. methinks the
> > solution is
> > actually making the kbd "smarter" in dealing with both scaling and sizing
> > - it
> > needs to deal with "finger size" and maybe based on that plus some
> > "padding"
> > config for the kbd - choose a better layout for that screen - one that adds
> > more keys for example. this would cover the portrait and landscape case AND
> > cover a whole range of screen sizes (form like 2" up to 20") as long as
> > enough
> > layouts were given to cover the extremes and various points in between.
> > finger_size will let e know how big a key must be to be hit... so we're
> > talking
> > elm. :)
> >
> > --
> > - Codito, ergo sum - "I code, therefore I am" --
> > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> >
> >
> 
> 
> -- 
> ~Jeff Hoogland 
> Thoughts on Technology , Tech Blog
> Bodhi Linux , Enlightenment for your Desktop


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


--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel