[EGIT] [core/efl] master 01/01: eina: allow eina_time_get to fall back to other clocks if the first one fails
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=ed0618407754fbfc497addc6824f1c06c684cd89
commit ed0618407754fbfc497addc6824f1c06c684cd89
Author: Albin Tonnerre albin.tonne...@gmail.com
Date: Wed Feb 12 11:50:48 2014 +0900
eina: allow eina_time_get to fall back to other clocks if the first one
fails
Summary:
eina_time_get tries to use only one clock which is defined at compile-time
and
returns the result of that one. This causes problems on platforms where eg.
CLOCK_PROCESS_CPUTIME_ID is defined but the clock is actually not
implemented
(ie. clock_gettime returns EINVAL), as we simply don't get any time at all.
Instead, make sure we include the code for all defined clocks and simply
fall
back to other clocks if the previous ones aren't implemented.
Reviewers: cedric, raster
Reviewed By: cedric
CC: cedric
Differential Revision: https://phab.enlightenment.org/D547
Signed-off-by: Cedric BAIL cedric.b...@samsung.com
---
src/lib/eina/eina_inline_private.h | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/src/lib/eina/eina_inline_private.h
b/src/lib/eina/eina_inline_private.h
index ee0c49b..fe0d7b4 100644
--- a/src/lib/eina/eina_inline_private.h
+++ b/src/lib/eina/eina_inline_private.h
@@ -41,12 +41,17 @@ _eina_time_get(Eina_Nano_Time *tp)
{
#ifndef _WIN32
# if defined(CLOCK_PROCESS_CPUTIME_ID)
- return clock_gettime(CLOCK_PROCESS_CPUTIME_ID, tp);
-# elif defined(CLOCK_PROF)
- return clock_gettime(CLOCK_PROF, tp);
-# elif defined(CLOCK_REALTIME)
- return clock_gettime(CLOCK_REALTIME, tp);
-# else
+ if (!clock_gettime(CLOCK_PROCESS_CPUTIME_ID, tp))
+ return 0;
+# endif
+# if defined(CLOCK_PROF)
+ if (!clock_gettime(CLOCK_PROF, tp))
+ return 0;
+# endif
+# if defined(CLOCK_REALTIME)
+ if (!clock_gettime(CLOCK_REALTIME, tp))
+ return 0;
+# endif
struct timeval tv;
if (gettimeofday(tv, NULL))
@@ -56,7 +61,6 @@ _eina_time_get(Eina_Nano_Time *tp)
tp-tv_nsec = tv.tv_usec * 1000L;
return 0;
-# endif
#else
return QueryPerformanceCounter(tp);
#endif /* _WIN2 */
--
[EGIT] [core/efl] efl-1.8 01/01: eina: allow eina_time_get to fall back to other clocks if the first one fails
cedric pushed a commit to branch efl-1.8.
http://git.enlightenment.org/core/efl.git/commit/?id=5ff5f509fccab9196449f1c31109e316a1a7fed3
commit 5ff5f509fccab9196449f1c31109e316a1a7fed3
Author: Albin Tonnerre albin.tonne...@gmail.com
Date: Wed Feb 12 11:50:48 2014 +0900
eina: allow eina_time_get to fall back to other clocks if the first one
fails
Summary:
eina_time_get tries to use only one clock which is defined at compile-time
and
returns the result of that one. This causes problems on platforms where eg.
CLOCK_PROCESS_CPUTIME_ID is defined but the clock is actually not
implemented
(ie. clock_gettime returns EINVAL), as we simply don't get any time at all.
Instead, make sure we include the code for all defined clocks and simply
fall
back to other clocks if the previous ones aren't implemented.
Reviewers: cedric, raster
Reviewed By: cedric
CC: cedric
Differential Revision: https://phab.enlightenment.org/D547
Signed-off-by: Cedric BAIL cedric.b...@samsung.com
---
src/lib/eina/eina_inline_private.h | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/src/lib/eina/eina_inline_private.h
b/src/lib/eina/eina_inline_private.h
index ee0c49b..fe0d7b4 100644
--- a/src/lib/eina/eina_inline_private.h
+++ b/src/lib/eina/eina_inline_private.h
@@ -41,12 +41,17 @@ _eina_time_get(Eina_Nano_Time *tp)
{
#ifndef _WIN32
# if defined(CLOCK_PROCESS_CPUTIME_ID)
- return clock_gettime(CLOCK_PROCESS_CPUTIME_ID, tp);
-# elif defined(CLOCK_PROF)
- return clock_gettime(CLOCK_PROF, tp);
-# elif defined(CLOCK_REALTIME)
- return clock_gettime(CLOCK_REALTIME, tp);
-# else
+ if (!clock_gettime(CLOCK_PROCESS_CPUTIME_ID, tp))
+ return 0;
+# endif
+# if defined(CLOCK_PROF)
+ if (!clock_gettime(CLOCK_PROF, tp))
+ return 0;
+# endif
+# if defined(CLOCK_REALTIME)
+ if (!clock_gettime(CLOCK_REALTIME, tp))
+ return 0;
+# endif
struct timeval tv;
if (gettimeofday(tv, NULL))
@@ -56,7 +61,6 @@ _eina_time_get(Eina_Nano_Time *tp)
tp-tv_nsec = tv.tv_usec * 1000L;
return 0;
-# endif
#else
return QueryPerformanceCounter(tp);
#endif /* _WIN2 */
--
Re: [E-devel] [EGIT] [core/efl] master 01/02: configure - don't add -mfpu-neon on arm - this breaks building for armv6/4...
On Mon, Feb 10, 2014 at 6:00 PM, Gustavo Sverzut Barbieri barbi...@gmail.com wrote: Hi Raster, This was added as Albin (ARM developer) requested, could you both check if it should stay or not? I'm unsure why that breaks build on earlier architectures, but removing -mfpu=neon doesn't make the check any more correct: since #include arm_neon.h will error out if you don't compile with the flag, the net effect is that it's now disabled for everyone... What was the issue exactly? -- Albin -- Androidtrade; apps run on BlackBerryreg;10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/02: configure - don't add -mfpu-neon on arm - this breaks building for armv6/4...
On Tue, Feb 11, 2014 at 12:32 AM, Carsten Haitzler ras...@rasterman.com wrote: the check temporarily adds -mfpu-neon to then #include arm_neon.h + arm asm check as the next check and then enables neon builds if this works... then restores CFLAGS. so it turns neon on regardless if -mfpu-neon is on in my CFLAGS. if neon compiling requires -mfpu=neon (in the past it most certainly has with gcc), then this breaks unless my CFLAGS also contain or enable neon in some way. -mfpu=neon is not added manually to any Makefile.am to be attached to specific files either, so neon support compilation is enabled regardless if the relevant compiler options are on or not during compilation of that neon code. :) That's not the case at the moment. Compiling with -mfpu-neon is only necessary when using #include arm_neon.h, and the EFL code doesn't do that. Instead, it uses __asm__ (.fpu neon) where necessary to get NEON code. Proper support in Makefile.am will be necessary when using intrinsics, but that's not what we do now. -- Albin -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 01/01: cleanup - Remove the extra copy of the code and use a define instead
raster pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=64e153ea7fffa269dcc4566aeb6e17f2b24580ea
commit 64e153ea7fffa269dcc4566aeb6e17f2b24580ea
Author: Albin Tonnerre albin.tonne...@gmail.com
Date: Sun Feb 9 19:44:49 2014 +0900
cleanup - Remove the extra copy of the code and use a define instead
_op_blend_pan_mas_dp is just a duplication of the code in
_op_blend_pas_mas_dp. Remove the extra copy of the code and use a define
instead; this is what the SSE3 code already does.
---
.../common/evas_op_blend/op_blend_pixel_mask_.c| 24 +-
1 file changed, 1 insertion(+), 23 deletions(-)
diff --git a/src/lib/evas/common/evas_op_blend/op_blend_pixel_mask_.c
b/src/lib/evas/common/evas_op_blend/op_blend_pixel_mask_.c
index 5d6c976..78ff716 100644
--- a/src/lib/evas/common/evas_op_blend/op_blend_pixel_mask_.c
+++ b/src/lib/evas/common/evas_op_blend/op_blend_pixel_mask_.c
@@ -48,29 +48,7 @@ _op_blend_pas_mas_dp(DATA32 *s, DATA8 *m, DATA32 c
EINA_UNUSED, DATA32 *d, int l
});
}
-static void
-_op_blend_pan_mas_dp(DATA32 *s, DATA8 *m, DATA32 c EINA_UNUSED, DATA32 *d, int
l) {
- DATA32 *e;
- int alpha;
- UNROLL8_PLD_WHILE(d, l, e,
- {
-alpha = *m;
-switch(alpha)
- {
- case 0:
- break;
- case 255:
- *d = *s;
- break;
- default:
- alpha++;
- *d = INTERP_256(alpha, *s, *d);
- break;
- }
-m++; s++; d++;
- });
-}
-
+#define _op_blend_pan_mas_dp _op_blend_pas_mas_dp
#define _op_blend_p_mas_dpan _op_blend_p_mas_dp
#define _op_blend_pas_mas_dpan _op_blend_pas_mas_dp
--
[EGIT] [core/efl] master 01/02: comments: typo fix - s/dictionnary/dictionary
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=62efaed9dcb27e4b07a5d35cd1d0819db7624aac
commit 62efaed9dcb27e4b07a5d35cd1d0819db7624aac
Author: Albin Tonnerre albin.tonne...@gmail.com
Date: Mon Feb 10 10:40:08 2014 +0900
comments: typo fix - s/dictionnary/dictionary
Reviewers: cedric
Reviewed By: cedric
CC: cedric
Differential Revision: https://phab.enlightenment.org/D533
Signed-off-by: Cedric BAIL cedric.b...@samsung.com
---
src/lib/edje/edje_load.c | 2 +-
src/lib/eet/eet_lib.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/lib/edje/edje_load.c b/src/lib/edje/edje_load.c
index 073de55..c27808e 100644
--- a/src/lib/edje/edje_load.c
+++ b/src/lib/edje/edje_load.c
@@ -1527,7 +1527,7 @@ _edje_file_free(Edje_File *edf)
eina_stringshare_del(edf-image_dir-entries[i].entry);
}
-/* Sets have been added after edje received eet dictionnary support */
+/* Sets have been added after edje received eet dictionary support */
for (i = 0; i edf-image_dir-sets_count; ++i)
{
Edje_Image_Directory_Set_Entry *se;
diff --git a/src/lib/eet/eet_lib.c b/src/lib/eet/eet_lib.c
index 6ff2a3c..e1099cb 100644
--- a/src/lib/eet/eet_lib.c
+++ b/src/lib/eet/eet_lib.c
@@ -938,7 +938,7 @@ eet_internal_read2(Eet_File *ef)
if (eet_test_close(!ef-ed, ef))
return NULL;
-INF(loading dictionnary for '%s' with %lu entries of size %zu,
+INF(loading dictionary for '%s' with %lu entries of size %zu,
ef-path, num_dictionary_entries, sizeof(Eet_String));
ef-ed-all = calloc(1, num_dictionary_entries * sizeof(Eet_String));
--
[E-devel] [PATCH] evas/op_blend: remove duplicated function _op_blend_pan_mas_dp
_op_blend_pan_mas_dp is just a duplication of the code in
_op_blend_pas_mas_dp. Remove the extra copy of the code and use a define
instead; this is what the SSE3 code already does.
---
Hi,
I tried submitting that change using 'arc diff' but it keeps crashing because
of some JSON error, so here goes...
.../common/evas_op_blend/op_blend_pixel_mask_.c| 24 +-
1 file changed, 1 insertion(+), 23 deletions(-)
diff --git a/src/lib/evas/common/evas_op_blend/op_blend_pixel_mask_.c
b/src/lib/evas/common/evas_op_blend/op_blend_pixel_mask_.c
index 5d6c976..78ff716 100644
--- a/src/lib/evas/common/evas_op_blend/op_blend_pixel_mask_.c
+++ b/src/lib/evas/common/evas_op_blend/op_blend_pixel_mask_.c
@@ -48,29 +48,7 @@ _op_blend_pas_mas_dp(DATA32 *s, DATA8 *m, DATA32 c
EINA_UNUSED, DATA32 *d, int l
});
}
-static void
-_op_blend_pan_mas_dp(DATA32 *s, DATA8 *m, DATA32 c EINA_UNUSED, DATA32 *d, int
l) {
- DATA32 *e;
- int alpha;
- UNROLL8_PLD_WHILE(d, l, e,
- {
-alpha = *m;
-switch(alpha)
- {
- case 0:
- break;
- case 255:
- *d = *s;
- break;
- default:
- alpha++;
- *d = INTERP_256(alpha, *s, *d);
- break;
- }
-m++; s++; d++;
- });
-}
-
+#define _op_blend_pan_mas_dp _op_blend_pas_mas_dp
#define _op_blend_p_mas_dpan _op_blend_p_mas_dp
#define _op_blend_pas_mas_dpan _op_blend_pas_mas_dp
--
1.9.rc1
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] evas/op_blend: remove duplicated function _op_blend_pan_mas_dp
As requested, here's the patch as an attachement
--
Albin
On Sat, Feb 8, 2014 at 1:50 PM, Albin Tonnerre albin.tonne...@gmail.com wrote:
_op_blend_pan_mas_dp is just a duplication of the code in
_op_blend_pas_mas_dp. Remove the extra copy of the code and use a define
instead; this is what the SSE3 code already does.
---
Hi,
I tried submitting that change using 'arc diff' but it keeps crashing because
of some JSON error, so here goes...
.../common/evas_op_blend/op_blend_pixel_mask_.c| 24
+-
1 file changed, 1 insertion(+), 23 deletions(-)
diff --git a/src/lib/evas/common/evas_op_blend/op_blend_pixel_mask_.c
b/src/lib/evas/common/evas_op_blend/op_blend_pixel_mask_.c
index 5d6c976..78ff716 100644
--- a/src/lib/evas/common/evas_op_blend/op_blend_pixel_mask_.c
+++ b/src/lib/evas/common/evas_op_blend/op_blend_pixel_mask_.c
@@ -48,29 +48,7 @@ _op_blend_pas_mas_dp(DATA32 *s, DATA8 *m, DATA32 c
EINA_UNUSED, DATA32 *d, int l
});
}
-static void
-_op_blend_pan_mas_dp(DATA32 *s, DATA8 *m, DATA32 c EINA_UNUSED, DATA32 *d,
int l) {
- DATA32 *e;
- int alpha;
- UNROLL8_PLD_WHILE(d, l, e,
- {
-alpha = *m;
-switch(alpha)
- {
- case 0:
- break;
- case 255:
- *d = *s;
- break;
- default:
- alpha++;
- *d = INTERP_256(alpha, *s, *d);
- break;
- }
-m++; s++; d++;
- });
-}
-
+#define _op_blend_pan_mas_dp _op_blend_pas_mas_dp
#define _op_blend_p_mas_dpan _op_blend_p_mas_dp
#define _op_blend_pas_mas_dpan _op_blend_pas_mas_dp
--
1.9.rc1
From d687e125ce4b83d92ab22937aa5e61ad0139aaa9 Mon Sep 17 00:00:00 2001
From: Albin Tonnerre albin.tonne...@gmail.com
Date: Thu, 6 Feb 2014 20:50:00 +0100
Subject: [PATCH] evas/op_blend: remove duplicated function
_op_blend_pan_mas_dp
_op_blend_pan_mas_dp is just a duplication of the code in
_op_blend_pas_mas_dp. Remove the extra copy of the code and use a define
instead; this is what the SSE3 code already does.
---
Hi,
I tried submitting that change using 'arc diff' but it keeps crashing because
of some JSON error, so here goes...
.../common/evas_op_blend/op_blend_pixel_mask_.c| 24 +-
1 file changed, 1 insertion(+), 23 deletions(-)
diff --git a/src/lib/evas/common/evas_op_blend/op_blend_pixel_mask_.c b/src/lib/evas/common/evas_op_blend/op_blend_pixel_mask_.c
index 5d6c976..78ff716 100644
--- a/src/lib/evas/common/evas_op_blend/op_blend_pixel_mask_.c
+++ b/src/lib/evas/common/evas_op_blend/op_blend_pixel_mask_.c
@@ -48,29 +48,7 @@ _op_blend_pas_mas_dp(DATA32 *s, DATA8 *m, DATA32 c EINA_UNUSED, DATA32 *d, int l
});
}
-static void
-_op_blend_pan_mas_dp(DATA32 *s, DATA8 *m, DATA32 c EINA_UNUSED, DATA32 *d, int l) {
- DATA32 *e;
- int alpha;
- UNROLL8_PLD_WHILE(d, l, e,
- {
-alpha = *m;
-switch(alpha)
- {
- case 0:
- break;
- case 255:
- *d = *s;
- break;
- default:
- alpha++;
- *d = INTERP_256(alpha, *s, *d);
- break;
- }
-m++; s++; d++;
- });
-}
-
+#define _op_blend_pan_mas_dp _op_blend_pas_mas_dp
#define _op_blend_p_mas_dpan _op_blend_p_mas_dp
#define _op_blend_pas_mas_dpan _op_blend_pas_mas_dp
--
1.9.rc1
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 01/01: evas/op_blend: rename LOOP_ALIGNED_U1_A48_SSE3 to LOOP_ALIGNED_U1_A48
raster pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=259f33679c38e03de3e35c3a0859b3f3f0f9c39a
commit 259f33679c38e03de3e35c3a0859b3f3f0f9c39a
Author: Albin Tonnerre albin.tonne...@gmail.com
Date: Sun Feb 9 09:42:52 2014 +0900
evas/op_blend: rename LOOP_ALIGNED_U1_A48_SSE3 to LOOP_ALIGNED_U1_A48
Summary:
There's nothing SSE3-specific about that macro, let's use a more generic
name
for it. Since that's just a generic macro, we can also allow non-SSE (eg.
NEON) code to use it if they want to
Reviewers: cedric
CC: cedric
Differential Revision: https://phab.enlightenment.org/D528
---
src/lib/evas/common/evas_op_blend/op_blend_color_sse3.c| 4 ++--
.../evas/common/evas_op_blend/op_blend_mask_color_sse3.c | 6 +++---
.../evas/common/evas_op_blend/op_blend_pixel_color_sse3.c | 14 +++---
.../evas/common/evas_op_blend/op_blend_pixel_mask_sse3.c | 6 +++---
src/lib/evas/common/evas_op_blend/op_blend_pixel_sse3.c| 8
src/lib/evas/include/evas_blend_ops.h | 9 -
6 files changed, 23 insertions(+), 24 deletions(-)
diff --git a/src/lib/evas/common/evas_op_blend/op_blend_color_sse3.c
b/src/lib/evas/common/evas_op_blend/op_blend_color_sse3.c
index 02321b5..e986f10 100644
--- a/src/lib/evas/common/evas_op_blend/op_blend_color_sse3.c
+++ b/src/lib/evas/common/evas_op_blend/op_blend_color_sse3.c
@@ -10,7 +10,7 @@ _op_blend_c_dp_sse3(DATA32 *s EINA_UNUSED, DATA8 *m
EINA_UNUSED, DATA32 c, DATA3
const __m128i c_packed = _mm_set_epi32(c, c, c, c);
const __m128i a_packed = _mm_set_epi32(a, a, a, a);
- LOOP_ALIGNED_U1_A48_SSE3(d, l,
+ LOOP_ALIGNED_U1_A48(d, l,
{ /* UOP */
*d = c + MUL_256(a, *d);
@@ -94,7 +94,7 @@ _op_blend_rel_c_dp_sse3(DATA32 *s EINA_UNUSED, DATA8 *m
EINA_UNUSED, DATA32 c, D
const __m128i c_packed = _mm_set_epi32(c, c, c, c);
const __m128i alpha_packed = _mm_set_epi32(alpha, alpha, alpha, alpha);
- LOOP_ALIGNED_U1_A48_SSE3(d, l,
+ LOOP_ALIGNED_U1_A48(d, l,
{ /* UOP */
*d = MUL_SYM(*d 24, c) + MUL_256(alpha, *d);
diff --git a/src/lib/evas/common/evas_op_blend/op_blend_mask_color_sse3.c
b/src/lib/evas/common/evas_op_blend/op_blend_mask_color_sse3.c
index 429e8d5..576220d 100644
--- a/src/lib/evas/common/evas_op_blend/op_blend_mask_color_sse3.c
+++ b/src/lib/evas/common/evas_op_blend/op_blend_mask_color_sse3.c
@@ -7,7 +7,7 @@ _op_blend_mas_c_dp_sse3(DATA32 *s EINA_UNUSED, DATA8 *m, DATA32
c, DATA32 *d, in
const __m128i c_packed = _mm_set_epi32(c, c, c, c);
- LOOP_ALIGNED_U1_A48_SSE3(d, l,
+ LOOP_ALIGNED_U1_A48(d, l,
{ /* UOP */
DATA32 a = *m;
@@ -76,7 +76,7 @@ _op_blend_mas_can_dp_sse3(DATA32 *s EINA_UNUSED, DATA8 *m,
DATA32 c, DATA32 *d,
const __m128i one = _mm_set_epi32(1, 1, 1, 1);
const __m128i c_packed = _mm_set_epi32(c, c, c, c);
- LOOP_ALIGNED_U1_A48_SSE3(d, l,
+ LOOP_ALIGNED_U1_A48(d, l,
{ /* UOP */
alpha = *m;
@@ -215,7 +215,7 @@ _op_blend_rel_mas_c_dp_sse3(DATA32 *s EINA_UNUSED, DATA8
*m, DATA32 c, DATA32 *d
const __m128i c_packed = _mm_set_epi32(c, c, c, c);
- LOOP_ALIGNED_U1_A48_SSE3(d, l,
+ LOOP_ALIGNED_U1_A48(d, l,
{ /* UOP */
DATA32 mc = MUL_SYM(*m, c);
diff --git a/src/lib/evas/common/evas_op_blend/op_blend_pixel_color_sse3.c
b/src/lib/evas/common/evas_op_blend/op_blend_pixel_color_sse3.c
index b0c2b84..c97fd2e 100644
--- a/src/lib/evas/common/evas_op_blend/op_blend_pixel_color_sse3.c
+++ b/src/lib/evas/common/evas_op_blend/op_blend_pixel_color_sse3.c
@@ -9,7 +9,7 @@ _op_blend_p_c_dp_sse3(DATA32 *s, DATA8 *m EINA_UNUSED, DATA32
c, DATA32 *d, int
const __m128i c_packed = _mm_set_epi32(c, c, c, c);
- LOOP_ALIGNED_U1_A48_SSE3(d, l,
+ LOOP_ALIGNED_U1_A48(d, l,
{ /* UOP */
DATA32 sc = MUL4_SYM(c, *s);
@@ -69,7 +69,7 @@ _op_blend_pan_c_dp_sse3(DATA32 *s, DATA8 *m EINA_UNUSED,
DATA32 c, DATA32 *d, in
const __m128i c_alpha = _mm_set_epi32(c_a, c_a, c_a, c_a);
const __m128i a0 = _mm_set_epi32(alpha, alpha, alpha, alpha);
- LOOP_ALIGNED_U1_A48_SSE3(d, l,
+ LOOP_ALIGNED_U1_A48(d, l,
{ /* UOP */
*d = ((c 0xff00) + MUL3_SYM(c, *s)) + MUL_256(alpha, *d);
@@ -119,7 +119,7 @@ _op_blend_p_can_dp_sse3(DATA32 *s, DATA8 *m EINA_UNUSED,
DATA32 c, DATA32 *d, in
int alpha;
const __m128i c_packed = _mm_set_epi32(c, c, c, c);
- LOOP_ALIGNED_U1_A48_SSE3(d, l,
+ LOOP_ALIGNED_U1_A48(d, l,
{ /* UOP */
alpha = 256 - (*s 24);
@@ -173,7 +173,7 @@ _op_blend_pan_can_dp_sse3(DATA32 *s, DATA8 *m EINA_UNUSED,
DATA32 c, DATA32 *d,
const __m128i c_packed = _mm_set_epi32(c, c, c, c);
- LOOP_ALIGNED_U1_A48_SSE3(d, l,
+ LOOP_ALIGNED_U1_A48(d, l,
{ /* UOP */
*d++ = 0xff00 + MUL3_SYM(c, *s);
@@ -215,7 +215,7 @@ _op_blend_p_caa_dp_sse3(DATA32 *s, DATA8 *m EINA_UNUSED
[E-devel] NEON detection in configure.ac doesn't seem to work properly
Hi,
I just tried building EFL 1.8 on my Chromebook at it appears that even
though the CPU supports NEON, the code snippet doing NEON detection in
configure.ac fails (using Debian Unstable, GCC 4.8.2):
configure:23270: checking whether to use NEON instructions
configure:23283: gcc -std=gnu99 -c -g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security
-fvisibility=hidden -D_FORTIFY_SOURCE=2 conftest.c 5
In file included from conftest.c:59:0:
/usr/lib/gcc/arm-linux-gnueabihf/4.8/include/arm_neon.h:32:2: error:
#error You must enable NEON instructions (e.g. -mfloat-abi=softfp
-mfpu=neon) to use arm_neon.h
#error You must enable NEON instructions (e.g. -mfloat-abi=softfp
-mfpu=neon) to use arm_neon.h
^
The following patch fixes the issue for me. Does that look OK to you?
In that case, can it be cherry-picked in the efl-1.8 branch?
--- configure.ac2014-01-07 15:25:10.0 +0100
+++ configure.ac2014-01-19 10:12:04.658764527 +0100
@@ -516,6 +516,8 @@
arm*)
build_cpu_neon=yes
AC_MSG_CHECKING([whether to use NEON instructions])
+CFLAGS_save=${CFLAGS}
+CFLAGS=${CFLAGS} -mfpu=neon
AC_TRY_COMPILE([#include arm_neon.h],
[asm volatile (vqadd.u8 d0, d1, d0\n)],
[
@@ -527,6 +529,7 @@
AC_MSG_RESULT([no])
build_cpu_neon=no
])
+CFLAGS=${CFLAGS_save}
;;
esac
Thanks,
--
Albin
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] NEON detection in configure.ac doesn't seem to work properly
Hi Gustavo, On Sun, Jan 19, 2014 at 1:24 PM, Gustavo Sverzut Barbieri barbi...@gmail.com wrote: looks okay to me, do you have commit access? Otherwise I can commit for you I don't have commit access, so I'm happy with you doing the commit :) Thanks, -- Albin -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Issues with Ecore_Audio in efl-1.8
On Mon, Jan 13, 2014 at 1:51 PM, Albin Tonnerre lu...@debian.org wrote: Hi, Hi, I recently try to debug an issue with Ecore_Audio (segfault when running the testsuite, haven't gone to the bottom of that yet) and noticed a couple things that make using it rather difficult: - Some headers are installed depending on PULSE and SNDFILE, but Ecore_Audio.h includes them unconditionally: this causes compile errors when compiling with either PULSE or SNDFILE turned off - It appears that ecore_audio_obj.h uses Eo_Op, which is only exported by the Eo header if EFL_BETA_API_SUPPORT is defined. When compiling EFL, the define is always set so the code compiles just fine, but that's not the case once Ecore_Audio is installed: at that point, nothing defines EFL_BETA_API_SUPPORT but the header still uses it... Ping? I kind of thought it would be interesting to have this fixed in the next stable 1.8 release, since Ecore_Audio is pretty unusable in its current state... -- Albin -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Issues with Ecore_Audio in efl-1.8
Hi, I recently try to debug an issue with Ecore_Audio (segfault when running the testsuite, haven't gone to the bottom of that yet) and noticed a couple things that make using it rather difficult: - Some headers are installed depending on PULSE and SNDFILE, but Ecore_Audio.h includes them unconditionally: this causes compile errors when compiling with either PULSE or SNDFILE turned off - It appears that ecore_audio_obj.h uses Eo_Op, which is only exported by the Eo header if EFL_BETA_API_SUPPORT is defined. When compiling EFL, the define is always set so the code compiles just fine, but that's not the case once Ecore_Audio is installed: at that point, nothing defines EFL_BETA_API_SUPPORT but the header still uses it... Cheers, -- Albin -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ECORE_EVAS_EXTN_CLIENT_ADD / ECORE_EVAS_EXTN_CLIENT_DEL
On Fri, Jan 3, 2014 at 1:05 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Ops! I guess it was a problem when we split ecore_evas into modules, these events should be, indeed, defined in libecore_evas.so, not in the module. I can't commit a fix right now, could someone move the EAPI declaration and ecore_event_new() attribution to ecore_evas.c? As Cedric just pointed out to me, it got fixed by commit e1b12968a54e9bbb3ab9603f9510854a363f72f4 on efl-1.8 and 3e302e7e61abe9c2342e3e891e13df599d5c60b5 on master. Thanks! -- Albin -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] ECORE_EVAS_EXTN_CLIENT_ADD / ECORE_EVAS_EXTN_CLIENT_DEL
Hi, I noticed something strange while working on the Debian packaging for EFL 1.8: the two symbols mentionned in the title are no longer present in libecore-evas.so but are apparently part of the API: they're exported in Ecore_Evas.h Those two variables seem to have been moved to a module by commit 85f8163c3ee5b5d776d94c70ff9fbc667a615b2a , but as far a I can tell moving the actual symbols in an Ecore_Evas module effectively breaks the ABI: any library or application that used this variable will fail to load because the symbols can't be resolved. Similarly, it's not possible to use them in an application since the symbol can't be resolved at link time. Does anyone know what to make of this? Thanks, -- Albin -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [legacy/eina] eina-1.7 01/01: Tests: Link against @EFL_PTHREAD_LIBS@
etrunko pushed a commit to branch eina-1.7. http://git.enlightenment.org/legacy/eina.git/commit/?id=13eb61dacb2cabcc8a5d2fd29703759f69df5c0e commit 13eb61dacb2cabcc8a5d2fd29703759f69df5c0e Author: Albin Tonnerre lu...@debian.org Date: Fri Nov 1 11:25:11 2013 -0200 Tests: Link against @EFL_PTHREAD_LIBS@ Signed-off-by: Eduardo Lima (Etrunko) eduardo.l...@intel.com --- src/tests/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/tests/Makefile.am b/src/tests/Makefile.am index cc37476..f6e7f6b 100644 --- a/src/tests/Makefile.am +++ b/src/tests/Makefile.am @@ -70,7 +70,7 @@ eina_test_simple_xml_parser.c \ eina_test_value.c # eina_test_model.c -eina_suite_LDADD = @CHECK_LIBS@ $(top_builddir)/src/lib/libeina.la @EINA_LIBS@ -lm +eina_suite_LDADD = @CHECK_LIBS@ $(top_builddir)/src/lib/libeina.la @EINA_LIBS@ @EFL_PTHREAD_LIBS@ -lm cxx_compile_test_SOURCES = cxx_compile_test.cxx cxx_compile_test_LDADD = $(top_builddir)/src/lib/libeina.la @EINA_LIBS@ --
[EGIT] [core/efl] master 01/01: ecore_x/xlib/ecore_x_vsync.c uses dlopen and dlsym, but configure.ac only checks for this for the XCB variant. This results in linker errors when using strict linker fl
yoz pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=6b130d8b18e5077f4a5fe0fefe534a73053fcb08
commit 6b130d8b18e5077f4a5fe0fefe534a73053fcb08
Author: Albin Tonnerre lu...@debian.org
Date: Tue Oct 29 23:25:54 2013 +0100
ecore_x/xlib/ecore_x_vsync.c uses dlopen and dlsym, but configure.ac
only checks for this for the XCB variant. This results in linker errors
when using strict linker flags (-Wl,-z,defs)
---
configure.ac | 3 +++
1 file changed, 3 insertions(+)
diff --git a/configure.ac b/configure.ac
index 2060040..413264a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2772,6 +2772,9 @@ if test x${want_x11_xlib} = xyes ; then
AC_DEFINE([HAVE_ECORE_X_XLIB], [1], [Defined to 1 if Xlib is enabled.])
HAVE_ECORE_X_BACKEND=HAVE_ECORE_X_XLIB
+
+ EFL_EVAL_PKGS([ECORE_X])
+ EFL_CHECK_FUNCS([ECORE_X], [dlopen dlsym])
fi
## XCB
--
[E-devel] [PATCH] configure.ac: check for dlopen/dlsym and use -ldl for Ecore_X/Xlib
ecore_x/xlib/ecore_x_vsync.c uses dlopen and dlsym, but configure.ac
only checks for this for the XCB variant. This results in linker errors
when using strict linker flags (-Wl,-z,defs)
---
configure.ac | 3 +++
1 file changed, 3 insertions(+)
diff --git a/configure.ac b/configure.ac
index 2060040..413264a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2772,6 +2772,9 @@ if test x${want_x11_xlib} = xyes ; then
AC_DEFINE([HAVE_ECORE_X_XLIB], [1], [Defined to 1 if Xlib is enabled.])
HAVE_ECORE_X_BACKEND=HAVE_ECORE_X_XLIB
+
+ EFL_EVAL_PKGS([ECORE_X])
+ EFL_CHECK_FUNCS([ECORE_X], [dlopen dlsym])
fi
## XCB
--
1.8.4.rc3
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eet testsuite failures
On Tue, Jan 8, 2013 at 11:18 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Hi Lutin, both seem correct to me. Let's wait for others to chime in, but they should be okay. I'd like to upload those fixes to Debian soon, so now would be a good time for anyone who'd like to object :) -- Albin -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Eet testsuite failures
Hi,
I recently uploaded Eet 1.7.4 to Debian; this was the first version to
have the testsuite enabled and to my suprise, it failed on all
bigendian architectures
(https://buildd.debian.org/status/package.php?p=eetsuite=experimental)
I tried to find the cause of the issue, and it would seem there's a
code path in eet_data_image_lossless_compressed_convert that fails to
appropriately convert the input data to little endian before
compressing it; this data is then uncompressed in
_eet_data_image_decode_inside and, on bigend machines, converted
back to bigend which obviously yields incorrect results.
I've used the following patch to solve the issue, but since I'm no eet
expert I'd gladly appreciate any input :)
diff --git a/src/lib/eet_image.c b/src/lib/eet_image.c
index 7116a3c..5a37bf2 100644
--- a/src/lib/eet_image.c
+++ b/src/lib/eet_image.c
@@ -746,13 +746,26 @@ eet_data_image_lossless_compressed_convert(int
*size,
{
unsigned char *d, *comp;
- int *header, ret, ok = 1;
+ int *header, *bigend_data, ret, ok = 1;
uLongf buflen = 0;
buflen = (((w * h * 101) / 100) + 3) * 4;
ret = LZ4_compressBound((w * h * 4));
if ((ret 0) ((uLongf)ret buflen)) buflen = ret;
-
+
+ if (_eet_image_words_bigendian)
+{
+ int i;
+ int *bigend_data = (int *) malloc(w * h * 4);
+
+ if (!bigend_data) return NULL;
+
+ memcpy(bigend_data, data, w * h * 4);
+ for (i = 0; i w * h; i++) SWAP32(bigend_data[i]);
+
+ data = (const char *) bigend_data;
+}
+
comp = malloc(buflen);
if (!comp) return NULL;
@@ -803,6 +816,7 @@ eet_data_image_lossless_compressed_convert(int
*size,
unsigned int i;
for (i = 0; i 8; i++) SWAP32(header[i]);
+ free(bigend_data);
}
memcpy(d + (8 * sizeof(int)), comp, buflen);
On a related matter, the testsuite also dies with SIGBUS on SPARC due
to what seems to be an arbitrarily-aligned void* used as an int* in
eet_cipher. The following patch fixes the issue for me:
diff --git a/src/lib/eet_cipher.c b/src/lib/eet_cipher.c
index 3317538..4e1433c 100644
--- a/src/lib/eet_cipher.c
+++ b/src/lib/eet_cipher.c
@@ -706,9 +706,13 @@ eet_identity_check(const void *data_base,
return NULL;
/* Get the header */
- magic = ntohl(header[0]);
- sign_len = ntohl(header[1]);
- cert_len = ntohl(header[2]);
+ memcpy(magic,header, sizeof(int));
+ memcpy(sign_len, header+1, sizeof(int));
+ memcpy(cert_len, header+2, sizeof(int));
+
+ magic = ntohl(magic);
+ sign_len = ntohl(sign_len);
+ cert_len = ntohl(cert_len);
/* Verify the header */
if (magic != EET_MAGIC_SIGN)
Please let me know if you want me to rework the patches, submit them
with ChangeLog entries for the stable releases or whatever :)
Cheers,
--
Albin
--
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eet testsuite failures
On Wed, Jan 9, 2013 at 1:27 AM, Leandro Dorileo dori...@profusion.mobi wrote:
Hi,
{
unsigned char *d, *comp;
- int *header, ret, ok = 1;
+ int *header, *bigend_data, ret, ok = 1;
uLongf buflen = 0;
buflen = (((w * h * 101) / 100) + 3) * 4;
ret = LZ4_compressBound((w * h * 4));
if ((ret 0) ((uLongf)ret buflen)) buflen = ret;
-
+
+ if (_eet_image_words_bigendian)
+{
+ int i;
+ int *bigend_data = (int *) malloc(w * h * 4);
Shadowed declaration of bigend_data here.
Oops, correct. That must have crept in while doing some refactoring :)
Obvisouly the first declaration is the one we need to keep, since we
free the pointer later on.
--
Albin
--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] e17: use #!/bin/bash for e_remote since it uses bash-specific features
On Sun, Dec 30, 2012 at 5:14 AM, P Purkayastha ppu...@gmail.com wrote: Are you sure variable substitution (using #, %, etc) is not POSIX? As far I could remember, it is POSIX. I also found it mentioned here, and a couple of other places on Google search: I stand corrected :) Looks like some other forms of variable substitutions aren't in POSIX, but the ones we use actually are. Thanks for pointing this out. There are only two lines in enlightenment_remote which use echo -e and I think in both the lines they are unnecessary. True. I have a couple other patches fixing issues in Eet, I guess I'll just send a patch dropping the echo -e along with that. Cheers, -- Albin -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fun with 0.17.0
On Fri, Jan 4, 2013 at 10:34 AM, Carsten Haitzler ras...@rasterman.com wrote: we upgraded major config version for e17 - thus yes - it gets wiped. Just curious - what was the particular change that required the config to get wiped? Thanks, -- Albin -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] eina-1.7: allow running the testsuite independantly of coverage support
On Sat, Dec 29, 2012 at 2:49 PM, Albin Tonnerre albin.tonne...@gmail.com wrote: It used to be possible to run the testsuite whether coverage was enabled or not; this is very useful for eg. distros who want to automatically run the testsuite without having to compile with coverage support. Most other EFL in the stable branch already allow this (evas, ecore, edje); update Eina to bring it in line with them. I kind of expected our beloved autofoo maintainer to apply that patch, but sadly he has resigned since... Anybody brave enough to pick it up (or at least comment) ? Thanks, -- Albin -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] eina-1.7: allow running the testsuite independantly of coverage support
It used to be possible to run the testsuite whether coverage was enabled
or not; this is very useful for eg. distros who want to automatically
run the testsuite without having to compile with coverage support.
Most other EFL in the stable branch already allow this (evas, ecore,
edje); update Eina to bring it in line with them.
---
Makefile.am | 29 -
configure.ac | 10 +++-
m4/common/efl_coverage.m4 | 62 +
m4/common/efl_tests.m4| 27 +++-
4 files changed, 97 insertions(+), 31 deletions(-)
create mode 100644 m4/common/efl_coverage.m4
diff --git a/Makefile.am b/Makefile.am
index 5ff1896..e67c183 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -42,7 +42,8 @@ m4/common/efl_attribute.m4 \
m4/common/efl_benchmark.m4 \
m4/common/efl_check_funcs.m4 \
m4/common/efl_compiler_flag.m4 \
-m4/common/efl_cpu.m4 \
+m4/common/efl_coverage.m4 \
+m4/common/efl_cpu.m4\
m4/common/efl_doxygen.m4 \
m4/common/efl_examples.m4 \
m4/common/efl_path_max.m4 \
@@ -68,6 +69,20 @@ install-doc:
if EFL_ENABLE_TESTS
+check-local:
+ @./src/tests/eina_suite
+
+else
+
+check-local:
+ @echo reconfigure with --enable-tests
+
+endif
+
+# Coverage report
+
+if EFL_ENABLE_COVERAGE
+
lcov-reset:
@rm -rf $(top_builddir)/coverage
@find $(top_builddir) -name *.gcda -delete
@@ -80,21 +95,21 @@ lcov-report:
genhtml -t $(PACKAGE_STRING) -o $(top_builddir)/coverage/html
$(top_builddir)/coverage/coverage.cleaned.info
@echo Coverage Report at $(top_builddir)/coverage/html
-check-local:
+coverage:
@$(MAKE) lcov-reset
- @./src/tests/eina_suite
+ @$(MAKE) check
@$(MAKE) lcov-report
else
lcov-reset:
- @echo reconfigure with --enable-tests
+ @echo reconfigure with --enable-coverage
lcov-report:
- @echo reconfigure with --enable-tests
+ @echo reconfigure with --enable-coverage
-check-local:
- @echo reconfigure with --enable-tests
+coverage:
+ @echo reconfigure with --enable-tests --enable-coverage
endif
diff --git a/configure.ac b/configure.ac
index d132d15..1775f0e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -553,6 +553,14 @@ EINA_CHECK_MODULE([one-big],[${enable_one_big}],
[one big])
EFL_CHECK_TESTS([eina], [enable_tests=yes], [enable_tests=no])
+EFL_CHECK_COVERAGE([${enable_tests}], [enable_coverage=yes],
[enable_coverage=no])
+EINA_CFLAGS=${EINA_CFLAGS} ${EFL_COVERAGE_CFLAGS} ${EXOTIC_CFLAGS}
+EINA_LIBS=${EINA_LIBS} ${EFL_COVERAGE_LIBS} ${EXOTIC_LIBS}
+if test x$enable_coverage = xyes ; then
+ EINA_CFLAGS=${EINA_CFLAGS} ${EFL_DEBUG_CFLAGS}
+fi
+
+
EFL_CHECK_BENCHMARK([enable_benchmark=yes], [enable_benchmark=no])
EINA_BENCH_MODULE([glib], [${enable_benchmark}], [glib-2.0],
[enable_benchmark_glib=yes], [enable_benchmark_glib=no])
if test -n $CXX test x$enable_benchmark = xyes ; then
@@ -628,7 +636,7 @@ echo Documentation: ${build_doc}
if test x${build_doc} = xyes ; then
echo Installation...: make install-doc
fi
-echo Tests: ${enable_tests} (Coverage:
${efl_enable_coverage})
+echo Tests: ${enable_tests} (Coverage: ${enable_coverage})
echo Examples.: ${enable_build_examples}
echo Tiler Example: ${build_tiler_example}
echo Examples installed...: ${enable_install_examples}
diff --git a/m4/common/efl_coverage.m4 b/m4/common/efl_coverage.m4
new file mode 100644
index 000..85d0321
--- /dev/null
+++ b/m4/common/efl_coverage.m4
@@ -0,0 +1,62 @@
+dnl Copyright (C) 2008 Vincent Torri vtorri at univ-evry dot fr
+dnl That code is public domain and can be freely used or copied.
+
+dnl Macro that check if coverage support is wanted and, if yes, if
+dnl lcov is available.
+
+dnl Usage: EFL_CHECK_COVERAGE(tests [, ACTION-IF-FOUND [,
ACTION-IF-NOT-FOUND]])
+dnl The parameter 'tests' is used if a dependency is needed. If set to yes,
+dnl the dependency is available.
+dnl Defines EFL_COVERAGE_CFLAGS and EFL_COVERAGE_LIBS variables
+dnl Defines the automake conditionnal EFL_ENABLE_COVERAGE
+
+AC_DEFUN([EFL_CHECK_COVERAGE],
+[
+
+dnl configure option
+
+AC_ARG_ENABLE([coverage],
+ [AC_HELP_STRING([--enable-coverage], [enable coverage profiling
instrumentation @:@default=disabled@:@])],
+ [
+if test x${enableval} = xyes ; then
+ _efl_enable_coverage=yes
+else
+ _efl_enable_coverage=no
+fi
+ ],
+ [_efl_enable_coverage=no])
+
+AC_MSG_CHECKING([whether to use profiling instrumentation])
+AC_MSG_RESULT([$_efl_enable_coverage])
+
+dnl lcov check
+
+if test x$_efl_enable_coverage = xyes test ! x$1 = xyes ; then
+ AC_MSG_WARN([Coverage report requested but tests not being built, disable
profiling instrumentation.])
+ AC_MSG_WARN([Run configure with --enable-tests])
+ _efl_enable_coverage=no
+fi
+
+if test x$_efl_enable_coverage = xyes ; then
+
[E-devel] [PATCH] e17: use #!/bin/bash for e_remote since it uses bash-specific features
enlightenment_remote uses at least variable substitution (${var%%.*})
and options (echo -e) that are not guaranteed to be available in
stricter (wrt. what's in POSIX) shell implementations, which may lead to
malfunction. Running the script using bash ensures things work as
intended.
---
data/tools/enlightenment_remote |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/data/tools/enlightenment_remote b/data/tools/enlightenment_remote
index 45295bb..a5e5d74 100644
--- a/data/tools/enlightenment_remote
+++ b/data/tools/enlightenment_remote
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
#
# See the function show_help_new_tool in order to know more about this tool
--
1.7.10.4
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122912
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] e17: use #!/bin/bash for e_remote since it uses bash-specific features
On Sat, Dec 29, 2012 at 6:30 PM, Brian 'morlenxus' Miculcy morlen...@gmx.net wrote: Hm, i suggest to use #!/usr/bin/env bash The common usage for shell scripts seems to be /bin/$SHELL (since unlike perl or python there tends not be several competing versions of a given shell interpreter), but feel free to use whatever you think is appropriate :) Cheers, -- Albin -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ABI break in eina ?
On Mon, Nov 14, 2011 at 1:22 AM, Carsten Haitzler ras...@rasterman.com wrote: On Sun, 13 Nov 2011 19:25:48 +0100 (CET) Vincent Torri vto...@univ-evry.fr said: comparison of symbols of eina 1.0.0 and 1.0.99 shows no exported symbols removed. only added. Yup. If memory serves, the function I had an issue with was eina_array_clean, which was moved from a symbol to header-exported inline function a while back. I don't remember exactly when this happened, but I think it was between 1.0.0 beta and the actual 1.0.0 (though it still technically is an ABI break, which is why I still export that symbol in the packages. heh.) Cheers, -- Albin Tonnerre -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] about removing trailing whitespaces
On Sun, 19 Jun 2011 12:38 +0200, Vincent Torri wrote : Hey another idea about trailing whitespaces : what about adding a rule in the toplevel Makefile.am, named for example remove-ws, that call find with a sed expression. I'll add it to Evil and test it a bit, and if nobody complains, i'll add it to the EFL + e. While it is nice to get rid of trailing whitespaces, I think that actively removing them periodically does more harm than good. In particular, it adds a lot of noise in the history and makes it harder to compare different revisions. If we indeed want to get rid of them, I'd be much happier if the SVN server simply rejected commits containing them (the same holds true for formatting - it's much better to ask people to submit properly formatted patches rather than going on a reformatting spree every now and then) Cheers, -- Albin Tonnerre -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 xdg menus
On Tue, Mar 22, 2011 at 9:13 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Hi all, Recently I had to do a new install and that's the time when you realize shortcomings exist :-) Â For instance I use Gentoo and we don't ship gnome-menus or kde-similar by default, so the result is an empty applications menu. Google reminded me of http://wiki.enlightenment.org/index.php/E17_and_Efreet with hints on how to hack around it. Not good if we're willing to release. Given that pulling in gnome-menus will bring in lots of unneeded stuff just for a handful of .directory or .menu, why not create our own and install it with E17 or Efreet? We can get either Gnome or KDE files and derive our own, that is always installed and we default to it. Comments, suggestions? That's what I've been doing in Debian for ages, and I completely agree with it. And please, *please* don't ship it with Efreet. It has nothing do there and rather belongs with E itself. Cheers, -- Albin Tonnerre -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore tests fail with beta3 tarballs
On Sun, 19 Dec 2010 09:11 +0100, Vincent Torri wrote : tests are for developpers, not packagers That is terribly wrong. Packagers care about testsuites for one simple reason: as thoroughly as developers may be testing the code, that will never guarantee proper behaviour on the system on which the code is built. When creating packages for Debian, I /do/ care about the testsuites because the testsuite not failing is the only reliable thing telling me the lib is not utterly broken on the system it is being built on. I understand users not listening or unwilling to fix the suite to fit their needs is a pain, but let's not make it an even greater pain for people who just want to use it and manage to. Things have improved a lot as far as packaging is concerned in the last months, and this is clearly a step backwards. Please reconsider your decision. Cheers, -- Albin Tonnerre signature.asc Description: Digital signature -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore tests fail with beta3 tarballs
On Sun, 19 Dec 2010 22:14 +0900, Carsten Haitzler wrote : On Sun, 19 Dec 2010 10:28:20 +0100 Albin Tonnerre lu...@debian.org said: On Sun, 19 Dec 2010 09:11 +0100, Vincent Torri wrote : tests are for developpers, not packagers That is terribly wrong. Packagers care about testsuites for one simple reason: as thoroughly as developers may be testing the code, that will never guarantee proper behaviour on the system on which the code is built. When creating packages for Debian, I /do/ care about the testsuites because the testsuite not failing is the only reliable thing telling me the lib is not utterly broken on the system it is being built on. I understand users not listening or unwilling to fix the suite to fit their needs is a pain, but let's not make it an even greater pain for people who just want to use it and manage to. Things have improved a lot as far as packaging is concerned in the last months, and this is clearly a step backwards. tests are for developers so when they modify code they can check they didn't break anything. packagers can't do much with a test suite. At the very least, they can notice the testsuite is failing and investigate possible issues (and report them when/if approriate). does the linux kernel have a test suite that is run when people build packages? does xorg have one? i can continue with the list. they don't. Glibc does have one. GCC has one. And they do find bugs - especially tricky, architecture-specific ones. any test suites are part of the development cycle not the packaging cycle, but as they are in the sr4c tree, some gentoo devs seem to think that they should work as part of their ebuild (which is packaging). this is not the case. Are you purposedly ignoring my point here? I just explained why those suites are useful in the process of building packages. And not only to Gentoo devs, since I've been using them pretty much since they've been around. Besides, moving them away from src/ is basically making them harder for just about everyone, not just packagers. As bored as you might be by some people's behaviour, this is wrong. I think you did get your point across fairly clearly, but let's be realistic: you're not doing anyone - not even yourself - a favour by moving the tests away. Cheers, -- Albin Tonnerre signature.asc Description: Digital signature -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore tests fail with beta3 tarballs
On Sun, 19 Dec 2010 19:49 +0100, Vincent Torri wrote : On Sun, 19 Dec 2010, Albin Tonnerre wrote: On Sun, 19 Dec 2010 09:11 +0100, Vincent Torri wrote : tests are for developpers, not packagers That is terribly wrong. Packagers care about testsuites for one simple reason: as thoroughly as developers may be testing the code, that will never guarantee proper behaviour on the system on which the code is built. When creating packages for Debian, I /do/ care about the testsuites because the testsuite not failing is the only reliable thing telling me the lib is not utterly broken on the system it is being built on. I understand users not listening or unwilling to fix the suite to fit their needs is a pain, but let's not make it an even greater pain for people who just want to use it and manage to. Things have improved a lot as far as packaging is concerned in the last months, and this is clearly a step backwards. Please reconsider your decision. are you packaging the test suite ? I'm not sure what you mean exactly, but anyway: the testsuite is run when the package is built for at least eina and ecore. Cheers, -- Albin Tonnerre -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore tests fail with beta3 tarballs
On Sun, 19 Dec 2010 20:02 +0100, Vincent Torri wrote : I understand users not listening or unwilling to fix the suite to fit their needs is a pain, but let's not make it an even greater pain for people who just want to use it and manage to. Things have improved a lot as far as packaging is concerned in the last months, and this is clearly a step backwards. keeping the unit tests inside the source code is a step backward ? Because that's what I want. Putting the unitt tests outside makes impossible (at least, i don't see anyway of doing that) coverage support. And that is for me a big step backward. I might have been misleading. I completely agree that tests should remain within the source tree - that's why I wrote that email in the first place :) Cheers, -- Albin Tonnerre -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore tests fail with beta3 tarballs
On Sat, 18 Dec 2010 17:14 +0100, Thomas Sachau wrote : Attached is a build log with the failures. Are you by any chance building on a headless machine, or in a tty ? If so, that failure is expected - the test fails whenever ecore can't reach the X server. I ended up disabling this test completely for the Debian packages. Cheers, -- Albin Tonnerre -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e install locations
On Mon, 30 Aug 2010 12:39 +0900, Carsten Haitzler wrote : the problem with PREFIX/share/doc is that this will conflict with distro policies on doc dir naming most likely. distros like debian and ubuntu qand that docdir to be the package name. almost nothing installs docs from src that i know of, so packagers populate those doc dirs with a set of standard files etc. from the src tree in a standard way. the alternative will be yet another flame-fest involving debian and ubuntu and other distro packagers and their policies and them having to patch e's build scripts/makeifles to not conflict with distro policies. As the maintainer of the Debian packages, I'm not going to start any flamewar. Even better: I agree with Michael here, and think that this move would make sense. Cheers, -- Albin Tonnerre -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: lucas IN trunk: E16/e/src PROTO/eon/src/lib/layout ecore/src/lib/ecore_win32 ecore/src/lib/ecore_wince edje/src/lib evas/src/lib/cache exalt/src/lib
On Fri, 27 Aug 2010 00:08 +0200, Vincent Torri wrote : On Thu, 26 Aug 2010, Michael Jennings wrote: No, that's the whole point. Every instance that was patched needs to be examined and probably fixed. Reverting it doesn't accomplish anything either. that patch is NOT good, hence it should not be in. A mail showing where the problems are, without modifying the code in svn is far way better than committing something wrong. I don't have any strong opinion as to whether this should be reverted or not, but I do agree with Vincent that sending the patch to the ML saying hey, those places probably need fixing would have been a far nicer approach. Cheers, -- Albin Tonnerre -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: mej IN trunk/eterm: Eterm/src Eterm/utils libast/src libast/test spite
On Mon, 23 Aug 2010 15:28 -0300, Lucas De Marchi wrote : On Mon, Aug 23, 2010 at 2:55 PM, Enlightenment SVN no-re...@enlightenment.org wrote: Log:  Revert coccinelle changes.  Using !! instead of != NULL results in significantly and unacceptably  less readable code, and I refuse to accept those changes.  Unfortunately, since they were all done at once, I have to revert the  whole thing.  Oh well. :( Did you revert the whole thing? Why do you have to do so? At least for EFL, it should be like this as agreed on mailing list / irc The particular change Michael is unhappy with is != NULL = !!, and he did express his disagreement about it (and so did I, FWIW). That being said, I'm not going to fight over it if the general opinion is that it's fine. Cheers, -- Albin Tonnerre -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Using -Wall -Wextra -Wno-unused-parameter
On Wed, 18 Aug 2010, Tom Hacohen wrote: On Wed, Aug 18, 2010 at 10:27 PM, Vincent Torri vto...@univ-evry.fr wrote: EFL_COMPILER_FLAG([-Wall]) adds -Wall to CFLAGS m4_ifdef([v_mic] ***) checks if v_mic is used (that is if the micro version of eina is defined. I did that in order to add these flags only when in developper mode (not in release mode) But you can use EFL_COMPILER_FLAG without m4_ifdef. Just like that: EFL_COMPILER_FLAG([-Wall]) Cool. Is there a standard way to choose between developer mode to release mode in autotools? (except for what you did with the versions) Maybe we should consider adding that as well. better ask raster, as i'm not sure exactly which part of the version is not used for the release mode IIRC, v_mic is always used. The development part is v_rev - the current SVN revision, which is m4_undefine'd for releases. Cheers, -- Albin Tonnerre -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: lucas IN trunk/embryo/src: bin lib
On Mon, 16 Aug 2010 15:22 -0700, Michael Jennings wrote :
On Monday, 16 August 2010, at 19:15:02 (-0300),
Lucas De Marchi wrote:
6) i = a == NULL;= i = !a;
7) i = a != NULL;= i = !!a;
Those four are valid also for while loops.
Eina_Bool func(char *a)
{
8)return a == NULL;= return !a;
9)return a != NULL;= return !!a;
}
int func2(Eina_Bool b) { return 0; }
...
char *a;
10) func2(a == NULL); = func2(!a);
11) func2(a != NULL); = func2(!!a);
Those significantly reduce readability IMHO.
I agree with Michael here.
Cheers,
--
Albin Tonnerre
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Insecure SVG loader test
On Sun, 15 Aug 2010 07:00 +0200, vto...@univ-evry.fr wrote : Quoting Albin Tonnerre albin.tonne...@gmail.com: you can test that only at runtime and not at configure time, as someone can add the svg loader (as a shared lib) after an installation of evas. So it can only be after testing a svg file, I think. There's no doubt about that. The question was whether the test file should be shipped with e17, or created on the fly. In both cases, we end up doing runtime checks though. Cheers, -- Albin Tonnerre -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Insecure SVG loader test
On Sat, 14 Aug 2010 23:13 +0200, Joerg Sonnenberger wrote : hi all, in src/bin/e_main.c there is this wonderful gem _e_main_test_svg_loader. Writting a hard-coded XML file to a known location is just asking for trouble. It basically means that anyone with write access to /tmp can make the E17 user overwrite a file with permissions of the user. It also creates race conditions for multiple users. Thanks for sending this. I think I mentionned it on IRC at one point, and then forgot about it. Any reason why this piece of code is needed at all? That's a little bit complicated: - The freedesktop.org spec says that SVG icons lookup is optional, but if it is supported, then the lookup order is png - svg - xpm - If efreet returns an SVG icon when SVG rendering is not compiled in evas, then you get no icon where an xpm icon (which could have been rendered correctly) might have existed. - Since there is no way to ask evas if SVG support is available (which I think is a mistake), you need to do some kind of runtime detection. - Right now, the only practical way to do that is using some voodoo: create a dummy file and try to load it. To sum it up: it's here because such kind of tests are the only way to check whether Evas supports a particular format. Or at least, so were they when the patch got commited. Cheers, -- Albin Tonnerre -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Insecure SVG loader test
On Sat, 14 Aug 2010 23:46 +0200, Joerg Sonnenberger wrote : On Sat, Aug 14, 2010 at 11:35:13PM +0200, Albin Tonnerre wrote: - If efreet returns an SVG icon when SVG rendering is not compiled in evas, then you get no icon where an xpm icon (which could have been rendered correctly) might have existed. OK - Since there is no way to ask evas if SVG support is available (which I think is a mistake), you need to do some kind of runtime detection. Yes, that's bad. - Right now, the only practical way to do that is using some voodoo: create a dummy file and try to load it. Why not use install the dummy file to a known location and try loading it that way? share/enlightenment/data/icons/dummy.svg or so. I can't recall, and like I said I'd much rather have Evas being able to expose the information. But if it's not going to happen, then the file should either be shipped with e17 or created in a more secure manner (I'd prefer that, but that's a matter of personal taste). Cheers, -- Albin Tonnerre -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/e/src/bin
On Tue, Apr 27, 2010 at 3:30 PM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Â no more e_fm_open - use dbus... eg: Â dbus-send --session --dest=org.enlightenment.FileManager /org/enlightenment/FileManager org.enlightenment.FileManager.OpenDirectory string:'/home/raster' Author: Â Â Â raster Date: Â Â Â Â 2010-04-27 06:30:33 -0700 (Tue, 27 Apr 2010) New Revision: 48362 Removed: Â trunk/e/src/bin/e_fm_open.c Modified: Â trunk/e/src/bin/e_ipc.c I guess you also need to fix Makefile.am Cheers, Albin -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Dumping Exebuf in favor of Everything?
On Sat, 10 Apr 2010 18:43 -0300, Gustavo Sverzut Barbieri wrote : Hi all, I'd like to call a voting to dump Exebuf and use Everything by default. It is fancier, it is more powerful and i see no reason to not do it. exebuf can be then disabled or just removed from SVN, as well as its conf_exebuf. Speaking of which… I just recompiled from SVN, and everything (which I have been using as a replacement for exebuf for a long time) now uses modules. That's all nice and awesome, but please do enable those modules by default. Updating e17 and not being able to do anything with everything (heh) anymore is just plain annoying. Cheers, -- Albin Tonnerre -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Dumping Exebuf in favor of Everything?
On Sun, 11 Apr 2010 16:19 +0200, hannes.janet...@gmail.com wrote : On Sun, Apr 11, 2010 at 3:04 PM, Albin Tonnerre albin.tonne...@gmail.com wrote: On Sat, 10 Apr 2010 18:43 -0300, Gustavo Sverzut Barbieri wrote : Hi all, I'd like to call a voting to dump Exebuf and use Everything by default. It is fancier, it is more powerful and i see no reason to not do it. exebuf can be then disabled or just removed from SVN, as well as its conf_exebuf. Speaking of which… I just recompiled from SVN, and everything (which I have been using as a replacement for exebuf for a long time) now uses modules. That's all nice and awesome, but please do enable those modules by default. Updating e17 and not being able to do anything with everything (heh) anymore is just plain annoying. The modules are enabled by default in standard profile. Dont know if and how one should update old configs automatically. I know it's possible to add new default values on upgrades, but I don't whether that's also true for modules. Raster: is there any way to make a module automatically loaded when upgrading to a new version ? Regards, -- Albin Tonnerre -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] Efreet: move efreet_desktop_cache_create out of the path
This binary is just an internal helper, and isn't expected to be run by anything but efreet. Therefore, let's emphasize this and keep it out of the path by installing it in PACKAGE_LIB_DIR/efreet/ Signed-off-by: Albin Tonnerre lu...@debian.org --- src/bin/Makefile.am |3 ++- src/lib/Makefile.am |2 +- src/lib/efreet_desktop.c |4 ++-- 3 files changed, 5 insertions(+), 4 deletions(-) diff --git a/src/bin/Makefile.am b/src/bin/Makefile.am index a516ebe..71886c1 100644 --- a/src/bin/Makefile.am +++ b/src/bin/Makefile.am @@ -9,7 +9,8 @@ AM_CPPFLAGS = \ -DPACKAGE_DATA_DIR=\$(datadir)/$(PACKAGE)\ \ @EFREET_CFLAGS@ -bin_PROGRAMS = \ +internal_bindir=$(libdir)/efreet +internal_bin_PROGRAMS = \ efreet_desktop_cache_create efreet_desktop_cache_create_LDADD = \ diff --git a/src/lib/Makefile.am b/src/lib/Makefile.am index f3d1c6c..eb4b7fc 100644 --- a/src/lib/Makefile.am +++ b/src/lib/Makefile.am @@ -31,7 +31,7 @@ dist_installed_headers_DATA = $(EFREETHEADERS) Efreet_Mime.h Efreet_Trash.h libefreet_la_SOURCES = $(EFREETSOURCES) libefreet_la_CPPFLAGS = \ -DPACKAGE_DATA_DIR=\$(datadir)\ \ --DPACKAGE_BIN_DIR=\$(bindir)\ \ +-DPACKAGE_LIB_DIR=\$(libdir)\ \ -I$(top_builddir)/src/lib \ -I$(top_srcdir)/src/lib \ @EFL_EFREET_BUILD@ \ diff --git a/src/lib/efreet_desktop.c b/src/lib/efreet_desktop.c index f202f53..06c5779 100644 --- a/src/lib/efreet_desktop.c +++ b/src/lib/efreet_desktop.c @@ -289,7 +289,7 @@ efreet_desktop_init(void) efreet_desktop_listen_changes(); -ecore_exe_run(PACKAGE_BIN_DIR /efreet_desktop_cache_create, NULL); +ecore_exe_run(PACKAGE_LIB_DIR /efreet/efreet_desktop_cache_create, NULL); } @@ -2384,7 +2384,7 @@ efreet_desktop_update_cache_job(void *data __UNUSED__) if (efreet_desktop_exe_lock 0) return; /* TODO: Retry update cache later */ if (flock(efreet_desktop_exe_lock, LOCK_EX | LOCK_NB) 0) goto error; -efreet_desktop_exe = ecore_exe_run(PACKAGE_BIN_DIR /efreet_desktop_cache_create, NULL); +efreet_desktop_exe = ecore_exe_run(PACKAGE_LIB_DIR /efreet/efreet_desktop_cache_create, NULL); if (!efreet_desktop_exe) goto error; return; -- 1.7.0.4 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Include hour and minute in rpm spec release tags
On Wed, Apr 7, 2010 at 1:27 PM, Rui Miguel Silva Seabra r...@1407.org wrote: Again: I have no intention of treading on your toes, you're making it personal and I have more than once pointed out that there is nothing of the such. I don't think anyone is trying to make it personal. You think that adding HHMM to the spec files would be helpful, Michael doesn't. I guess you'll just have to agree to disagree on this. Cheers, Albin -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: rui trunk/elmdentica/src
On Sun, 28 Feb 2010 12:07 -0300, Gustavo Sverzut Barbieri wrote : On Sun, Feb 28, 2010 at 11:44 AM, Rui Miguel Silva Seabra r...@1407.org wrote: Em 28-02-2010 14:37, Vaudano Luca escreveu: Just out of curiosity, why is glib not advised? You're taking it the wrong way. The advice was to use the functionality that is in EFL instead of picking up the same functionality from external libraries. Actually some things are not even EFL, but simple POSIX calls like strdup() instead of g_strdup(), asprintf() instead of g_strdup_printf() This not being against fair glib usage, but those are abuses that don't need to exist and Rui kindly fixed those. I wouldn't consider using g_strdup_printf vs. asprintf an abuse. asprint is a GNU-specific extension, and is not guaranteed to be available. g_strdup_printf, OTOH, is part on the glib API, which guarantees that it's available on a fair - and defined - set of plartforms. That being said, please note that I'm not arguing against the change. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] SVN cleanup for impending release
On Tue, 02 Feb 2010 18:59 -0200, Gustavo Sverzut Barbieri wrote : What's good in keeping them? SVN's version of Attic? :-) Again, I see no other projects keeping attic stuff... see kde3 stuff, gnome, kernel... once things are gone, they're gone! just svn log will show they ever existed. If you wish we could create a Dead_Projects wiki page and list the revision each directory was removed so one can easily recover it. Yes, please. That would really help. There's no point in keeping dead code around, it just makes things harder for everyone. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster IN trunk/eina: . src/include src/lib src/modules/mp/buddy src/modules/mp/chained_pool src/modules/mp/ememoa_fixed src/modules/mp/ememoa_unknown src/modules/mp/fixed_bitmap
On Tue, 26 Jan 2010 07:54 -0800, Enlightenment SVN wrote : Log: eina - does modules like the rest of efl, so it's able to be installed with multiple versions at the same time. eventually will neeed to also include major number in release name too. /* dynamic backends */ - _modules = eina_module_list_get(NULL, PACKAGE_LIB_DIR /eina-VMAJ/mp/, 0, NULL, NULL); + _modules = eina_module_arch_list_get(NULL, PACKAGE_LIB_DIR /eina/modules/mp, MODULE_ARCH); - path = eina_module_environment_path_get(HOME, /.eina-VMAJ/mp/); - _modules = eina_module_list_get(_modules, path, 0, NULL, NULL); + path = eina_module_environment_path_get(HOME, /.eina/mp/modules/mp); + _modules = eina_module_arch_list_get(_modules, path, MODULE_ARCH); if (path) free(path); Err. The major number was alredy present and consistent with the naming scheme for the eina includes...You just reverted it. Regards, -- Albin Tonnerre -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Ecore_Job is gone (was: merge ecore job and txt into ecore?)
Hi there, SVN rev. 45570 merged all of ecore_job into ecore. While I updated everything in our SVN to cope with this change (thanks cedric for catching some of my mistakes), if you're using ecore_job in your projects, you need to update your code. If you were using ecore previously, all you need to do is remove all checks for ecore-job in configure.ac, as well as stop including Ecore_Job.h and stop calling ecore_job_init/ecore_job_shutdown. If you were using only ecore-job, you now need to check for ecore instead of ecore-job, include Ecore.h instead of Ecore_Job.h and call ecore_init/ecore_shutdown instead of ecore_job_init/shutdown Regards, -- Albin Tonnerre -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: quaker IN trunk/devs: . romanhornik
On Mon, 25 Jan 2010 15:22 -0600, Stephen Houston wrote : On Jan 25, 2010, at 3:15 PM, Albin Tonnerre albin.tonne...@gmail.com wrote: On Mon, 25 Jan 2010 15:07 -0600, Stephen Houston wrote : On Jan 25, 2010, at 2:57 PM, Vincent Torri vto...@univ-evry.fr wrote: On Mon, 25 Jan 2010, Stephen Houston wrote: I don't think this is a problem... If we are interested in widespread use of our software, then packages/packagers are an essential part of the process. it's not our job to package our libs and binaries... It's the job of the package managers of the different distros. They have their own repositories. Vincent Bit of a different situation when it's software in a versioning control tree that is constantly changing and hasn't been released in 10 years. Please, let's not turn this into yet another release-related troll. Several distributions have official packages for e17. Even though they don't provide all the applications that are in SVN, I think that's a pretty good step forward. Ummm? Chill out. No one is asking when or questioning whether the software should be released. Slow down and read what I said in context. Due to the fact of the release circumstances, it makes packaging a different situation. Completely relevant. I've been maintaining all the EFL-related package in Debian for the past 2 years. Believe me, I completely understand what it's like dealing with this situation. While I acknowledge that this used to be a PITA (things improved quite a bit recently), I'm pretty convinced that maintaing my packages in the SVN would have made my work even harder. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: quaker trunk/packaging/debian/extras/entrance
On Sun, 24 Jan 2010 09:17 -0800, Enlightenment SVN wrote : Log: Entrance - fix deb stuff DEB_MAKE_CLEAN_TARGET := distclean -DEB_CONFIGURE_EXTRA_FLAGS := --disable-rpath +DEB_CONFIGURE_EXTRA_FLAGS := --disable-rpath --with-xbin=/usr/bin clean:: [ ! -f Makefile ] || make distclean AFAIK, /usr/bin is pretty common path for the X binary these days. What about fixing configure.ac instead? Regards, -- Albin Tonnerre -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] merge ecore job and txt into ecore?
On Sun, 24 Jan 2010 00:02 +0100, Vincent Torri wrote : to summarize: * ecore_txt moved in eina I think we'll just have to agree to disagree here :) * ecore_job merged in ecore I've made a patch doing this. * nothing done for ecore_file (raster wants it in ecore) Do you mean ecore_input here ? I would like ecore_input_evas being not merged into ecore_input. The reason is that if so, ecore_input depends on evas. As ecore_x and other graphic subsystems depends on ecore_input, that would mean that ecore_x would then depend on evas, which is not good. Merging ecopre_input_evas into ecore_input is not the question. I'm more curious about merging ecore_input in ecore. Since englebass split the evas-specific parts out, it means that ecore_input is basically a handful functions only relying on ecore. Hence, I don't see any clear rationale as to why we should keep it separate. Regards, -- Albin Tonnerre -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] merge ecore job and txt into ecore?
On Fri, 22 Jan 2010 11:32 +0100, Cedric BAIL wrote : Good idea to start discussing about ecore. On Fri, Jan 22, 2010 at 1:32 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Thu, Jan 21, 2010 at 10:25 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Why ecore_job and ecore_txt are split? They are so stupid that is should go into main ecore. Anyone with time to merge this and fix all apps that pkg-config ecore-job or ecore-txt to use simply ecore? If there's a general agreement that moving ecore_txt, ecore_job and ecore_input to ecore is a good thing, I'm willing to work on it. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] merge ecore job and txt into ecore?
On Fri, 22 Jan 2010 23:19 +0100, Vincent Torri wrote : On Fri, 22 Jan 2010, Gustavo Sverzut Barbieri wrote: On 1/22/10, Albin Tonnerre albin.tonne...@gmail.com wrote: On Fri, 22 Jan 2010 11:32 +0100, Cedric BAIL wrote : Good idea to start discussing about ecore. On Fri, Jan 22, 2010 at 1:32 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Thu, Jan 21, 2010 at 10:25 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Why ecore_job and ecore_txt are split? They are so stupid that is should go into main ecore. Anyone with time to merge this and fix all apps that pkg-config ecore-job or ecore-txt to use simply ecore? If there's a general agreement that moving ecore_txt, ecore_job and ecore_input to ecore is a good thing, I'm willing to work on it. i believe nobody will disagree. if you do, also do for ecore_str.h move to eina. As cedric said. why not moving ecore_txt to eina, btw ? As far as I understand it, eina is about providing data types. IMHO neither ecore_str nor ecore_txt fit in that category. Cheers, -- Albin Tonnerre signature.asc Description: Digital signature -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ubuntu packages
On Tue, 05 Jan 2010 08:39 +0800, Tom Haste wrote : Hey chums! As some of you might be aware, theres been a bit of back and forwards on Ubuntu launchpad bug on getting python-efl ( EFL) into the official ubuntu forums. I know its hardly any of our responsibility but I know some of the package folks from Debian would be interested in this. It also provides distribution of EFL in the biggest linux distro ever (Which would be quite nice). Lets leave out the fact that its still unreleased software, and see it as an opportunity to generate some usage, bugs, and more importantly, developers. Anyway, heres the Packaging Guidlines for ubuntu. https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages It says... Debian Import Freeze for lucid is on February 11, 2010. which gives us a month to see if we can get the debain experimental packages into Ubuntu. They're no longer in Debian experimental, but in unstable. If you want the packages to be in Ubuntu, the best way to achieve that is to ask for a sync report, so that the packages from Debian are imported into Ubuntu. AFAIK there should be no ubuntu-specific changes, so there's no reason not to sync directly. Please see https://wiki.ubuntu.com/SyncRequestProcess Id be happy to put in some effort to getting it in. Anyone else have experience in getting packages into Debian/Ubuntu? Sure. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Emotion failing to configure on latest Ubuntu.
On Tue, 05 Jan 2010 13:02 +1000, David Seikel wrote : Apparently emotions checking of the version of gstreamer is getting confused with the version numbers used by the latest Ubuntu. checking for GSTREAMER... configure: error: Package requirements (gstreamer-0.10 = 0.10.2 gstreamer-plugins-base-0.10 = 0.10.1 evas = 0.9.9) were not met: No package 'gstreamer-plugins-base-0.10' found Version 0.10.25 of both required gstreamer packages is in fact installed. I'm not upto fixing this quickly, as I lack knowledge in how version numbers are compared. gstreamer-plugins-base-0.10 is part of libgstreamer-plugins-base0.10-dev, are you sure you installed it? Here on Ubuntu Karmic, it seems to work correctly once installed: [7:45 ~]% pkg-config --exists 'gstreamer-plugins-base-0.10 = 0.10.1'; echo $? 0 Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns IN trunk/efreet/src: bin lib
On Thu, 24 Dec 2009 12:16 +0100, Vincent Torri wrote : On Thu, 24 Dec 2009, Brett Nash wrote: Also, doing sizeof() is a compiler directive so does not incur any performance hits...plus it matches the rest of EFL. using a macro does not involved any performance hit too as PATH_MAX is directly replaced by its value before the compilation. Yes, but it's a damn big performance hit when someone changes one size, but not the other and the whole thing falls over in a steaming heap... ;-) if someone changes the size of the buffer without looking how the buffer is used, it should stop coding and try to be cabinetmaker of fisherman Of course. However, not using the buffer size directly avoids unnecessary code changes, no matter how carefully you check the code. So far, I've yet to see any reasonable argument as to why you're seemingly so hostile to this change. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Using the release name in paths in e17
On Sat, 05 Dec 2009 15:58 +0200, Tom Hacohen wrote : Hey, ATM there's that weird module arch in the path of the modules: MODULE_ARCH=$(host_os)-$(host_cpu)-$(release) For instance, if I want to be able to write my own app with pages for the wizard module, I can't. I'll have to manually set the module arch if I want it to install to the proper place (because of the release version). I don't get what is it for anyway, I can hardly get the module_arch in general, but at least, if you use that, what's the release for? making sure people don't stuff modules after backwards compatibility is broken? In conclusion I see this as a bug in design that's blocking us from effectively installing 3rd party modules. As annoying as you may find it, that's not a blocking issue. You can get the release number using `pkg-config --variable=release enlightenment` Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Fwd: embryo: FTBFS on hurd-i386]
On Sun, 22 Nov 2009 12:33 +1100, Carsten Haitzler wrote : On Sat, 21 Nov 2009 16:44:54 +0100 Albin Tonnerre albin.tonne...@gmail.com said: On Sun, 05 Jul 2009 12:45 -0300, Gustavo Sverzut Barbieri wrote : On Sun, Jul 5, 2009 at 9:22 AM, Albin Tonnerrealbin.tonne...@gmail.com wrote: Hi there, Here's a bug report that got submitted on the Debian BTS, with a patch allowing embryo to compile on debian/hurd (and more generally on systems were PATH_MAX is udefined). I could apply this patch, but I fear it's nothing compared to the whole EFL where PATH_MAX is heavily used. I guess that a better option is to define PATH_MAX = 4096/1024/something-user-specified in config.h, which should be included in every source file anyway. With that new .m4, we could just copy it to all efl projects and call the macro from configure.ac and fix them in the same way. Would the following patch do the trick? hmmm... platforms that dont have a PATH_MAX. ew. well it'd need to not just be added, but be used and everything made sure to include config.h if it doesnt explicitly or implicitly yet Sure, but at least that's a first step. Just wanted to make sure you were OK with the patch before spending more time on this. Regards, -- Albin Tonnerre -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Fwd: embryo: FTBFS on hurd-i386]
On Sun, 22 Nov 2009 12:33 +1100, Carsten Haitzler wrote : On Sat, 21 Nov 2009 16:44:54 +0100 Albin Tonnerre albin.tonne...@gmail.com said: On Sun, 05 Jul 2009 12:45 -0300, Gustavo Sverzut Barbieri wrote : On Sun, Jul 5, 2009 at 9:22 AM, Albin Tonnerrealbin.tonne...@gmail.com wrote: Hi there, Here's a bug report that got submitted on the Debian BTS, with a patch allowing embryo to compile on debian/hurd (and more generally on systems were PATH_MAX is udefined). I could apply this patch, but I fear it's nothing compared to the whole EFL where PATH_MAX is heavily used. I guess that a better option is to define PATH_MAX = 4096/1024/something-user-specified in config.h, which should be included in every source file anyway. With that new .m4, we could just copy it to all efl projects and call the macro from configure.ac and fix them in the same way. Would the following patch do the trick? hmmm... platforms that dont have a PATH_MAX. ew. well it'd need to not just be added, but be used and everything made sure to include config.h if it doesnt explicitly or implicitly yet Or, as initially suggested in the debian bugreports, we could just stop using PATH_MAX and use dynamic allocations. The bug submitter submitted patches for that. What do you prefer ? Regards, -- Albin Tonnerre -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Fwd: embryo: FTBFS on hurd-i386]
On Sun, 05 Jul 2009 12:45 -0300, Gustavo Sverzut Barbieri wrote :
On Sun, Jul 5, 2009 at 9:22 AM, Albin Tonnerrealbin.tonne...@gmail.com
wrote:
Hi there,
Here's a bug report that got submitted on the Debian BTS, with a patch
allowing
embryo to compile on debian/hurd (and more generally on systems were
PATH_MAX is
udefined).
I could apply this patch, but I fear it's nothing compared to the
whole EFL where PATH_MAX is heavily used. I guess that a better option
is to define PATH_MAX = 4096/1024/something-user-specified in
config.h, which should be included in every source file anyway. With
that new .m4, we could just copy it to all efl projects and call the
macro from configure.ac and fix them in the same way.
Would the following patch do the trick?
--- /dev/null 2009-11-21 13:03:47.817351087 +0100
+++ m4/efl_path_max.m4 2009-11-21 16:43:28.0 +0100
@@ -0,0 +1,33 @@
+dnl Check for PATH_MAX in limits.h, and define a default value if not found
+dnl This is a workaround for systems not providing PATH_MAX, like GNU/Hurd
+
+dnl EFL_CHECK_PATH_MAX([DEFAULT_VALUE_IF_NOT_FOUND])
+dnl
+dnl If PATH_MAX is not defined in limits.h, defines it
+dnl to DEFAULT_VALUE_IF_NOT_FOUND if it exists, or fallback
+dnl to using 4096
+
+AC_DEFUN([EFL_CHECK_PATH_MAX],
+[
+
+default_max=m4_default([$1], 4096)
+AC_LANG_PUSH([C])
+
+AC_MSG_CHECKING([for PATH_MAX in limits.h])
+AC_COMPILE_IFELSE(
+ [AC_LANG_PROGRAM([[#include limits.h]],
+[[int i = PATH_MAX;]])
+ ],
+ AC_MSG_RESULT([yes]),
+ [
+ AC_DEFINE_UNQUOTED([PATH_MAX],
+[${default_max}],
+[default value since PATH_MAX is not defined])
+ AC_MSG_RESULT([no: using ${default_max}])
+ ]
+)
+
+AC_LANG_POP([C])
+
+])
+dnl end of efl_path_max.m4
Regards,
--
Albin Tonnerre
signature.asc
Description: Digital signature
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] resolve eet build failure
On Thu, 10 Sep 2009 15:42 +1000, Simon Horman wrote : As reported in track ticket 377 (amongst other things), eet seems to fail to build (on Debian). # svn checkout FOO/eet # cd eet # ./autogen.sh # make [snip] libtool: link: gcc -std=gnu99 -Wall -O2 -fomit-frame-pointer -pipe -Wl,--as-needed -o .libs/eet eet-eet_main.o ../../src/lib/.libs/libeet.so ../../src/lib/.libs/libeet.so: undefined reference to `clock_gettime' ../../src/lib/.libs/libeet.so: undefined reference to `dlsym' ../../src/lib/.libs/libeet.so: undefined reference to `dlerror' ../../src/lib/.libs/libeet.so: undefined reference to `pthread_spin_lock' ../../src/lib/.libs/libeet.so: undefined reference to `pthread_spin_unlock' ../../src/lib/.libs/libeet.so: undefined reference to `pthread_spin_init' ../../src/lib/.libs/libeet.so: undefined reference to `dladdr' ../../src/lib/.libs/libeet.so: undefined reference to `pthread_spin_destroy' ../../src/lib/.libs/libeet.so: undefined reference to `dlopen' ../../src/lib/.libs/libeet.so: undefined reference to `dlclose' collect2: ld returned 1 exit status make[3]: *** [eet] Error 1 make[3]: Leaving directory `/home/horms/projects/e/svn/trunk/eet/src/bin' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/horms/projects/e/svn/trunk/eet/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/horms/projects/e/svn/trunk/eet' make: *** [all] Error 2 A simple solution seems to be to link libeet against ldl and lrt as follows. Is this acceptable? That looks *a lot* like one of eet's dependencies is missing proper linking, rather as eet itself - as it doesn't have any pthread code nor dlopen code. Have you checked whether eina is correctly linked against libdl and libpthread ? Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [patch] esmart: Add autogen.sh to dist tarball
On Wed, 09 Sep 2009 09:24 +1000, Simon Horman wrote : Is the following appropriate? - Subject: Add autogen.sh to dist tarball autogen.sh is used by the debian packaging so it seems appropriate to include it in the dist tarball Either you're packaging from SVN and therefore don't need it to be part of the dist tarball, or you're packaging from the snapshots at download.enlightenment.org (or snapshots you generated) and then your packaging should be fixed to use directly ./configure instead of configure.sh. Is there an actual use case I'm missing, for which this change would be required? Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: turning pkg-config's Requires: fiels into Requires.private
On Fri, Sep 04, 2009 at 03:36:28AM +0700, Mikhail Gusarov wrote :
Twas brillig at 22:30:44 03.09.2009 UTC+02 when vto...@univ-evry.fr did gyre
and gimble:
VT Looks good to me. I've looked at others .og files (in fontconfig
VT for example), and I have seen a Libs.private. SHould it be used ?
Yes, of course!
The rule of thumb is when something is not needed to link with a shared
library, it goes to {Requires,Libs}.private
As far as the EFL are concerned Requires.private can replace Requires virtually
everywhere, however this is not true /at all/ for Libs.
In fact, most of what's in Libs currently shouldn't move to Libs.private,
because they actually are justified.
Cheers,
--
Albin Tonnerre
signature.asc
Description: Digital signature
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: turning pkg-config's Requires: fiels into Requires.private
On Thu, Sep 03, 2009 at 11:02:34PM +0200, Vincent Torri wrote :
On Thu, 3 Sep 2009, Albin Tonnerre wrote:
On Fri, Sep 04, 2009 at 03:36:28AM +0700, Mikhail Gusarov wrote :
Twas brillig at 22:30:44 03.09.2009 UTC+02 when vto...@univ-evry.fr did
gyre and gimble:
VT Looks good to me. I've looked at others .og files (in fontconfig
VT for example), and I have seen a Libs.private. SHould it be used ?
Yes, of course!
The rule of thumb is when something is not needed to link with a shared
library, it goes to {Requires,Libs}.private
As far as the EFL are concerned Requires.private can replace Requires
virtually
everywhere, however this is not true /at all/ for Libs.
In fact, most of what's in Libs currently shouldn't move to Libs.private,
because they actually are justified.
are you sure ?
http://people.freedesktop.org/~dbn/pkg-config-guide.html
shouln't -liconv be in Libs.private ?
[23:35 ~/e17/svn/trunk:svn|r42212]% find -name \*.pc.in | xargs grep iconv
zsh: done find -name \*.pc.in |
zsh: exit 123 xargs grep iconv
I've never stated that Libs and Libs.private were all correctly set. I said that
*most* of what is currently in Libs shouldn't move to Libs.private, and that's
correct.
Regards,
--
Albin Tonnerre
signature.asc
Description: Digital signature
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas bugger
On Mon, Aug 24, 2009 at 06:07:20PM +0700, Mikhail Gusarov wrote : Twas brillig at 06:55:12 24.08.2009 UTC-04 when cpmicha...@comcast.net did gyre and gimble: CM regardless of platform the returns are as expected. NULL is declared as 0 in C standard. Consistency wins, I agree, but portability is not hurt by using 0 instead of NULL. IIRC a conformant C implementation could define NULL to (void *) 0 Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [eet] Update libeet1.symbols file
On Sun, Aug 16, 2009 at 09:10:38PM +0700, Mikhail Gusarov wrote : Those symbols appeared earlier than in 1.2.2, but debian/libeet1.symbols was not updated, so there is no point to look at the actual minimal versions of symbols. Actually, it did get updated, SVN just didn't follow: see http://git.debian.org/?p=pkg-e/libs/eet.git;a=history;f=debian/libeet1.symbols;h=deb0e65f90dbb9aa49afb20feb2e0626970aa138;hb=master Cheers, -- Albin Tonnerre signature.asc Description: Digital signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [Fwd: embryo: FTBFS on hurd-i386]
Hi there,
Here's a bug report that got submitted on the Debian BTS, with a patch allowing
embryo to compile on debian/hurd (and more generally on systems were PATH_MAX is
udefined).
Regards,
--
Albin Tonnerre
---BeginMessage---
Package: embryo
Severity: important
Tags: patch
Justification: fails to build from source
embryo defines the _MAX_PATH constant, since PATH_MAX is optional according to
POSIX.
But there's still one occurrence of PATH_MAX in the source, which prevents
embryo from
building on GNU/Hurd.
I have attached a patch that fixes this minor problem.
Manuel Menal
diff -urp embryo-0.9.9.050+svn20090204/src/bin/embryo_cc_sc1.c
../embryo-0.9.9.050+svn20090204/src/bin/embryo_cc_sc1.c
--- embryo-0.9.9.050+svn20090204/src/bin/embryo_cc_sc1.c2009-02-04
21:16:57.0 +0100
+++ ../embryo-0.9.9.050+svn20090204/src/bin/embryo_cc_sc1.c 2009-06-23
12:03:37.0 +0200
@@ -603,7 +603,7 @@ static void
parseoptions(int argc, char **argv, char *iname, char *oname,
char *pname __UNUSED__, char *rname __UNUSED__)
{
- char str[PATH_MAX];
+ char str[_MAX_PATH];
int i, stack_size;
size_t len;
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: hurd-i386 (i686-AT386)
Kernel: GNU-Mach 1.3.99/Hurd-0.3
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
___
Pkg-e-devel mailing list
pkg-e-de...@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-e-devel
---End Message---
signature.asc
Description: Digital signature
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] build error of eina when configuring with --disable-magic-debug
On Sat, Jun 06, 2009 at 02:05:11PM +0200, Vincent Torri wrote :
Hey,
there is an error when configuring eina with --disable-magic-debug.
Indeed, in that case, eina_magic_string_init is defined to :
do {} while(0)
and putting that in a if() is not that good.
The same goes for eina_magic_string_shutdown, BTW.
I don't know the best way to fix that. Imho, we should implement the
function, which returns 1 if --disable-magic-debug is passed to configure.
If you think that there is a better thing to do, please let me know (or
fix it directly in svn)
I agree with you here, I think having a function which returns 1 for init and 0
for shutdown is the best way to go.
Regards,
--
Albin Tonnerre
signature.asc
Description: Digital signature
--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Fix eina build error with --disable-magic-debug, unified patch for my yesterday patches
On Sat, Jun 06, 2009 at 12:12:49PM -0300, Andre Dieb wrote : This patch contains my other two previous patches: - [PATCH] Fix eina mempool leak, init error handling, remove consumed TODO msg - [PATCH] Add checks to eina_module_new Also fixes the build error with --disable-magic-debug. I still think that when ecore_magic is disabled, it would be better to use functions rather than preprocessor macros for things like eina_magic_string_init(). Indeed, that would avoid exporting different symbols depending on whether eina has magic-debug enabled or not. If you use macros, an application using magic debug compiled against eina without magic-debug will have to be recompiled to benefit from it if it gets enabled in eina at a later point. If you use functions, this is no longer an issue. Thoughts ? Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Fix eina build error with --disable-magic-debug, unified patch for my yesterday patches
On Sat, Jun 06, 2009 at 07:20:39PM +0200, Cedric BAIL wrote : On Sat, Jun 6, 2009 at 5:48 PM, Albin Tonnerrealbin.tonne...@gmail.com wrote: On Sat, Jun 06, 2009 at 12:12:49PM -0300, Andre Dieb wrote : This patch contains my other two previous patches:   - [PATCH] Fix eina mempool leak, init error handling, remove consumed   TODO msg   - [PATCH] Add checks to eina_module_new Also fixes the build error with --disable-magic-debug. I still think that when ecore_magic is disabled, it would be better to use functions rather than preprocessor macros for things like eina_magic_string_init(). Indeed, that would avoid exporting different symbols depending on whether eina has magic-debug enabled or not. If you use macros, an application using magic debug compiled against eina without magic-debug will have to be recompiled to benefit from it if it gets enabled in eina at a later point. If you use functions, this is no longer an issue. Thoughts ? I strongly disagree, when you disable magic debug in eina, you want to avoid it's cost at all. This include the call of the function call. And from my test, it does have a big impact to just enter an empty function. When we are speaking about performance, I think we can accept the little tradeoff of needing to recompile application using eina for maximum performance. If you're an application developer and use eina_magic, you're ready to pay that cost and more likely to rant about eina_magic being disabled than about any performance loss, as you explicitely asked for it. If you're talking about eina, nothing prevents us to do some trickery so that functions calls are avoided internally, while still exporting the symbols. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Fix eina build error with --disable-magic-debug, unified patch for my yesterday patches
On Sat, Jun 06, 2009 at 08:12:23PM +0200, Cedric BAIL wrote : On Sat, Jun 6, 2009 at 7:43 PM, Albin Tonnerrealbin.tonne...@gmail.com wrote: On Sat, Jun 06, 2009 at 07:20:39PM +0200, Cedric BAIL wrote : On Sat, Jun 6, 2009 at 5:48 PM, Albin Tonnerrealbin.tonne...@gmail.com wrote: On Sat, Jun 06, 2009 at 12:12:49PM -0300, Andre Dieb wrote : This patch contains my other two previous patches:   - [PATCH] Fix eina mempool leak, init error handling, remove consumed   TODO msg   - [PATCH] Add checks to eina_module_new Also fixes the build error with --disable-magic-debug. I still think that when ecore_magic is disabled, it would be better to use functions rather than preprocessor macros for things like eina_magic_string_init(). Indeed, that would avoid exporting different symbols depending on whether eina has magic-debug enabled or not. If you use macros, an application using magic debug compiled against eina without magic-debug will have to be recompiled to benefit from it if it gets enabled in eina at a later point. If you use functions, this is no longer an issue. Thoughts ? I strongly disagree, when you disable magic debug in eina, you want to avoid it's cost at all. This include the call of the function call. And from my test, it does have a big impact to just enter an empty function. When we are speaking about performance, I think we can accept the little tradeoff of needing to recompile application using eina for maximum performance. If you're an application developer and use eina_magic, you're ready to pay that cost and more likely to rant about eina_magic being disabled than about any performance loss, as you explicitely asked for it. Well, in my opinion, when doing development I use magic debug for easing the stabilisation of my code, but in production I don't want to pay a price at all. That would mean that you rely on a production build of eina without magic debug, and one with magic debug, and that you would recompile your app against the production build of eina when you don't want magic debug. I don't think that's a valid use case, as you as a developper should put guards around uses of eina_magic *in your application* so that in doesn't get used when you don't want to. Relying on eina providing macros or functions just looks like a bad idea to me. Regards, - Albin Tonnerre signature.asc Description: Digital signature -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Accessing the structure containing an Eina_Inlist
On Thu, May 07, 2009 at 10:53:06AM -0300, Gustavo Sverzut Barbieri wrote : On Thu, May 7, 2009 at 5:31 AM, Albin Tonnerre albin.tonne...@gmail.com wrote: On Fri, May 01, 2009 at 08:43:01AM -0300, Gustavo Sverzut Barbieri wrote : On Fri, May 1, 2009 at 8:34 AM, Albin Tonnerre albin.tonne...@gmail.com wrote: On Fri, May 01, 2009 at 01:18:38PM +0200, Vincent Torri wrote : On Fri, 1 May 2009, Gustavo Sverzut Barbieri wrote: On Thu, Apr 30, 2009 at 9:13 PM, Carsten Haitzler ras...@rasterman.com wrote: The only problem I see and I already talked to Albin about it is on weird compilers without offsetof() macros. offsetof seems to exist in the lib c of Microsoft And FWIW, ISO C (both 89 and 99) says it should be defined in stddef.h, so if it doesn't exist you probably have more serious problems than this. excellent, so no problems! So, commit or not commmit ? :) commit. Patch attached. Regard, -- Albin Tonnerre Index: eina/src/include/eina_inlist.h === --- eina/src/include/eina_inlist.h (revision 40723) +++ eina/src/include/eina_inlist.h (working copy) @@ -38,6 +38,7 @@ #define EINA_INLIST Eina_Inlist __in_list #define EINA_INLIST_GET(Inlist) (((Inlist)-__in_list)) +#define EINA_INLIST_CONTAINER_GET(ptr, type) ((type *) ((Eina_Inlist *) ptr - offsetof(type, __in_list))) EAPI Eina_Inlist * eina_inlist_append(Eina_Inlist *in_list, Eina_Inlist *in_item) EINA_ARG_NONNULL(2) EINA_WARN_UNUSED_RESULT; EAPI Eina_Inlist * eina_inlist_prepend(Eina_Inlist *in_list, Eina_Inlist *in_item) EINA_ARG_NONNULL(2) EINA_WARN_UNUSED_RESULT; signature.asc Description: Digital signature -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] CVS dependency on etk
On Sat, May 09, 2009 at 02:27:28AM +0200, Peter Wehrfritz wrote : Rodrigo Belem schrieb: Hi all, I was building etk so I saw that etk depends on cvs. This dependency comes from autopoint that lives in autogen.sh. So do all the core EFL, too rodr...@sculptor:/tmp/etk$ ./autogen.sh Running autopoint... autopoint: *** cvs program not found autopoint: *** Stop. Is it right? Do we need this? I wouldn't say it's ``right'', as gettext should arguably be depending on cvs. You can see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506022#17 and the related discussion for further information. Yes, autopoint has cvs as dep. And yes we need autopoint. At least I don't know a better way to setup gettext support. And it isn't a hard limitation, on the long run -- once e17 is released -- only packagers and developers need it. Packagers shouldn't even need it. Ideally, packages should be created using release tarballs, which are produced by make dist, and as a consequence one wouldn't need cvs (nor autopoint, for that matter) as ./autogen.sh has already been run Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Accessing the structure containing an Eina_Inlist
On Fri, May 01, 2009 at 08:43:01AM -0300, Gustavo Sverzut Barbieri wrote : On Fri, May 1, 2009 at 8:34 AM, Albin Tonnerre albin.tonne...@gmail.com wrote: On Fri, May 01, 2009 at 01:18:38PM +0200, Vincent Torri wrote : On Fri, 1 May 2009, Gustavo Sverzut Barbieri wrote: On Thu, Apr 30, 2009 at 9:13 PM, Carsten Haitzler ras...@rasterman.com wrote: The only problem I see and I already talked to Albin about it is on weird compilers without offsetof() macros. offsetof seems to exist in the lib c of Microsoft And FWIW, ISO C (both 89 and 99) says it should be defined in stddef.h, so if it doesn't exist you probably have more serious problems than this. excellent, so no problems! So, commit or not commmit ? :) Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: jeffdameth IN trunk/e: . data/themes src/modules src/modules/everything
Log: initial checkin of 'everything' module with sources for apps, windows and settings Author: jeffdameth Date: 2009-05-06 07:20:45 -0700 (Wed, 06 May 2009) New Revision: 40526 Maybe it deserves an email announcing it/explaining what it's for ? Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] e17 crashes when loading/unloading modules
Hello, On my two computers, unloading and loading modules via the GUI gives a segfault. Apparently, it's due to _e_configure_module_update_cb being called, as the backtrace shows: 0x7f32973f3af3 in select () from /lib/libc.so.6 (gdb) bt #0 0x7f32973f3af3 in select () from /lib/libc.so.6 #1 0x7f329447382e in ?? () from /usr/lib/libxcb.so.1 #2 0x7f329447559a in xcb_wait_for_event () from /usr/lib/libxcb.so.1 #3 0x7f3297ced4a8 in ?? () from /usr/lib/libX11.so.6 #4 0x7f3297ced85d in ?? () from /usr/lib/libX11.so.6 #5 0x7f3297cee131 in _XReadEvents () from /usr/lib/libX11.so.6 #6 0x7f3297cd4958 in XNextEvent () from /usr/lib/libX11.so.6 #7 0x0048516f in e_alert_show ( text=0x4e2d48 This is very bad. Enlightenment SEGV'd.\n\nThis is not meant to happen and is likely a sign of\na bug in Enlightenment or the libraries it relies\non. You can gdb attach to this process now to try\ndebug i...) at e_alert.c:129 #8 0x0046f017 in e_sigseg_act (x=value optimized out, info=value optimized out, data=value optimized out) at e_signals.c:69 #9 signal handler called #10 eina_list_append (list=0x1, data=0x20fba50) at eina_list.c:566 #11 0x004a0b56 in _queue_append (obj=0x1736e20, command=4, icon=0x0, label=0x0, header=0, func=0, data=0x0, val=0x0, relative=0, use_relative=0, item=-1) at e_widget_ilist.c:222 #12 0x004a0ced in e_widget_ilist_selected_set (obj=0x1, n=value optimized out) at e_widget_ilist.c:598 #13 0x7f328e7bd4d9 in _e_configure_module_update_cb (data=0x1a68610, type=value optimized out, event=value optimized out) at e_conf.c:519 #14 0x7f32981f87d6 in _ecore_event_call () at ecore_events.c:439 #15 0x7f32982014e5 in _ecore_main_loop_iterate_internal (once_only=-1740584304) at ecore_main.c:679 #16 0x7f32982016f7 in ecore_main_loop_begin () at ecore_main.c:97 #17 0x0042ea5a in main (argc=1, argv=0x1550294) at e_main.c:1062 Looking at the source, I found that e_widget_ilist_selected_get is called with eco-cat_list as an argument, in e_conf.c. However, cat_list has been a widget_toolbar since November, so there's likely a mistake here and this call should probably be replaced with e_widget_toolbar_item_select However, I'm not sure how to fix this, as I'm not sure whether a call to e_widget_toolbar_item_select is necessary (the correct category is still selected without the function being called, eg when commenting out the whole callback). Also, I'm not sure why the callback is called when loading modules, in the first place. I'd appreciate if anyone had pointers and could enlighten me on the matter. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Accessing the structure containing an Eina_Inlist
On Fri, May 01, 2009 at 10:13:09AM +1000, Carsten Haitzler wrote : On Thu, 30 Apr 2009 18:02:45 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: On Thu, Apr 30, 2009 at 10:11 AM, Albin Tonnerre albin.tonne...@gmail.com wrote: Hello, While playing with Eina_Inlist, I noticed that given a pointer to an Eina_Inlist, one can't easily get a pointer to the structure containing it. The only option now is to put the Eina_Inlist first in the structure, and then cast this structure to an Eina_Inlist, which is far from optimal. I'd therefore like to propose that we add in eina_inlist.h a macro along the lines of #define FIND_A_SENSBILE_NAME_FOR_THIS(ptr, type) ((type *) ((Eina_Inlist *) #ptr - offsetof(type, __in_list))) Then, we could get a pointer to the containing structure, no matter where the Eina_Inlist is (note that I used __in_list as the member as we already have a macro '#define EINA_INLIST Eina_Inlist __in_list', but a member argument could be added just as well) Thoughts ? As we discussed on IRC, I like this. It would help avoid casts and try to make code bit easier to get right. much uglier as now you need to drag an offset Well, if the Eina_Inlist is the first member in the struct the compiler will probably optimize the substraction, as the offset would be 0. If it's not the first member, you need it anyway. # around all the time, and now you still need to cast anyway (use a raw pointer offset and cast to ah Inlist pointer). you don't get rid of it. Same here. The point is not only to avoid casts. It allows people to place the inlist wherever they want within a structure, and have easy access to it. Providing it in eina just doesn't cost anything, and allows people to do it painlessly. -- Albin Tonnerre signature.asc Description: Digital signature -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Accessing the structure containing an Eina_Inlist
On Fri, May 01, 2009 at 01:18:38PM +0200, Vincent Torri wrote : On Fri, 1 May 2009, Gustavo Sverzut Barbieri wrote: On Thu, Apr 30, 2009 at 9:13 PM, Carsten Haitzler ras...@rasterman.com wrote: The only problem I see and I already talked to Albin about it is on weird compilers without offsetof() macros. offsetof seems to exist in the lib c of Microsoft And FWIW, ISO C (both 89 and 99) says it should be defined in stddef.h, so if it doesn't exist you probably have more serious problems than this. -- Albin Tonnerre signature.asc Description: Digital signature -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Accessing the structure containing an Eina_Inlist
Hello, While playing with Eina_Inlist, I noticed that given a pointer to an Eina_Inlist, one can't easily get a pointer to the structure containing it. The only option now is to put the Eina_Inlist first in the structure, and then cast this structure to an Eina_Inlist, which is far from optimal. I'd therefore like to propose that we add in eina_inlist.h a macro along the lines of #define FIND_A_SENSBILE_NAME_FOR_THIS(ptr, type) ((type *) ((Eina_Inlist *) ptr - offsetof(type, __in_list))) Then, we could get a pointer to the containing structure, no matter where the Eina_Inlist is (note that I used __in_list as the member as we already have a macro '#define EINA_INLIST Eina_Inlist __in_list', but a member argument could be added just as well) Thoughts ? Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: morlenxus trunk/E-MODULES-EXTRA/diskio/src
On Thu, Apr 30, 2009 at 06:15:10AM -0700, Enlightenment SVN wrote :
Log:
replace ecore with eina
Author: morlenxus
Date: 2009-04-30 06:15:10 -0700 (Thu, 30 Apr 2009)
New Revision: 40474
Modified:
trunk/E-MODULES-EXTRA/diskio/src/e_mod_config.c
Modified: trunk/E-MODULES-EXTRA/diskio/src/e_mod_config.c
===
--- trunk/E-MODULES-EXTRA/diskio/src/e_mod_config.c 2009-04-30 10:13:31 UTC
(rev 40473)
+++ trunk/E-MODULES-EXTRA/diskio/src/e_mod_config.c 2009-04-30 13:15:10 UTC
(rev 40474)
@@ -3,7 +3,7 @@
struct _E_Config_Dialog_Data
{
- Ecore_List *disks;
+ Eina_List *disks;
int diskpos;
};
@@ -78,6 +78,7 @@
_basic_create(E_Config_Dialog *cfd, Evas *evas, E_Config_Dialog_Data
*cfdata)
{
Config_Item *ci;
+ Eina_List *l;
Evas_Object *o = NULL, *of = NULL, *ob = NULL;
E_Radio_Group *rg;
char path[128], *disk;
@@ -93,8 +94,9 @@
if (cfdata-disks)
{
- while ((disk = ecore_list_next(cfdata-disks)))
+ for (l = cfdata-disks; l; l = eina_list_next(l))
{
+ disk = eina_list_data_get(l);
pos++;
EINA_LIST_FOREACH(cfdata-disks, l, disk)
{
...
}
might be easier/better to use there
Regards,
--
Albin Tonnerre
signature.asc
Description: Digital signature
--
Register Now Save for Velocity, the Web Performance Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Replace Ecore_List2 with Eina_List
On Mon, Apr 27, 2009 at 09:18:39AM -0300, Gustavo Sverzut Barbieri wrote : Sachiel is right, List2 is the same as Inlist, lists where the data is the node, you avoid a bit of memory fragmentation. Eina_List can use the eina mempool, why Inlist can't, so I wouldn't say using Inlists reduce memory fragmentation. and also another pointer redirection (-data). That's the argument for using inlists in the kernel. I'm not sure how this applies to ecore. They're better suited for elements that are always in a list (ie: Evas_Object always in evas), but you can still have them in other Eina_List (not inlist!) if you wish. The downside, at least at the moment, is that you don't have fast count operation, it need to walk the whole list in order to figure out how many elements exists. But you can append fast (O(1)) since it will keep a pointer to last element. Eina_List too. Anyway, TBH I only did it this way because cedric advised me to do so. I'll change it to Eina_Inlists if you think that really would have a benefit, which I doubt. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Replace Ecore_List2 with Eina_List
On Sun, Apr 26, 2009 at 10:48:40AM +0200, Vincent Torri wrote : On Sun, 26 Apr 2009, Albin Tonnerre wrote: Hello, The attached patches completely replace Ecore_List2 with Ecore_List. you mean with Eina_List ? Indeed. Thanks :) -- Albin Tonnerre signature.asc Description: Digital signature -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: quaker IN trunk/E-MODULES-EXTRA
On Sat, Apr 25, 2009 at 04:05:01AM -0700, Enlightenment SVN wrote : EDJE_FLAGS = -v \ -id $(top_srcdir) \ --fd $(top_srcdir)/fonts +-fd $(top_srcdir) -fd is used to add a directory to look in for fonts. Unless I'm missing something, you no longer need it and should drop this line instead of just stripping fonts. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] fixes to configure.ac
On Thu, Apr 23, 2009 at 04:36:18AM +0200, Vincent Torri wrote : On Thu, 23 Apr 2009, Carsten Haitzler (The Rasterman) wrote: On Wed, 22 Apr 2009 16:29:18 -0400 Rodrigo Belem rclbe...@gmail.com said: Hi all, I was getting some build fails, so I notice that the error was coming from configure.ac. The patch is attached, but I did not tested if the others libs need this fix too. hmm i changed it for consistency in the version strip - it worked for me but not you (odd). i've gone the other way and removed all the []'s instead. it''s at least consistent maybe you should search why it does not work, instead of committing this I agree with vincent here, it's been this way for long and nobody ever had issues with it. Would you mind providing an error log so that we can try to understand why you were getting this error ? Cheers, -- Albin Tonnerre signature.asc Description: Digital signature -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] modules to disable by default in monday release
On Sun, Apr 19, 2009 at 06:03:06PM -0300, Gustavo Sverzut Barbieri wrote : n.b. - i'd disable in config profile, not build... ? new users will lose them - old users keep what they have. ok, I'd rather disable their build, but just in profiles is fine. I agree with raster. Unless those modules are broken, there's no point preventing users from trying them out - disabled at runtime is better IMHO. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fwd: [Proposal] release schedule and version numbering
On Thu, Apr 16, 2009 at 7:38 AM, Vincent Torri vto...@univ-evry.fr wrote: On Wed, 15 Apr 2009, Albin Tonnerre wrote: Patch attached. As usual, comments are welcome in ecore, is it really necessary to have a release-info for each module ? I think it's better, unless you want to force a SONAME change upon all the 18 libs every time one of them changes. That would force a lot of unneeded recompiles for programs who rely on parts which haven't changed (for example, if you break the ecore_win32 API, you sure don't want all the libs to change SONAME) Regards, Albin -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fwd: [Proposal] release schedule and version numbering
On Thu, Apr 16, 2009 at 9:57 AM, Vincent Torri vto...@univ-evry.fr wrote: in that case, is it good to specify both -release and -version-info in _LDFLAGS ? I think it's mostly a matter of taste. Keeping both doesn't hurt much IMHO, and all you'll have to do when there's a real release is remove the '-release' part. Albin -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fwd: [Proposal] release schedule and version numbering
On Thu, Apr 16, 2009 at 6:25 PM, sda dmitry.serpok...@gmail.com wrote: hi, just FYI - general rules for rpm packaging: http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html brief summary of packaging conventions which confirms to the LSB could be reviewed below (distro-specific!): http://en.opensuse.org/Packaging the offer above is about to change NAME - ???!!!. if (when) we settle the exact E-svn-revision numbers to be packaged and available for all the info like RC, Alpha, Beta, Fix1 to RC etc shoulg go to the Changelog or Summary (as a last resort). I'm sorry, but I don't understand what your point is. Regards, Albin -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fwd: [Proposal] release schedule and version numbering
On Thu, Apr 16, 2009 at 7:00 PM, Albin Tonnerre albin.tonne...@gmail.com wrote: On Thu, Apr 16, 2009 at 6:25 PM, sda dmitry.serpok...@gmail.com wrote: hi, just FYI - general rules for rpm packaging: http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html brief summary of packaging conventions which confirms to the LSB could be reviewed below (distro-specific!): http://en.opensuse.org/Packaging the offer above is about to change NAME - ???!!!. if (when) we settle the exact E-svn-revision numbers to be packaged and available for all the info like RC, Alpha, Beta, Fix1 to RC etc shoulg go to the Changelog or Summary (as a last resort). This patch is not about changing package names. It's about getting proper SONAME changes when devs break the API or the ABI. What happends to the package names is not releveant to this, as this is the maintainer's decision. Regards, Albin -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Efreet: use eina_list instead of ecore_dlist
Hi,
Please find attached an updated patch which sets to NULL the pointer to a list
being merged into another list.
Regards,
--
Albin Tonnerre
diff --git a/src/lib/efreet_desktop.c b/src/lib/efreet_desktop.c
index 9357add..2dfa357 100644
--- a/src/lib/efreet_desktop.c
+++ b/src/lib/efreet_desktop.c
@@ -1089,7 +1089,7 @@ efreet_desktop_environment_check(Efreet_Ini *ini)
/**
* @param desktop: the desktop entry
- * @param files: an ecore list of file names to execute, as either absolute paths,
+ * @param files: an eina list of file names to execute, as either absolute paths,
* relative paths, or uris
* @param func: a callback to call for each prepared command line
* @param data: user data passed to the callback
@@ -1105,8 +1105,8 @@ efreet_desktop_command_get(Efreet_Desktop *desktop, Eina_List *files,
/**
* @param desktop: the desktop entry
- * @param files an ecore list of local files, as absolute paths, local paths, or file:// uris (or NULL to get exec string with no files appended)
- * @return Returns an ecore list of exec strings
+ * @param files an eina list of local files, as absolute paths, local paths, or file:// uris (or NULL to get exec string with no files appended)
+ * @return Returns an eina list of exec strings
* @brief Get the command to use to execute a desktop entry
*
* The returned list and each of its elements must be freed.
@@ -1153,7 +1153,7 @@ efreet_desktop_command_local_get(Efreet_Desktop *desktop, Eina_List *files)
/**
* @param desktop: the desktop entry
- * @param files: an ecore list of file names to execute, as either absolute paths,
+ * @param files: an eina list of file names to execute, as either absolute paths,
* relative paths, or uris
* @param cb_command: a callback to call for each prepared command line
* @param cb_progress: a callback to get progress for the downloads
diff --git a/src/lib/efreet_menu.c b/src/lib/efreet_menu.c
index 1a77a38..e11336a 100644
--- a/src/lib/efreet_menu.c
+++ b/src/lib/efreet_menu.c
@@ -41,7 +41,7 @@ struct Efreet_Menu_Internal
} name; /** The names for this menu */
Efreet_Desktop *directory; /** The directory */
-Ecore_DList *directories; /** All the directories set in the menu file */
+Eina_List *directories; /** All the directories set in the menu file */
Efreet_Menu_Move *current_move; /** The current move */
@@ -50,7 +50,7 @@ struct Efreet_Menu_Internal
Eina_List *app_pool; /** application pool */
Eina_List *applications; /** applications in this menu */
-Ecore_DList *directory_dirs;/** .directory file directories */
+Eina_List *directory_dirs;/** .directory file directories */
Eina_Hash *directory_cache;/** .directory dirs */
Eina_List *moves; /** List of moves to be handled by the menu */
@@ -1001,10 +1001,10 @@ efreet_menu_internal_free(Efreet_Menu_Internal *internal)
internal-applications = eina_list_free(internal-applications);
-IF_FREE_DLIST(internal-directories);
+IF_FREE_LIST(internal-directories, free);
IF_FREE_LIST(internal-app_dirs, efreet_menu_app_dir_free);
IF_FREE_LIST(internal-app_pool, efreet_menu_desktop_free);
-IF_FREE_DLIST(internal-directory_dirs);
+IF_FREE_LIST(internal-directory_dirs, free);
IF_FREE_HASH(internal-directory_cache);
IF_FREE_LIST(internal-moves, efreet_menu_move_free);
@@ -1053,10 +1053,10 @@ static int
efreet_menu_handle_menu(Efreet_Menu_Internal *internal, Efreet_Xml *xml)
{
Efreet_Xml *child;
+Eina_List *l;
int (*cb)(Efreet_Menu_Internal *parent, Efreet_Xml *xml);
-ecore_list_last_goto(xml-children);
-while ((child = ecore_dlist_previous(xml-children)))
+EINA_LIST_REVERSE_FOREACH(xml-children, l, child)
{
cb = eina_hash_find(efreet_menu_handle_cbs, child-tag);
if (cb)
@@ -1206,13 +1206,13 @@ efreet_menu_handle_directory_dir(Efreet_Menu_Internal *parent, Efreet_Xml *xml)
if (!path) return 0;
/* we've already got this guy in our list we can skip it */
-if (ecore_list_find(parent-directory_dirs, ECORE_COMPARE_CB(strcmp), path))
+if (eina_list_search_unsorted(parent-directory_dirs, EINA_COMPARE_CB(strcmp), path))
{
FREE(path);
return 1;
}
-ecore_dlist_prepend(parent-directory_dirs, path);
+parent-directory_dirs = eina_list_prepend(parent-directory_dirs, path);
return 1;
}
@@ -1237,10 +1237,10 @@ efreet_menu_handle_default_directory_dirs(Efreet_Menu_Internal *parent, Efreet_X
desktop-directories);
EINA_LIST_FOREACH(dirs, l, dir)
{
-if (ecore_list_find(parent-directory_dirs, ECORE_COMPARE_CB(strcmp), dir))
+if (eina_list_search_unsorted(parent-directory_dirs, EINA_COMPARE_CB(strcmp), dir))
continue;
-ecore_dlist_prepend(parent-directory_dirs, strdup(dir));
+parent
[E-devel] [PATCH] Efreet: use eina_list instead of ecore_dlist
Hi,
The attached patches fix three things:
0001 converts the remaining uses of ecore_dlist to using eina_list
0002 replaces the use of Eina_Compare_Cb with the use of EINA_COMPARE_CB
0003 Allows the e17-specified menu to be chosen as a menu only if STRICT_SPEC is
not defined, as it is obviously not conforming to the spec.
I tested a bit on my system and everything seems to be working correctly,
however I haven't tested it really thoroughly.
Comments welcome.
Regards,
--
Albin Tonnerre
diff --git a/src/lib/efreet_desktop.c b/src/lib/efreet_desktop.c
index 9357add..2dfa357 100644
--- a/src/lib/efreet_desktop.c
+++ b/src/lib/efreet_desktop.c
@@ -1089,7 +1089,7 @@ efreet_desktop_environment_check(Efreet_Ini *ini)
/**
* @param desktop: the desktop entry
- * @param files: an ecore list of file names to execute, as either absolute paths,
+ * @param files: an eina list of file names to execute, as either absolute paths,
* relative paths, or uris
* @param func: a callback to call for each prepared command line
* @param data: user data passed to the callback
@@ -1105,8 +1105,8 @@ efreet_desktop_command_get(Efreet_Desktop *desktop, Eina_List *files,
/**
* @param desktop: the desktop entry
- * @param files an ecore list of local files, as absolute paths, local paths, or file:// uris (or NULL to get exec string with no files appended)
- * @return Returns an ecore list of exec strings
+ * @param files an eina list of local files, as absolute paths, local paths, or file:// uris (or NULL to get exec string with no files appended)
+ * @return Returns an eina list of exec strings
* @brief Get the command to use to execute a desktop entry
*
* The returned list and each of its elements must be freed.
@@ -1153,7 +1153,7 @@ efreet_desktop_command_local_get(Efreet_Desktop *desktop, Eina_List *files)
/**
* @param desktop: the desktop entry
- * @param files: an ecore list of file names to execute, as either absolute paths,
+ * @param files: an eina list of file names to execute, as either absolute paths,
* relative paths, or uris
* @param cb_command: a callback to call for each prepared command line
* @param cb_progress: a callback to get progress for the downloads
diff --git a/src/lib/efreet_menu.c b/src/lib/efreet_menu.c
index 1a77a38..57c85fa 100644
--- a/src/lib/efreet_menu.c
+++ b/src/lib/efreet_menu.c
@@ -41,7 +41,7 @@ struct Efreet_Menu_Internal
} name; /** The names for this menu */
Efreet_Desktop *directory; /** The directory */
-Ecore_DList *directories; /** All the directories set in the menu file */
+Eina_List *directories; /** All the directories set in the menu file */
Efreet_Menu_Move *current_move; /** The current move */
@@ -50,7 +50,7 @@ struct Efreet_Menu_Internal
Eina_List *app_pool; /** application pool */
Eina_List *applications; /** applications in this menu */
-Ecore_DList *directory_dirs;/** .directory file directories */
+Eina_List *directory_dirs;/** .directory file directories */
Eina_Hash *directory_cache;/** .directory dirs */
Eina_List *moves; /** List of moves to be handled by the menu */
@@ -1001,10 +1001,10 @@ efreet_menu_internal_free(Efreet_Menu_Internal *internal)
internal-applications = eina_list_free(internal-applications);
-IF_FREE_DLIST(internal-directories);
+IF_FREE_LIST(internal-directories, free);
IF_FREE_LIST(internal-app_dirs, efreet_menu_app_dir_free);
IF_FREE_LIST(internal-app_pool, efreet_menu_desktop_free);
-IF_FREE_DLIST(internal-directory_dirs);
+IF_FREE_LIST(internal-directory_dirs, free);
IF_FREE_HASH(internal-directory_cache);
IF_FREE_LIST(internal-moves, efreet_menu_move_free);
@@ -1053,10 +1053,10 @@ static int
efreet_menu_handle_menu(Efreet_Menu_Internal *internal, Efreet_Xml *xml)
{
Efreet_Xml *child;
+Eina_List *l;
int (*cb)(Efreet_Menu_Internal *parent, Efreet_Xml *xml);
-ecore_list_last_goto(xml-children);
-while ((child = ecore_dlist_previous(xml-children)))
+EINA_LIST_REVERSE_FOREACH(xml-children, l, child)
{
cb = eina_hash_find(efreet_menu_handle_cbs, child-tag);
if (cb)
@@ -1206,13 +1206,13 @@ efreet_menu_handle_directory_dir(Efreet_Menu_Internal *parent, Efreet_Xml *xml)
if (!path) return 0;
/* we've already got this guy in our list we can skip it */
-if (ecore_list_find(parent-directory_dirs, ECORE_COMPARE_CB(strcmp), path))
+if (eina_list_search_unsorted(parent-directory_dirs, EINA_COMPARE_CB(strcmp), path))
{
FREE(path);
return 1;
}
-ecore_dlist_prepend(parent-directory_dirs, path);
+parent-directory_dirs = eina_list_prepend(parent-directory_dirs, path);
return 1;
}
@@ -1237,10 +1237,10 @@ efreet_menu_handle_default_directory_dirs(Efreet_Menu_Internal *parent, Efreet_X
desktop
[E-devel] [PATCH] signedness issues in efreet_menu.c
Hello, efreet_menu.c compare variables which have type 'char' to -1 (members of the Efreet_Menu_Internal and Efreet_Menu_Layout structures). This causes issues on architectures where chars are unsigned, such as ARM (at least on the freerunner). In particular, the use of Layout in menu files results in malformed menus. The attached patch intends to fix this. Regards, Albin Index: src/lib/efreet_menu.c === --- src/lib/efreet_menu.c (revision 39603) +++ src/lib/efreet_menu.c (working copy) @@ -61,11 +61,11 @@ Eina_List *layout; /** This menus layout */ Eina_List *default_layout; /** Default layout */ -char show_empty;/** Whether to show empty menus */ -char in_line; /** Whether this meny can be inlined */ -char inline_limit; /** Number of elements which triggers inline */ -char inline_header; /** Whether we should use the header name when this menu is inlined */ -char inline_alias; /** Whether we should use the menu name when inlining */ +signed char show_empty;/** Whether to show empty menus */ +signed char in_line; /** Whether this meny can be inlined */ +signed char inline_limit; /** Number of elements which triggers inline */ +signed char inline_header; /** Whether we should use the header name when this menu is inlined */ +signed char inline_alias; /** Whether we should use the menu name when inlining */ unsigned char seen_allocated:1; /** have we set the only_unallocated */ unsigned char only_unallocated:1; /** Show only unallocated .desktops */ @@ -184,11 +184,11 @@ char *name; /** The name of the element */ /* The items below are for Menuname Layout elements */ -char show_empty;/** Whether to show empty menus */ -char in_line; /** Whether this meny can be inlined */ -char inline_limit; /** Number of elements which triggers inline */ -char inline_header; /** Whether we should use the header name when this menu is inlined */ -char inline_alias; /** Whether we should use the menu name when inlining */ +signed char show_empty;/** Whether to show empty menus */ +signed char in_line; /** Whether this meny can be inlined */ +signed char inline_limit; /** Number of elements which triggers inline */ +signed char inline_header; /** Whether we should use the header name when this menu is inlined */ +signed char inline_alias; /** Whether we should use the menu name when inlining */ }; /** -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] SUID bits for E17
On Mon, Dec 15, 2008 at 7:12 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: I told you that :-) then you just need to do the dbus messages and have an option in enlightenment's configure.ac --enable-hal-shutdown and --enable-hal-cpufreq I'd vote for that, just don't have the time to do it myself. I'll have time when my exams are finished, I think I'll work on that if nobody does it before :) Cheers, Albin -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/e/src/bin
Oh, sorry, didn't think about that :/ On Fri, Jan 2, 2009 at 12:19 PM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: fix things that broke after utils moved to lib/e/subdir Author: raster Date: 2009-01-02 03:19:06 -0800 (Fri, 02 Jan 2009) New Revision: 38418 Modified: trunk/e/src/bin/Makefile.am trunk/e/src/bin/e_fm_main.c trunk/e/src/bin/e_prefix.c Modified: trunk/e/src/bin/Makefile.am === --- trunk/e/src/bin/Makefile.am 2009-01-02 10:57:02 UTC (rev 38417) +++ trunk/e/src/bin/Makefile.am 2009-01-02 11:19:06 UTC (rev 38418) @@ -345,8 +345,7 @@ enlightenment_fm_SOURCES = \ e_fm_main.c \ e_user.c \ -e_sha1.c \ -e_prefix.c +e_sha1.c Now you might need e_utils.c too, or you'll end up with a build failure when compiling with multiple make jobs Cheers, Albin -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Move binaries reserved for E internal use out of /usr/bin
Hello,
On Thu, Jan 1, 2009 at 1:56 AM, The Rasterman Carsten Haitzler
ras...@rasterman.com wrote:
no problem with this - though some people who like to be really nitty might
say
we should have a libexec/enlightenment dir... but really - not worth
quibbling
over.
libexec is neither present in all distributions nor part of the FHS anyway,
looks like a bad candidate
lib is ok - it's inside e's dir and whatever e puts inside of that is e's
business.
but i'd move these to a subdir ie:
PREFIX/lib/enlightenment/bin/
or
PREFIX/lib/enlightenment/utils/
or something as modules are in modules/ - preload hacks in preload/
etc. :)
All right, updated patch attached :)
Cheers,
Albin
diff -Nur e/src/bin/e_fm.c e.new/src/bin/e_fm.c
--- e/src/bin/e_fm.c 2008-12-28 11:18:18.0 +0100
+++ e.new/src/bin/e_fm.c 2009-01-01 17:28:52.0 +0100
@@ -1511,7 +1511,7 @@
char buf[4096];
if (_e_fm2_client_spawning) return;
- snprintf(buf, sizeof(buf), %s/enlightenment_fm, e_prefix_bin_get());
+ snprintf(buf, sizeof(buf), %s/enlightenment/utils/enlightenment_fm, e_prefix_lib_get());
exe = ecore_exe_run(buf, NULL);
_e_fm2_client_spawning = 1;
}
diff -Nur e/src/bin/e_fm_main.c e.new/src/bin/e_fm_main.c
--- e/src/bin/e_fm_main.c 2008-12-28 11:18:18.0 +0100
+++ e.new/src/bin/e_fm_main.c 2009-01-01 17:28:52.0 +0100
@@ -2177,7 +2177,7 @@
length = 256 + strlen(e_prefix_bin_get()) + strlen(args);
buffer = malloc(length);
- length = snprintf(buffer, length, %s/enlightenment_fm_op %s %s, e_prefix_bin_get(), command, args);
+ length = snprintf(buffer, length, %s/enlightenment/utils/enlightenment_fm_op %s %s, e_prefix_lib_get(), command, args);
return buffer;
}
diff -Nur e/src/bin/e_init.c e.new/src/bin/e_init.c
--- e/src/bin/e_init.c 2008-12-01 00:27:29.0 +0100
+++ e.new/src/bin/e_init.c 2009-01-01 17:28:52.0 +0100
@@ -77,8 +77,8 @@
if (version) ver = strdup(e_util_filename_escape(version));
else ver = strdup(XvX);
- snprintf(buf, sizeof(buf), %s/enlightenment_init \'%s\' \'%i\' \'%i\' \'%s\' \'%s\',
- e_prefix_bin_get(),
+ snprintf(buf, sizeof(buf), %s/enlightenment/utils/enlightenment_init \'%s\' \'%i\' \'%i\' \'%s\' \'%s\',
+ e_prefix_lib_get(),
theme,
e_canvas_engine_decide(e_config-evas_engine_init),
e_config-font_hinting,
diff -Nur e/src/bin/e_sys.c e.new/src/bin/e_sys.c
--- e/src/bin/e_sys.c 2008-12-01 00:27:29.0 +0100
+++ e.new/src/bin/e_sys.c 2009-01-01 17:28:52.0 +0100
@@ -168,13 +168,13 @@
char buf[4096];
e_init_status_set(_(Checking System Permissions));
- snprintf(buf, sizeof(buf), %s/enlightenment_sys -t halt, e_prefix_bin_get());
+ snprintf(buf, sizeof(buf), %s/enlightenment/utils/enlightenment_sys -t halt, e_prefix_lib_get());
_e_sys_halt_check_exe = ecore_exe_run(buf, NULL);
- snprintf(buf, sizeof(buf), %s/enlightenment_sys -t reboot, e_prefix_bin_get());
+ snprintf(buf, sizeof(buf), %s/enlightenment/utils/enlightenment_sys -t reboot, e_prefix_lib_get());
_e_sys_reboot_check_exe = ecore_exe_run(buf, NULL);
- snprintf(buf, sizeof(buf), %s/enlightenment_sys -t suspend, e_prefix_bin_get());
+ snprintf(buf, sizeof(buf), %s/enlightenment/utils/enlightenment_sys -t suspend, e_prefix_lib_get());
_e_sys_suspend_check_exe = ecore_exe_run(buf, NULL);
- snprintf(buf, sizeof(buf), %s/enlightenment_sys -t hibernate, e_prefix_bin_get());
+ snprintf(buf, sizeof(buf), %s/enlightenment/utils/enlightenment_sys -t hibernate, e_prefix_lib_get());
_e_sys_hibernate_check_exe = ecore_exe_run(buf, NULL);
return 0;
}
@@ -515,8 +515,8 @@
case E_SYS_HALT_NOW:
/* shutdown -h now */
if (e_util_immortal_check()) return 0;
- snprintf(buf, sizeof(buf), %s/enlightenment_sys halt,
- e_prefix_bin_get());
+ snprintf(buf, sizeof(buf), %s/enlightenment/utils/enlightenment_sys halt,
+ e_prefix_lib_get());
if (_e_sys_exe)
{
_e_sys_current_action();
@@ -542,8 +542,8 @@
case E_SYS_REBOOT:
/* shutdown -r now */
if (e_util_immortal_check()) return 0;
- snprintf(buf, sizeof(buf), %s/enlightenment_sys reboot,
- e_prefix_bin_get());
+ snprintf(buf, sizeof(buf), %s/enlightenment/utils/enlightenment_sys reboot,
+ e_prefix_lib_get());
if (_e_sys_exe)
{
_e_sys_current_action();
@@ -568,8 +568,8 @@
break;
case E_SYS_SUSPEND:
/* /etc/acpi/sleep.sh force */
- snprintf(buf, sizeof(buf), %s/enlightenment_sys suspend,
- e_prefix_bin_get());
+ snprintf(buf, sizeof(buf), %s/enlightenment/utils/enlightenment_sys suspend,
+ e_prefix_lib_get());
if (_e_sys_exe)
{
_e_sys_current_action();
@@ -594,8 +594,8 @@
break;
case E_SYS_HIBERNATE:
/* /etc/acpi/hibernate.sh force */
- snprintf(buf, sizeof(buf), %s/enlightenment_sys hibernate,
- e_prefix_bin_get());
+ snprintf(buf, sizeof(buf), %s/enlightenment/utils/enlightenment_sys hibernate,
+ e_prefix_lib_get());
if (_e_sys_exe)
[E-devel] Move binaries reserved for E internal use out of /usr/bin
Hi there,
I think it might be a good idea to stop putting all the binairies e17 creates
into /usr/bin, as half of them are actually only for internal use, and have
nothing to do in $PATH.
The attached patch moves the following binaries to /usr/lib/enlightenment and
updates
the code accordingly:
- enlightenment_fm
- enlightenment_fm_op
- enlightenment_init
- enlightenment_sys
- enlightenment_thumb
Toughts ?
Regards,
--
Albin Tonnerre
diff -Nur e/src/bin/e_fm.c e.new/src/bin/e_fm.c
--- e/src/bin/e_fm.c 2008-12-10 17:15:12.0 +0100
+++ e.new/src/bin/e_fm.c 2008-12-15 13:45:22.0 +0100
@@ -1511,7 +1511,7 @@
char buf[4096];
if (_e_fm2_client_spawning) return;
- snprintf(buf, sizeof(buf), %s/enlightenment_fm, e_prefix_bin_get());
+ snprintf(buf, sizeof(buf), %s/enlightenment/enlightenment_fm, e_prefix_lib_get());
exe = ecore_exe_run(buf, NULL);
_e_fm2_client_spawning = 1;
}
diff -Nur e/src/bin/e_fm_main.c e.new/src/bin/e_fm_main.c
--- e/src/bin/e_fm_main.c 2008-11-30 23:08:27.0 +0100
+++ e.new/src/bin/e_fm_main.c 2008-12-15 13:45:22.0 +0100
@@ -2175,7 +2175,7 @@
length = 256 + strlen(e_prefix_bin_get()) + strlen(args);
buffer = malloc(length);
- length = snprintf(buffer, length, %s/enlightenment_fm_op %s %s, e_prefix_bin_get(), command, args);
+ length = snprintf(buffer, length, %s/enlightenment_fm_op %s %s, e_prefix_lib_get(), command, args);
return buffer;
}
diff -Nur e/src/bin/e_init.c e.new/src/bin/e_init.c
--- e/src/bin/e_init.c 2008-11-30 23:08:27.0 +0100
+++ e.new/src/bin/e_init.c 2008-12-15 13:45:22.0 +0100
@@ -77,8 +77,8 @@
if (version) ver = strdup(e_util_filename_escape(version));
else ver = strdup(XvX);
- snprintf(buf, sizeof(buf), %s/enlightenment_init \'%s\' \'%i\' \'%i\' \'%s\' \'%s\',
- e_prefix_bin_get(),
+ snprintf(buf, sizeof(buf), %s/enlightenment/enlightenment_init \'%s\' \'%i\' \'%i\' \'%s\' \'%s\',
+ e_prefix_lib_get(),
theme,
e_canvas_engine_decide(e_config-evas_engine_init),
e_config-font_hinting,
diff -Nur e/src/bin/e_sys.c e.new/src/bin/e_sys.c
--- e/src/bin/e_sys.c 2008-11-30 23:08:27.0 +0100
+++ e.new/src/bin/e_sys.c 2008-12-15 13:45:22.0 +0100
@@ -168,13 +168,13 @@
char buf[4096];
e_init_status_set(_(Checking System Permissions));
- snprintf(buf, sizeof(buf), %s/enlightenment_sys -t halt, e_prefix_bin_get());
+ snprintf(buf, sizeof(buf), %s/enlightenment/enlightenment_sys -t halt, e_prefix_lib_get());
_e_sys_halt_check_exe = ecore_exe_run(buf, NULL);
- snprintf(buf, sizeof(buf), %s/enlightenment_sys -t reboot, e_prefix_bin_get());
+ snprintf(buf, sizeof(buf), %s/enlightenment/enlightenment_sys -t reboot, e_prefix_lib_get());
_e_sys_reboot_check_exe = ecore_exe_run(buf, NULL);
- snprintf(buf, sizeof(buf), %s/enlightenment_sys -t suspend, e_prefix_bin_get());
+ snprintf(buf, sizeof(buf), %s/enlightenment/enlightenment_sys -t suspend, e_prefix_lib_get());
_e_sys_suspend_check_exe = ecore_exe_run(buf, NULL);
- snprintf(buf, sizeof(buf), %s/enlightenment_sys -t hibernate, e_prefix_bin_get());
+ snprintf(buf, sizeof(buf), %s/enlightenment/enlightenment_sys -t hibernate, e_prefix_lib_get());
_e_sys_hibernate_check_exe = ecore_exe_run(buf, NULL);
return 0;
}
@@ -515,8 +515,8 @@
case E_SYS_HALT_NOW:
/* shutdown -h now */
if (e_util_immortal_check()) return 0;
- snprintf(buf, sizeof(buf), %s/enlightenment_sys halt,
- e_prefix_bin_get());
+ snprintf(buf, sizeof(buf), %s/enlightenment/enlightenment_sys halt,
+ e_prefix_lib_get());
if (_e_sys_exe)
{
_e_sys_current_action();
@@ -542,8 +542,8 @@
case E_SYS_REBOOT:
/* shutdown -r now */
if (e_util_immortal_check()) return 0;
- snprintf(buf, sizeof(buf), %s/enlightenment_sys reboot,
- e_prefix_bin_get());
+ snprintf(buf, sizeof(buf), %s/enlightenment/enlightenment_sys reboot,
+ e_prefix_lib_get());
if (_e_sys_exe)
{
_e_sys_current_action();
@@ -568,8 +568,8 @@
break;
case E_SYS_SUSPEND:
/* /etc/acpi/sleep.sh force */
- snprintf(buf, sizeof(buf), %s/enlightenment_sys suspend,
- e_prefix_bin_get());
+ snprintf(buf, sizeof(buf), %s/enlightenment/enlightenment_sys suspend,
+ e_prefix_lib_get());
if (_e_sys_exe)
{
_e_sys_current_action();
@@ -594,8 +594,8 @@
break;
case E_SYS_HIBERNATE:
/* /etc/acpi/hibernate.sh force */
- snprintf(buf, sizeof(buf), %s/enlightenment_sys hibernate,
- e_prefix_bin_get());
+ snprintf(buf, sizeof(buf), %s/enlightenment/enlightenment_sys hibernate,
+ e_prefix_lib_get());
if (_e_sys_exe)
{
_e_sys_current_action();
diff -Nur e/src/bin/e_thumb.c e.new/src/bin/e_thumb.c
--- e/src/bin/e_thumb.c 2008-11-30 23:08:27.0 +0100
+++ e.new/src/bin/e_thumb.c 2008-12-15 13:45:22.0 +0100
@@ -134,7 +134,7 @@
{
Ecore_Exe *exe;
- snprintf(buf, sizeof(buf), %s/enlightenment_thumb --nice=%d
