gtk-gnutella-devel Digest, Vol 24, Issue 2

[gtk-gnutella-devel-request]

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:  DHT assert. (Raphael Manfredi)
   2.  Patch for Search Stats (Mitch Harder (aka DontPanic))
   3. Re:  Patch for Search Stats (Raphael Manfredi)
   4. Re:  Patch for Search Stats (Mitch Harder (aka DontPanic))
   5. Re:  Patch for Search Stats (Christian Biere)
   6.  Endian compile failure on PPC7450 (back from ignomy)
      (Matthew Lye)
   7. Re:  Patch for Search Stats (Mitch Harder (aka DontPanic))
   8. Re:  Endian compile failure on PPC7450 (back from ignomy)
      (Christian Biere)


----------------------------------------------------------------------

Message: 1
Date: Sat, 16 Aug 2008 21:55:15 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] DHT assert.
To: gtk-gnutella-devel@...
Message-ID: <g87ic3$s93$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Bill Pringlemeir <bpringle@...> from ml.softs.gtk-gnutella.devel:
:That certainly did seem to fix the problem.  Previously runs were only
:averaging 1/2 hour or less until an assertion.  With revision 15637, I
:was running for over 10 hours before an assertion [the trace is
:completely different].  I am not even sure it is DHT related; maybe it
:is a side effect?

It was a side effect of using DHT code... but it was a bug.

You triggered flow control on your UDP queue because of DHT traffic probably,
and the gnet stats code was not expecting to see a message with a TTL = 0.
However, DHT messages are special in that their header is a Gnutella one
but only for convenience.  They are not Gnutella but Kademlia messages and
the field used for TTL is actually a version number...

I've fixed the assertion in rev 15648, thanks for the stack trace!

Raphael



------------------------------

Message: 2
Date: Sat, 23 Aug 2008 18:10:27 -0500
From: "Mitch Harder (aka DontPanic)" <mmharder@...>
Subject: [gtk-gnutella-devel] Patch for Search Stats
To: gtk-gnutella-devel@...
Message-ID:
        <89ed0c690808231610s2b0db433t3cbfb953fe3a0b6d@...>
Content-Type: text/plain; charset="iso-8859-1"

I've been playing around with the Search Stats code, and I've gotten
it partially working.

I only had a chance so far to put together a patch for the gtk2
version of search_stats.c, and haven't looked at the gtk1 version yet.

I found the problem with CPU utilization was due to re-sorting the
list after each item was added to the list, even though the user
didn't see a sorted list until it was finished anyways.  I also found
a minor problem with the matching as search terms were added to the
hash table.

I have found a way to turn off sorting while the list is built.
However, I couldn't find an automatic way to turn sorting back on, so
the user has to click on a column header to sort the list.

There's also still a remaining issue with starting the sorting.  I
found that sorting did not start simply by selecting one of the
searchs.  I had to select a search, reset the stats, and then change
my selection for search type to activate search stats.

I am attaching a patch for the src/ui/gtk/gtk2/search_stats.c file
with the changes that worked for me.

I hope you find this useful.  Let me know if you see any problems, or
need something additional.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: search_stats_patch
Type: application/octet-stream
Size: 2725 bytes
Desc: not available

------------------------------

Message: 3
Date: Sun, 24 Aug 2008 08:34:06 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] Patch for Search Stats
To: gtk-gnutella-devel@...
Message-ID: <g8r6du$mu$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Hello Mitch,

Quoting "Mitch Harder" <mmharder@...> from ml.softs.gtk-gnutella.devel:
:I only had a chance so far to put together a patch for the gtk2
:version of search_stats.c, and haven't looked at the gtk1 version yet.

Thanks for contributing.

May I ask that you read the doc/devguide/STYLE document so that you submit
code that fits the overall style of gtk-gnutella?  This is extremely important.

On the patch itself, apparently you have not completely finished the task since
sorting is not re-enabled after being disabled.  Once everything works,
it will be added to the SVN repository.

You need to see whether the GTK1 version suffers from the same problems and
if yes, how it could also be fixed there.  Maybe it doesn't, as the internals
of the two GUIs can be different.

Thanks a lot,
Raphael



------------------------------

Message: 4
Date: Sun, 24 Aug 2008 12:20:48 -0500
From: "Mitch Harder (aka DontPanic)" <mmharder@...>
Subject: Re: [gtk-gnutella-devel] Patch for Search Stats
To: gtk-gnutella-devel <gtk-gnutella-devel@...>
Message-ID:
        <89ed0c690808241020n4cfba540sd26dcd4de029f82b@...>
Content-Type: text/plain; charset=ISO-8859-1

Thanks for taking the time to look at my patch.

Of the issues you listed, re-enabling the sort seems to be the trickiest.

