Re: [E-devel] Eina
Hi devs, this is a nice work. I compiled the lib on x86_64 bits system and i pass without problems. I attached the various information and warning in the error file. You will also find the results of the implemented tests (log file). Regards Mathieu So now, what remain in the TODO. Still some doc, but mainly compiling and running it on more computer/OS would be a good thing. Reviewing the API and it's internal too. It could be part of the autobuild too. And if nobody complain about it, eina should be moved out of PROTO at the end of the week. Perhaps making the autotools of each efl that could use it depend on eina in the same move, so that people working on it could easily replace old code with eina one. I already identified eet/evas/ecore/edje/efreet/e as the one that could benefit from a move (reduction in size code and speed improvement). Have fun ! ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined eina_hash.c: In function 'eina_hash_del': eina_hash.c:820: warning: 'hash_num' may be used uninitialized in this function ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined eina_array.c: In function 'eina_array_remove': eina_array.c:404: warning: 'data' may be used uninitialized in this function ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined eina_rbtree.c: In function 'eina_rbtree_inline_insert': eina_rbtree.c:248: warning: 'last' may be used uninitialized in this function ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined ../../../../src/include/eina_private.h:101: warning: inline function 'eina_print_warning' declared but never defined
Re: [E-devel] E SVN: cedric trunk/ecore/src/lib/ecore_con
On Mon, Oct 6, 2008 at 7:08 PM, Peter Wehrfritz [EMAIL PROTECTED]wrote:
Enlightenment SVN schrieb:
Log:
Another step toward IPv6 support with more cleanup.
Patch from Arnaud de Turckheim.
Author: cedric
Date: 2008-10-06 09:40:01 -0700 (Mon, 06 Oct 2008)
New Revision: 36483
Modified:
trunk/ecore/src/lib/ecore_con/ecore_con.c
trunk/ecore/src/lib/ecore_con/ecore_con_info.c
Modified: trunk/ecore/src/lib/ecore_con/ecore_con.c
===
--- trunk/ecore/src/lib/ecore_con/ecore_con.c 2008-10-06 15:58:21 UTC
(rev 36482)
+++ trunk/ecore/src/lib/ecore_con/ecore_con.c 2008-10-06 16:40:01 UTC
(rev 36483)
@@ -26,21 +26,23 @@
# include winsock2.h
#endif
-static void _ecore_con_cb_dns_lookup(void *data, struct hostent *he);
-static void _ecore_con_cb_udp_dns_lookup(void *data, struct hostent
*he);
static void _ecore_con_cb_tcp_connect(void *data, Ecore_Con_Netinfo
*info);
static void _ecore_con_cb_udp_connect(void *data, Ecore_Con_Netinfo
*info);
static void _ecore_con_cb_tcp_listen(void *data, Ecore_Con_Netinfo
*info);
static void _ecore_con_cb_udp_listen(void *data, Ecore_Con_Netinfo
*info);
+
static void _ecore_con_server_free(Ecore_Con_Server *svr);
static void _ecore_con_client_free(Ecore_Con_Client *cl);
+
static int _ecore_con_svr_handler(void *data, Ecore_Fd_Handler
*fd_handler);
static int _ecore_con_cl_handler(void *data, Ecore_Fd_Handler
*fd_handler);
static int _ecore_con_cl_udp_handler(void *data, Ecore_Fd_Handler
*fd_handler);
static int _ecore_con_svr_udp_handler(void *data, Ecore_Fd_Handler
*fd_handler);
static int _ecore_con_svr_cl_handler(void *data, Ecore_Fd_Handler
*fd_handler);
+
static void _ecore_con_server_flush(Ecore_Con_Server *svr);
static void _ecore_con_client_flush(Ecore_Con_Client *cl);
+
static void _ecore_con_event_client_add_free(void *data, void *ev);
static void _ecore_con_event_client_del_free(void *data, void *ev);
static void _ecore_con_event_client_data_free(void *data, void *ev);
@@ -57,8 +59,25 @@
static Ecore_List *servers = NULL;
static int init_count = 0;
+
#if USE_OPENSSL
static int ssl_init_count = 0;
+static int _ecore_con_init_ssl(Ecore_Con_Server *svr);
+static int _ecore_con_shutdown_ssl(Ecore_Con_Server *svr);
+static int _ecore_con_free_ssl(Ecore_Con_Server *svr);
+
+# define INIT_SSL(svr) _ecore_con_init_ssl(svr)
+# define SHUTDOWN_SSL(svr) _ecore_con_shutdown_ssl(svr)
+# define FREE_SSL(svr) _ecore_con_free_ssl(svr)
+# define UNSET_SSL(svr) \
+ do { \
+svr-ssl = NULL; \
+svr-ssl_ctx = NULL; \
+ } while (0);
The point of using do {} while(0) in macros, fades away if you append a
semicolon.
I'll remove the semicolon, sorry about that.
+#else
+# define INIT_SSL(svr) 0
+# define SHUTDOWN_SSL(svr) 0
+# define FREE_SSL(svr) 0
#endi
I haven't read the full code, but I think you are missing the
UNSET_SSL() for the !OPENSSL case.
We don't need UNSET_SSL() to be define when !USE_OPENSSL.
INIT_SSL, SHUTDOWN_SSL and FREE_SSL have to be define to 0 because these
macros are used in if tests.
Peter
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Arnaud de Turckheim
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/ecore/src/lib/ecore_con
On Tue, Oct 7, 2008 at 1:24 PM, Arnaud de Turckheim [EMAIL PROTECTED]wrote:
On Mon, Oct 6, 2008 at 7:08 PM, Peter Wehrfritz [EMAIL PROTECTED]wrote:
Enlightenment SVN schrieb:
Log:
Another step toward IPv6 support with more cleanup.
Patch from Arnaud de Turckheim.
Author: cedric
Date: 2008-10-06 09:40:01 -0700 (Mon, 06 Oct 2008)
New Revision: 36483
Modified:
trunk/ecore/src/lib/ecore_con/ecore_con.c
trunk/ecore/src/lib/ecore_con/ecore_con_info.c
Modified: trunk/ecore/src/lib/ecore_con/ecore_con.c
===
--- trunk/ecore/src/lib/ecore_con/ecore_con.c 2008-10-06 15:58:21 UTC
(rev 36482)
+++ trunk/ecore/src/lib/ecore_con/ecore_con.c 2008-10-06 16:40:01 UTC
(rev 36483)
@@ -26,21 +26,23 @@
# include winsock2.h
#endif
-static void _ecore_con_cb_dns_lookup(void *data, struct hostent *he);
-static void _ecore_con_cb_udp_dns_lookup(void *data, struct hostent
*he);
static void _ecore_con_cb_tcp_connect(void *data, Ecore_Con_Netinfo
*info);
static void _ecore_con_cb_udp_connect(void *data, Ecore_Con_Netinfo
*info);
static void _ecore_con_cb_tcp_listen(void *data, Ecore_Con_Netinfo
*info);
static void _ecore_con_cb_udp_listen(void *data, Ecore_Con_Netinfo
*info);
+
static void _ecore_con_server_free(Ecore_Con_Server *svr);
static void _ecore_con_client_free(Ecore_Con_Client *cl);
+
static int _ecore_con_svr_handler(void *data, Ecore_Fd_Handler
*fd_handler);
static int _ecore_con_cl_handler(void *data, Ecore_Fd_Handler
*fd_handler);
static int _ecore_con_cl_udp_handler(void *data, Ecore_Fd_Handler
*fd_handler);
static int _ecore_con_svr_udp_handler(void *data, Ecore_Fd_Handler
*fd_handler);
static int _ecore_con_svr_cl_handler(void *data, Ecore_Fd_Handler
*fd_handler);
+
static void _ecore_con_server_flush(Ecore_Con_Server *svr);
static void _ecore_con_client_flush(Ecore_Con_Client *cl);
+
static void _ecore_con_event_client_add_free(void *data, void *ev);
static void _ecore_con_event_client_del_free(void *data, void *ev);
static void _ecore_con_event_client_data_free(void *data, void *ev);
@@ -57,8 +59,25 @@
static Ecore_List *servers = NULL;
static int init_count = 0;
+
#if USE_OPENSSL
static int ssl_init_count = 0;
+static int _ecore_con_init_ssl(Ecore_Con_Server *svr);
+static int _ecore_con_shutdown_ssl(Ecore_Con_Server *svr);
+static int _ecore_con_free_ssl(Ecore_Con_Server *svr);
+
+# define INIT_SSL(svr) _ecore_con_init_ssl(svr)
+# define SHUTDOWN_SSL(svr) _ecore_con_shutdown_ssl(svr)
+# define FREE_SSL(svr) _ecore_con_free_ssl(svr)
+# define UNSET_SSL(svr) \
+ do { \
+svr-ssl = NULL; \
+svr-ssl_ctx = NULL; \
+ } while (0);
The point of using do {} while(0) in macros, fades away if you append a
semicolon.
I'll remove the semicolon, sorry about that.
+#else
+# define INIT_SSL(svr) 0
+# define SHUTDOWN_SSL(svr) 0
+# define FREE_SSL(svr) 0
#endi
I haven't read the full code, but I think you are missing the
UNSET_SSL() for the !OPENSSL case.
We don't need UNSET_SSL() to be define when !USE_OPENSSL.
INIT_SSL, SHUTDOWN_SSL and FREE_SSL have to be define to 0 because these
macros are used in if tests.
Hmmm... Sorry we definitively need to define UNSET_SSL()...
Peter
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Arnaud de Turckheim
--
Arnaud de Turckheim
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eina
On Tue, Oct 7, 2008 at 12:10 PM, Mathieu Taillefumier [EMAIL PROTECTED] wrote: this is a nice work. I compiled the lib on x86_64 bits system and i pass without problems. I attached the various information and warning in the error file. You will also find the results of the implemented tests (log file). Thanks for the report. eina_print_warning is a dead code, so I just removed it and most warning should be gone now. eina_hash.c: In function 'eina_hash_del': eina_hash.c:820: warning: 'hash_num' may be used uninitialized in this function This warning is a false positive as the code should never execute the code using hash_num if it's uninitialized. And I don't want to hide this warning as if this goes wrong somewhere valgrind will be able to tell me what is going on. eina_array.c: In function 'eina_array_remove': eina_array.c:404: warning: 'data' may be used uninitialized in this function In fact it's also a false positive as we should have leave the function before reaching this point if data is not initialized. eina_rbtree.c: In function 'eina_rbtree_inline_insert': eina_rbtree.c:248: warning: 'last' may be used uninitialized in this function This one is also a false positive, but it's really harder to understand, as it relly on red black tree property. In fact q and p could never be red and last not initialized, because when p == NULL, p must be considered as a black node. So during the first loop, their will be no test on last, but it will be setted and further used correctly. eina_ememoa_fixed.c: In function 'eina_ememoa_fixed_statistics': eina_ememoa_fixed.c:77: warning: unused variable 'efm' eina_ememoa_unknown.c: In function 'eina_ememoa_unknown_size_statistics': eina_ememoa_unknown.c:78: warning: unused variable 'efm' That's because of ememoa macro that doesn't use its parameters when debug is desactivated. Something that should be fixed in ememoa indeed. Running suite(s): Eina [eina_test_error.c:71] eina_error_macro() An error [eina_test_error.c:72] eina_error_macro() An info [eina_test_error.c:73] eina_error_macro() A warning [eina_test_error.c:74] eina_error_macro() A debug [31;1m[eina_test_magic.c:69] eina_magic_simple() [0m*** Eina Magic Check Failed !!! Input handle pointer is NULL ! *** NAUGHTY PROGRAMMER!!! *** SPANK SPANK SPANK!!! *** Now go fix your code. Tut tut tut! [31;1m[eina_test_magic.c:78] eina_magic_simple() [0m*** Eina Magic Check Failed !!! Input handle has already been freed! *** NAUGHTY PROGRAMMER!!! *** SPANK SPANK SPANK!!! *** Now go fix your code. Tut tut tut! [31;1m[eina_test_magic.c:81] eina_magic_simple() [0m*** Eina Magic Check Failed !!! Input handle is wrong type Expected: 7781fee7 - Eina Magic Test Supplied: 028757b2 - (null) *** NAUGHTY PROGRAMMER!!! *** SPANK SPANK SPANK!!! *** Now go fix your code. Tut tut tut! This are the result of checking the error subsystem, and every thing seems to be ok. # specimen experiment time starting time ending time 10 5635989 140939 5776928 20 142163605778156 19994516 Run specimens_check: 1000 100%: Checks: 51, Failures: 0, Errors: 0 So far so good. Thanks for reporting all of this. Between what compiler are you using ? -- Cedric BAIL - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: illogict trunk/e/src/modules/conf_interaction
On Tue, Oct 7, 2008 at 2:57 AM, Enlightenment SVN [EMAIL PROTECTED] wrote: Log: Some work on interaction settings: - group on a thumbscroll framelist; - threshhold ?\226?\134?\146 threshold; - add check changed. that's awesome, I see people liked the check_changed, we should add this to other dialogs as well. something else I'd like to see is to move, where possible, layouts to edje with swallow parts, that way we can have special layouts in embedded systems like illume. Side effect is to simplify code a lot. What do you think? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: illogict trunk/e/src/modules/conf_interaction
On Tue, Oct 7, 2008 at 10:00 AM, Toma [EMAIL PROTECTED] wrote: 2008/10/7 Gustavo Sverzut Barbieri [EMAIL PROTECTED]: On Tue, Oct 7, 2008 at 2:57 AM, Enlightenment SVN [EMAIL PROTECTED] wrote: Log: Some work on interaction settings: - group on a thumbscroll framelist; - threshhold ?\226?\134?\146 threshold; - add check changed. that's awesome, I see people liked the check_changed, we should add this to other dialogs as well. something else I'd like to see is to move, where possible, layouts to edje with swallow parts, that way we can have special layouts in embedded systems like illume. Side effect is to simplify code a lot. What do you think? Nah. Its hard enough to write a theme as it is. No need to complicate the matter further :(. You could just make illume work like that tho, since it has its own little theme. Since raster added the option to inherit + override edje groups, we can keep this a a separate layouts.edc file. My points are: - it's easier to write an edje group with swallows where you want, it's more powerful to describe relationships and create good layouts, edje_editor is your friend as well. Just notice i say where possible, some elements are dynamic and Edje still does not support such dynamic layouts (vbox, with variable number of items); - themes may wish to change the layout, illume is one of them because it's meant for small touch screen, this might serve for set top boxes to be controlled with remote control. so why not? :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eina
On Tue, Oct 7, 2008 at 8:20 AM, Cedric BAIL [EMAIL PROTECTED] wrote: eina_hash.c: In function 'eina_hash_del': eina_hash.c:820: warning: 'hash_num' may be used uninitialized in this function This warning is a false positive as the code should never execute the code using hash_num if it's uninitialized. And I don't want to hide this warning as if this goes wrong somewhere valgrind will be able to tell me what is going on. as for this warning and others related, it's due bad design, so it's indeed a bug. Ok, we're using the high-level api there to make it easy, that api will then choose whatever to use, and we're quite sure it will not use the wrong value, and we want to confirm that (with valgrind). But what should be done is to split the high level api into 2 static internal functions, that will be used by this high level api and by the function currently giving warnings. This way we remove the warnings and remove some parameters while calling the functions and still leaves option for compiler to remove the function call and duplicate the code if it is worth (inline). For this case it might not be the most dramatic optimization, but it will help everywhere. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: illogict trunk/e/src/modules/conf_interaction
On Tue, Oct 7, 2008 at 10:45 AM, Toma [EMAIL PROTECTED] wrote: 2008/10/7 Gustavo Sverzut Barbieri [EMAIL PROTECTED]: On Tue, Oct 7, 2008 at 10:00 AM, Toma [EMAIL PROTECTED] wrote: 2008/10/7 Gustavo Sverzut Barbieri [EMAIL PROTECTED]: On Tue, Oct 7, 2008 at 2:57 AM, Enlightenment SVN [EMAIL PROTECTED] wrote: Log: Some work on interaction settings: - group on a thumbscroll framelist; - threshhold ?\226?\134?\146 threshold; - add check changed. that's awesome, I see people liked the check_changed, we should add this to other dialogs as well. something else I'd like to see is to move, where possible, layouts to edje with swallow parts, that way we can have special layouts in embedded systems like illume. Side effect is to simplify code a lot. What do you think? Nah. Its hard enough to write a theme as it is. No need to complicate the matter further :(. You could just make illume work like that tho, since it has its own little theme. Since raster added the option to inherit + override edje groups, we can keep this a a separate layouts.edc file. My points are: - it's easier to write an edje group with swallows where you want, it's more powerful to describe relationships and create good layouts, edje_editor is your friend as well. Just notice i say where possible, some elements are dynamic and Edje still does not support such dynamic layouts (vbox, with variable number of items); - themes may wish to change the layout, illume is one of them because it's meant for small touch screen, this might serve for set top boxes to be controlled with remote control. so why not? :-) As long as it is entirely separate, and not required, then Id agree that its a good option to have. The basic setup for layouts is rather well set and thought out already, but i suppose it would be nice to demonstrate that flexibility. one thing: we already inherit groups from basic theme if they're not found in the selected theme, so we'll always have this fallback. as for well thought dialogs, yes, they're good already, but i guess it will be even easier to go that route. The more we make those things be evas-edje based, the more we win. See raster's new elementary toolkit, he made it easier to use and smaller by going that route. I want to add sequence box to edje before the end of the year, so even the dynamic elements will be possible. (For those that don't know what I mean with sequence box, it's a box, or container, that packs a sequence of objects, you can think of it as vertical/horizontal box or flow layout, that would position children like a text flow). This will be easy to add since we know have size hints as object property and we'll make edje use those. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: illogict trunk/e/src/modules/conf_interaction
2008/10/7 Gustavo Sverzut Barbieri [EMAIL PROTECTED]: On Tue, Oct 7, 2008 at 10:00 AM, Toma [EMAIL PROTECTED] wrote: 2008/10/7 Gustavo Sverzut Barbieri [EMAIL PROTECTED]: On Tue, Oct 7, 2008 at 2:57 AM, Enlightenment SVN [EMAIL PROTECTED] wrote: Log: Some work on interaction settings: - group on a thumbscroll framelist; - threshhold ?\226?\134?\146 threshold; - add check changed. that's awesome, I see people liked the check_changed, we should add this to other dialogs as well. something else I'd like to see is to move, where possible, layouts to edje with swallow parts, that way we can have special layouts in embedded systems like illume. Side effect is to simplify code a lot. What do you think? Nah. Its hard enough to write a theme as it is. No need to complicate the matter further :(. You could just make illume work like that tho, since it has its own little theme. Since raster added the option to inherit + override edje groups, we can keep this a a separate layouts.edc file. My points are: - it's easier to write an edje group with swallows where you want, it's more powerful to describe relationships and create good layouts, edje_editor is your friend as well. Just notice i say where possible, some elements are dynamic and Edje still does not support such dynamic layouts (vbox, with variable number of items); - themes may wish to change the layout, illume is one of them because it's meant for small touch screen, this might serve for set top boxes to be controlled with remote control. so why not? :-) As long as it is entirely separate, and not required, then Id agree that its a good option to have. The basic setup for layouts is rather well set and thought out already, but i suppose it would be nice to demonstrate that flexibility. Toma -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Edje gradient rel1/rel2
Hi all it seems to me that in edje the rel1 and rel2 properties of gradients are unused now. Gradient always use the fill properties, is this right? can I remove that unused props? Thanks Dave - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/ecore/src/lib/ecore_con
Arnaud de Turckheim schrieb:
On Tue, Oct 7, 2008 at 1:24 PM, Arnaud de Turckheim [EMAIL PROTECTED]wrote:
On Mon, Oct 6, 2008 at 7:08 PM, Peter Wehrfritz [EMAIL PROTECTED]wrote:
Enlightenment SVN schrieb:
+
+# define INIT_SSL(svr) _ecore_con_init_ssl(svr)
+# define SHUTDOWN_SSL(svr) _ecore_con_shutdown_ssl(svr)
+# define FREE_SSL(svr) _ecore_con_free_ssl(svr)
+# define UNSET_SSL(svr) \
+ do { \
+svr-ssl = NULL; \
+svr-ssl_ctx = NULL; \
+ } while (0);
The point of using do {} while(0) in macros, fades away if you append a
semicolon.
I'll remove the semicolon, sorry about that.
No problem.
+#else
+# define INIT_SSL(svr) 0
+# define SHUTDOWN_SSL(svr) 0
+# define FREE_SSL(svr) 0
#endi
I haven't read the full code, but I think you are missing the
UNSET_SSL() for the !OPENSSL case.
We don't need UNSET_SSL() to be define when !USE_OPENSSL.
INIT_SSL, SHUTDOWN_SSL and FREE_SSL have to be define to 0 because these
macros are used in if tests.
Hmmm... Sorry we definitively need to define UNSET_SSL()...
Yeah, I wasn't sure either, else I probably fixed it myself.
Peter
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: illogict trunk/e/src/modules/conf_interaction
2008/10/7 Gustavo Sverzut Barbieri [EMAIL PROTECTED]: On Tue, Oct 7, 2008 at 2:57 AM, Enlightenment SVN [EMAIL PROTECTED] wrote: Log: Some work on interaction settings: - group on a thumbscroll framelist; - threshhold ?\226?\134?\146 threshold; - add check changed. that's awesome, I see people liked the check_changed, we should add this to other dialogs as well. something else I'd like to see is to move, where possible, layouts to edje with swallow parts, that way we can have special layouts in embedded systems like illume. Side effect is to simplify code a lot. What do you think? Nah. Its hard enough to write a theme as it is. No need to complicate the matter further :(. You could just make illume work like that tho, since it has its own little theme. Toma -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] EFL in embedded devices... which devices?
Hi guys, My question is simple, but I dont found the answer... What embedded systems EFL was ported? I known openmoko and maemo, which others systems support EFL too? I am interested to develop efl in embedded devices, so I want to know what is the systems to develop for. Thank you. -- === Diogo Dutra Albuquerque - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL in embedded devices... which devices?
On Tue, Oct 7, 2008 at 4:47 PM, Diogo Dutra [EMAIL PROTECTED] wrote: Hi guys, My question is simple, but I dont found the answer... What embedded systems EFL was ported? I known openmoko and maemo, which others systems support EFL too? - arm imx31 and possible others freescale systems (we have imx31 running e17) - xscale/arm intel ce2110 (set top box, digital tv) - mips box for set top boxes, by free.fr I am interested to develop efl in embedded devices, so I want to know what is the systems to develop for. the one you have :-) really, linux should abstract most of stuff. what's often required to change is the media pipelines in the case you use gstreamer/ffmpeg. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL in embedded devices... which devices?
Ounnn, everyone forgot Windows CE based devices. Not completely ready, though. I'm working on it, these days. Vincent On Tue, 7 Oct 2008, Atton Jonathan wrote: hum with cedric and caro we thought about porting efl on Symbian, this is not a device but symbian works on embedded device :) Our idea is to have eyelight on a phone as the nokia n95 and try to display the presentation on a video projector with the phone. 2008/10/7 Gustavo Sverzut Barbieri [EMAIL PROTECTED] On Tue, Oct 7, 2008 at 4:47 PM, Diogo Dutra [EMAIL PROTECTED] wrote: Hi guys, My question is simple, but I dont found the answer... What embedded systems EFL was ported? I known openmoko and maemo, which others systems support EFL too? - arm imx31 and possible others freescale systems (we have imx31 running e17) - xscale/arm intel ce2110 (set top box, digital tv) - mips box for set top boxes, by free.fr I am interested to develop efl in embedded devices, so I want to know what is the systems to develop for. the one you have :-) really, linux should abstract most of stuff. what's often required to change is the media pipelines in the case you use gstreamer/ffmpeg. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Regards. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Ce message a été vérifié par MailScanner pour des virus ou des polluriels et rien de suspect n'a été trouvé. Message délivré par le serveur de messagerie de l'Université d'Evry. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Invitation for Enlightenment Project to Southern California Linux Expo 7x
Greetings, I would once again like to formerly invite the Enlightenment project to attend the 7th Annual Southern California Linux Expo. The show will be held February 20th-22nd, 2009 once again at the Westin LAX in Los Angeles, CA. SCALE 7x will be an excellent venue to showcase all the hard work going into Enlightenment 17 as well as other the other Enlightenment related applications. Because Enlightenment is an open source project, SCALE will provide a complementary booth on our show floor including all the usual amenities such a 6' table, chairs, 500W power drop, one Ethernet drop and 3-5 complementary passes to the show. I am including our application for dotORG exhibitors as well as our Call For Papers. If there is interest in having again Enlightenment presence at SCALE 7x, I encourage someone to answer the questions in the application. Any questions, please do not hesitate to ask. Thanks for your time! Gareth http://scale7x.socallinuxexpo.org/s7x_cfp http://scale7x.socallinuxexpo.org/s7x_call_for_dotOrg_exhibitors -- Gareth J. Greenaway [EMAIL PROTECTED] Voice - 877-831-2569 x130 Southern California Linux Expo http://www.socallinuxexpo.org - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL in embedded devices... which devices?
On Tue, 7 Oct 2008 16:47:50 -0300 Diogo Dutra [EMAIL PROTECTED] babbled: Hi guys, My question is simple, but I dont found the answer... What embedded systems EFL was ported? I known openmoko and maemo, which others systems support EFL too? I am interested to develop efl in embedded devices, so I want to know what is the systems to develop for. anything openembedded works on. efl doesn't need porting. it's ported. it works. all you need to do is compile it for your target. if it runs linux at any rate - embedded is just linux with a different architecture for the cpu. that's all. but if you MUST have a list of things that i have personally run EFL stuff on: compaq ipaq3660 sharp zaurus sl-5000 sharp zaurus sl-c860 openmoko gta01 openmoko gta02 nokia n800 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Enlightenment 17 from SVN requires CVS to configure
On Tue, 30 Sep 2008 23:36:29 +0200 Kim Woelders [EMAIL PROTECTED] wrote: On Tue, 30 Sep 2008 22:53:01 +0200, Eric Sandall [EMAIL PROTECTED] wrote: Quoting Ivan [EMAIL PROTECTED]: Is not E, but autopoint (a part of gettext) which requires cvs, so not much to do about it. Does E17 require autopoint? If not, can we remove it? As I mentioned, other EFL packages build fine without cvs installed, though most of them use automake 1.10 instead of 1.9 (not sure if that matters). Sure, remove it. There is no reason to assume it was put there for a reason. Grrr. Ok, seriously, any package using gettext requires autopoint when running autogen.sh unless you want to go into insane workarounds. And yes, e17 uses gettext. /Kim On Tue, 30 Sep 2008 23:35:00 +0200 Peter Wehrfritz [EMAIL PROTECTED] wrote: E17 doesn't require autopoint, it doesn't even require gettext, _but_ you need autopoint to generate the ./configure script. And that libs like eet, evas, edje, etc. don't need a library for i18n is more then obvious. E17 needs support for i18n. Peter Thanks both :), for now I'll just make sure we have cvs installed until gettext decides to getsmart. -sandalle -- Eric Sandall | Source Mage GNU/Linux Developer [EMAIL PROTECTED] PGP: 0xA8EFDD61 | http://www.sourcemage.org/ http://eric.sandall.us/ | http://counter.li.org/ #196285 signature.asc Description: PGP signature - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL in embedded devices... which devices?
On Tue, Oct 7, 2008 at 5:27 PM, Atton Jonathan [EMAIL PROTECTED] wrote: hum with cedric and caro we thought about porting efl on Symbian, this is not a device but symbian works on embedded device :) Our idea is to have eyelight on a phone as the nokia n95 and try to display the presentation on a video projector with the phone. It sounds great to me! Symbian is a great market for embedded, and I will love efl in it. Have you anything did about this? Or it is only speculations? 2008/10/7 Gustavo Sverzut Barbieri [EMAIL PROTECTED] On Tue, Oct 7, 2008 at 4:47 PM, Diogo Dutra [EMAIL PROTECTED] wrote: Hi guys, My question is simple, but I dont found the answer... What embedded systems EFL was ported? I known openmoko and maemo, which others systems support EFL too? - arm imx31 and possible others freescale systems (we have imx31 running e17) - xscale/arm intel ce2110 (set top box, digital tv) - mips box for set top boxes, by free.fr I am interested to develop efl in embedded devices, so I want to know what is the systems to develop for. the one you have :-) really, linux should abstract most of stuff. what's often required to change is the media pipelines in the case you use gstreamer/ffmpeg. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Regards. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- === Diogo Dutra Albuquerque Meu Curriculum Lattes: http://lattes.cnpq.br/3624796077679922 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] ANN: Guarana and Enjoy 0.1.0
Hello guys, ProFUSION is proud to announce the first public release of Guarana framework and its demo Enjoy. Guarana is a set of free software libraries to aid embedded application development. It comes with with a remote control access library, module loader, model-view-controller machinery, basic data structures and a fast growing widget set. Enjoy is a demo music player targeted at embedded touchscreen devices. It uses Guarana's MVC and widgets and Emotion to play media. More details, including screenshot and video of it running on imx31 see: http://profusion.mobi/node/10 Code: git clone git://git.profusion.mobi/guarana.git git clone git://git.profusion.mobi/enjoy.git Gitweb: http://gitweb.profusion.mobi/ -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL in embedded devices... which devices?
On Tue, 7 Oct 2008, Diogo Dutra wrote: On Tue, Oct 7, 2008 at 5:27 PM, Atton Jonathan [EMAIL PROTECTED] wrote: hum with cedric and caro we thought about porting efl on Symbian, this is not a device but symbian works on embedded device :) Our idea is to have eyelight on a phone as the nokia n95 and try to display the presentation on a video projector with the phone. It sounds great to me! Symbian is a great market for embedded, and I will love efl in it. Have you anything did about this? Or it is only speculations? Only speculations. We need someone who have a symbian device, who knows how to deal with graphics with it and who is motivated to port evas and ecore to symbian. I've seen that we can use the gdi or open gl es. gdi can be slow. open gl es should be very easy to port as most of the gl code is here, so we need someone who implement it in evas. It should not be very difficult. Another solution would be to access the framebuffer. cedric and I are too busy to really take time for that port. But we can help such person, of course. Vincent PS: I'm 'caro' - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
