gtk-gnutella-devel Digest, Vol 25, Issue 1
|
View:
New views
1 Messages
—
Rating Filter:
Alert me
|
 |
gtk-gnutella-devel Digest, Vol 25, Issue 1
by gtk-gnutella-devel-request
::
Rate this Message:
Send gtk-gnutella-devel mailing list submissions to
gtk-gnutella-devel@... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel or, via email, send a message with subject or body 'help' to gtk-gnutella-devel-request@... You can reach the person managing the list at gtk-gnutella-devel-owner@... When replying, please edit your Subject line so it is more specific than "Re: Contents of gtk-gnutella-devel digest..." Today's Topics: 1. Re: Endian compile failure on PPC7450 (back from ignomy) (Matthew Lye) 2. Re: Patch for Search Stats (Mitch Harder (aka DontPanic)) 3. Re: Patch for Search Stats (Christian Biere) 4. assertion failure in routing.c:767 (Meelis Roos) 5. Re: assertion failure in routing.c:767 (Raphael Manfredi) 6. Re: assertion failure in routing.c:767 (Meelis Roos) ---------------------------------------------------------------------- Message: 1 Date: Sun, 24 Aug 2008 22:55:07 -0400 From: Matthew Lye <mlye@...> Subject: Re: [gtk-gnutella-devel] Endian compile failure on PPC7450 (back from ignomy) To: gtk-gnutella-devel@... Message-ID: <C2EE8354-5946-49CB-89AC-82A1F32D0DC6@...> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes On 24-Aug-08, at 3:24 PM, Christian Biere wrote: > You can peek at such definitions like this: > echo | gcc -E -g3 - > > I guess your system defined __ppc__ and it should be semantically > equivalent to __powerpc__, except for endianness maybe but that > doesn't matter here. Both __ppc__ and __POWERPC__ [all caps] are defined by my system. Not, however, __powerpc__ [no caps]. From a 2004 gcc patch at <http://gcc.gnu.org/ml/gcc-patches/2004-03/msg00501.html >, it seems that gcc and BEOS originally used different token styles. > defined (_ARCH_PWR) /* AIX */ > defined (_ARCH_COM) /* AIX */ > defined (__powerpc__) /* gcc */ > defined (__POWERPC__) /* BEOS */ > defined (__ppc__) /* Darwin */ > defined (PPC) /* GNU/Linux, SysV */ >> For myself, I just threw in >>> #define __powerppc__ >> right before the IEEE 754 check, and everything worked fine. > > That's not recommendable. I had not thought this thing for a moment. - Matt ------------------------------ Message: 2 Date: Mon, 1 Sep 2008 13:12:14 -0500 From: "Mitch Harder (aka DontPanic)" <mmharder@...> Subject: Re: [gtk-gnutella-devel] Patch for Search Stats To: gtk-gnutella-devel@... Message-ID: <89ed0c690809011112n5db9f6edh37e4b25a48625484@...> Content-Type: text/plain; charset="iso-8859-1" On Sun, Aug 24, 2008 at 1:14 PM, Christian Biere <christianbiere@...> wrote: > > Look for SORTABLE in these files: > src/ui/gtk/gtk2/fileinfo.c > src/ui/gtk/gtk2/search.c > > -- > Christian > I drew up some changes based on the code in src/ui/gtk/gtk2/fileinfo.c. I ran into a few issues. "#ifdef GTK_TREE_SORTABLE_UNSORTED_SORT_COLUMN_ID" was not correctly recognized by my compiler. It didn't throw out an error, my compiler just didn't see this as being defined. I am using gcc-4.2.4 and gtk+-2.12.10. In this version of gtk-2, GTK_TREE_SORTABLE_UNSORTED_SORT_COLUMN_ID is part of an enum structure in gtktreesortable.h, and apparently not recognized by the preprocessor. I had to employ: "#ifdef __GTK_TREE_SORTABLE_H__", which is the same #ifdef used in gtk's gtktreesortable.h file. I also ran into some issues with the way search stats was implemented. First, I found that search stats processing is not performed when the search stats gui is not in focus. This occasionally had the affect of accumulating a large backlog of search terms when the search stats page was finally brought back up, and gtk-gnutella was ignoring it's other duties for several seconds. I had to adjust the code so that the search stats are still processed at the established interval to avoid accumulating that backlog. I played around with a few methods of minimizing the amount of processing required when the search stats was not in view, but this had the potential of building a land-mine when the view was finally switched back to search stats, and needed to be fully processed. Second, I found you could still set the search stats parameters so as to accumulate so many terms that it could still run into problems with gtk-gnutella processing the stats. So I built in some simple load evaluation code that would first disable sorting if more than 0.33 seconds were required to process the stats, and would disable search stats altogether if more than 0.4 seconds were required to process even without sorting. It seems like the biggest usage of time is with building the gtk list. The hash table is very fast, but it seems like there is still the potential for building a gtk list that is to large to process efficiently. One final issue that remains is this is a gtk-2.0 specific method that is not incorporated in gtk-1.2, so this leaves me without a comparable method for implementing these changes in the gtk-1.2 section. I hope you find these changes are not too extensive. I tried to change as little as possible, but I also understand that you would want to be very careful about re-enabling a section of code that could hurt the primary function of gtk-gnutella. I am attaching a patch containing my current changes for enabling search stats in gtk-gnutella. If you decide not to employ the patch, I hope you at least find the exercise of revisiting this issue of some value. -------------- next part -------------- A non-text attachment was scrubbed... Name: search_stats_patch_v0.2 Type: application/octet-stream Size: 6355 bytes Desc: not available ------------------------------ Message: 3 Date: Wed, 3 Sep 2008 00:00:33 +0200 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] Patch for Search Stats To: gtk-gnutella-devel@... Message-ID: <20080902220033.GA21404@cyclonus> Content-Type: text/plain; charset=utf-8 Mitch Harder (aka DontPanic) wrote: > "#ifdef GTK_TREE_SORTABLE_UNSORTED_SORT_COLUMN_ID" was not correctly > recognized by my compiler. It didn't throw out an error, my compiler > just didn't see this as being defined. > I am using gcc-4.2.4 and gtk+-2.12.10. In this version of gtk-2, > GTK_TREE_SORTABLE_UNSORTED_SORT_COLUMN_ID is part of an enum structure > in gtktreesortable.h, and apparently not recognized by the > preprocessor. I had to employ: "#ifdef __GTK_TREE_SORTABLE_H__", > which is the same #ifdef used in gtk's gtktreesortable.h file. Thanks. Apparently this code was never active before because there were also syntax errors. The point of the check was, that this enumerator wasn't always available. I've changed it to check for Gtk+ >= 2.6.0 instead. > First, I found that search stats processing is not performed when the > search stats gui is not in focus. This occasionally had the affect of > accumulating a large backlog of search terms when the search stats > page was finally brought back up, and gtk-gnutella was ignoring it's > other duties for several seconds. That was certainly not correct but the work for non-visible widgets should be kept to a minimum. If you look at the other GUI code, you'll see that they check for visibility in the periodic callback. The treeviews and stores should be frozen when a widget becomes invisible and sorting should be disabled too because inserting items into a sorted treestore is extremely slow. > Second, I found you could still set the search stats parameters so as > to accumulate so many terms that it could still run into problems with > gtk-gnutella processing the stats. So I built in some simple load > evaluation code that would first disable sorting if more than 0.33 > seconds were required to process the stats, and would disable search > stats altogether if more than 0.4 seconds were required to process > even without sorting. I reduced these limits. Frequent stalls of up to 300 ms just aren't acceptable, especially not for such a gimmick. My main concern here is that an average user might not realize the source of these stalls or sluggishness and dismiss gtk-gnutella as a whole. > It seems like the biggest usage of time is with building the gtk list. > The hash table is very fast, but it seems like there is still the > potential for building a gtk list that is to large to process > efficiently. With the current code, the number of items grows indefinitely. So after a couple of days or even just hours, performance becomes absolutely unacceptable at least in ultrapeer mode. For the moment, I've committed your patch to SVN but I might decide to disable it again for the next release. I don't know whether it's worth fixing these issues. Personally, I am not interested which means I'm not going to fix them myself. Patches are welcome nonetheless. For serious statistics, you would just log the query strings and process them externally. Also there's so much spam/crap in the queries, you're unlikely to extract much if any useful information from them. -- Christian ------------------------------ Message: 4 Date: Mon, 8 Sep 2008 22:15:07 +0300 (EEST) From: Meelis Roos <mroos@...> Subject: [gtk-gnutella-devel] assertion failure in routing.c:767 To: gtk-gnutella-devel@... Message-ID: <Pine.SOC.4.64.0809082212380.23258@...> Content-Type: TEXT/PLAIN; charset=US-ASCII Tried todays SVN revision 15830 and fails to start with assertion failure: FATAL: Assertion failure in routing.c:767: "guid_is_gtkg(&guid_buf, NULL, NULL, NULL)" -- Meelis Roos (mroos@...) ------------------------------ Message: 5 Date: Tue, 9 Sep 2008 05:41:20 +0000 (UTC) From: Raphael_Manfredi@... (Raphael Manfredi) Subject: Re: [gtk-gnutella-devel] assertion failure in routing.c:767 To: gtk-gnutella-devel@... Message-ID: <ga52a0$s9k$1@...> Content-Type: text/plain; charset="iso-8859-1" Quoting Meelis Roos <mroos@...> from ml.softs.gtk-gnutella.devel: :Tried todays SVN revision 15830 and fails to start with assertion :failure: : :FATAL: Assertion failure in routing.c:767: "guid_is_gtkg(&guid_buf, NULL, NULL, NULL)" Can you show me the output of the following commands: grep ^guid ~/.gtk-gnutella/config_gnet grep _guid ~/.gtk-gnutella/config_gnet Thanks, Raphael ------------------------------ Message: 6 Date: Tue, 9 Sep 2008 09:59:43 +0300 (EEST) From: Meelis Roos <mroos@...> Subject: Re: [gtk-gnutella-devel] assertion failure in routing.c:767 To: gtk-gnutella-devel@... Message-ID: <Pine.SOC.4.64.0809090958420.453@...> Content-Type: TEXT/PLAIN; charset=US-ASCII > Can you show me the output of the following commands: > > grep ^guid ~/.gtk-gnutella/config_gnet guid = "703360e01265aa27f60c30797b3152a6" > grep _guid ~/.gtk-gnutella/config_gnet (nothing) 15381 does not fix it either. -- Meelis Roos (mroos@...) ------------------------------ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ------------------------------ _______________________________________________ gtk-gnutella-devel mailing list gtk-gnutella-devel@... https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel End of gtk-gnutella-devel Digest, Vol 25, Issue 1 ************************************************* |
| Free embeddable forum powered by Nabble | Forum Help |