For the GTK objects implemented, I was unable to locate GTK functions
to accomplish this result.  I considered writing some custom functions
to manipulate the GTK objects for those functions I couldn't find, but
I worry about adding those kind of functions which can get broken by
other changes the gtk developers make.

Let me know if your thoughts are different, or if you have a viewpoint
I have overlooked.



------------------------------

Message: 5
Date: Sun, 24 Aug 2008 20:14:22 +0200
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] Patch for Search Stats
To: gtk-gnutella-devel@...
Message-ID: <20080824181422.GB19643@cyclonus>
Content-Type: text/plain; charset=utf-8

Mitch Harder (aka DontPanic) wrote:
> Thanks for taking the time to look at my patch.
>
> Of the issues you listed, re-enabling the sort seems to be the trickiest.
>
> For the GTK objects implemented, I was unable to locate GTK functions
> to accomplish this result.  I considered writing some custom functions
> to manipulate the GTK objects for those functions I couldn't find, but
> I worry about adding those kind of functions which can get broken by
> other changes the gtk developers make.

Look for SORTABLE in these files:
src/ui/gtk/gtk2/fileinfo.c
src/ui/gtk/gtk2/search.c

--
Christian



------------------------------

Message: 6
Date: Sun, 24 Aug 2008 13:30:34 -0400
From: Matthew Lye <mlye@...>
Subject: [gtk-gnutella-devel] Endian compile failure on PPC7450 (back
        from ignomy)
To: gtk-gnutella-devel@...
Message-ID: <19D36C62-E98D-48FC-B5DF-07E8920D5526@...>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed;
        delsp=yes

Hey,

Putting the GUID debacle behind us.  Ahem.

I've been noticing this lately, so I ran build.sh for a 'clean' (un-
fiddled with) version of GTKG, and got the same error.  Basically, the  
__powerpc__ token isn't defined on my machine.  I don't know when or  
how in the compile this is supposed to happen, nor how to track it  
down, but I suspect that (a) gcc-darwin uses a different token for the  
processor or (b) this breaks compiles which are optimized for a  
particular PPC chip.  [This last point just occurred to me.]

For myself, I just threw in
> #define __powerppc__
right before the IEEE 754 check, and everything worked fine.

The error text:

> In file included from ./lib/host_addr.h:42,
>                  from core/ban.h:40,
>                  from main.c:41:
> ./lib/endian.h:223:2: error: #error "This architecture may be  
> unsupported. float must use IEEE 754."
> In file included from ./core/rx.h:41,
>                  from ./if/core/downloads.h:34,
>                  from ./if/core/fileinfo.h:31,
>                  from core/share.h:49,
>                  from core/fileinfo.h:40,
>                  from core/downloads.h:43,
>                  from core/dmesh.h:40,
>                  from main.c:47:
> ./lib/pmsg.h: In function ?pmsg_write_float_be?:
> ./lib/pmsg.h:392: warning: implicit declaration of function  
> ?poke_float_be32?
> ./lib/pmsg.h:392: warning: assignment makes pointer from integer  
> without a cast
> make[2]: *** [main.o] Error 1
> make[1]: *** [subdirs] Error 1
> make: *** [all] Error 2

- Matt



------------------------------

Message: 7
Date: Sun, 24 Aug 2008 13:30:55 -0500
From: "Mitch Harder (aka DontPanic)" <mmharder@...>
Subject: Re: [gtk-gnutella-devel] Patch for Search Stats
To: gtk-gnutella-devel@...
Message-ID:
        <89ed0c690808241130h1f92b2cetbd90355f76555cc2@...>
Content-Type: text/plain; charset=ISO-8859-1

Thanks, those look interesting.

Give me some time to look at implementing this the same way.

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



------------------------------

Message: 8
Date: Sun, 24 Aug 2008 21:24:28 +0200
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] Endian compile failure on PPC7450
        (back from ignomy)
To: gtk-gnutella-devel@...
Message-ID: <20080824192428.GC19643@cyclonus>
Content-Type: text/plain; charset=utf-8

Matthew Lye wrote:
> Hey,
>
> Putting the GUID debacle behind us.  Ahem.
>
> I've been noticing this lately, so I ran build.sh for a 'clean' (un-
> fiddled with) version of GTKG, and got the same error.  Basically, the  
> __powerpc__ token isn't defined on my machine.

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.

> I don't know when or  
> how in the compile this is supposed to happen, nor how to track it  
> down, but I suspect that (a) gcc-darwin uses a different token for the  
> processor or (b) this breaks compiles which are optimized for a  
> particular PPC chip.  [This last point just occurred to me.]
>
> For myself, I just threw in
> > #define __powerppc__
> right before the IEEE 754 check, and everything worked fine.

That's not recommendable.

--
Christian



------------------------------

-------------------------------------------------------------------------
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 24, Issue 2
*************************************************