« Return to Thread: gtk-gnutella-devel Digest, Vol 25, Issue 1
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
*************************************************
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
*************************************************
« Return to Thread: gtk-gnutella-devel Digest, Vol 25, Issue 1
| Free embeddable forum powered by Nabble | Forum Help |
