Re: [E-devel] [PATCH] ecore main loop "fd_handlers_to_call" list optimization
On Thu, Dec 2, 2010 at 10:20 PM, Mike Blumenkrantz wrote: > On Thu, 2 Dec 2010 13:18:02 +0100 > Cedric BAIL wrote: >> On Thu, Dec 2, 2010 at 1:08 PM, Iván Briano (Sachiel) >> wrote: >> > 2010/12/2 Mike McCormack : >> >> On 12/02/2010 08:20 PM, Lucas De Marchi wrote: >> >>> On Thu, Dec 2, 2010 at 8:34 AM, Cedric BAIL wrote: >> On Thu, Dec 2, 2010 at 7:22 AM, Mike McCormack >> wrote: >> > Rather than using malloc'ed list entries in the mail loop, use a single >> > linked in-place list. >> > >> > This avoid lots of mallocs and frees as the main loop iterates. >> >> I like the idea, but I fear that doing change to the core main loop >> structure could break things. Maybe we should post pone this change to >> 1.1. From my point of view we already did to much change to ecore main >> loop during the beta cycle. >> >>> >> >>> I agree. >> >>> >> >>> How long are we for 1.0 release? >> >> >> >> Come on guys. >> >> >> >> The only reason that you're seeing this is that I don't commit directly to >> >> SVN. >> >> >> >> This is a tweak on fixes that have been put in by others in the last few >> >> days. If you object to this, please read the SVN commits list and object >> >> to the other patches in the same area. >> > >> > True, all the refactoring of fd handlers was a big enough thing to put >> > off until 1.1, >> > and it was done directly in SVN. So what's the reason to not commit >> > this one now? >> >> I know I should have objected at that time, but I didn't. Right now I >> think we already have to much change in the ecore main loop to feel >> safe with all possible scenario (glib integration, multiple ecore main >> loop imbrication and all) that I would really prefer to postpone more >> change in this aread. But that's just my opinion. If you really want >> to do it, wait at least for beta3 to be released tomorrow. > This change absolutely must go through before 1.0 if we want to have a > respectable main loop, and the following data will prove it. This data can > easily be replicated using the client/server_bench.c files in ecore/examples. > > ecore revision 54616: > === > 25000 fd test: > Connection lost! #10400! > ^C > Time elapsed for 25000 connections: 371.606825 seconds > # specimen experiment time starting time ending time > 1 645014268 3993714 649007982 > ./bench_client 4.38s user 0.70s system 1% cpu 6:11.76 total > (Note: at this point I killed it because after 10400 fds, ecore stopped > and no longer processed any connections) > ecore revision HEAD: > === > 25000 fd test with printf disabled: > Time elapsed for 25000 connections: 1.141623 seconds > # specimen experiment time starting time ending time > 1 1136243319 3866130 1140109449 > ./bench_client 0.43s user 0.91s system 98% cpu 1.356 total > 25000 fd test with Mike's newest patch: > Time elapsed for 25000 connections: 1.131604 seconds > # specimen experiment time starting time ending time > 1 1127458798 3833513 1131292311 > ./bench_client 0.43s user 0.91s system 99% cpu 1.345 total > > Again, a clear, though smaller, improvement. Regardless of whether this > specific patch makes it into 1.0, our policy here should definitely not be > "how > fast can we revert the work on ecore?", it should be "how fast and efficiently > can we test/fix this issue to make sure it's working as intended?" because > it's > definitely a bug. I beg to differ. In fact you are right for the first case, it was a bug, from unusable to usable. So that's fine. But new patch from Mike isn't, it's from fast to faster and it doesn't use Eina_Inlist, but it's own implementation. It also does touch a lot of logic inside ecore main loop, much more than what I would like for a beta cycle. So if that patch is not for fixing a bug, I would really prefer to postpone it. And as you guys are playing with ecore, we have still some report related to it that should be fixed for the release. It would be good if you could take care of them :-) Thanks, -- Cedric BAIL -- Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/edje/src/bin
On Fri, 3 Dec 2010, Enlightenment SVN wrote:
> Log:
> * edje: improve portability and simplify code.
>
> + snprintf(buf, sizeof(buf), "%s -I%s %s -E -o %s - < %s",
> + getenv("CC") ? getenv("CC") : "cc",
> inc, def, tmpn, file_in);
>ret = system(buf);
shouldn't you also pass
-x c
to force the language (gcc can rely on the file extension to select the
language) and
-std=c99
to be sure to remove the c++ comments
?
Vincent
--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/eet
On Fri, 3 Dec 2010, Enlightenment SVN wrote:
> Log:
> * eet: compile with -Werror on 64bits too.
on Win64, long long is of size 32 bits. You can use uintptr_t on Windows
And btw, shouldn't you use unsigned long long (to be pedantic) ?
Vincent
>
>
> Author: cedric
> Date: 2010-12-03 08:55:50 -0800 (Fri, 03 Dec 2010)
> New Revision: 55201
> Trac: http://trac.enlightenment.org/e/changeset/55201
>
> Modified:
> trunk/eet/configure.ac
>
> Modified: trunk/eet/configure.ac
> ===
> --- trunk/eet/configure.ac2010-12-03 16:49:20 UTC (rev 55200)
> +++ trunk/eet/configure.ac2010-12-03 16:55:50 UTC (rev 55201)
> @@ -368,8 +368,8 @@
> #include
> int main (int argc, char **argv) {
> void *foo = NULL;
> - int bar = (int)foo;
> - return (int)foo;
> + long long bar = (long long)foo;
> + return (long long)foo;
> }
>],
>[have_null="yes"],
>
>
> --
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
>
--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] elmdentica and strftime
in src/elmdentica.c:1081 and :1084 there are two strftime invocations which uses %F and %T flags, and in the generated elmdentica.pot file the first strings is detected as c-format. this situation prevents changing the flag in the translated po file because msgfmt errors out. I would suggest to use %x and %X to print the time as defined in the system locale, but if it would not be possible please add at least the following comment in the same line (or the preceding one) where is the strftime invocation to tell gettext to not consider it as a c-format strings: # xgettext:no-c-format thanks :) -- Massimo Maiurana massimoragusa.linux.it http://massimo.solira.orgGPG keyID #7044D601 Creare l'uomo fu un'idea bizzarra e originale, ma aggiungere la pecora fu una tautologia. [Mark Twain] signature.asc Description: OpenPGP digital signature -- Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/edje/src/bin
On Fri, Dec 3, 2010 at 5:57 PM, Vincent Torri wrote:
> On Fri, 3 Dec 2010, Enlightenment SVN wrote:
>> Log:
>> * edje: improve portability and simplify code.
>>
>> + snprintf(buf, sizeof(buf), "%s -I%s %s -E -o %s - < %s",
>> + getenv("CC") ? getenv("CC") : "cc",
>> inc, def, tmpn, file_in);
>> ret = system(buf);
>
> shouldn't you also pass
>
> -x c
>
> to force the language (gcc can rely on the file extension to select the
No need as I pass it using redirection instead of directly the
filename. That was to avoid complexifying the command line.
> language) and
> -std=c99
>
> to be sure to remove the c++ comments ?
Good question, don't know if it will be supported by other compiler
than gcc. What's your opinion ?
--
Cedric BAIL
--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/eet
On Fri, Dec 3, 2010 at 6:00 PM, Vincent Torri wrote: > On Fri, 3 Dec 2010, Enlightenment SVN wrote: >> Log: >> * eet: compile with -Werror on 64bits too. > > on Win64, long long is of size 32 bits. You can use uintptr_t on Windows Is that type available every where ? > And btw, shouldn't you use unsigned long long (to be pedantic) ? Don't think that one is necessary. -- Cedric BAIL -- Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/edje/src/bin
On Fri, 3 Dec 2010, Cedric BAIL wrote:
On Fri, Dec 3, 2010 at 5:57 PM, Vincent Torri wrote:
On Fri, 3 Dec 2010, Enlightenment SVN wrote:
Log:
* edje: improve portability and simplify code.
+ snprintf(buf, sizeof(buf), "%s -I%s %s -E -o %s - < %s",
+ getenv("CC") ? getenv("CC") : "cc",
inc, def, tmpn, file_in);
ret = system(buf);
shouldn't you also pass
-x c
to force the language (gcc can rely on the file extension to select the
No need as I pass it using redirection instead of directly the
filename. That was to avoid complexifying the command line.
language) and
-std=c99
to be sure to remove the c++ comments ?
Good question, don't know if it will be supported by other compiler
than gcc. What's your opinion ?
sun (oracle) compiler: -xc99 (no -std option)
icc: -std=c99
x86 open64 (amd) : -std=c99
vc++ (cl.exe): i don't know
so maybe try first with -std=c99 ; if the command fails, try with -xc99
I don't know other interesting compiler
Vincent--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/eet
On Fri, 3 Dec 2010, Cedric BAIL wrote: On Fri, Dec 3, 2010 at 6:00 PM, Vincent Torri wrote: On Fri, 3 Dec 2010, Enlightenment SVN wrote: Log: * eet: compile with -Werror on 64bits too. on Win64, long long is of size 32 bits. You can use uintptr_t on Windows Is that type available every where ? on all Windows versions, yes. Otherwise, it's a C99 type. Vincent-- Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/embryo/src/bin
On Fri, 3 Dec 2010, Enlightenment SVN wrote:
> Log:
> * embryo: fix binary path detection on MacOsX.
>
>
> Author: cedric
> Date: 2010-12-03 09:48:17 -0800 (Fri, 03 Dec 2010)
> New Revision: 55208
> Trac: http://trac.enlightenment.org/e/changeset/55208
>
> Modified:
> trunk/embryo/src/bin/embryo_cc_prefix.c
>
> Modified: trunk/embryo/src/bin/embryo_cc_prefix.c
> ===
> --- trunk/embryo/src/bin/embryo_cc_prefix.c 2010-12-03 17:28:18 UTC (rev
> 55207)
> +++ trunk/embryo/src/bin/embryo_cc_prefix.c 2010-12-03 17:48:17 UTC (rev
> 55208)
> @@ -29,6 +29,10 @@
> # include
> #endif /* ! HAVE_EVIL */
>
> +#ifdef __MacOSX__
are you sure it exists on all mac os x platform ?
maybe we should detect it at configure time. It would be safer (same for
eina_cpu)
Vincent
> +# include
> +#endif
> +
> #include "embryo_cc_prefix.h"
>
> /* local subsystem functions */
> @@ -36,6 +40,9 @@
> static int _e_prefix_fallbacks(void);
> static int _e_prefix_try_proc(void);
> static int _e_prefix_try_argv(char *argv0);
> +#ifdef __MacOSX__
> +static int _e_prefix_try_dyld(void);
> +#endif
>
> /* local subsystem globals */
> static char *_exe_path = NULL;
> @@ -89,8 +96,16 @@
> {
> if (!_e_prefix_try_argv(argv0))
> {
> - _e_prefix_fallbacks();
> - return 0;
> +#ifdef __MacOSX__
> + if (!_e_prefix_try_dyld())
> + {
> +#endif
> + _e_prefix_fallbacks();
> + return 0;
> +#ifdef __MacOSX__
> + }
> +#endif
> +
> }
> }
>/* _exe_path is now a full absolute path TO this exe - figure out rest */
> @@ -313,7 +328,22 @@
>return 1;
> }
>
> +#ifdef __MacOSX__
> static int
> +_e_prefix_try_dyld(void)
> +{
> + char path[PATH_MAX];
> + uint32_t size = sizeof (path);
> +
> + if (_NSGetExecutablePath(path, &size) != 0)
> + return 0;
> +
> + _exe_path = strdup(path);
> + return 1;
> +}
> +#endif
> +
> +static int
> _e_prefix_try_proc(void)
> {
>FILE *f;
>
>
> --
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
>
--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/embryo/src/bin
On Fri, Dec 3, 2010 at 6:53 PM, Vincent Torri wrote: > On Fri, 3 Dec 2010, Enlightenment SVN wrote: >> Log: >> * embryo: fix binary path detection on MacOsX. >> >> >> Author: cedric >> Date: 2010-12-03 09:48:17 -0800 (Fri, 03 Dec 2010) >> New Revision: 55208 >> Trac: http://trac.enlightenment.org/e/changeset/55208 >> >> Modified: >> trunk/embryo/src/bin/embryo_cc_prefix.c >> >> Modified: trunk/embryo/src/bin/embryo_cc_prefix.c >> === >> --- trunk/embryo/src/bin/embryo_cc_prefix.c 2010-12-03 17:28:18 UTC (rev >> 55207) >> +++ trunk/embryo/src/bin/embryo_cc_prefix.c 2010-12-03 17:48:17 UTC (rev >> 55208) >> @@ -29,6 +29,10 @@ >> # include >> #endif /* ! HAVE_EVIL */ >> >> +#ifdef __MacOSX__ > > are you sure it exists on all mac os x platform ? It's available on all platform supported by Apple right now. That is 10.5 and 10.6, I don't think we need to support more version than that. > maybe we should detect it at configure time. It would be safer (same for > eina_cpu) Maybe, but I don't think its worth it at the moment. -- Cedric BAIL -- Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/edje/src/lib
On Fri, Dec 3, 2010 at 4:21 PM, Enlightenment SVN
wrote:
> Log:
> * edje: SPANK ! SPANK ! SPANK !
>
> fprintf should always specify a format.
>
>
> Author: cedric
> Date: 2010-12-03 10:21:56 -0800 (Fri, 03 Dec 2010)
> New Revision: 55213
> Trac: http://trac.enlightenment.org/e/changeset/55213
>
> Modified:
> trunk/edje/src/lib/edje_edit.c
>
> Modified: trunk/edje/src/lib/edje_edit.c
> ===
> --- trunk/edje/src/lib/edje_edit.c 2010-12-03 18:12:19 UTC (rev 55212)
> +++ trunk/edje/src/lib/edje_edit.c 2010-12-03 18:21:56 UTC (rev 55213)
> @@ -6357,7 +6357,7 @@
> success = EINA_FALSE;
> }
> else
> - fprintf(f, eed->embryo_processed);
> + fprintf(f, "%s", eed->embryo_processed);
> }
>
> it = eina_hash_iterator_data_new(eed->program_scripts);
> @@ -6384,7 +6384,7 @@
> continue;
> }
> fprintf(f, "public _p%i(sig[], src[]) {\n", ps->id);
> - fprintf(f, ps->processed);
> + fprintf(f, "%s", ps->processed);
although GCC is smart and it shouldn't matter much, you should
actually call fputs() :-) (gcc should do it automatically)
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric IN trunk: e_dbus ecore edje eet eeze efreet eina embryo evas
hello, is that the beta3 before 1.0 ? thanks. Daniel Juyung Seo. On Sat, Dec 4, 2010 at 9:50 AM, Enlightenment SVN wrote: > Log: > * eina,eet,embryo,evas,ecore,edje,efreet,e_dbus,eeze: beta3 ! > > > Author: cedric > Date: 2010-12-03 16:50:58 -0800 (Fri, 03 Dec 2010) > New Revision: 55238 > Trac: http://trac.enlightenment.org/e/changeset/55238 > > Modified: > trunk/e_dbus/configure.ac trunk/ecore/configure.ac trunk/edje/configure.ac > trunk/eet/configure.ac trunk/eeze/configure.ac trunk/efreet/configure.ac > trunk/eina/configure.ac trunk/embryo/configure.ac trunk/evas/configure.ac > > Modified: trunk/e_dbus/configure.ac > === > --- trunk/e_dbus/configure.ac 2010-12-04 00:46:01 UTC (rev 55237) > +++ trunk/e_dbus/configure.ac 2010-12-04 00:50:58 UTC (rev 55238) > @@ -19,7 +19,7 @@ > ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## > ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## > > -AC_INIT([e_dbus], [v_ver.beta2], [enlightenment-de...@lists.sourceforge.net]) > +AC_INIT([e_dbus], [v_ver.beta3], [enlightenment-de...@lists.sourceforge.net]) > AC_PREREQ([2.52]) > AC_CONFIG_SRCDIR([configure.ac]) > AC_CONFIG_MACRO_DIR([m4]) > > Modified: trunk/ecore/configure.ac > === > --- trunk/ecore/configure.ac 2010-12-04 00:46:01 UTC (rev 55237) > +++ trunk/ecore/configure.ac 2010-12-04 00:50:58 UTC (rev 55238) > @@ -18,7 +18,7 @@ > ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## > ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## > > -AC_INIT([ecore], [v_ver.beta2], [enlightenment-de...@lists.sourceforge.net]) > +AC_INIT([ecore], [v_ver.beta3], [enlightenment-de...@lists.sourceforge.net]) > AC_PREREQ([2.52]) > AC_CONFIG_SRCDIR([configure.ac]) > AC_CONFIG_MACRO_DIR([m4]) > > Modified: trunk/edje/configure.ac > === > --- trunk/edje/configure.ac 2010-12-04 00:46:01 UTC (rev 55237) > +++ trunk/edje/configure.ac 2010-12-04 00:50:58 UTC (rev 55238) > @@ -18,7 +18,7 @@ > ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## > ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## > > -AC_INIT([edje], [v_ver.beta2], [enlightenment-de...@lists.sourceforge.net]) > +AC_INIT([edje], [v_ver.beta3], [enlightenment-de...@lists.sourceforge.net]) > AC_PREREQ([2.52]) > AC_CONFIG_SRCDIR([configure.ac]) > AC_CONFIG_MACRO_DIR([m4]) > > Modified: trunk/eet/configure.ac > === > --- trunk/eet/configure.ac 2010-12-04 00:46:01 UTC (rev 55237) > +++ trunk/eet/configure.ac 2010-12-04 00:50:58 UTC (rev 55238) > @@ -18,7 +18,7 @@ > ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## > ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## > > -AC_INIT([eet], [v_ver.beta2], [enlightenment-de...@lists.sourceforge.net]) > +AC_INIT([eet], [v_ver.beta3], [enlightenment-de...@lists.sourceforge.net]) > AC_PREREQ([2.52]) > AC_CONFIG_SRCDIR([configure.ac]) > AC_CONFIG_MACRO_DIR([m4]) > > Modified: trunk/eeze/configure.ac > === > --- trunk/eeze/configure.ac 2010-12-04 00:46:01 UTC (rev 55237) > +++ trunk/eeze/configure.ac 2010-12-04 00:50:58 UTC (rev 55238) > @@ -18,7 +18,7 @@ > ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## > ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## > > -AC_INIT([eeze], [v_ver.beta2], [enlightenment-de...@lists.sourceforge.net]) > +AC_INIT([eeze], [v_ver.beta3], [enlightenment-de...@lists.sourceforge.net]) > AC_PREREQ([2.52]) > AC_CONFIG_SRCDIR([configure.ac]) > AC_CONFIG_MACRO_DIR([m4]) > > Modified: trunk/efreet/configure.ac > === > --- trunk/efreet/configure.ac 2010-12-04 00:46:01 UTC (rev 55237) > +++ trunk/efreet/configure.ac 2010-12-04 00:50:58 UTC (rev 55238) > @@ -18,7 +18,7 @@ > ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## > ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## > > -AC_INIT([efreet], [v_ver.beta2], [enlightenment-de...@lists.sourceforge.net]) > +AC_INIT([efreet], [v_ver.beta3], [enlightenment-de...@lists.sourceforge.net]) > AC_PREREQ([2.52]) > AC_CONFIG_SRCDIR([configure.ac]) > AC_CONFIG_MACRO_DIR([m4]) > > Modified: trunk/eina/configure.ac > === > --- trunk/eina/configure.ac 2010-12-04 00:46:01 UTC (rev 55237) > +++ trunk/eina/configure.ac 2010-12-04 00:50:58 UTC (rev 55238) > @@ -18,7 +18,7 @@ > ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## > ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## > > -AC_INIT([eina], [v_ver.beta
Re: [E-devel] [PATCH] ecore main loop "fd_handlers_to_call" list optimization
On Sat, 4 Dec 2010 10:25:30 +0900 Carsten Haitzler (The Rasterman) wrote: > On Thu, 2 Dec 2010 16:20:36 -0500 Mike Blumenkrantz said: > > > On Thu, 2 Dec 2010 13:18:02 +0100 > > Cedric BAIL wrote: > > > > > On Thu, Dec 2, 2010 at 1:08 PM, Iván Briano (Sachiel) > > > wrote: > > > > 2010/12/2 Mike McCormack : > > > >> On 12/02/2010 08:20 PM, Lucas De Marchi wrote: > > > >>> On Thu, Dec 2, 2010 at 8:34 AM, Cedric BAIL > > > >>> wrote: > > > On Thu, Dec 2, 2010 at 7:22 AM, Mike > > > McCormack wrote: > > > > Rather than using malloc'ed list entries in the mail loop, use a > > > > single linked in-place list. > > > > > > > > This avoid lots of mallocs and frees as the main loop iterates. > > > > > > I like the idea, but I fear that doing change to the core main loop > > > structure could break things. Maybe we should post pone this change > > > to 1.1. From my point of view we already did to much change to ecore > > > main loop during the beta cycle. > > > >>> > > > >>> I agree. > > > >>> > > > >>> How long are we for 1.0 release? > > > >> > > > >> Come on guys. > > > >> > > > >> The only reason that you're seeing this is that I don't commit directly > > > >> to SVN. > > > >> > > > >> This is a tweak on fixes that have been put in by others in the last > > > >> few days. If you object to this, please read the SVN commits list and > > > >> object to the other patches in the same area. > > > > > > > > True, all the refactoring of fd handlers was a big enough thing to put > > > > off until 1.1, > > > > and it was done directly in SVN. So what's the reason to not commit > > > > this one now? > > > > > > I know I should have objected at that time, but I didn't. Right now I > > > think we already have to much change in the ecore main loop to feel > > > safe with all possible scenario (glib integration, multiple ecore main > > > loop imbrication and all) that I would really prefer to postpone more > > > change in this aread. But that's just my opinion. If you really want > > > to do it, wait at least for beta3 to be released tomorrow. > > > > > > Thanks, > > This change absolutely must go through before 1.0 if we want to have a > > respectable main loop, and the following data will prove it. This data can > > easily be replicated using the client/server_bench.c files in > > ecore/examples. > > > > ecore revision 54616: > > === > > 25000 fd test: > > Connection lost! #10400! > > ^C > > Time elapsed for 25000 connections: 371.606825 seconds > > # specimen experiment time starting time ending time > > 1 645014268 3993714 649007982 > > ./bench_client 4.38s user 0.70s system 1% cpu 6:11.76 total > > (Note: at this point I killed it because after 10400 fds, ecore stopped > > and no longer processed any connections) > > > > 1 fd test: > > Connection lost! #8933! > > ^C > > Time elapsed for 1 connections: 443.156038 seconds > > # specimen experiment time starting time ending time > > 1 746600745 3902720 750503465 > > ./bench_client 0.55s user 0.28s system 0% cpu 7:23.28 total > > (Note: at this point I killed it because after 8933 fds, ecore stopped > > and no longer processed any connections) > > > > 5000 fd test: > > Time elapsed for 5000 connections: 45.284662 seconds > > # specimen experiment time starting time ending time > > 1 259416526 3992216 263408742 > > ./bench_client 0.14s user 0.16s system 0% cpu 45.331 total > > > > 2000 fd test: > > Time elapsed for 2000 connections: 3.086964 seconds > > # specimen experiment time starting time ending time > > 1 101628352 3916119 105544471 > > ./bench_client 0.05s user 0.07s system 3% cpu 3.107 total > > > > 1000 fd test: > > Time elapsed for 1000 connections: 0.048472 seconds > > # specimen experiment time starting time ending time > > 1 472029003945319 51148219 > > ./bench_client 0.02s user 0.03s system 96% cpu 0.060 total > > > > A note about the above results: The numbers for the first two tests were the > > "best" that I could achieve. I ran both tests multiple times to attempt the > > highest number of connections possible. When ecore showed no further > > connections after a full minute, I ended the test. The reason why the 25k > > fd test achieves more connections is because it sends more attempts in the > > same amount of time, allowing for more to be successfully picked up (like > > throwing a bunch of marbles at something far away, only a few will hit). > > > > Here are the exact same tests once again. > > ecore revision HEAD: > > === > > 25000 fd test with printf disabled: > > Time elapsed for 25000 connections: 1.141623 seconds > > # specimen experiment time starting time ending time > > 1 1136243319 3866130 1140109449 > > ./bench_client 0.43s user 0.91s system 98% cpu 1.356 total > > > > 25000 fd test: > > Time elapsed for 25000 connections: 3.439958 seconds > > # specimen
Re: [E-devel] E SVN: cedric trunk/edje/src/bin
On Fri, 3 Dec 2010 18:47:38 +0100 (CET) Vincent Torri
said:
>
>
> On Fri, 3 Dec 2010, Cedric BAIL wrote:
>
> > On Fri, Dec 3, 2010 at 5:57 PM, Vincent Torri wrote:
> >> On Fri, 3 Dec 2010, Enlightenment SVN wrote:
> >>> Log:
> >>> * edje: improve portability and simplify code.
> >>>
> >>> + snprintf(buf, sizeof(buf), "%s -I%s %s -E -o %s - < %s",
> >>> + getenv("CC") ? getenv("CC") : "cc",
> >>> inc, def, tmpn, file_in);
> >>> ret = system(buf);
> >>
> >> shouldn't you also pass
> >>
> >> -x c
> >>
> >> to force the language (gcc can rely on the file extension to select the
> >
> > No need as I pass it using redirection instead of directly the
> > filename. That was to avoid complexifying the command line.
> >
> >> language) and
> >
> >> -std=c99
> >>
> >> to be sure to remove the c++ comments ?
> >
> > Good question, don't know if it will be supported by other compiler
> > than gcc. What's your opinion ?
>
> sun (oracle) compiler: -xc99 (no -std option)
> icc: -std=c99
> x86 open64 (amd) : -std=c99
> vc++ (cl.exe): i don't know
>
> so maybe try first with -std=c99 ; if the command fails, try with -xc99
>
> I don't know other interesting compiler
actually... this brings up a bit of an issue. using cpp/cc/gcc to handle
#includes and macros and #ifdefs and so on was a handy idea... but it creates a
LOT of problems in the maintainability and portability of edje_cc due to
relying on a nebulous cpp that may or may not behave as we expect.
i'm thinking post 1.0 a lot of these features should go into edje_cc itself.
being able to do includes and macros - maybe we can do much more intelligent
macros that are able to understand the rest of the edc syntax and model.
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
What happens now with your Lotus Notes apps - do you make another costly
upgrade, or settle for being marooned without product support? Time to move
off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
use, and manage than apps on traditional platforms. Sign up for the Lotus
Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] elm_transit
On Thu, 02 Dec 2010 04:35:32 + (GMT) ChunEon Park said: hmm it is a bit confusing (trhe api) well.. ok - not confusing. simply... less obvious and instantly recognisable. it needs a little thought. we could have both api's and deprecate 1 for now and wait for people to move over and finally kill it off. that's my suggestion. > >Ah.. of course when i named this API, > >I remember there are no enabled_set maybe. > > >The problem is that current SLP developers may use this APIs. > >So if it did not need to change, i just prefered keeping. > > >Thanks. :) > > >--- Original Message --- > >Sender : 박춘언 E3(사원)/사원/Mobile S/W > Platform Lab(DMC연)/삼성전자 > >Date : 2010-12-02 13:19 (GMT+09:00) > >Title : Re: [E-devel] [Patch] elm_transit > > > Hi this is Hermet. > The reason why i used the API name is any other APIs follow the naming >rule. > For example, > elm_object_disabled_set, > elm_gengrid_item_disabled_set > elm_entry_context_menu_disabled_set > elm_toobl_item_disabled_set > > Frackly, I dont prefer disabled_set. > It makes people thinked one more. > However, I just followed the naming rule. > if the default is the enabled, then it provides disabled_set > If this is my fault, OK I agree with you. > Thanks. > --- Original Message --- > Sender : Dave Andreoli > Date : 2010-12-02 08:53 (GMT+09:00) > Title : Re: [E-devel] [Patch] elm_transit > 2010/12/1 Gustavo Sverzut Barbieri : > > On Wed, Dec 1, 2010 at 4:00 PM, Daniel Juyung Seo wrote: > >> I agree with Helen. > >> > >> Even the event block is set by default > >> and I understand why Hermet prefers > elm_transit_event_block_disabled_set(), > >> elm_transit_event_block_set(transit, EINA_TRUE) > >> is less confusing than > >> elm_transit_event_block_disabled_set(transit, EINA_TRUE). > >> > >> But I think BOTH are confusing. > >> > >> I suggest another solution for this. > >> Why don't you use > >> elm_transit_event_enabled_set(transit, EINA_TRUE) instead? > >> Because event is blocked by default, > >> someone who wants to use events needs to call > >> elm_transit_event_enabled_set() API. > > > > +1, that seems the most reasonable api. > indeed +1 > davemds > > > > -- > > Gustavo Sverzut Barbieri > > http://profusion.mobi embedded systems > > -- > > MSN: barbi...@gmail.com > > Skype: gsbarbieri > > Mobile: +55 (19) 9225-2202 > > > > > > > > -- > > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > > Tap into the largest installed PC base & get more eyes on your game by > > optimizing for Intel(R) Graphics Technology. Get started today with > > the Intel(R) Software Partner Program. Five $500 cash prizes are up > > for >grabs. > > http://p.sf.net/sfu/intelisp-dev2dev > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > -- > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for >grabs. > http://p.sf.net/sfu/intelisp-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > [cid:V0UVOUUB9220@namo.co.kr] > >[SeenTimeChecker? > do=d9ce704749a25c62756122855015f930f101de264366a50c6b754d17 > > > d001ca18ba777c355c197185c465c2cf80a2b7ef9aba4bb3b2b5ca43ddd7e184e0604d958075 > b6b33f32d245b7f8aafe245478a5f1d21d5ebee74427cf878f9a26ce15a0] > > >[cid:XT4NZ5JE7EUA@namo.co.kr] > >[SeenTimeChecker? > do=d9ce704749a25c621a7b3bbe209e285e9991b7b6d404ee9e6b754d17 > d001ca18ba777c355c197185c465c2cf80a2b7ef9aba4bb3b2b5ca43ddd7e184e0604d958075 > b6b33f32d245b7f8aafe245478a5f1d21d5ebee74427cf878f9a26ce15a0] -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- What happens now with your Lotus Notes apps - do you make another cost
Re: [E-devel] [PATCH] ecore main loop "fd_handlers_to_call" list optimization
On Thu, 2 Dec 2010 16:20:36 -0500 Mike Blumenkrantz said: > On Thu, 2 Dec 2010 13:18:02 +0100 > Cedric BAIL wrote: > > > On Thu, Dec 2, 2010 at 1:08 PM, Iván Briano (Sachiel) > > wrote: > > > 2010/12/2 Mike McCormack : > > >> On 12/02/2010 08:20 PM, Lucas De Marchi wrote: > > >>> On Thu, Dec 2, 2010 at 8:34 AM, Cedric BAIL wrote: > > On Thu, Dec 2, 2010 at 7:22 AM, Mike > > McCormack wrote: > > > Rather than using malloc'ed list entries in the mail loop, use a > > > single linked in-place list. > > > > > > This avoid lots of mallocs and frees as the main loop iterates. > > > > I like the idea, but I fear that doing change to the core main loop > > structure could break things. Maybe we should post pone this change to > > 1.1. From my point of view we already did to much change to ecore main > > loop during the beta cycle. > > >>> > > >>> I agree. > > >>> > > >>> How long are we for 1.0 release? > > >> > > >> Come on guys. > > >> > > >> The only reason that you're seeing this is that I don't commit directly > > >> to SVN. > > >> > > >> This is a tweak on fixes that have been put in by others in the last few > > >> days. If you object to this, please read the SVN commits list and object > > >> to the other patches in the same area. > > > > > > True, all the refactoring of fd handlers was a big enough thing to put > > > off until 1.1, > > > and it was done directly in SVN. So what's the reason to not commit > > > this one now? > > > > I know I should have objected at that time, but I didn't. Right now I > > think we already have to much change in the ecore main loop to feel > > safe with all possible scenario (glib integration, multiple ecore main > > loop imbrication and all) that I would really prefer to postpone more > > change in this aread. But that's just my opinion. If you really want > > to do it, wait at least for beta3 to be released tomorrow. > > > > Thanks, > This change absolutely must go through before 1.0 if we want to have a > respectable main loop, and the following data will prove it. This data can > easily be replicated using the client/server_bench.c files in ecore/examples. > > ecore revision 54616: > === > 25000 fd test: > Connection lost! #10400! > ^C > Time elapsed for 25000 connections: 371.606825 seconds > # specimenexperiment time starting time ending time > 1 645014268 3993714 649007982 > ./bench_client 4.38s user 0.70s system 1% cpu 6:11.76 total > (Note: at this point I killed it because after 10400 fds, ecore stopped > and no longer processed any connections) > > 1 fd test: > Connection lost! #8933! > ^C > Time elapsed for 1 connections: 443.156038 seconds > # specimenexperiment time starting time ending time > 1 746600745 3902720 750503465 > ./bench_client 0.55s user 0.28s system 0% cpu 7:23.28 total > (Note: at this point I killed it because after 8933 fds, ecore stopped > and no longer processed any connections) > > 5000 fd test: > Time elapsed for 5000 connections: 45.284662 seconds > # specimenexperiment time starting time ending time > 1 259416526 3992216 263408742 > ./bench_client 0.14s user 0.16s system 0% cpu 45.331 total > > 2000 fd test: > Time elapsed for 2000 connections: 3.086964 seconds > # specimenexperiment time starting time ending time > 1 101628352 3916119 105544471 > ./bench_client 0.05s user 0.07s system 3% cpu 3.107 total > > 1000 fd test: > Time elapsed for 1000 connections: 0.048472 seconds > # specimenexperiment time starting time ending time > 1 472029003945319 51148219 > ./bench_client 0.02s user 0.03s system 96% cpu 0.060 total > > A note about the above results: The numbers for the first two tests were the > "best" that I could achieve. I ran both tests multiple times to attempt the > highest number of connections possible. When ecore showed no further > connections after a full minute, I ended the test. The reason why the 25k fd > test achieves more connections is because it sends more attempts in the same > amount of time, allowing for more to be successfully picked up (like throwing > a bunch of marbles at something far away, only a few will hit). > > Here are the exact same tests once again. > ecore revision HEAD: > === > 25000 fd test with printf disabled: > Time elapsed for 25000 connections: 1.141623 seconds > # specimenexperiment time starting time ending time > 1 1136243319 3866130 1140109449 > ./bench_client 0.43s user 0.91s system 98% cpu 1.356 total > > 25000 fd test: > Time elapsed for 25000 connections: 3.439958 seconds > # specimenexperiment time starting time ending time > 1 -892811351 3977067 -34284 > ./bench_client 0.44s user 0.94s system 37% cpu 3.651 total > > 1 fd test: > Time elapsed for 1 connections: 0.479854 seconds > # specimenexperiment time starting time ending time > 1
Re: [E-devel] [Patch] elm_transit
On Thu, 2 Dec 2010 00:53:22 +0100 Dave Andreoli said: > 2010/12/1 Gustavo Sverzut Barbieri : > > On Wed, Dec 1, 2010 at 4:00 PM, Daniel Juyung Seo > > wrote: > >> I agree with Helen. > >> > >> Even the event block is set by default > >> and I understand why Hermet prefers elm_transit_event_block_disabled_set(), > >> elm_transit_event_block_set(transit, EINA_TRUE) > >> is less confusing than > >> elm_transit_event_block_disabled_set(transit, EINA_TRUE). > >> > >> But I think BOTH are confusing. > >> > >> I suggest another solution for this. > >> Why don't you use > >> elm_transit_event_enabled_set(transit, EINA_TRUE) instead? > >> Because event is blocked by default, > >> someone who wants to use events needs to call > >> elm_transit_event_enabled_set() API. > > > > +1, that seems the most reasonable api. > > indeed +1 > davemds hermet - why don't you provide a patch that provides the new suggested api above, but only deprecates the old (still keeping it). EINA_DEPRECATED in front of the EAPI's to mark it. nothing wil break right now, we have new api thats better for people to use and people using the old api have a chance to move over without a break for a period of time. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Problem to run E17 in an ARM Cortex-A8
On Tue, 30 Nov 2010 19:55:41 -0200 Fabiano Fidêncio said: what func did it die in in page_080.so ? it's cut off and that could be any one of a several of functions :) > Howdy! > > I'm trying to have fun with a little board and E17 running Illume. > However, in the wizard to select a profile, I'm having a segfault > in an ARM Cortex-A8. > > Could someone take a look? > > The gdb's backtrace is that: http://pastebin.com/tPLR6BAN > > BR, > -- > Fabiano Fidêncio > ProFUSION embedded systems > http://www.profusion.mobi > > -- > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] elm_animator
On Wed, 01 Dec 2010 09:17:48 +0900 ChunEon Park said: in svn (fixed so it applies). :) > Please check this small patch. > Added one miner API. > > Thanks. > > The Hermet -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] elm_genlist and elm_list patch.
On Wed, 1 Dec 2010 03:35:09 +0900 Daniel Juyung Seo said: > Dear all, I have a patch for some issues. > Anybody can review this patch and apply this to upstream? > > [Genlist] > 1. fixed elm_genlist_item_display_only_set() API bug. > "elm,state,selected" signal should not be emitted when display_only is set. > display_only was not set properly when it->block did not exist. good. cool. > 2. Add a macro for SWIPE_TIMEOUT >Instead of using constant "0.4" for swipe timer in the middle of > code, I added a macro SWIPE_TIMEOUT. issue here. could you actually make this an elm config value? so its in system config, it's loaded at start and can be configured by elm's config tool? (well not now, but in the future). resubmit patch then? don't forget config version and to upgrade it and handle the upgrade - examples in the code how to do that already :) > 3. Indentation and space fix. >I fixed indentations for item cache and some other lines. >I removed some unnecessary spaces. ok. so just the above :) > [List] > 1. Add macros for SWIPE_TIMEOUT and LONGPRESS_TIMEOUT > Instead of using constants in the middle of code, I added macros. > > Thanks. > Daniel Juyung Seo. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] First (Hopefully) Weekly report
On Mon, 29 Nov 2010 19:22:39 -0200 Iván Briano (Sachiel) said: i like! > Hello people, for those of you that don't check out our Trac news or > Planet every hour, > I give you the first of the new Weekly Reports on what's going on with > and around the EFL. > > The link: http://trac.enlightenment.org/e/blog/weekly_report_1 > Actually, whether it is or not a link will depend on your client. > > This one began with stuff done by ProFUSION, as an extension of our > internal reports, > but since k-s already appointed me at the IRC channel as the official > writer of this thing, > from now on, you all can send whatever you want published between Sunday night > and Monday morning (GMT-3 aprox.) and it will all show up nicely together. > Short one-liners with links to other sites are accepted. > > G'day > > -- > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > ___ > enlightenment-users mailing list > enlightenment-us...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ 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/e: data/themes data/themes/images src/modules/cpufreq
On Mon, 29 Nov 2010 11:29:16 -0200 Gustavo Lima Chaves said: > * Enlightenment SVN [2010-11-29 02:52:33 -0800]: > > > Log: > > happy lucky fun improvement in cpufreq gadget - dial moves smoothly > > now... and uses map... like clock... and i added 2 more mini dialos > > for min and max freq if u have multiple cores at differetn frequencies > > :) red one now has a white tip for easier visbility and shows average > > of all cores. > > I loved it :) it could do with much more stuff - like a mixer-lick left click to get a control panel thats simpler to choose a power management strategy from alone with a slider for the "accelerator" pedal (to manually set freq) :) now the issue is actually the kernel and modern core cpu's with turbo-boost support. you cant get the turbo boos freq from cores via the kernel /sys interface. you have to do some nasty evil stuff. i don't know if the kernel will fix this - but there are ways - if u are root, to get this info. i'm hoping kernel will fix first though. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Link time optimization
On Sun, 28 Nov 2010 12:37:53 +0100 (CET) Vincent Torri said: belongs in CFLAGS/LDFLAGS of the people doing the compiling. (users/packagers) > > Hey, > > with newer gcc, we could optimize link with -flto (and > also maybe -fwhole-program). Shouldn't we add those options if they are > available (i have already written m4 macro to add such flags) ? > > Vincent > > -- > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric IN trunk: e_dbus ecore edje eet eeze efreet eina embryo evas
On Sat, 4 Dec 2010, Daniel Juyung Seo wrote: hello, is that the beta3 before 1.0 ? no, some RC should be done first. Vincent thanks. Daniel Juyung Seo. On Sat, Dec 4, 2010 at 9:50 AM, Enlightenment SVN wrote: Log: * eina,eet,embryo,evas,ecore,edje,efreet,e_dbus,eeze: beta3 ! Author: cedric Date: 2010-12-03 16:50:58 -0800 (Fri, 03 Dec 2010) New Revision: 55238 Trac: http://trac.enlightenment.org/e/changeset/55238 Modified: trunk/e_dbus/configure.ac trunk/ecore/configure.ac trunk/edje/configure.ac trunk/eet/configure.ac trunk/eeze/configure.ac trunk/efreet/configure.ac trunk/eina/configure.ac trunk/embryo/configure.ac trunk/evas/configure.ac Modified: trunk/e_dbus/configure.ac === --- trunk/e_dbus/configure.ac 2010-12-04 00:46:01 UTC (rev 55237) +++ trunk/e_dbus/configure.ac 2010-12-04 00:50:58 UTC (rev 55238) @@ -19,7 +19,7 @@ ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## -AC_INIT([e_dbus], [v_ver.beta2], [enlightenment-de...@lists.sourceforge.net]) +AC_INIT([e_dbus], [v_ver.beta3], [enlightenment-de...@lists.sourceforge.net]) AC_PREREQ([2.52]) AC_CONFIG_SRCDIR([configure.ac]) AC_CONFIG_MACRO_DIR([m4]) Modified: trunk/ecore/configure.ac === --- trunk/ecore/configure.ac 2010-12-04 00:46:01 UTC (rev 55237) +++ trunk/ecore/configure.ac 2010-12-04 00:50:58 UTC (rev 55238) @@ -18,7 +18,7 @@ ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## -AC_INIT([ecore], [v_ver.beta2], [enlightenment-de...@lists.sourceforge.net]) +AC_INIT([ecore], [v_ver.beta3], [enlightenment-de...@lists.sourceforge.net]) AC_PREREQ([2.52]) AC_CONFIG_SRCDIR([configure.ac]) AC_CONFIG_MACRO_DIR([m4]) Modified: trunk/edje/configure.ac === --- trunk/edje/configure.ac 2010-12-04 00:46:01 UTC (rev 55237) +++ trunk/edje/configure.ac 2010-12-04 00:50:58 UTC (rev 55238) @@ -18,7 +18,7 @@ ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## -AC_INIT([edje], [v_ver.beta2], [enlightenment-de...@lists.sourceforge.net]) +AC_INIT([edje], [v_ver.beta3], [enlightenment-de...@lists.sourceforge.net]) AC_PREREQ([2.52]) AC_CONFIG_SRCDIR([configure.ac]) AC_CONFIG_MACRO_DIR([m4]) Modified: trunk/eet/configure.ac === --- trunk/eet/configure.ac 2010-12-04 00:46:01 UTC (rev 55237) +++ trunk/eet/configure.ac 2010-12-04 00:50:58 UTC (rev 55238) @@ -18,7 +18,7 @@ ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## -AC_INIT([eet], [v_ver.beta2], [enlightenment-de...@lists.sourceforge.net]) +AC_INIT([eet], [v_ver.beta3], [enlightenment-de...@lists.sourceforge.net]) AC_PREREQ([2.52]) AC_CONFIG_SRCDIR([configure.ac]) AC_CONFIG_MACRO_DIR([m4]) Modified: trunk/eeze/configure.ac === --- trunk/eeze/configure.ac 2010-12-04 00:46:01 UTC (rev 55237) +++ trunk/eeze/configure.ac 2010-12-04 00:50:58 UTC (rev 55238) @@ -18,7 +18,7 @@ ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## -AC_INIT([eeze], [v_ver.beta2], [enlightenment-de...@lists.sourceforge.net]) +AC_INIT([eeze], [v_ver.beta3], [enlightenment-de...@lists.sourceforge.net]) AC_PREREQ([2.52]) AC_CONFIG_SRCDIR([configure.ac]) AC_CONFIG_MACRO_DIR([m4]) Modified: trunk/efreet/configure.ac === --- trunk/efreet/configure.ac 2010-12-04 00:46:01 UTC (rev 55237) +++ trunk/efreet/configure.ac 2010-12-04 00:50:58 UTC (rev 55238) @@ -18,7 +18,7 @@ ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## -AC_INIT([efreet], [v_ver.beta2], [enlightenment-de...@lists.sourceforge.net]) +AC_INIT([efreet], [v_ver.beta3], [enlightenment-de...@lists.sourceforge.net]) AC_PREREQ([2.52]) AC_CONFIG_SRCDIR([configure.ac]) AC_CONFIG_MACRO_DIR([m4]) Modified: trunk/eina/configure.ac === --- trunk/eina/configure.ac 2010-12-04 00:46:01 UTC (rev 55237) +++ trunk/eina/configure.ac 2010-12-04 00:50:58 UTC (rev 55238) @@ -18,7 +18,7 @@ ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--## -AC_INIT([eina], [v_ver.beta2], [enlightenment-de...@lists.sourceforge.net]) +AC_INIT([eina], [v_ver.beta3], [enlightenment-de.
Re: [E-devel] E SVN: cedric trunk/edje/src/bin
On Sat, 4 Dec 2010, Carsten Haitzler (The Rasterman) wrote:
On Fri, 3 Dec 2010 18:47:38 +0100 (CET) Vincent Torri
said:
On Fri, 3 Dec 2010, Cedric BAIL wrote:
On Fri, Dec 3, 2010 at 5:57 PM, Vincent Torri wrote:
On Fri, 3 Dec 2010, Enlightenment SVN wrote:
Log:
* edje: improve portability and simplify code.
+ snprintf(buf, sizeof(buf), "%s -I%s %s -E -o %s - < %s",
+ getenv("CC") ? getenv("CC") : "cc",
inc, def, tmpn, file_in);
ret = system(buf);
shouldn't you also pass
-x c
to force the language (gcc can rely on the file extension to select the
No need as I pass it using redirection instead of directly the
filename. That was to avoid complexifying the command line.
language) and
-std=c99
to be sure to remove the c++ comments ?
Good question, don't know if it will be supported by other compiler
than gcc. What's your opinion ?
sun (oracle) compiler: -xc99 (no -std option)
icc: -std=c99
x86 open64 (amd) : -std=c99
vc++ (cl.exe): i don't know
so maybe try first with -std=c99 ; if the command fails, try with -xc99
I don't know other interesting compiler
actually... this brings up a bit of an issue. using cpp/cc/gcc to handle
#includes and macros and #ifdefs and so on was a handy idea... but it creates a
LOT of problems in the maintainability and portability of edje_cc due to
relying on a nebulous cpp that may or may not behave as we expect.
i'm thinking post 1.0 a lot of these features should go into edje_cc itself.
being able to do includes and macros - maybe we can do much more intelligent
macros that are able to understand the rest of the edc syntax and model.
cedric had the same kind of idea, actually (writing a specific
preprocessor for edc syntax).
Vincent--
What happens now with your Lotus Notes apps - do you make another costly
upgrade, or settle for being marooned without product support? Time to move
off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
use, and manage than apps on traditional platforms. Sign up for the Lotus
Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] exchange
Hi, 1) See http://trac.enlightenment.org/e/wiki/Exchange 2) Post ideas for me to implement 3) ??? 4) Profit! -- Mike Blumenkrantz Zentific: We run the three-legged race individually. -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/edje/src/bin
On Sat, 4 Dec 2010 07:39:42 +0100 (CET) Vincent Torri said: > > actually... this brings up a bit of an issue. using cpp/cc/gcc to handle > > #includes and macros and #ifdefs and so on was a handy idea... but it > > #creates a > > LOT of problems in the maintainability and portability of edje_cc due to > > relying on a nebulous cpp that may or may not behave as we expect. > > > > i'm thinking post 1.0 a lot of these features should go into edje_cc itself. > > being able to do includes and macros - maybe we can do much more intelligent > > macros that are able to understand the rest of the edc syntax and model. > > cedric had the same kind of idea, actually (writing a specific > preprocessor for edc syntax). great minds think :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
