Re: [E-devel] [PATCH] ecore main loop fd_handlers_to_call list optimization
On Thu, 02 Dec 2010 15:22:13 +0900 Mike McCormack mj.mccorm...@samsung.com said: probably is a good thing as its fewer mallocs in a loop. :) Hi All, 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. thanks, Mike -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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: devilhorns trunk/e/src/bin
On Thu, 2 Dec 2010 00:05:54 -0800 Enlightenment SVN no-re...@enlightenment.org wrote: Log: Adjust min sizes of ilist and textblock so that Modules dialog fits nicely into 240x320 (without these changes, the toolbar is partially obscured by illume indicator). Author: devilhorns Date: 2010-12-02 00:05:52 -0800 (Thu, 02 Dec 2010) New Revision: 55132 Trac: http://trac.enlightenment.org/e/changeset/55132 Modified: trunk/e/src/bin/e_int_config_modules.c Modified: trunk/e/src/bin/e_int_config_modules.c === --- trunk/e/src/bin/e_int_config_modules.c2010-12-02 08:01:19 UTC (rev 55131) +++ trunk/e/src/bin/e_int_config_modules.c2010-12-02 08:05:52 UTC (rev 55132) @@ -167,7 +167,7 @@ e_widget_ilist_go(cfdata-l_modules); e_widget_size_min_get(cfdata-l_modules, mw, mh); if (mw (200 * e_scale)) mw = 200 * e_scale; - if (mh (120 * e_scale)) mh = 120 * e_scale; + if (mh (100 * e_scale)) mh = 100 * e_scale; e_widget_size_min_set(cfdata-l_modules, mw, mh); e_widget_on_change_hook_set(cfdata-l_modules, _widget_list_selection_changed, cfdata); @@ -184,7 +184,7 @@ e_widget_table_object_append(of, ol, 1, 2, 1, 1, 1, 1, 1, 0); ol = e_widget_textblock_add(evas); - e_widget_size_min_set(ol, (200 * e_scale), 60 * e_scale); + e_widget_size_min_set(ol, (200 * e_scale), 40 * e_scale); cfdata-o_desc = ol; e_widget_table_object_append(of, ol, 0, 3, 2, 1, 1, 0, 1, 0); -- 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 Resizinghorns! -- Mike Blumenkrantz Zentific: Our boolean values are huge. -- 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] [PATCH] ecore main loop fd_handlers_to_call list optimization
On Thu, Dec 2, 2010 at 4:38 AM, Mike Blumenkrantz m...@zentific.com wrote: On Thu, 02 Dec 2010 15:22:13 +0900 Mike McCormack mj.mccorm...@samsung.com wrote: Hi All, 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. thanks, Mike Tested, produces a small (unnoticeable to most users/applications) but definite performance improvement using the fd benchmarks. Could you share the results? Lucas De Marchi -- 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] [PATCH] ecore main loop fd_handlers_to_call list optimization
Hi, On Thu, Dec 2, 2010 at 7:22 AM, Mike McCormack mj.mccorm...@samsung.com 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. -- 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] [PATCH] ecore main loop fd_handlers_to_call list optimization
On Thu, 2010-12-02 at 11:34 +0100, Cedric BAIL wrote: 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. Omg, I forgot we are still in beta (when I looked at this commit). I also think this should wait. -- Tom. -- 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] [PATCH] ecore main loop fd_handlers_to_call list optimization
On Thu, Dec 2, 2010 at 8:34 AM, Cedric BAIL cedric.b...@free.fr wrote: Hi, On Thu, Dec 2, 2010 at 7:22 AM, Mike McCormack mj.mccorm...@samsung.com 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? Lucas De Marchi -- 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] [PATCH] ecore main loop fd_handlers_to_call list optimization
On 12/02/2010 08:20 PM, Lucas De Marchi wrote: On Thu, Dec 2, 2010 at 8:34 AM, Cedric BAILcedric.b...@free.fr wrote: Hi, On Thu, Dec 2, 2010 at 7:22 AM, Mike McCormackmj.mccorm...@samsung.com 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. thanks, Mike -- 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] [PATCH] ecore main loop fd_handlers_to_call list optimization
2010/12/2 Mike McCormack mj.mccorm...@samsung.com: On 12/02/2010 08:20 PM, Lucas De Marchi wrote: On Thu, Dec 2, 2010 at 8:34 AM, Cedric BAILcedric.b...@free.fr wrote: Hi, On Thu, Dec 2, 2010 at 7:22 AM, Mike McCormackmj.mccorm...@samsung.com 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. thanks, 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? Mike -- 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
Re: [E-devel] [PATCH] ecore main loop fd_handlers_to_call list optimization
On Thu, Dec 2, 2010 at 1:08 PM, Iván Briano (Sachiel) sachi...@gmail.com wrote: 2010/12/2 Mike McCormack mj.mccorm...@samsung.com: On 12/02/2010 08:20 PM, Lucas De Marchi wrote: On Thu, Dec 2, 2010 at 8:34 AM, Cedric BAILcedric.b...@free.fr wrote: On Thu, Dec 2, 2010 at 7:22 AM, Mike McCormackmj.mccorm...@samsung.com 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, -- 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] [PATCH] ecore main loop fd_handlers_to_call list optimization
On Thu, Dec 2, 2010 at 10:03 AM, Mike McCormack mj.mccorm...@samsung.com wrote: Come on guys. The only reason that you're seeing this is that I don't commit directly to SVN. No, I object because it's a huge change that might introduce bugs. The fact is that this feature freeze is taking longer than most of us desired. What we can do is settle the remaining issues (who knows them?) and release 1.0. 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. Currently I don't have time to follow all commits, but people is indeed committing more than should be allowed. Lucas De Marchi -- 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] [PATCH] ecore main loop fd_handlers_to_call list optimization
On Thu, 2 Dec 2010, Iván Briano (Sachiel) wrote: 2010/12/2 Mike McCormack mj.mccorm...@samsung.com: On 12/02/2010 08:20 PM, Lucas De Marchi wrote: On Thu, Dec 2, 2010 at 8:34 AM, Cedric BAILcedric.b...@free.fr wrote: Hi, On Thu, Dec 2, 2010 at 7:22 AM, Mike McCormackmj.mccorm...@samsung.com 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. i for removing all of them. 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] [PATCH] ecore main loop fd_handlers_to_call list optimization
On Thu, 2 Dec 2010, Lucas De Marchi wrote: On Thu, Dec 2, 2010 at 10:03 AM, Mike McCormack mj.mccorm...@samsung.com wrote: Come on guys. The only reason that you're seeing this is that I don't commit directly to SVN. No, I object because it's a huge change that might introduce bugs. The fact is that this feature freeze is taking longer than most of us desired. What we can do is settle the remaining issues (who knows them?) and release 1.0. 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. Currently I don't have time to follow all commits, but people is indeed committing more than should be allowed. +1 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] [PATCH] ecore main loop fd_handlers_to_call list optimization
On Thu, Dec 2, 2010 at 1:19 PM, Lucas De Marchi lucas.demar...@profusion.mobi wrote: On Thu, Dec 2, 2010 at 10:03 AM, Mike McCormack mj.mccorm...@samsung.com wrote: Come on guys. The only reason that you're seeing this is that I don't commit directly to SVN. No, I object because it's a huge change that might introduce bugs. The fact is that this feature freeze is taking longer than most of us desired. What we can do is settle the remaining issues (who knows them?) and release 1.0. Agreed and as far as I know we have not so much pending bug. One with map, clip and color and one related to ecore fd and maybe glib integration. If people remember more issue I think it's a good time to raise your hand so we, developper, can take care of them. Plan is to do a beta3 tomorrow, and focus on portability and build issue. The openbsd and fedora guys helped us a lot on this, I have some pending work to do to fix the build on MacOS X. If you have any build issue, I would like to ear about them really soon. Once this beta3 and the know bugs are found and fixed we should be able to jump in rc I think. When in rc, we will just go over our documentation, website and translation to do a shiny 1.0. We should also take advantage of this 1.0 to coordinate with all major distribution to be sure packaging issue are all solved. I don't think we have so much to do before an 1.0. So maybe it would be a good idea to keep focusing on it instead of improving benchmark score and adding feature. 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. Currently I don't have time to follow all commits, but people is indeed committing more than should be allowed. Agreed to. -- 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] [PATCH] ecore main loop fd_handlers_to_call list optimization
On Thu, 2010-12-02 at 10:19 -0200, Lucas De Marchi wrote: On Thu, Dec 2, 2010 at 10:03 AM, Mike McCormack mj.mccorm...@samsung.com wrote: Come on guys. The only reason that you're seeing this is that I don't commit directly to SVN. No, I object because it's a huge change that might introduce bugs. The fact is that this feature freeze is taking longer than most of us desired. What we can do is settle the remaining issues (who knows them?) and release 1.0. 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. Currently I don't have time to follow all commits, but people is indeed committing more than should be allowed. Exactly. I have a bunch of features I can shove in that will be just fine and will probably not introduce bugs, but that's not how a feature freeze works... A freeze is a freeze and we should respect that as such. I hope we'll release soon and this freeze hell will be over. -- Tom. -- 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] [PATCH] eve: save history and favorites when added
On Wed, Dec 1, 2010 at 6:49 PM, Marco Trevisan (Treviño) m...@3v1n0.net wrote: I often experience crashes when using eve, when I reload it no saved informations (like favorites) or history are kept. Why not saving them when something changes? Modifying eve_state.c is bad, since it is auto-generated: any changes to eve_state.geneet and the changes are gone. Things like this should be changed in geneet itself; this tool might see a rewrite (as it is/was a quick hack) and something like this will be integrated on the next version. Cheers, Leandro -- 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] [PATCH] eve: add support for Android User-Agent
On Wed, Dec 1, 2010 at 5:03 PM, Marco Trevisan (Treviño) m...@3v1n0.net wrote: Here you are. Applied, thanks. -- Cheers, Leandro -- 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] [PATCH] eve: use file realpath for file:// schema
On Wed, Dec 1, 2010 at 4:06 PM, Marco Trevisan (Treviño) m...@3v1n0.net wrote: I've also another version for this function, this one supports any protocol, following the syntax rules stated by the RFC 3986 considering everything that precedes a semicolon (:) as the schema, and the rest as the path (this allows to get working about:* pages too, also if webkit-efl doesn't seem to support them yet). However I had to check that the parsed schema was not actually a port number or a password (with urls like www.google.com:80 or http://user:p...@anysite.com:80 ;) All the cases I've tested seem to work, let me know what you think. I've checked RFC 3896 and it seems that URL parsing isn't as simple as it sounds. There are libraries there to provide URL parsing and they're quite complicated because there are lots of ambiguities and other pitfalls. I don't see any need right now to make this thing beefier, since the current naive implementation is working fine already. Well, except for about: URLs, but I think this is the wrong layer to put this; there is already a patch to WebKit Soup backend to support custom scheme handlers, which will also make it possible to embed external resources (e.g. images). -- Cheers, Leandro -- 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] [PATCH] ecore main loop fd_handlers_to_call list optimization
2010/12/2 Tom Hacohen tom.haco...@partner.samsung.com: On Thu, 2010-12-02 at 10:19 -0200, Lucas De Marchi wrote: On Thu, Dec 2, 2010 at 10:03 AM, Mike McCormack mj.mccorm...@samsung.com wrote: Come on guys. The only reason that you're seeing this is that I don't commit directly to SVN. No, I object because it's a huge change that might introduce bugs. The fact is that this feature freeze is taking longer than most of us desired. What we can do is settle the remaining issues (who knows them?) and release 1.0. 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. Currently I don't have time to follow all commits, but people is indeed committing more than should be allowed. Exactly. I have a bunch of features I can shove in that will be just fine and will probably not introduce bugs, but that's not how a feature freeze works... A freeze is a freeze and we should respect that as such. I hope we'll release soon and this freeze hell will be over. The freeze hell will not be over at 1.0, we will have to freeze for 1.1 and so on, we must accustom ourself to real software life cycle. DaveMDS -- Tom. -- 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
Re: [E-devel] [PATCH] ecore main loop fd_handlers_to_call list optimization
On Thu, Dec 2, 2010 at 4:47 PM, Dave Andreoli d...@gurumeditation.it wrote: 2010/12/2 Tom Hacohen tom.haco...@partner.samsung.com: On Thu, 2010-12-02 at 10:19 -0200, Lucas De Marchi wrote: On Thu, Dec 2, 2010 at 10:03 AM, Mike McCormack mj.mccorm...@samsung.com wrote: Come on guys. The only reason that you're seeing this is that I don't commit directly to SVN. No, I object because it's a huge change that might introduce bugs. The fact is that this feature freeze is taking longer than most of us desired. What we can do is settle the remaining issues (who knows them?) and release 1.0. 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. Currently I don't have time to follow all commits, but people is indeed committing more than should be allowed. Exactly. I have a bunch of features I can shove in that will be just fine and will probably not introduce bugs, but that's not how a feature freeze works... A freeze is a freeze and we should respect that as such. I hope we'll release soon and this freeze hell will be over. The freeze hell will not be over at 1.0, we will have to freeze for 1.1 and so on, we must accustom ourself to real software life cycle. what software cycle? Release early, release often? Lucas De Marchi -- 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: sachiel trunk/edje/src/bin
2010/11/30 Gustavo Sverzut Barbieri barbi...@profusion.mobi: On Tue, Nov 30, 2010 at 2:10 PM, Iván Briano (Sachiel) sachi...@gmail.com wrote: 2010/11/30 Dave Andreoli d...@gurumeditation.it: 2010/11/30 Enlightenment SVN no-re...@enlightenment.org: Log: Make edje_cc store script source snippets (only embryo now) in the generated file. Yeah... yeah... we are on a freeze and we aren't supposed to be doing things like this, but it's not change anything other than allow edje_edit to know about scripts in order to not screw them up when modifying a file. OMG thanks!!! I was waiting for this for 3 yearsand was so simplestupid me... Wait for the edje_edit part. It's not that simple... or is it? In any case, they are a lot of pitfalls to consider when taking care of this. Yeah Dave, right now the current Edje_Edit.h API will turn edjes with scripts into unusable things after you restack parts or add/remove them, as the PART:name id will change. Same for signal add/removal so other than saving and restoring it to EDJ/EDC, Sachiel will have the nasty work to make edje_edit_object to recompile the embryo and replace the VM references in runtime :-/ yup, now I remember why I was scared about it :) good work Sachiel ! -- 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: sachiel trunk/edje/src/bin
2010/12/2 Dave Andreoli d...@gurumeditation.it: 2010/11/30 Gustavo Sverzut Barbieri barbi...@profusion.mobi: On Tue, Nov 30, 2010 at 2:10 PM, Iván Briano (Sachiel) sachi...@gmail.com wrote: 2010/11/30 Dave Andreoli d...@gurumeditation.it: 2010/11/30 Enlightenment SVN no-re...@enlightenment.org: Log: Make edje_cc store script source snippets (only embryo now) in the generated file. Yeah... yeah... we are on a freeze and we aren't supposed to be doing things like this, but it's not change anything other than allow edje_edit to know about scripts in order to not screw them up when modifying a file. OMG thanks!!! I was waiting for this for 3 yearsand was so simplestupid me... Wait for the edje_edit part. It's not that simple... or is it? In any case, they are a lot of pitfalls to consider when taking care of this. Yeah Dave, right now the current Edje_Edit.h API will turn edjes with scripts into unusable things after you restack parts or add/remove them, as the PART:name id will change. Same for signal add/removal so other than saving and restoring it to EDJ/EDC, Sachiel will have the nasty work to make edje_edit_object to recompile the embryo and replace the VM references in runtime :-/ yup, now I remember why I was scared about it :) good work Sachiel ! Thanks, though there's still work to do about it, and more reasons to be scare about it. -- 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] [PATCH] ecore main loop fd_handlers_to_call list optimization
On Thu, 2 Dec 2010 13:18:02 +0100 Cedric BAIL cedric.b...@free.fr wrote: On Thu, Dec 2, 2010 at 1:08 PM, Iván Briano (Sachiel) sachi...@gmail.com wrote: 2010/12/2 Mike McCormack mj.mccorm...@samsung.com: On 12/02/2010 08:20 PM, Lucas De Marchi wrote: On Thu, Dec 2, 2010 at 8:34 AM, Cedric BAILcedric.b...@free.fr wrote: On Thu, Dec 2, 2010 at 7:22 AM, Mike McCormackmj.mccorm...@samsung.com 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 experiment 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 # specimen experiment time starting time ending time 1 470182903 3876967 474059870 ./bench_client 0.17s user 0.38s system 97% cpu 0.567 total 5000 fd test: Time elapsed for 5000 connections: 0.247735 seconds # specimen experiment time starting time ending time 1 237503799 3889656 241393455 ./bench_client 0.10s
Re: [E-devel] [PATCH] ecore main loop fd_handlers_to_call list optimization
On Thu, 2 Dec 2010 16:54:36 -0200 Lucas De Marchi lucas.demar...@profusion.mobi said: On Thu, Dec 2, 2010 at 4:47 PM, Dave Andreoli d...@gurumeditation.it wrote: 2010/12/2 Tom Hacohen tom.haco...@partner.samsung.com: On Thu, 2010-12-02 at 10:19 -0200, Lucas De Marchi wrote: On Thu, Dec 2, 2010 at 10:03 AM, Mike McCormack mj.mccorm...@samsung.com wrote: Come on guys. The only reason that you're seeing this is that I don't commit directly to SVN. No, I object because it's a huge change that might introduce bugs. The fact is that this feature freeze is taking longer than most of us desired. What we can do is settle the remaining issues (who knows them?) and release 1.0. 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. Currently I don't have time to follow all commits, but people is indeed committing more than should be allowed. Exactly. I have a bunch of features I can shove in that will be just fine and will probably not introduce bugs, but that's not how a feature freeze works... A freeze is a freeze and we should respect that as such. I hope we'll release soon and this freeze hell will be over. The freeze hell will not be over at 1.0, we will have to freeze for 1.1 and so on, we must accustom ourself to real software life cycle. what software cycle? Release early, release often? you still have freezes. you just spin faster. technically we release on every commit. its all in public svn for the taking. release early, release often says zero about quality, and a philosophy of doing this will result in poor release quality if you dont freeze and fix and just march on - which is zero difference to simply saying we have done 55000 releases. you can pick any of the 55000 svn revisions we have - it's a release. it's just not a tarball. people need to stop and focus on what's important. the quality of the software, not mantras. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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] [Patch] elm_genlist and elm_list patch.
Dear all, anybody can review and apply this to upstream? Thank you. Daniel Juyung Seo. On Wed, Dec 1, 2010 at 8:51 AM, Daniel Juyung Seo juyung@samsung.com wrote: I attached a patch file again. Thanks. Daniel Juyung Seo. -Original Message- From: Daniel Juyung Seo [mailto:seojuyu...@gmail.com] Sent: Wednesday, December 01, 2010 3:35 AM To: enlightenment-devel@lists.sourceforge.net Subject: [E-devel] [Patch] elm_genlist and elm_list patch. 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. 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. 3. Indentation and space fix. I fixed indentations for item cache and some other lines. I removed some unnecessary spaces. [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. -- 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] [Patch] elm_genlist and elm_list patch.
On Fri, 3 Dec 2010 14:11:37 +0900 Daniel Juyung Seo seojuyu...@gmail.com said: i'll look at all of these little things... once i'm done digging thru all the other... changes i have here... :) merge merge merge... tired of merging... Dear all, anybody can review and apply this to upstream? Thank you. Daniel Juyung Seo. On Wed, Dec 1, 2010 at 8:51 AM, Daniel Juyung Seo juyung@samsung.com wrote: I attached a patch file again. Thanks. Daniel Juyung Seo. -Original Message- From: Daniel Juyung Seo [mailto:seojuyu...@gmail.com] Sent: Wednesday, December 01, 2010 3:35 AM To: enlightenment-devel@lists.sourceforge.net Subject: [E-devel] [Patch] elm_genlist and elm_list patch. 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. 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. 3. Indentation and space fix. I fixed indentations for item cache and some other lines. I removed some unnecessary spaces. [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. -- 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 -- 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
