On Thu, 4 Nov 2010 17:45:51 -0200 Rafael Antognolli <antogno...@profusion.mobi> wrote:
> On Thu, Nov 4, 2010 at 5:26 PM, Mike Blumenkrantz <m...@zentific.com> wrote: > > On Thu, 4 Nov 2010 12:00:32 -0500 > > Mike Blumenkrantz <m...@zentific.com> wrote: > > > >> On Thu, 4 Nov 2010 09:42:55 -0700 > >> "Enlightenment SVN" <no-re...@enlightenment.org> wrote: > >> > >> > blah blah commit blah blah > >> > >> This library, aptly named by Tom Hacohen aka TAsn who has demanded that I > >> give him all credit, exposes a serious bug in ecore 100% of the time > >> through my tests: the duplication of events. > >> > >> To demonstrate, simply compile and run 'make check' to compile the > >> additional tests. Then run src/tests/server (must be run from src/tests) > >> and src/tests/client. In the output of the client, you will see something > >> like this at the bottom: > >> > >> > >> DBG<17405>:azy azy_client_events.c:151 _azy_client_handler_data() > >> (handler_data=0x9ab2900, method='TTest1.getBigArray', ev=0x9b179f0, > >> data=0x9b17a00) (~15 other lines...) DBG<17405>:azy azy_client_events.c:151 > >> _azy_client_handler_data() (handler_data=0x9ab28d8, > >> method='TTest1.putBigArray', ev=0x9b179f0, data=0x9b17a00) > >> > >> Note the pointer addresses for ev and data in these lines. While some > >> other events may have the same addresses, they are not the same data. > >> This is not, however, the case for the final pair of events. The data is > >> identical. Additionally, this final event IS NOT EMITTED. To see what I > >> mean, run the client in gdb with breakpoints/printfs at ecore_con.c:1786 > >> (ECORE_CON_EVENT_SERVER_DATA event is ONLY emitted here in this app) and > >> _azy_client_handler_data. You will notice that every occurrence of > >> _azy_client_handler_data has an event right before it except for the final > >> one. This is a bug. > >> > > Okay, I have found the bug. If, in your event handler callback, you add > > another handler for the same event type, the current event will be passed to > > that new handler as well. My use case is that I am deleting the current > > handler and adding a new one during an event, so I do not want the same > > event to be passed to the new handler. Is this something that should be > > fixed in ecore, or something that I should be working around in my own code? > > 17:38 discomfit> I could fix it in ecore by counting the number of handlers > before I start running them, and stopping after I reach that > count > 17:39 discomfit> can't really think of a good way to handle it outside of > ecore 17:39 discomfit> the purpose of doing this is to switch data > associated with the handler > 17:39 discomfit> since there is no event_handler_data_get/set > 17:39 discomfit> you have to delete and recreate handlers > 17:40 discomfit> which is horribly inefficient, but whatever > 17:40 antognoll> i like both ideas (ev. handler count and > event_handler_data_get/set) > 17:41 antognoll> why don't you put these ideas in the ML? > 17:41 discomfit> why don't you do it so I don't have a thread where I'm > replying to myself > > So, I like the idea of having this setter/getter and also fixing the > wrong handling of events (not for this case, but would be good to have > the correct behavior for this). > > Anyone against that? > I implemented the data_set/get calls, waiting on someone to provide feedback about the internal ecore fix. -- Mike Blumenkrantz Zentific: Our boolean values are huge. ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
